/Attest

Catching a fact checker in the act of overreaching

Attest is the last thing that reads a report before somebody trusts it. We built a second reader whose only job is to catch it being too generous, and measured what that is worth.

Run 18 September 2026 · 5 runs of the new configuration against one of the deployed product, on 190 hand-labelled claims, confirmed on 64 more the system was never tuned against

Claims190 + 64
Runs5 v 1
Overclaims reaching a reader4.7% → 1.4% ±0.5
Held for a person6.0% ±1.2

01

One kind of mistake costs more than the other

Attest exists to be the last thing that reads a report before a person trusts it. That job has an asymmetry built into it. If Attest is too cautious it wastes a few minutes of somebody’s time, and if it is too generous it tells a reader that something is established when the evidence never said so. We call the second kind an overclaim, and we treat it as the number that matters rather than as one error among several.

What counts as one? Grounding asserted that is not there, or a refutation the report walked past, over every claim scored. Not the narrower count of verdicts that came back SUPPORTED, which on the deployed product reads 0.8% where the figure above reads 4.7%. Reporting the smaller one would be the exact failure this product is sold to catch.

02

What moved the number was subtraction

The obvious way to reduce overclaims is to make the model that reaches the verdict more careful. We spent a long time on that and it did not work. Asking for more reasoning made it worse. Asking a second model to review the first changed little.

What finally moved the number was taking something away. Attest had been running three extra language model passes to produce written explanations, and those passes were feeding corrections back into the verdict. Removing them took accuracy from 91.6% to 93.8% ±1.0 and cut the overclaim rate by a third, which tells you something uncomfortable about how much the explanations were worth.

03

A model that only decides

We were given early access to a model that does not write text at all. It answers typed questions and returns a probability for each one, and one request carries every question and is charged once.

Our first instinct was to let it do the grading. That was wrong, and it was wrong in five different configurations. As a grader on its own it reaches 82.8% against the language model’s 93.8% ±1.0. Letting it handle the claims it was most confident about and passing the rest on sounded better and measured worse, because its confidence turns out to identify easy claims rather than claims where it has an advantage. On the third of claims it was surest about it graded at 97.4% with no overclaims at all, which reads as a triumph until you notice the language model scores 97.6% on those same claims.

The lesson took us a while to accept. A model that only decides is not better at deciding. It is better at checking.

04

Asking the right question

So we stopped asking it what the verdict should be, and started showing it the verdict somebody else had already reached. The verdict is restated as a plain sentence about the evidence, because a label like PARTIALLY_SUPPORTED is the name of a bucket and not something you can check. Then it is asked whether that sentence is too generous to the claim, and separately whether anything in the evidence tells against the claim that the sentence fails to account for.

What does that cost? One request of about 281ms. The citations behind the verdict ride in the same request for nothing: the check alone takes 281ms and the check carrying all six citation questions takes 270ms, because the model is charged by the request and not by the question.

MeasureDeployed todayShipping
Verdict accuracy91.6%93.8% ±1.0
Overclaims produced4.7%3.1% ±0.4
Overclaims that reach a reader4.7%1.4% ±0.5
Reports held for a personnone6.0% ±1.2
False alarms1.1%1.2% ±0.2
Model calls per claim4.02
Time per claim3202ms1294ms

5 runs of the new configuration against one run of the deployed product, on the same 190 claims. The deployed product gets one run for a reason given in section 08.

RunAccuracyOverclaims producedReaching a readerHeldTime per claim
194.2%3.2%1.1%7.4%1263ms
294.2%3.2%1.6%4.7%1304ms
392.1%3.7%2.1%4.7%1379ms
494.7%2.6%1.1%6.8%1193ms
593.7%2.6%1.1%6.3%1332ms

Every run, so the spread is visible rather than averaged away.

05

Holding is not the same as fixing

