TL;DR
Enterprise data analysis fails surprisingly often before the first formula is calculated. The business question is vague, the unit of analysis is unclear, a join multiplies records, the denominator changes between reports, a fiscal period is compared with a calendar period, or a sample is treated as though it represents the entire population. The resulting chart can be mathematically correct and still support the wrong decision.
A stronger operating model treats analysis as an evidence pipeline. Define the question, population, grain, metric, joins, filters, time boundaries, decision threshold, and permitted method before calculation. Profile the data before interpreting it. Separate observed results from explanation. Quantify uncertainty where statistical inference is used. Preserve enough logic, code, formulas, row counts, parameters, and source versions for another analyst to reproduce the result.
The Enterprise Data Analysis and Insight Generation prompt below turns those practices into an executable analysis contract. It is designed for spreadsheets, SQL extracts, operational metrics, surveys, financial data, customer data, service data, and other structured enterprise sources.
The key principle: a result is decision-ready only when the organization can explain what was measured, why the data was fit for that purpose, how the result was produced, what could invalidate it, and how another qualified analyst could reproduce it.
Introduction
Imagine an executive asks why service cost increased last quarter.
The analyst receives a finance extract, an operational usage table, and a customer dataset. A few hours later, the team has a polished chart showing a 17 percent increase in cost per customer. The numbers reconcile to the analyst’s workbook. The presentation looks convincing.
Then somebody asks what counts as a customer.
Finance used billed accounts. Operations used active tenants. The customer table contains one row per contract, not one row per organization. A many-to-many join duplicated several large accounts. One source uses fiscal quarters while another uses calendar months. Customers with missing activity records disappeared in an inner join.
Nothing about the arithmetic itself was necessarily wrong.
The analytical contract was wrong.
That distinction becomes more important as organizations place spreadsheets, SQL engines, Python notebooks, business intelligence platforms, and generative AI behind the same question. Faster analysis does not eliminate ambiguity. It can accelerate it.
The U.S. Government Accountability Office provides a useful way to frame the problem. Its data reliability guidance evaluates whether data is accurate, complete, and applicable for the intended purpose. Applicability matters because a dataset can be perfectly accurate about something that does not answer the question being asked.
The U.S. Census Bureau’s Statistical Quality Standard E1 takes a similar approach from the analysis side. It requires planning before analysis, including the purpose, research questions, data sources, variables, methodology, assumptions, limitations, and verification of computational accuracy.
That is the operating principle behind this prompt.
The objective is not to make every analysis academic, slow, or statistically sophisticated. It is to stop preventable analytical errors before they acquire the authority of a dashboard.
The Analysis Can Fail Before the First Calculation
Many organizations treat data quality as something checked after data has been loaded.
That is too late.
Before evaluating missing values or outliers, the analyst needs to know whether the available data can answer the business question at all.
Suppose leadership asks:
Did the new support process reduce customer resolution time?
A dataset containing only successfully closed tickets cannot establish what happened to abandoned, reopened, escalated, or still-open cases. A report containing only customers who remained active cannot reliably answer questions about churn. A monthly snapshot cannot necessarily reconstruct daily state transitions.
The first analytical gate is therefore not syntax.
It is answerability.
That gate should ask:
- What population does the decision concern?
- What population does the dataset actually represent?
- What is the unit of analysis?
- What outcome is being measured?
- What comparison is required?
- Does the available time window contain that comparison?
- Are the relevant exclusions observable?
- Are required relationships between sources available?
- Does the design support the type of conclusion being requested?
If the answer is no, the right output may be a data request rather than a metric.
That is a successful analytical outcome.
The Analytic Contract Comes Before the Tool
A defensible analysis begins by translating the business request into a specification.
The tool comes later.
| Contract element | Question it must answer | Failure it helps prevent |
|---|---|---|
| Population | Who or what is the conclusion about? | Generalizing beyond represented data |
| Unit of analysis | What does one analytical observation represent? | Mixing customers, transactions, devices, or days |
| Grain | What does one source row represent? | Double counting and invalid aggregation |
| Metric | What exactly is being measured? | Metric drift |
| Numerator | What events qualify? | Inconsistent counting |
| Denominator | What population is eligible? | Misleading rates and percentages |
| Time boundary | Which dates, time zones, and calendar rules apply? | Period mismatch |
| Comparison | What is the baseline, control, target, or prior period? | Unsupported improvement claims |
| Join logic | How are datasets related? | Row multiplication and population loss |
| Filters | What is included and excluded? | Hidden population changes |
| Method | What type of analysis is justified? | Statistical overengineering |
| Threshold | What result would change the decision? | Analysis without a decision boundary |
This is one of the places where AI-assisted analysis can become dangerous.
A model can write syntactically valid SQL for a poorly defined metric. It can calculate a percentage without knowing whether the denominator matches the business definition. It can produce an attractive explanation after a join silently doubles the population.
The prompt therefore makes definitions first-class inputs rather than details to infer.
Build a Data Readiness Gate
The workflow should stop when a blocking condition makes the requested conclusion unreliable.
What matters in the diagram below is that analysis does not automatically proceed from question to calculation. Data readiness is a control point, and insufficient evidence has an explicit exit path.
A mature analysis workflow should be comfortable returning:
- insufficient data,
- unresolved definition,
- unsupported causal question,
- unreliable join,
- inadequate sample,
- unknown population coverage,
- or a specific additional data requirement.
Those states are more useful than false precision.
Profile Before You Interpret
Exploratory data analysis exists for a reason.
The NIST/SEMATECH Engineering Statistics Handbook describes exploratory data analysis as a way to gain insight into a dataset, uncover structure, detect anomalies and outliers, examine assumptions, and identify useful relationships before prematurely locking into a model.
That philosophy translates well to enterprise analysis.
Before calculating the headline metric, establish the shape and reliability of the inputs.
At minimum, profile:
- record count
- column names and types
- expected and actual grain
- key uniqueness
- missing values
- duplicated records
- invalid categories
- impossible values
- minimum and maximum values
- date coverage
- future dates
- unit consistency
- currency consistency
- outliers
- segment coverage
- stale records
- contradictory records
The prompt classifies findings as blocking, material but manageable, or minor.
That classification matters.
A null middle name probably does not invalidate a server-availability analysis. Missing timestamps for 35 percent of incidents may invalidate a mean-time-to-restore calculation. Duplicate customer identifiers may be manageable for one aggregation and fatal for another.
“Data quality issue” is too broad to guide a decision.
The analyst should explain what the defect changes.
Grain Is One of the Most Dangerous Hidden Variables
A surprising number of analytical problems are grain problems wearing another name.
Consider three tables:
| Source | Grain |
|---|---|
| Customer | One row per customer |
| Contract | One row per contract |
| Invoice | One row per invoice line |
Joining all three tables on customer identifier can produce a valid SQL result and an invalid business population.
A customer with three contracts and 20 invoice lines can become 60 rows.
If the analyst then counts customers without returning to a distinct customer grain, the resulting metric is wrong even though every join technically succeeded.
The analysis workflow should therefore record expected row counts at major transformations.
For example:
Customer source: 48,215 rows After approved population: 46,902 rows Contract join: 46,902 customer entities Invoice detail expansion: 713,408 invoice-line rows Metric aggregation: 46,902 customer entities
If a supposedly one-to-one join changes 46,902 rows into 53,411 rows, that is not a cosmetic discrepancy.
It is a failed validation.
Join Validation Must Be Explicit
A join should answer more than whether the query executed.
For every material join, capture:
- left-side row count
- right-side row count
- distinct key count
- unmatched left keys
- unmatched right keys when relevant
- duplicate keys
- resulting row count
- expected cardinality
- actual cardinality
- records removed by join type
The analyst should know whether the intended relationship is:
1 : 1 1 : many many : 1 many : many
Many-to-many relationships are not inherently wrong. They become dangerous when the analysis treats their expanded result as though the original grain still exists.
The Denominator Is Often More Important Than the Numerator
Enterprise reporting tends to spend most of its attention on what happened.
The denominator defines who had the opportunity for it to happen.
A failure rate of 4 percent means little until the eligible population is defined. Churn can mean cancelled customers divided by opening customers, average customers, customers eligible for renewal, or accounts active during any part of the period.
Those are different metrics.
The prompt therefore asks for numerator and denominator separately.
That design forces questions such as:
- Are suspended accounts included?
- Are test transactions excluded?
- Does the denominator include customers without activity?
- Are failed records included in throughput?
- Do reopened tickets belong to the original period or current period?
- Does the rate use customers, contracts, transactions, or devices?
If two teams cannot agree on the denominator, they do not yet have one metric.
They have two business definitions sharing a label.
Time Is Part of the Definition
Time boundaries deserve the same discipline as joins.
An analysis should state:
- start date
- end date
- time zone
- inclusive or exclusive boundaries
- fiscal versus calendar period
- business-day rules
- treatment of partial periods
- event-time versus ingestion-time logic
- late-arriving data treatment
A service incident opened at 11:58 PM in Dallas and closed at 12:14 AM can belong to different dates depending on the system and reporting time zone.
A global platform can produce larger problems when source systems store local time inconsistently or timestamps without offsets.
Time-zone handling should never be inferred silently.
Separate Result from Interpretation
A strong analytical output contains four layers.
Suppose support resolution time decreased by 12 percent after a new workflow was introduced.
The result is the observed decrease.
The interpretation might be that the workflow contributed to faster handling.
The implication could be to continue the rollout while monitoring quality and escalation rates.
The limitation may be that staffing also increased, ticket mix changed, or the comparison used different seasonal periods.
Collapsing those four layers into one sentence turns association into certainty.
The prompt prevents that by requiring them separately.
Causality Is a Property of the Design
A dashboard does not create causality.
Neither does a regression coefficient, an attribution model, a sequence of events, or a convincing explanation generated by an AI model.
If the organization asks:
Did intervention X cause outcome Y?
the analyst needs to determine whether the available design supports causal inference.
In many enterprise datasets, the defensible answer will be narrower:
Outcome Y changed after intervention X, and the available observational data shows an association. Other plausible explanations remain.
That answer may still support a decision.
It is simply a different level of evidence.
The prompt therefore requires the analyst to identify a causal request before analysis and downgrade it to association when the data and design do not support causality.
That is evidence discipline, not excessive caution.
Statistical Sophistication Is Not the Objective
Advanced analysis has a place.
It should not be the default response to a simple question.
If leadership asks how many incidents exceeded the service-level objective last month, the correct method may be a deterministic filter and count.
A forecasting model is unnecessary.
If the organization wants to know whether two sampled populations differ meaningfully, statistical inference may be appropriate. In that case, the method needs to expose:
- sample size
- sampling design
- assumptions
- uncertainty
- practical effect size
- statistical significance where relevant
- multiple-testing risk
- limitations
The Census Bureau’s analysis standard explicitly connects statistical conclusions from sample data with appropriate measures of uncertainty.
The operating rule is straightforward:
Use the simplest method that can answer the decision question correctly. For external evidence that complements the dataset, apply the Enterprise Research and Evidence Synthesis workflow.
Complexity is not evidence.
Sensitivity Testing Protects the Decision
Many enterprise conclusions depend on choices that are reasonable but not uniquely correct.
For example:
- include or exclude partially active customers
- count an incident by open date or close date
- classify an outlier as an error or real event
- use mean or median
- treat missing values as excluded or unknown
- compare calendar months or matched business days
- use one customer definition or another approved definition
When one of those choices could change the decision, test it.
A useful result might say:
Under the approved definition, the failure rate is 3.8 percent. Including partially active devices increases it to 4.1 percent. Both remain below the 5 percent threshold, so the operational decision does not change.
That is stronger than hiding the assumption.
Sensitivity analysis tells the decision-maker whether the conclusion is robust.
Reproducibility Is Part of the Deliverable
The analysis is not complete when the chart renders.
Another qualified analyst should be able to reproduce the result using the same source state and definitions.
The Census Bureau’s data and document management standard explicitly connects retained data and documentation with transparency and reproducibility. Its examples include analysis plans, variable definitions, processing methodology, weighting and estimation methods, code, models, and quality measures.
An enterprise reproducibility package should capture the equivalent information appropriate to the task:
- source system
- extraction date
- source version or snapshot
- table or file names
- input record counts
- filters
- join logic
- formulas
- SQL
- code
- parameter values
- expected intermediate row counts
- missing-value treatment
- time-zone logic
- rounding rules
- output validation
- unresolved discrepancies
The objective is not archival perfection.
It is the ability to answer:
How did we get this number?
without reconstructing the analysis from memory.
Validation Should Be Independent of the Calculation Path
A query returning successfully proves that the database accepted the query.
It does not prove that the result is correct.
A spreadsheet recalculating without errors proves that formulas were evaluated.
It does not prove that the denominator is correct.
A Python script finishing proves that the process ran.
It does not establish that the source population was complete.
Validation should therefore include independent checks where practical.
Examples include:
- reconcile totals with source reports
- compare segment totals with overall totals
- re-run a key metric through a second method
- verify random records against the source
- check signs and units
- inspect percentage totals
- confirm date boundaries manually
- test joins using key counts
- compare expected and actual row counts
- review exceptional or high-impact records
When totals do not reconcile, expose the discrepancy.
Do not “fix” the report by quietly changing the analysis until the numbers match.
AI Can Accelerate Analysis Without Becoming the Authority
Generative AI can be extremely useful in this workflow.
It can help:
- translate a business question into an analytic specification
- draft SQL
- create Python or spreadsheet formulas
- identify candidate quality checks
- explain statistical methods
- propose visualizations
- summarize anomalies
- generate reproducibility documentation
- convert technical findings into executive language
It can also confidently invent missing context.
That makes the prompt boundary important.
An AI analyst should never silently invent:
- the meaning of a column
- the business definition of a metric
- a missing denominator
- a join relationship
- a sampling design
- a data owner
- a currency conversion
- an approved threshold
- an execution result
If it has not actually executed code or queried the source, it must not claim that it did.
NIST’s AI Risk Management Framework is useful at this boundary because it treats AI risk management as an operational discipline spanning the design, use, and evaluation of AI systems rather than as a model-only concern.
For enterprise analytics, the practical implication is simple: use AI to accelerate the analytical process, but keep definitions, data authority, execution evidence, access control, and decision ownership outside the model.
The Seven-Stage Analysis Operating Loop
The prompt organizes the work into seven stages.
Translate the Question
Turn the business request into a testable specification.
Define the population, grain, outcome, comparison, segments, time period, precision, threshold, method, and known exclusions.
This is where vague requests become analytical work.
Validate Access and Structure
Confirm what data actually exists.
Inspect sources, tables, sheets, fields, types, row counts, key validity, dates, sensitive fields, freshness, and joins.
A source that cannot be read is not an input.
A field that does not exist is not an assumption.
Profile Data Quality
Inspect the data before using it to support a conclusion.
Classify material defects and determine whether they prevent the requested analysis.
Execute the Simplest Sufficient Analysis
Establish baseline counts first.
Calculate the primary metric using the approved definition.
Only then add comparisons, segments, sensitivity analysis, uncertainty, and anomaly investigation.
Interpret for the Decision
Explain what the data shows, what might explain it, what action is reasonable, and what uncertainty remains.
Do not equate movement with improvement.
Make the Work Reproducible
Preserve the logic and parameters necessary for another analyst to recreate the result.
Verify and Monitor
Reconcile the result and define how the metric will be refreshed, monitored, and owned.
This turns a one-time analysis into an operational measurement when the business needs one.
Copy-Ready Enterprise Data Analysis Prompt
The following Version 2.0 prompt packages the operating model into a reusable instruction set.
ROLE You are a senior enterprise data analyst. Analyze the supplied data to answer the stated business question. Make the work reproducible, preserve business definitions, distinguish observed results from interpretation, and explain any limitation that could change the decision. BUSINESS QUESTION [State the exact question the data should answer] DECISION CONTEXT - Intended audience: [Audience] - Decision or action supported: [Decision] - Business owner: [Owner] - Data owner: [Owner] - Deadline or reporting period: [Date or period] - Cost of an incorrect conclusion: [Impact] - Required output: [Analysis, dashboard specification, report, table, chart, forecast, SQL, code, or other] DATA SCOPE - Data sources: [Files, tables, systems, APIs, surveys, or other] - Authorized purpose: [Approved use] - Data classification: [Public, internal, confidential, personal, customer, regulated, or organization-specific class] - Unit of analysis: [Customer, transaction, order, system, employee, site, device, day, incident, or other] - Population: [Who or what is represented] - Time period: [Start and end] - Time zone and calendar rules: [Time zone, fiscal calendar, business day definition] - Grain: [One row per what] - Primary key or expected uniqueness: [Fields] - Relevant tables and joins: [Relationships] - Required filters and exclusions: [Rules] - Known sampling method: [Method or unknown] - Known data limitations: [Limitations] BUSINESS DEFINITIONS - Target metric: [Metric and definition] - Numerator: [Definition] - Denominator: [Definition] - Dimensions and segments: [Fields and definitions] - Baseline: [Current value or comparison period] - Target or threshold: [Target, SLO, budget, benchmark] - Currency and conversion rules: [Rules] - Units: [Units] - Status definitions: [Active, complete, failed, churned, qualified, or other] - Required calculations: [Calculations] - Approved external benchmarks: [Sources or none] ANALYTIC BOUNDARY - Permitted methods: [Descriptive, diagnostic, statistical, forecasting, machine learning, or other] - Prohibited fields or uses: [Fields or decisions] - Sensitive groups requiring protection: [Groups] - Minimum aggregation or suppression rule: [Rule] - Tool availability: [Spreadsheet, SQL, Python, BI tool, calculator, none, or other] - Execution authorization: [Analyze only, execute read-only queries, create code, or other] NONNEGOTIABLE DATA RULES 1. Determine whether the available data can answer the business question before calculating results. 2. Preserve source definitions. Do not silently redefine a metric, population, time period, or denominator to fit available data. 3. Separate: - Source-supplied field - Derived field - Reported metric - Calculated result - Estimate - Forecast - Assumption - Interpretation 4. Profile the data before substantive analysis. Check schema, record count, uniqueness, missingness, duplicates, invalid categories, range, date coverage, units, impossible values, and outliers. 5. Validate joins. Report unmatched keys, many-to-many expansion, duplicate amplification, and any population loss caused by joining. 6. State all filters, exclusions, grouping logic, denominator choices, date boundaries, time-zone handling, currency treatment, and missing-value treatment. 7. Use the simplest method capable of answering the question. Do not apply advanced statistics or machine learning when a deterministic calculation, SQL query, or descriptive analysis is sufficient. 8. When statistical inference is used, state method, sample size, assumptions, uncertainty, practical significance, and limitations. 9. Do not imply causation from correlation, sequence, attribution models, or observational patterns unless the design supports causal inference. 10. Check relevant risks such as selection bias, survivorship bias, nonresponse bias, label leakage, target leakage, class imbalance, seasonality, cohort effects, distribution shift, Simpson's paradox, small segments, and multiple testing. 11. Do not combine roles, survey categories, customer segments, currencies, units, or time periods without a stated and defensible method. 12. Protect confidential, personal, customer, regulated, and security-sensitive data. Aggregate, mask, suppress, or omit row-level detail unless it is essential and authorized. 13. Do not use sensitive attributes or proxies for prohibited decisions. Flag potential fairness or discrimination concerns. 14. If code or queries are produced, include validation, safe parameterization, deterministic logic where appropriate, and instructions to reproduce the result. 15. Do not claim that code ran, a query executed, a workbook recalculated, or a result was validated unless that action was observed. 16. If the data is insufficient, identify the smallest additional data request or definition decision that would resolve the limitation. ANALYSIS WORKFLOW Stage 1: Translate the question into an analytic specification Define: - Target population - Unit of analysis - Outcome or metric - Comparison or baseline - Segments - Time period - Required precision - Decision threshold - Acceptable method - Known confounders or exclusions Restate the question in a testable form. If the request is causal but the data supports only association, say so before analysis. Stage 2: Validate data access and structure For each source determine: - Availability and readability - Table or sheet names - Column names and data types - Record count - Expected versus actual grain - Primary-key validity - Date coverage - Sensitive fields - Source owner and freshness - Join keys and referential integrity Identify whether any source is a sample, snapshot, partial extract, or transformed dataset. Stage 3: Profile data quality Produce checks for: - Missing values by field and segment - Duplicate records and duplicate keys - Invalid or unexpected categories - Out-of-range and impossible values - Unit and format inconsistencies - Date gaps and future dates - Outliers and whether they are errors or real events - Join loss or multiplication - Coverage differences among segments - Potential leakage - Stale or conflicting records Classify issues as blocking, material but manageable, or minor. Stage 4: Execute the analysis Use an ordered method: 1. Establish baseline counts and totals. 2. Calculate the primary metric using the approved definition. 3. Compare against the baseline, target, or control. 4. Segment results only where sample and definition support it. 5. Test alternative reasonable assumptions when they could change the conclusion. 6. Investigate material anomalies. 7. Quantify uncertainty where appropriate. 8. Check whether the result is robust to filters, date boundaries, and denominator choices. Stage 5: Interpret for the business decision Separate the result from its meaning: - Result: what the data shows. - Interpretation: what may explain the result. - Implication: what the organization may reasonably do. - Limitation: why the conclusion could be wrong or incomplete. Do not recommend action solely because a metric moved. Consider materiality, operational feasibility, cost, risk, and alternative explanations. Stage 6: Make the work reproducible Provide, as applicable: - Formula definitions - SQL query - Code - Spreadsheet formulas - Filter list - Join logic - Parameter values - Data version or extraction date - Expected row counts at major steps - Validation checks Stage 7: Verify the result Reconcile totals to source data where possible. Check units, signs, percentages, denominators, date windows, rounding, and segment totals. If totals do not reconcile, report the discrepancy rather than hiding it. REQUIRED OUTPUT 1. Direct answer - Answer the business question in one concise section. 2. Data scope and quality - Sources, period, population, grain, record count, freshness, and material quality findings. 3. Method - Metric definitions, formulas, joins, filters, exclusions, missing-value handling, and assumptions. 4. Results - Table containing metric, value, unit, period, population or sample size, comparison value, absolute change, relative change, and status against threshold. 5. Segment and anomaly findings - Include only material differences with adequate support. 6. Interpretation - Separate measured results from supported explanations and hypotheses. 7. Business implications - Recommended action, owner, expected effect, and monitoring measure when supported. 8. Limitations and sensitivity - Material data gaps, definition risks, alternative assumptions, uncertainty, and what would change the conclusion. 9. Reproducibility package - Queries, formulas, code, parameters, or procedural steps requested. 10. Validation and monitoring - Independent check, reconciliation, refresh frequency, alert threshold, and owner. VISUALIZATION RULES - Use a table for exact values and mappings. - Use a line chart for time trends. - Use a bar chart for categorical comparison. - Use a distribution plot for spread and outliers. - Use a scatter plot only when a relationship between two numeric variables matters. - Label axes, units, period, filters, and source. - Do not truncate axes or use visual scaling that exaggerates differences without clear justification. - Do not include a chart when prose or a small table is clearer. FINAL QUALITY GATE Confirm that the population, grain, metric definition, denominator, units, period, and filters match the question; calculated and supplied values are distinguishable; sensitive data is protected; and the recommendation is proportional to the evidence.
Use the Prompt as a Contract, Not a Form to Complete Blindly
A prompt this detailed can become bureaucratic if every field is treated as mandatory for every question.
That is not the intent.
A simple descriptive analysis might need only:
- exact business question
- source
- population
- grain
- period
- metric
- numerator and denominator
- filters
- comparison
- output format
- tool authorization
A high-stakes financial, customer, workforce, regulated, or statistical analysis may need almost every control.
The depth should follow the consequence of being wrong.
The important requirement is that omitted fields are omitted consciously rather than guessed silently.
Use the Smallest Additional Data Request
One of the strongest controls in the prompt is also one of the simplest:
If the data is insufficient, identify the smallest additional data request or definition decision that would resolve the limitation.
Analysts often respond to uncertainty by asking for everything.
That creates delay and expands data exposure.
A better approach is precise.
Instead of:
I need the full CRM database.
ask:
I need the customer identifier, account status at quarter start, cancellation date, and approved churn definition for the same population represented in the billing extract.
Instead of:
I need more historical data.
ask:
I need the same metric for the preceding 13 complete weeks so the requested period can be compared with a like-for-like baseline.
This keeps the analysis moving while reducing unnecessary access.
Common Failure Modes This Prompt Is Designed to Stop
Metric Drift
The requested metric cannot be calculated from the available fields, so the analyst quietly substitutes a similar one.
Do not.
Expose the gap.
Join Multiplication
Two tables join successfully, but duplicate keys increase the population.
Validate cardinality and row counts.
Denominator Substitution
The numerator is available but the approved eligible population is not, so the analyst divides by a convenient total.
That produces a different metric.
Chart-First Analysis
The team begins with visualization instead of analytical specification.
A chart cannot repair an undefined population.
Statistical Theater
A sophisticated model is used where a deterministic count or comparison would answer the question.
Complexity can hide assumptions instead of improving evidence.
Causal Overreach
An event happened after a change, so the change is declared the cause.
Sequence is evidence worth investigating. It is not automatically causal evidence.
Privacy Expansion
Row-level personal or customer data is exposed because it is convenient for analysis even though aggregate data would answer the question.
Purpose and authorization should define the access boundary.
Fabricated Execution
An AI-generated query or workbook formula is described as tested despite never being run.
Code generation and code execution are different facts.
Irreproducible Insight
The final slide contains the number but not the filters, version, query, denominator, or source state that produced it.
That is a presentation, not a reproducible analysis.
What Decision-Ready Analysis Looks Like
A good enterprise analysis does not end with “the metric increased.”
It tells the decision-maker:
What happened: the measured result.
Compared with what: baseline, target, control, or prior period.
For whom: population and sample.
Under which definition: grain, numerator, denominator, units, and filters.
With what confidence: uncertainty and data-quality limitations.
What might explain it: supported interpretation and competing hypotheses.
What action is reasonable: proportional to the evidence and operational context.
What could change the answer: sensitivity and unresolved gaps.
How to reproduce it: query, code, formula, parameters, source state, and validation.
How it will be monitored: owner, refresh cycle, threshold, and escalation.
That is the difference between an interesting finding and an enterprise decision artifact.
Conclusion
Enterprise data analysis should be engineered around the decision, not around the analytical tool.
Start by defining the population, grain, metric, denominator, time period, comparison, and threshold. Determine whether the available data can actually answer the question. Profile it before interpreting it. Validate every material join. Use the simplest sufficient method. Keep observed results separate from explanations. Quantify uncertainty when the method requires it. Preserve enough evidence for another analyst to reproduce the result.
AI can make this workflow faster. SQL, Python, spreadsheets, and business intelligence platforms can make it more scalable. Neither changes the evidence standard.
The operating question is simpler:
Could another qualified analyst take the same source state and definitions, reproduce the result, explain its limitations, and reach the same decision boundary?
If the answer is no, the analysis still has work to do.
Continue the Enterprise Prompt Workflows
Follow the companion reading path in the Enterprise AI Strategy and Architecture hub, or explore the Advanced AI Business Prompts library.
Next: Executive Decision Brief: A Prompt Framework for Defensible Recommendations.
External References
- U.S. Government Accountability Office: Assessing Data Reliability (Supersedes GAO-09-680G)
- U.S. Census Bureau: Statistical Quality Standard E1: Analyzing Data
- U.S. Census Bureau: Statistical Quality Standard S2: Managing Data and Documents
- National Institute of Standards and Technology: Exploratory Data Analysis
- National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
Turn business outcomes into an architecture that can be evaluated and operated. This prompt connects requirements, constraints, alternatives, trust boundaries, failure behavior,...