Blog · AI and self-service analytics
How an analytics product uses a language model without letting it touch a number: deterministic code computes every measure from stated definitions, a tool registry names each computation, the model plans which tools to call and reads their outputs, every output carries its citation, and the model's own text is labelled as a reading. The four boundaries that make this hold, what crosses each, and what never does.
An analytics product that uses a language model has one design decision that matters more than the rest: whether the model can produce a number. This guide sets out an architecture in which it cannot, the registry that enumerates what the product does, what the model does instead, and the four boundaries that hold.
| Layer | Does | Never does |
|---|---|---|
| Definitions | State each measure, versioned | Change without a version |
| Deterministic computation | Computes every measure from the definitions on every upload; checks identities; writes tables with citations | Guess, estimate without a stated method, skip the identity |
| Tool registry | Names each computation with inputs, outputs, version | Accept a tool the model invented |
| Model: planning | Chooses tools for a question; orders them | Compute |
| Model: reading | Explains outputs in sentences that cite tables | State a number not in a table |
| Presentation | Shows tables, readings and citations; labels readings as the model's | Present a reading as a computed fact |
The model cannot write to a table. Every table is written by deterministic code from an upload. The model reads.
The model cannot produce a number that is not in a table. Every figure in its output is traceable to a cell. A sentence with a figure and no citation is rejected before it is shown.
The model cannot change a definition. Definitions are versioned files; the model reads the version and cites it.
The model cannot see a name. It works on identifiers. The lookup from identifier to name is outside the product.
| From | To | What crosses |
|---|---|---|
| Upload | Computation | Rows of identifiers, dates, amounts |
| Computation | Tables | Figures with citations; identity results |
| Tables | Model | Figures, citations, definition versions |
| Model | Presentation | Sentences with citations; a plan of tool calls; labelled as readings |
| Presentation | Reader | Tables, readings, citations, the validation report |
Nothing crosses from the model to the tables. Nothing crosses from names to anything.
| Tool | Inputs | Definition | Writes |
|---|---|---|---|
| coverage_by_rep | activities, assignments, tiers, period | Coverage v2026.3 | Table 3 |
| untouched_list | activities, assignments, ledger, period | Untouched v2026.1 | Table 3a |
| share_of_wallet | ledger, master, norms, period | Share of wallet v2026.2 | Table 6 |
| movements | tables 1 to 9, thresholds | Movements v2026.3 | Table 10 |
Asked "why did the North fall?", the model plans: movements, then coverage_by_rep for the North, then untouched_list for R-04. It reads the three tables and writes: "Coverage in the North fell eight points, driven by R-04 at 53 percent; five tier-one accounts are untouched, the largest 4471 at $310,000. Tables 10, 3, 3a." Three tools, one reading, three citations, no arithmetic.
The plan, which saves the reader from knowing which table to open. The reading, which is the sentence a good analyst would write. Both are valuable; neither is a number.
The model computes "just the small things". There is no way to tell which small things it got wrong.
Tools invented on the fly. Behaviour that cannot be enumerated or audited.
Readings presented as facts. The model's sentence with the same weight as the table.
Names in the model's context. A data protection surface for no analytic gain.
Covirage is built this way: definitions versioned, computation deterministic, a registry of tools, a model that plans and reads and cites, and four boundaries that hold on every request. The self-service analytics solution describes the product, and the arithmetic guide covers the first boundary in depth.
Because there is no way to tell a sum it got right from one it got wrong, and both look the same. Deterministic code gets the sum right every time and the identity check proves it. The model adds nothing by computing and risks everything.
A list of every computation the product can run, each with a name, the inputs it takes, the definition version it applies and the table it writes. The model picks tools by name; it cannot invent one. The registry is what makes the product's behaviour enumerable and auditable.
The plan and the reading. Asked a plain-language question, it decides which tools answer it and in what order, and having read the outputs it writes the sentence a person would: what moved, where, and what the table says about why. Both are labelled as the model's, and both cite the tables.