Verifying AI Outputs Against Trusted Sources and Structured Checks

Verification is the skill that generalises. Tools change every few months, but the discipline of deciding whether an output can be relied on transfers to every tool, and it is the practical answer to the fabrication risk described in Lesson 5. This lesson sets out how checking actually works, from the version every employee can do to the version an organisation can automate.

Start with the weakest technique so nobody relies on it. Asking a model whether its own answer is correct is close to worthless as assurance. The same process that produced a confident wrong answer will produce a confident defence of it, and a second opinion from the same model on the same context is not independent. It has some value as a drafting aid, since asking what might be wrong with an answer sometimes surfaces a real weakness, but it must never be recorded as the check.

The strongest everyday technique is to supply the source and require the output to stay inside it. Instead of asking what your refund policy says, give the model the policy and ask it to answer from that text, quoting the passage relied on. This converts an unbounded question into a bounded one and gives you something checkable, because you can read the quoted passage and confirm it exists and says what the answer claims. Fabricated quotations are far easier to spot than fabricated summaries.

The next technique is checking against an authoritative source that did not come from the model. Legal references get checked against the legislation, product specifications against the specification sheet, financial figures against the ledger, names and dates against the record system. This is slow if applied to everything, which is why literacy includes knowing what to check rather than checking everything. The working rule is to check anything that will leave the organisation, anything that will inform a decision about a person, anything numerical, and anything you would have to correct publicly if it were wrong.

Beyond manual checking sits structured verification, which is where organisations gain reliability that individual diligence cannot provide. The idea is to stop reading prose for errors and instead express the claim as something a machine can test. A recommendation letter can be checked by asking whether the referenced employee exists in the human resources system, whether the stated dates fall inside their employment period, and whether the stated role matches the record. An invoice summary can be checked by asking whether the line items sum to the total. A regulatory answer can be checked by asking whether the cited article number exists in the instrument. None of these checks requires a model, and all of them catch the failures models produce.

The structured approach becomes systematic when the domain is described explicitly rather than left implicit in the prose. Representing the entities, relationships and constraints of the domain as a knowledge graph, with an ontology that states what a valid claim looks like, means an output can be tested against it mechanically. The graph knows that a claim cannot refer to a supplier who does not exist, that a contract cannot end before it starts, and that a person cannot hold two mutually exclusive statuses. Contradictions surface as violations rather than as something a tired reviewer might notice on a Friday afternoon. Because the checks are deterministic, the result is the same every time and can be logged, which is exactly what an evidence pack needs.

Tardygrada, our open-source formally verified agent runtime, is the worked example of this approach, and its results show both the value and the honest limits. In its ablation, the full pipeline reached 95 percent against 71 percent for the ontology-only configuration and 24 percent without the ontology, which indicates that the structured layer is doing most of the work rather than the model. On work verification it reached an F1 of 0.92. On ContraDoc, a real-document contradiction task, it reached an F1 of 0.567, which is the number worth remembering, because it says plainly that contradiction detection in messy real documents remains hard and that no verification layer removes the need for human judgement. The primitive checks themselves run in 18.4 microseconds per document, so the cost of applying deterministic checks at scale is negligible compared with the cost of a wrong answer reaching a customer.

For the individual employee, the takeaway is a definition rather than a technology. Decide, for your own work, what the word “checked” means, write it down, and apply it consistently. For a support agent it might mean that every policy statement quotes the policy document. For an analyst it might mean that every figure traces to a named report. For a recruiter it might mean that no candidate is rejected without a human reading the application. Recording that the check happened turns good practice into evidence, and evidence of verification behaviour is among the most persuasive material an organisation can put in front of an assessor, because it shows literacy operating rather than merely being delivered.