The assistant writes the query, not the number

A language model that holds your figures can change them. It does not do this often, and that is the problem. A system that is wrong once in fifty answers is harder to catch than a system that is wrong every time.

The answer is not a better model. The answer is to keep the model away from the values. This page describes how that works.

How can an assistant answer with data it cannot see?

The assistant writes the query. It does not write the result.

1. You ask a question in plain language.
2. The assistant writes a query: a table, a set of filters, a measure.
3. The platform runs that query against your system, through your own connection.
4. The platform renders the rows it received as a block: a table, a value, a chart or a set of statistics.
5. The platform tells the assistant what came back: the fields, the row count and a small sample of the first rows. The sample shows the shape; a large result never reaches the model in full. When the question needs a difference or a total, the assistant asks for it in the query, the platform computes it on the rows, and that result comes back.
6. The assistant writes the sentence around the block.

The figures you read came out of your database and passed through nothing that could change them. The assistant chose what to ask for and how to describe it. It never held the whole answer.

This has a second benefit that matters more over a year than over a week. The query is a durable object. The same query that answered a question in a conversation becomes the report you open every month, which runs it again by default, and the definition your company agrees on. Nothing is retyped between them.

What about the sentence around the block?

The assistant still writes prose. It says what it filtered, what it noticed, and what it would check next. That prose is the one place where a number can appear without coming from a query.

So on a Controller seat, where analysis runs, the prose is checked too. Before the text becomes a message, each figure in it is matched against what the turn can prove. A figure survives if it meets one of these tests:

• It is a numeric value in a tool result from this turn.
• It is a number the assistant sent as a tool input, such as a filter value or the day count in a duration like P7D.
• It is a number in your question.
• It repeats, exactly, a figure that earlier prose in the conversation showed.

Anything else is replaced with an ellipsis, and the replacement is counted. The sentence survives. The invented figure does not.

What is not a figure?

Verification that treats every number as a claim makes the text unreadable. Dates are numbers. So are quarters, and week numbers, and the #3 in a ticket reference.

These are never treated as figures:

• Dates, in numeric and written form, in English, Danish, German and Spanish
• Years, clock times, week numbers and quarters
• List markers, including markers inside bold text or a heading
• Identifiers such as #3 or PR0017

A system that redacts the date in "3 September 2026" is not a verification system. It is a fault.

Why verify on the server?

Because there is more than one reader.

The text reaches a web client, a desktop application, a mobile application and a browser extension. It is stored in a database. It is sent back to the model as history on the next turn. If the check runs in the client, then each of those copies differs, and the model's own history holds figures that the reader never saw.

Verification therefore runs on the server, once, before the text is streamed and before it is stored. One verified text reaches every destination.

What does this cost?

Two things, and it is fair to name them.

You sometimes see an ellipsis. When the assistant rounds a figure, the rounded figure fails the check and is removed. "Roughly 800,000 DKK across 4 users" becomes "Roughly … DKK across … users" when the ledger said 812,400 across 3 users. The first version reads better. The second version is honest.

A caveat can lose its counts. "Only 500 of 3,901 rows are in this file" keeps its warning and loses its numbers if those counts were not returned. That is the correct trade. A warning with invented numbers is two errors, not one.

What it does not solve

Verification checks that a figure came from a row. It does not check that the row answers your question.

A perfectly grounded number can still be the wrong number, because the query filtered on the wrong date field, or because "revenue" in the query is not "revenue" in your company. That problem needs a different mechanism: a shared definition of each business term, and an assistant that asks when a reading is not settled.

Those are two further parts of the same design. Verification is the floor, not the ceiling. It removes one class of error completely, which is worth doing, and it leaves the rest of the work visible instead of hidden.