Our first design let the check weaken a flagged verdict by one step, on the theory that a verdict credited with too much should be credited with less. It did nothing. The overclaim rate went from 3.0% to 3.0% while accuracy fell, and the reason is worth stating because it is not obvious. Two thirds of overclaims are not inflated confidence. They are missed refutations, where the evidence actively contradicts the claim and the report simply does not say so.

Weakening “the evidence establishes this” to “the evidence partly establishes this” still never tells the reader that the evidence is against them. The verdict is exactly as wrong as it was, and every false alarm has damaged a verdict that was fine. A repair has to match the mistake, so the check does not rewrite anything. It holds the report for a person, which is what Attest is for.

How often is a hold right? Not often enough to call it a finding. Roughly two in three land on a verdict that turns out to be fine, which is the right trade for a hold and the reason nothing in the product phrases it as a conclusion. It says a person should look, never that the verdict is wrong.

06

The weaker path gains more

A claim can be checked against evidence the caller supplies, or against a document set an agent searches. The second is harder, and we measured the guard there separately rather than assuming the first result carried over.

The same 190 claims, rebuilt as document sets with 6 unrelated filler documents each so the search has to find the right passages among others. The agent’s verdicts are 84.7% accurate with 6.8% overclaims, against 93.8% ±1.0 and 3.1% ±0.4 when the same claims come with their evidence attached. Finding the evidence is most of the difficulty.

SensitivityHeldCaught of 13Right when it firesReaching a reader
0.4015.8%1033%1.6%
0.50 · shipped11.6%941%2.1%
0.607.4%750%3.2%
0.705.3%660%3.7%
0.803.2%467%4.7%

Swept on the recorded probabilities, so moving a threshold costs no model calls. 13 of the 190 verdicts were overclaims.

Why that row? At 0.50 the overclaims reaching a reader fall from 6.8% to 2.1%, for 11.6% of results held. The next step up the table buys one more catch out of 13 for a third more review, which is noise at this sample size.

07

What we shipped

One model call for the verdict, one call to a model that only decides, and nothing rewritten. Overclaims that reach a reader fall from 4.7% to 1.4% ±0.5 on the labelled set, and to 1.6% on a second set of 64 claims the system was never tuned against.

1.4% ±0.5

overclaims reach a reader, from 4.7%

6.0% ±1.2

of reports held for a person to read again

1294ms

a claim, from 3202ms

Most of the accuracy is the explanation passes coming out, not the second reader. What the second reader adds is the third row of the table above: of the overclaims that survive everything else, the ones a person now sees before a reader does.

08

What this run is not

A guard tuned only on its home material is a guard tuned on itself. Everything above was measured on document review, which is what Attest is built for, and none of it should be read as a claim about anything else. We also ran the check over an external set of 500 political and journalistic claims as a sanity check rather than as a result, and it changed exactly one thing: the sensitivity setting, where our own data had no opinion worth having and unfamiliar evidence had a strong one.

The deployed product gets one run and no error bar, and it cannot be given one today. It remembers a measurement for six hours, so asking it the same question again returns the answer it gave the first time rather than taking a new one. A replay is a valid verdict and a meaningless timing, so accuracy is reported over every claim and the timing and call counts over the 85% it measured freshly.

The guard catches about two thirds of overclaims, and that is a ceiling rather than a tuning target. What it misses needs two pieces of evidence combined: no single passage contradicts the claim, and the contradiction only exists when you join two of them. Three rewordings moved it nowhere, which is the documented weakness of a model that only decides.

The document-set figures are thin on positives. 13 overclaims among 190 verdicts, so adjacent rows of that sweep differ by one or two examples, and the filler makes the search harder than a supplied packet and easier than a real upload.

Run-to-run spread is about a point on 190 examples labelled by one author. The per-run table above is the whole spread rather than a summary of it.

The labelled set was in use during development. It is the set the figures on /attest are measured on, so it is not held out, and the second set of 64 claims is reported beside it for that reason.