Checks on the answer
The checks that run on a finished answer before it is sent — what each one catches, how often it fires, and why a check that fires often is a bug rather than a feature.
Retrieval decides what the model is allowed to see. This page is about what happens after it has written something, in the moment between the last token and the answer appearing on someone's screen.
The reason there is a stage here at all is a small, uncomfortable observation: a rule in a prompt is a request. You can write "never state a figure that is not in the material" at the top of every turn, and most turns will honour it, and the ones that do not are exactly the ones a careful reader would have caught. So the rules that matter are not written as requests. They are written as checks that run on the finished text, in code, where the answer either contains the sentence or it does not.
The shape of a check
Every check here has the same three parts, in this order, and the order is what makes it affordable:
- A deterministic pre-check. String and pattern work on the answer that was just written — no model call, no round trip. Almost always it says "this shape is not present" and the check ends.
- One extraction call, only if the pre-check fired. The model is asked to copy sentences out of the material verbatim — never to judge, never to conclude. "Copy every sentence that states whether this is permitted" is a question with a checkable answer; "is this answer correct?" is not.
- The decision, back in code. A copied sentence counts only if it appears in the material character-for-character. Without that comparison a judge can invent a sentence and overturn a correct answer with it — which is not a hypothetical, it is the reason the comparison is there.
A check that fires often is a bug. One of these once decided that a reply "mentioned a classification" by looking for a capitalised word followed by a code. In regulatory prose that matches article citations, currency codes, chemical registry numbers, month names — and the word within, as in "must be applied for within 30 business days". It fired on 57 replies in 100, each firing costing an extraction call and a full re-answer, on answers that were already correct. Keyed to actual classification words it fires on 4. A check with a high hit rate is not being thorough; it is measuring the wrong thing, and it is spending your latency to do it.
What they catch
Each of these exists because an answer went out that should not have. The trigger rates are measured against stored production-shaped answers, and they are deliberately low.
| The answer does this | Why it matters | Fires on |
|---|---|---|
| Says the material explicitly permits or forbids something, and the material contains no such sentence | "The material says X" is a claim about the text, and it can be checked word for word | 2 of 279 |
| Answers "yes, that is accepted" where the material says, in as many words, that it will not be accepted | The worst failure this product can have: someone prepares a filing on it and is rejected | 1 of 300 |
| Quotes a figure that appears in no retrieved passage | A number with a citation marker beside it is the most persuasive thing an agent can get wrong | — |
| Gives a figure without naming which jurisdiction it applies to, when every passage came from one | Fees and deadlines differ per market; an unlabelled number invites the wrong one to be used | — |
| Cites the one passage that came from a different document than the question named | Two instruments often describe near-identical things; the wording matches better in the wrong one | 2 of 399 |
| Cites an exception in the material and then overrules it with general practice | The material was read correctly and then argued away | 1 of 109 |
| Is, in its entirety, a tool call rather than an answer | Raw call syntax must never reach a reader — see Running on open models | — |
The em dashes are not omissions. Those checks predate the measurement discipline described here and their rates have not been counted the same way; they are listed because they run, not because a number can be quoted for them.
What happens on a hit
The answer is written again, with the same material in front of the model, plus one sentence saying what was wrong with the first attempt. Not deleted, not replaced with an apology.
That choice is deliberate. The material that would answer the question is usually still sitting there — the first attempt reached past it, or read the neighbouring row, or hedged. Re-answering with the same passages recovers it. Refusing does not.
The correction sentence is written under one rule that cost something to learn: it says what to produce, never what to avoid. An earlier version of one correction illustrated the bad format with three worked examples and then asked the model not to produce that format. It produced it again, and the reader got an apology instead of the answer — which was in the retrieved material, word for word.
A correction that only says "you got it wrong" often changes nothing. One check catches an answer that cited a passage from the wrong document. Told only that, the model re-answered the same way three times out of three — it believed it was using the right document. What changed the outcome was giving it the mapping it could not derive: these passage numbers are from the document you were asked about; the one you cited is not. Even then it comes right about a third of the time. The check is honest about being an improvement rather than a fix.
What this does not do
- It does not check whether the answer is true. It checks whether the answer's claims about the material are true. Those are different, and only the second one is decidable here.
- It does not fire on most turns. By design. The rates above are the point of the design, not a limitation of it.
- It is not a substitute for the material being right. If the passage that settles a question was never retrieved, no check on the output can invent it. That problem is retrieval's, and it is solved there or not at all.
- Every check fails open. If an extraction call errors or returns something unparseable, the answer goes out as written. A verification layer that can block answers when a backend is slow is a worse failure than the thing it was guarding against.
Related
- Grounded answers — what the model was allowed to see in the first place
- Running on open models — the model-layer breakages this stage backstops
- Writing pipeline — the same discipline applied to long documents