DaaX ClaimGuard: A Confidence Score Is Not Verification

Most systems hand you one number for the whole answer. ClaimGuard takes the answer apart and checks each claim on its own — because in a four-sentence answer, three sentences right and one wrong is the dangerous case, and a single score can't tell you which sentence to distrust.

A shopper asks whether a docking station will drive two external displays off their laptop. The system answers:

Three of those sentences are correct. One is not — it's a reasonable-sounding inference the source documents never actually support. The system reports a confidence of 0.91.

Which sentence is the wrong one?

The score can't tell you, and that's not a calibration problem you can tune your way out of. A single number describes the answer as a whole, but correctness isn't a property of answers — it's a property of individual assertions. An answer with one bad claim in it isn't 91% correct. It's wrong, in one specific place, and everything hinges on knowing where.

That's the problem ClaimGuard is built to solve, and it shapes the whole design: verification is a separate stage that runs after an answer is drafted and before anyone sees it, operating on claims rather than on the answer.

Decompose first, then check

When LAKEer drafts an answer, that draft doesn't go to the user. It goes to ClaimGuard, which breaks it into the individual assertions it makes and tests each one independently against the retrieved evidence.

Decomposition is doing real work here. Natural-language answers bundle claims together in ways that hide their differences — a sentence can carry a sourced fact and an unsupported inference in the same breath, joined by nothing more than a comma. Pulling them apart is what makes it possible to keep the parts that hold and cut the parts that don't, instead of accepting or rejecting the whole thing on one score.

Run the answer above through that process, and the four sentences come apart like this:

The third sentence is the wrong one, and it's the point of the whole exercise. Each of the other three claims is supported — but nothing in the corpus establishes the combination of two displays at full resolution at once. A model generating fluent prose will assert it anyway, because it follows naturally from the sentences on either side of it. The answer that ships states the three verified facts and says plainly that the combined case can't be confirmed. The alternative is one confident sentence that produces a return.

Three checks, not one

Each claim runs through a sequence of distinct tests rather than a single scoring pass.

Eligibility asks whether the claim is the kind of thing the retrieved evidence could settle at all. Some assertions are out of scope for the corpus — speculative, or about something the documents simply don't cover — and identifying those early prevents the system from manufacturing support for a question the evidence was never going to answer.

Factuality asks whether the evidence actually supports the claim as stated. Not whether it's related, not whether it's topically similar — whether it supports this specific assertion.

Citation binding asks whether the claim is correctly tied to the source it cites. This is the check that catches a subtle and common failure: a number that genuinely appears in the document set but has been attached to the wrong thing. For cartridges that define domain-specific value patterns — what a valid price binding looks like in the eCommerce cartridge, for instance — ClaimGuard also verifies that the entity-value pairing matches those patterns. A price that exists somewhere in your price list is not the same as the price for this product on this contract tier, and only a binding check distinguishes them.

Claims that fail aren't simply dropped. The pipeline has self-correction loopbacks — a failed claim can be corrected or regenerated against the evidence and re-tested, rather than the answer being discarded wholesale. Under the hood, the verification stages are DSPy-compiled rather than prompt-engineered by hand: MIPROv2 for eligibility, BootstrapFewShot for factuality. The practical consequence is that these stages are optimized against measured outcomes and can be re-optimized as the workload changes, instead of being frozen in a prompt someone wrote once.

Not all true things are true the same way

A verified claim still carries a question the verdict alone doesn't answer: verified by whom? A specification from your own engineering documents, a claim a vendor makes about its own product, and a value read live from your order system are all supportable — and they warrant different degrees of confidence when a customer acts on them.

ClaimGuard tracks that distinction as modality, which is why the table above has a column for it. It's what lets an answer hedge a vendor-asserted claim while stating a first-party one flatly — and it's what makes an estimated or inferred value explicitly flagged as non-authoritative rather than blended into the prose alongside sourced facts. Your team always knows the difference between a fact and an inference, because the answer says which is which.

Every answer ships with its receipts

Verification that happens invisibly is hard to trust, so it doesn't. Every answer comes with a ClaimGuard verification log: which claims were checked, which sources support them, what was flagged as estimated, and what the system declined to assert. Combined with the audit trail on each claim — the specific document, page, and table it came from — an answer becomes something you can hand to a compliance reviewer six months later and defend.

This also changes what a failure looks like. When the evidence isn't there, LAKEer says so. "We cannot confirm that" is not a degraded answer; it's the correct one, and it's the answer a plausible-sounding guess was crowding out. When two sources genuinely disagree, ClaimGuard surfaces both and the conflict rather than silently picking a winner — which turns a contradiction in your document set into something a human can go fix.

What it measures out to

This architecture is what produced LAKEer's result on Google DeepMind's FACTS Grounding benchmark: 77.7% accuracy at 92% eligibility, measured on the 860-example public split. For reference, Gemini 2.5 Pro led that leaderboard at 74.3% overall when we published our FACTS results in March 2026.

That comparison carries three qualifications, and we would rather state them than let a reader discover them. The official leaderboard score averages the public and private splits, and we could run only the public half — so the two figures are not strictly like-for-like. The benchmark was built to evaluate language models rather than complete retrieval-and-verification systems; Google's team has acknowledged that distinction and is weighing a separate category for full systems, so we report our score rather than claim a position on the board. And DeepMind has since revised the benchmark. Grounding v2, released in December 2025, expands the example set and improves the judge models, which makes any figure drawn from the original leaderboard a historical snapshot rather than a current standing.

What survives all three qualifications is the part we actually care about. The result came from a compact model rather than a frontier API — which matters less as a bragging point than as an economic one. Accurate grounding turns out to be a property of the architecture around the model rather than of the model's size, and that means it doesn't require paying frontier prices on every question.

The broader point is architectural. Hallucination isn't eliminated by a better prompt or a bigger model — both still produce fluent text with no mechanism for knowing whether it's true. It's reduced by adding a stage whose only job is to check, claim by claim, against evidence that can be pointed at. That stage has to be able to say no, and it has to tell you exactly which sentence it said no to.