ChatGPT Data Agent can connect enterprise data, investigate questions, and build interactive dashboards. The adoption gate is whether each important number can be traced and reproduced, not whether the chart looks convincing. This article proposes a verifiable analytics contract from business question to source, query, result, chart, refresh, and approved action.
Reading time: 8 minutes · About 1,650 words
TL;DR
- Data lineage routes evidence; independent checks establish confidence.
- Verify one analytical claim at a time, from metric definition and source snapshot through query, result, and chart.
- Use deterministic tools for calculations and tests, while the agent handles exploration, interpretation, and exception discovery.
- Lower the stated confidence when freshness, lineage, semantics, or validation is incomplete.
- Treat dashboard publication and external actions as separate approval gates.
What OpenAI has confirmed
OpenAI introduced the Data Agent in ChatGPT Work on September 10, 2026. The product can connect to approved sources such as Amazon Redshift, Google BigQuery, ClickHouse, Databricks, MongoDB, and Snowflake. It can also use files and documents from Google Drive and SharePoint.
OpenAI says the agent can use business terms, metric definitions, custom calculations, relationships, semantic layers, and existing BI context. It can build interactive dashboards that teams edit, share, and refresh, and it can work with Omni, Oracle BI, Power BI, Sigma, Tableau, and ThoughtSpot.
The authority boundary is equally important. Administrators choose available connections and eligible roles. Queries enforce the connected account's existing table, row, and column permissions. Users can review evidence behind findings, and actions through connected tools require approval.
Those statements establish a strong product baseline. They do not establish that the public product exposes complete generated SQL, query plans, row-level provenance, immutable snapshots, or deterministic replay for every dashboard cell. The contract below is an acceptance framework for buyers and builders, not a description of features OpenAI has already promised.
Lineage routes evidence; validation tests it
Data lineage answers where data came from and how it moved. It can identify an upstream table, transformation, semantic definition, or dashboard dependency. That is valuable for impact analysis and debugging.
Correctness requires additional questions:
- Did the agent choose the intended business metric?
- Was the source fresh enough for the decision?
- Did a many-to-many join multiply revenue?
- Were nulls, refunds, time zones, and excluded users handled correctly?
- Does another query or trusted report produce the same material result?
- Did the chart preserve the meaning of the result set?
This is the distinction between traceable and validated. A complete path to the wrong query remains a complete explanation of an error. Trust begins when the path can be replayed and checked.
The analytical claim is the verification unit
Treat each material claim as a small build artifact. A statement such as weekly net revenue fell 8.2% should carry an answer receipt:
question: Why did weekly net revenue fall?
claim: Net revenue fell 8.2%, mainly in returning customers.
metric_definition: net_revenue@v12
source_snapshot: warehouse://revenue_agg/2026-09-10T00:00:00Z
semantic_layer: finance_metrics@2026-09-09
query_hash: sha256:7d5...
result_artifact: notebook://analysis/turn-184/result-3
checks:
freshness: pass
join_cardinality: pass
null_rate: warning
independent_recalculation: pass
evidence_level: 3
dashboard: powerbi://workspace/report/page
approved_action: null
The exact schema can vary. The record should preserve enough information to answer seven questions:
- What business question was asked?
- Which metric definition and semantic version were used?
- Which source and time snapshot supplied the data?
- Which query or transformation produced the result?
- Which checks passed, warned, or failed?
- Which chart and refresh run present the result?
- Which person or policy approved publication or action?
Use a five-level evidence ladder
Conclusion strength should follow evidence strength. A practical ladder is:
| Level | Evidence | Allowed claim |
|---|---|---|
| 1. Discovery | Candidate table or document found | Possible source worth inspecting |
| 2. Replayable | Query, notebook, or transformation saved | Result can be reproduced on the same input |
| 3. Checked | Freshness, null, join, range, and invariant checks pass | Result meets defined technical rules |
| 4. Confirmed | Independent query, trusted report, or domain owner agrees | Material result has a separate confirmation path |
| 5. Controlled | Versioned dashboard or approved action records the claim | Result entered a governed business workflow |
Lineage usually helps with Levels 1 and 2. It does not automatically satisfy Levels 3 through 5. When a semantic definition conflicts, a table is stale, or lineage has gaps, the agent should lower the evidence level and surface the reason.
Fluent language must never hide a weak evidence state. A useful answer can say the leading hypothesis is supported by a replayable query, while independent confirmation is still pending.
Separate deterministic work from agent judgment
The agent is well suited to selecting investigative paths, proposing explanations, finding anomalies, and asking the next question. Deterministic systems are better for arithmetic, schema checks, invariants, comparison, and repeat execution.
A robust loop looks like this:
business question
-> agent selects sources and proposes a plan
-> query engine executes saved transformations
-> validators test freshness, joins, nulls, ranges, and totals
-> agent interprets checked results and states assumptions
-> independent path confirms material claims
-> dashboard publisher records the approved version
This division preserves flexibility without turning correctness into a style judgment.
OpenAI's internal system shows the building blocks
The January 2026 engineering article, Inside OpenAI's in-house data agent, describes six context layers: schema and table usage, human annotations, Codex-derived code context, institutional knowledge, memory, and live runtime context.
The internal system uses upstream and downstream table lineage, historical queries, source code, update frequency, business caveats, and live warehouse checks. It also evaluates generated SQL against manually authored golden SQL and compares the resulting data, not just the text of the query. Answers link to underlying results so users can inspect them.
That is strong first-party evidence for the architecture pattern. The article explicitly described an internal-only system at publication. The later public product builds on capabilities OpenAI uses internally, while the two surfaces should not be assumed to match feature for feature.
Verify every dashboard refresh
A dashboard is a repeated analytical claim. Each refresh can change the source data, semantic model, query engine, permissions, and generated transformation.
For every refresh, record:
- source freshness and snapshot time;
- semantic and metric-definition versions;
- query or transformation hash;
- row count, null rate, join cardinality, and key invariants;
- material differences from the previous accepted result;
- permission context used to produce the view;
- reviewer or automated gate that accepted publication.
Alert on unexpected change, not merely job failure. A refresh that completes successfully with half the expected rows is a business failure wearing a green infrastructure status.
Visualization checks remain a separate layer. The existing Flint chart contract covers semantic assignments, invariants, and rendered output. The analytics contract here starts earlier, at source and metric definition, and continues later, through refresh and approved action.
Put an approval boundary between insight and action
The Data Agent announcement says findings can be shared through Slack or email and actions can be carried out through connected tools after approval. That creates a critical boundary.
An analysis can be exploratory while an external action changes business state. Require a separate action receipt containing the supporting claim ID, current evidence level, target object, proposed change, requester, approver, and read-after-write result.
Existing permissions prove that an identity may access data or perform an action. They do not prove that the selected metric, customer, campaign, or amount is correct. The Admin Plugin control-plane pattern applies here: authorization and correctness need separate evidence.
Acceptance tests before rollout
Freeze a set of representative business questions, including known failures. Measure:
- correct source-selection rate;
- result agreement with an independent calculation;
- lineage and receipt completeness;
- stale-data and bad-join detection;
- confidence calibration when evidence is incomplete;
- dashboard refresh regression rate;
- permission-denial accuracy;
- human review time and cost per accepted claim.
Include adversarial cases: similar table names, changing metric definitions, many-to-many joins, late-arriving data, revoked access, partial connector failure, and a dashboard whose previous result was wrong.
FAQ
Does ChatGPT Data Agent provide data lineage?
OpenAI's product page says it uses data relationships, semantic layers, and trusted context. OpenAI's internal system uses table lineage. The public page does not specify a complete lineage UI or machine-readable column-level provenance for every result.
Can users inspect the SQL behind every answer?
The product page says users can review evidence behind findings. It does not promise that complete SQL, query plans, and parameters are exposed for every connector and dashboard. Treat that as a deployment question to verify.
Why is lineage insufficient for correctness?
Lineage locates sources and transformations. Correctness also depends on metric meaning, freshness, joins, filters, null handling, calculations, statistical interpretation, and chart semantics.
How should a team validate an AI-generated dashboard?
Save the source snapshot, metric and semantic versions, query hash, result artifact, checks, permission context, and refresh run. Compare important numbers through an independent calculation before controlled publication.
Build the receipt before scaling the agent
ChatGPT Data Agent reduces the friction between a business question and a working analysis. Scale should follow the evidence interface. When each claim has a replayable receipt, confidence can rise or fall with observable facts, errors can be localized, and dashboards can evolve without losing their history.
Next action: choose ten recurring business questions and define the answer receipt before expanding access. Run the same questions through the current analyst workflow and the Data Agent, then compare accepted claims, review time, refresh stability, and evidence completeness.
References
- OpenAI. Now everyone can put data to work, September 10, 2026.
- OpenAI. Inside OpenAI's in-house data agent, January 29, 2026.