Why grounded answers don't invent numbers

Ungrounded · the model produces the number

• Question→
• Modelanswers from memory→
• "About 400 orders"plausible, unverifiable

• Nothing was looked up
• Confident wording, invented figure
• No way to check it

Grounded · the index produces the number

• Question→
• Modelpicks collection, fields, facets→
• Indexcomputes: North 395→
• Modelwrites it up

• Every figure came from the index
• The same 395 a dashboard shows
• Unmappable question: it says so

The failure everyone fears

Ask a general-purpose model how many orders a company took last month and it will tell you. It will tell you with the confidence of a colleague who checked, in a well-formed sentence, with a number that looks right. It did not check. "About 400 orders," it will say, and 400 is not a count of anything; it is the most plausible continuation of the question, and plausibility is the one property a business number must never have instead of truth. Every team that has tried a chatbot over its data has met this moment, and it is the reason "AI over business data" is greeted with suspicion.

Where a grounded number comes from

1. Question"Orders by region this month"
2. MapThe model chooses from the vocabulary it was given.orders · facet region
3. ComputeThe index counts the records. The model is not involved.North 395 · West 247 · East 168 · South 142
4. WriteThe model phrases the result it was handed, numbers unchanged."North leads by a wide margin"
5. RefuseA question with no mapping gets a question back, not a guess."Which field do you mean?"

A grounded assistant removes the model from the path the number travels. The model reads the question and chooses - this collection, this field, this filter, this facet - from a vocabulary it was given. The index runs that request and computes the result: North 395 · West 247 · East 168 · South 142, counted from the records, the same way a dashboard would count them. The model then writes the sentence around figures it was handed and may not change. Every number in the answer has a source that can be pointed to, and that source is never the model.

What the model is not allowed to do

Three prohibitions make the design hold. No arithmetic. The model does not add, average or compare; if the question needs a total, the request asks the index for a stat facet and the total comes back computed. No free queries. The model does not write SQL or anything like it; it fills in a request from a constrained vocabulary, so it can only ask for things that exist. No filling gaps. If the question names a field the data does not have, or a period with no records, the assistant says so. A model that may invent a value to complete an answer will do so exactly when it is least wanted.

The refusal is a feature

"Which field do you mean by growth?" is a better answer than a number, because it is the true state of affairs: the question did not map. Grounding makes refusal possible, because the request either compiles against the vocabulary or it does not, and a request that does not compile has nowhere to get a number from. In a demo, ask something the data cannot answer and watch what happens. A grounded assistant asks back or says nothing matches. An ungrounded one answers.

What grounding does not fix

It does not make a badly mapped question right. If the model chooses the ship date when you meant the order date, the number is exact and the question was wrong. The protection here is visibility: the request names the field, so the mapping can be seen and corrected in a follow-up. It does not make stale data current; the answer is as of the last import, and a good assistant says so. And it does not stop a wrong question from getting a right answer. What it guarantees is narrower and more important: the figures in the answer are the figures in the data.

One more benefit is easy to overlook: a grounded assistant is auditable. Every answer corresponds to a request that can be logged - which collection, which filters, which facets, when - and replayed. If a number in a board pack came from the assistant, the request that produced it can be found and rerun. An answer written from a model's memory has no such trail, because there was nothing to trace.

Why this matters for trust

A dashboard is trusted because its numbers can be traced to definitions and records. A grounded assistant inherits that trust because its numbers come from the same place, by the same route, and agree with the dashboard to the unit. That agreement is checkable in a minute - ask the assistant for orders by region and compare it with the widget - and it is the check to run before anyone relies on either. Three ways AI answers from your data compares this approach with the two that let the model closer to the numbers.

Related

PILLAR How can AI answer questions about business data? The model does not read your database. It turns your question into a structured query, runs it against indexed data, and writes up the result. The numbers come from the index; the words come from the model. COMPARISON Three ways AI answers from your data: RAG, text-to-SQL and indexed retrieval "Is this RAG?" usually means "are the numbers right and is my data safe?" Three approaches, three different answers to that. EXPLAINER What the LLM sees Not your database, not your index, not your collections. The question, the names it needs to map it, and the result it writes up. That is the list.