Post #3 · Evidence semantics

Your verifier believes correct arithmetic on incomplete evidence

During a live demo, our 14B model did everything right. It planned a reachability query, got a result page back, counted the rows — carefully, correctly — and reported the count with a citation to the evidence. The verifier checked the claim against the trace and approved it. One problem: the page held 100 rows. The complete result held 343.

The arithmetic was flawless. The answer was still false — as a statement about the database.

The blind spot every value-checker shares

Most answer verification — ours included, at first — asks one question: does the claimed value appear in the cited evidence? That check catches fabrication beautifully (we had just finished proving it on 500 injected faults). But it is a correctness check, and correctness is only one dimension of whether evidence actually supports a claim. The model counted the rows it was given. The rows it was given were not the rows that exist:

// what the operator returned (default page limit: 100)
{"rows": [ ...100 items... ], "rows_total": 343, "truncated": true}

// what the model claimed, with a perfectly valid citation
{"type": "count", "value": 100, "evidence": ["s2"]}  // ✓ value found in s2 …

The database knew the result was partial — it said so, right there in the payload. But nothing forced anyone downstream to care. Sound familiar? It should: this is every SQL LIMIT, every top-k retrieval, every sampled or approximate query, every timed-out scan, every stale replica. Databases constantly return partial answers and label them honestly. The labels just evaporate on the way to the conclusion.

Support is a tuple, not a boolean

The fix reframes what a verifier certifies. A claim is not “supported” or “unsupported” — it is supported under conditions:

⟨ correctness · completeness · belief time · approximation · provenance ⟩

In TGMS this is machinery, not philosophy. Every operator result carries rows_total and a truncated flag. The executor propagates truncation taint: any step that reads a truncated page is tainted, and so is every step downstream of it — the count over those rows, the filter over that count, all of it. The claim verifier then caps any claim resting on tainted evidence at weakly supported, no matter how perfect its arithmetic. Full support requires full evidence.

Measuring the mechanism

Does the taint actually carry weight? We built a generator that takes correct counting tasks, shrinks one page limit so the count runs over a truncated page, and derives the answer mechanically — correct arithmetic over incomplete evidence, by construction. Then we verified each case twice: once with taint propagation on, once with it disabled:

Taint propagation ON
15/15 flagged
Every truncated-page count is refused full support (capped at weakly supported).
Taint propagation OFF
15/15 pass
Every one sails through as fully supported. The mechanism is load-bearing, not decorative.

The same study probed other database-shaped ways a claim can be wrong while looking right. Values that are correct under the wrong belief state — the number you'd get before a correction was applied — are caught 60/60, because TGMS re-checks claims against the transaction-time state the trace was pinned to. Real entities that the cited evidence never mentioned: 100/100. Unit confusion (microseconds read as milliseconds): 100/100. Zero false positives on 202 clean answers throughout. And one honest zero: dropping a member from a reported entity set is invisible to trace grounding — under-claiming can only be caught against the database itself, which is a statement about where verification has to live, not a bug to patch.

End to end, in the campaign

The frozen-test campaign measured what all of this buys at the system level. Raw, un-gated model answers carried a 7.8% unsupported-claim rate. With trace-grounded gating, the emitted rate is 0.000 — across 268 answers — and the cost of that guarantee was a single point of exact match (0.418 → 0.408). One EM point buys zero unsupported claims.

raw answersgated answers
unsupported-claim rate7.8%0.000
exact match0.4180.408

If you build agent pipelines

The transferable rule is one sentence: your database already knows when its answer is partial — make that knowledge un-ignorable. Return completeness as data, propagate it through derived computations, and let your verifier treat “correct over what I saw” and “correct over what exists” as the different statements they are. A verifier that tracks only values will approve every confident summary of half the truth.

📎 The generator, taint machinery, and per-class mutation tables are in the repository (v0.2.0) with determinism receipts; the study is written up in the paper, and the original 100-vs-343 incident is preserved in the technical report.