Every time you ask the assistant for a financial number, the answer comes with a short status line that tells you whether that figure has been checked against your ledger — and if it hasn't, it says so plainly. You never get a bare number.
There are five possible statuses:
Reconciled. The figure ties to your ERP's general ledger for that scope and period, with the difference shown (normally zero). This is the green line — "Reconciled to your GL — Corporate retail, June 2026, R0.00 variance" — with a link to the check behind it. Green only ever appears when a real check actually ran.
Reconciled with items. It ties except for a few named, understood differences, each with its amount and where it lands — the total, then a line like "+R1.2m POS-only deliveries (posted to Transport Recovery)". Nothing unexplained is hidden inside the tie.
Operational. A legitimate figure that has no ledger equivalent to check against — a unit count, a per-item margin. It shows a neutral line: "Operational figure — not reconciled to the GL." Useful, but it won't pretend to be a tied number.
Method tested against the GL. Most real questions cut the data somewhere your ledger doesn't: sales by brand, discount by store, one week rather than one month. Your ledger has no line for "Sealy in June", so that figure can't be tied — but the sum behind it can be. This status means the assistant took the exact calculation it used, ran it over your whole sales history month by month, and confirmed it reproduces your general ledger every time. It shows the evidence: "reproduces the general ledger in 15 of 15 tested periods (worst month 0.02%)", over All tested periods rather than one month.
Read it for what it says and no more: the arithmetic is proven, the slice isn't tied. It sits below Reconciled, not above it. You'll notice it never shows a rand variance — there is nothing at that level of detail to compare against, and a rand figure there would look like a tie that never happened.
Unmapped. No source-of-truth check has been set up for this figure yet. This is the safe default: "No baseline established for this figure — treat as indicative." It means "a tie hasn't been wired for this yet", not "this is wrong".
When Unmapped comes with a specific warning
Unmapped covers two quite different situations, and it now tells you which one you're looking at.
Most of the time it simply means nobody has wired a tie for that figure yet — the number is probably fine, it just hasn't been checked. But sometimes the assistant runs a query that shapes the answer wrongly: it joins two tables in a way that counts some sales twice, or it adds up a per-item price as though it were a line total, so a bed sold in pairs is counted once instead of twice. Both produce a number that looks perfectly reasonable and is materially wrong.
Every query the assistant runs is now checked for those shape problems before you see the result, whether or not the figure was headed for a full reconciliation. When something is found, the status line stops being generic and says what is actually wrong:
> Do not rely on this figure: Price is a per-unit column being added up as though it were > a line total. Ask me to verify it and I'll re-run it through the reconciled path.
Treat that as a stop sign, not a footnote — the number in front of you is very likely wrong, and asking the assistant to verify it will re-run the figure through the checked path. A softer version, opening "Unverified, and one thing to check…", means the shape is sound but something about the slice is worth a look — for example, a filter that keeps most of a group but quietly drops part of it.
If an answer contains several figures and only one of them came off an unchecked query, the warning appears in the text of the answer itself rather than in the status line, so that a tie on one number never reads as a clean bill of health for another.
When Unmapped means a known warning went unanswered
Over time, the things your team learns about your own data get written down — that a discount field is recorded including VAT, that a table keeps deleted rows, that a date column is the capture date and not the transaction date. These are the traps that make a query look right and come out wrong.
Until now those notes were shown to the assistant and it was free to ignore them. They are now enforced. When a question reads data carrying one of these warnings, the assistant has to say what it did about it — either it handled it, naming the part of the calculation that does so, or the warning doesn't bear on this question, with a reason. If it says nothing, the figure does not get a tie:
> Reported without certification: there is 1 recorded correctness caveat on the data > behind this figure that this answer does not say it accounted for. The figure and its > rows are shown in full — only the certification badge is withheld.
That is not the same as saying the number is wrong. It says the number was produced without addressing something we already know to be a trap, so it hasn't earned a status. Ask the assistant to account for the warning and it will re-run the figure having done so.
You get the count, not the list. These warnings are working notes about your own data, and a common table like the trial balance can carry a dozen of them at once — printed into your answer they buried the figure you actually asked for. Ask the assistant to account for them and it will name each one and say what it did about it. Nothing is hidden from you: your figure and its rows are always shown in full, and only the certification badge is held back.
The check is on whether the warning was addressed, not on whether the assistant addressed it correctly — that stays a judgement you and your team make, but now it is made against a stated claim by name rather than against a silence.
A warning written about one table also reaches the views built on top of it, so renaming a column in a view no longer quietly loses the warning attached to it.
When Unmapped points you somewhere you can check
An Unmapped figure is often built on top of something that is checked. Your store-level sales cut may have no tie of its own, while the sales table underneath it reconciles to the ledger month after month.
Where that is the case, the answer now carries a second panel headed Where this can be checked, naming the source underneath and how well it ties:
> POS sales, which this figure is built on, does tie: its documents reach the ledger at > 99.68% across 15 periods.
Read this carefully, because it is deliberately not a claim about the figure you asked for. The status above still says Unmapped and that is still the truth — the number in front of you has not been checked. The panel only tells you that a checkable version of the same thing exists, and where.
Alongside it is a button — Re-ask against … — which puts your question back to the assistant against that source instead, so you can get a figure that does tie to the ledger. You keep your original question; only the source it is answered from changes.
Two things keep this honest. The panel is built from the check itself, never from the assistant's own words, so it appears whether or not the model chose to mention it and it cannot overstate the match. And it never appears on a figure that already carries its own tie — on a Reconciled or Method-tested answer it would read as extra reassurance on a number that has already been checked, which is exactly the impression this system exists to prevent. If nothing underneath ties well enough to be worth pointing at, you see nothing rather than a weak suggestion.
Two of the five don't name a month, for opposite reasons. Method tested covers every month that could be tested, so naming one would understate it. Unmapped has nothing to name. The other three always tell you which period they're talking about.
Investigations carry the same status line
A deeper investigation — the kind that runs in the background and lands in your Inbox — now carries a status line too, read the same way and shown the same way. There is no lane where a figure arrives unlabelled.
It will usually read Unmapped, and that is the honest reading rather than a fault. An investigation cuts your data many ways in the course of answering one question, and the heavier checks — the ledger back-test, and the enforcement of your recorded warnings described above — are reserved for a figure being certified, not run over every exploratory step along the way. The shape checks do run on every query, so a total that doesn't add up is still caught. So the findings tell you what was found, and the status line tells you plainly that nobody has tied those numbers to your ledger. If you want a figure from an investigation checked, ask for it directly in chat — that answer goes down the full certification path and comes back with a real tie.
Occasionally the status line will say something stronger: that a check on the answer found the figure doesn't add up — a total that doesn't foot back to its own detail, for instance. That is a refusal rather than a gap, and it is worth acting on: the finding that rests on that number should be treated as unproven until the question is re-asked.
Two things are always true. The assistant never works out the tie itself — the figure is checked by a stored, vetted reconciliation, or by a calculation re-run against your ledger in code, never by the assistant deciding for itself that the number looks right. And no financial answer is ever shown without one of these five statuses: if a number can't be tied, you're told, rather than handed a false green tick.