A cited analytics-agent answer can still be numerically wrong

A citation answers only one question

Analytics-agent interfaces increasingly expose sources, traces and charts. Those are useful, but they prove different things. Google says its Conversational Analytics API can attach citations that link response text to context sources such as glossary terms or example queries. Qlik similarly lets users inspect content used as a source. Neither mechanism, by itself, establishes that the agent selected the intended business metric or generated the right query.

That distinction matters because the computation happens after retrieval. Google’s architecture gives agents SQL and Python tools; its chart pipeline can then pass a data result to a subagent that executes Python and may apply aggregations or filters before returning Vega-Lite JSON or an SVG. A citation to a glossary can be perfectly accurate while the query or downstream transformation is not.

The semantic model is part of the calculation

Microsoft’s Fabric guidance makes the dependency explicit. For Power BI semantic models, the data agent selects a source, generates DAX from schema and metadata, executes it, and formats the result. Microsoft warns that ambiguous fields can cause the generator to choose the wrong measure—for example, Gross Sales where the organization means Net Sales.

Fabric’s “verified answers” are also narrower than their name may suggest. Microsoft says they use approved question-and-visual configurations to guide later DAX generation; the agent still generates a new response rather than returning the approved visual itself. They are grounding aids, not a cryptographic certificate attached to every number.

Qlik’s documentation draws a similar operational boundary. Its guardrails scan for prompt injection, sanitize personal information and secrets, and test contextual relevance. Qlik still says users are responsible for reviewing and verifying generated output before using or sharing it.

What to test instead

A practical acceptance test should separate four layers:

1. Context provenance: Did the cited glossary, example or document actually support the interpretation?
2. Metric and grain: Did the agent choose the organization’s intended measure, population, date window and aggregation level?
3. Executable artifact: Does the generated SQL or DAX implement that interpretation, and does it return the expected rows?
4. Presentation: Did any Python, filtering, aggregation or chart specification alter the result correctly?

Google’s Prism framework illustrates the difference. It supports text and query checks, plus data assertions such as expected rows and row counts. A source-link check belongs beside those tests, not in place of them.

The buying question is therefore not “Does the answer have citations?” It is “Which stage does each piece of evidence validate?” A trustworthy interface should let reviewers connect the source context to the metric choice, query, returned data and final presentation. Citations improve auditability. They do not collapse that chain into proof of correctness.