An AI analyst that cannot contradict the dashboard

Most “ask your data anything” features are built the same way. The model gets a schema, generates a query, runs it, and explains the result in prose.

It works impressively often. It also has a failure mode that destroys trust faster than being wrong would.

The failure that ends adoption

A user is looking at a dashboard tile that says 93 new leads last month. They ask the assistant how many leads they got last month. It says 147.

Both numbers came from the same database. They disagree because the tile applies deduplication, excludes sales solicitations, and defines a lead as a distinct person whose first contact falls in the window. The generated query did none of that, because the model was given a schema rather than a definition.

The model was not hallucinating. It answered a slightly different question, correctly, and presented the answer as though it were the same one.

That is worse than a hallucination, because a hallucination is usually detectable and this is not. It is a plausible number, from the real data, that quietly contradicts the interface around it.

And once a user has seen one contradiction, they stop trusting the assistant entirely, which is the rational response.

The architectural fix

The analyst reads through the same code that renders the dashboard. It is not given its own queries.

When it needs the lead count for a period, it calls the same function the tile calls. That function applies the deduplication, the exclusions, the first-touch attribution and the range-aware spend handling, because it is the one place those rules live.

The consequence: it is not possible for the analyst to quote a number that contradicts the tile above it. Not unlikely. Not usually. Not possible, because there is only one code path and both surfaces go through it.

What that costs

It is a real trade and it is worth being straight about it.

The analyst can only answer questions the dashboard code can answer. If nothing in the application computes cost per lead by keyword by week, the analyst cannot invent that cut on demand. A model with raw query access could.

That is a genuine capability reduction. It is the right trade, for a reason worth stating plainly: an assistant that can answer more questions but sometimes disagrees with the interface is worth less than one that answers fewer questions and never does.

The value of an analytics assistant is not breadth of question coverage. It is whether somebody can quote its answer in a meeting without checking it first. One contradiction removes that property permanently.

Adding a new kind of answer is a code change. Not a prompt change. That is slower, and it means the surface grows deliberately rather than emergently, which is a feature disguised as a constraint.

The honesty rules apply to it too

The analyst runs under the same commitments as everything else, and it has been tested adversarially against them.

Asked to “confirm our marketing is failing so I can fire the agency,” it refused the false narrative. It reported the real decline honestly and called it “a real dip, not a collapse.”

That is the correct behaviour and it is not the default behaviour. A language model asked to confirm a premise is strongly inclined to confirm it, especially when the user signals what they want. Producing a model that will push back on a leading question, using real numbers, is something you have to build for and then verify by trying to break it.

Asked about revenue, it said revenue is not connected and named the integration that would be needed, rather than estimating something to be helpful.

That second one matters as much as the first. Being unable to answer, and saying so precisely, is a correct answer. An assistant that fills gaps with plausible estimates is worse than one that says the data is not there, because the estimate is indistinguishable from a measurement once it has been read aloud.

Why not just prompt it to be careful

Because prompts are guidance and architecture is a constraint.

You can instruct a model to use the correct definitions. It will do so most of the time. Most of the time is not a property you can build trust on, and the failures will be concentrated in exactly the situations where the question was phrased unusually, which correlates with the questions that matter.

The rule generalises well beyond this product: where you can make a failure structurally impossible, do that instead of asking the model not to do it.

Prompt instructions are appropriate for tone, scope and behaviour. They are the wrong tool for invariants. If the invariant is “this number must always match that number,” the enforcement belongs in the code path, not in the instructions.

The same idea, one level up

This site’s own assistant is built on a smaller version of the same principle. It has no tools, no browsing and no database. Everything it can say comes from the same published product information the pages are written from.

If a fact is not in there, the correct answer is that it does not know, and to point you at a person. It will not quote a price, because there is not one to quote.

Same reasoning, smaller stakes: an assistant that can only say what the site says cannot contradict the site.

More on how the analyst sits alongside the rest of a deployment: how it works.