An extraction pipeline that cannot show its evidence has not finished the job. In certification work, a value on a certificate is only as good as the trail connecting it to the source document. In finance, a payment decision is only as defensible as the invoice line behind it. Yet most document AI systems deliver values without locations: the number arrives, the evidence stays behind. This post argues that evidence traceability is not a feature to request but a design requirement to insist on. Its absence, more than any accuracy shortfall, is what keeps document AI out of the workflows where it would matter most. The argument rests on measured evaluation evidence and on a design principle that follows from it.
Document AI systems read business documents and produce structured values: an invoice total, a test result, a certified measurement. Evidence traceability means each produced value carries a citation to its exact source: the page and passage it came from. A person can then confirm the value in seconds rather than searching for it. The issue is live now because extraction quality stopped being the obstacle. Modern models read documents well, and organisations in regulated and financial settings are moving from pilots to production. There, auditors, accreditation bodies and internal controls ask a harder question than how accurate is the model. They ask: show me where this number came from. What is at stake differs by seat but converges in size. In a certification business, an inability to trace value can compromise the deliverable and jeopardise accreditation. For a finance department, this means every disputed invoice requires an investigation. In any organisation, it determines if qualified reviewers spend their time searching through documents or verifying evidence. That difference shows up in the review queue, which now drives deployment cost. This post is written for quality and certification leaders. It is equally relevant to finance operations owners, to transformation leads whose pilots must survive audit, and to the engineers who build the pipelines.
Evidence traceability is a design requirement, not a feature
If auditors ask where a number came from, the system’s real output is not the value but the value plus its evidence. That reframing sounds small and changes everything downstream.
Treat the citation as optional and the pipeline optimises for volume of values produced. Treat it as part of the deliverable and the pipeline must preserve the link between output and source at every stage. Conversion steps that flatten a table into loose text break that link even when the values survive.
The requirement has a regulatory face and an economic face. The regulatory face is familiar to anyone in certification or audit: a result that cannot be traced is a finding waiting to happen. The economic face is less discussed. A reviewer confirming a cited value performs seconds of work. A reviewer hunting for uncited evidence in a long document performs minutes of it, per field.
Multiply that difference across every field of every document and it becomes the deployment cost. Which raises the question of why the market underweights traceability, and the answer sits in how responsibility is distributed.
Extraction liability is asymmetric, so human review is permanent
The model that makes the error does not carry it. The organisation does.
When an extracted value is wrong, the consequences land close to home. The certifier whose mark is on the report bears them, as does the finance team whose payment cleared. No accuracy percentage transfers that exposure back to the tool. A responsible organisation therefore verifies every value that matters, at any accuracy level current tools can reach.
Our evaluation quantified those levels. Across five extraction approaches on a 39-document corpus with known ground truth, the best mean field score was 0.908 (Aicadium Phase 1 evaluation, 2026). That is roughly one field in eleven wrong, with no advance warning of which. Moving from a strong model to a slightly stronger one does not release the reviewer. The reviewer is there for the errors nobody can predict.
Once review is understood as permanent, the design goal flips. The question stops being how to remove the human and becomes how to make each human decision fast, informed and recorded. That is a workflow property, not a model property.
And it leads directly to the hardest case a reviewer faces: the document that disagrees with itself.
Surface discrepancies; never silently fix them
What a system does at that moment reveals whether it was designed for audit.
Suppose an invoice’s line items do not sum to its printed total. There are two possible explanations, and from the output alone they are indistinguishable: the system misread the document, or the document itself is wrong. Both happen in production. A supplier’s spreadsheet error looks exactly like an extraction error until a person inspects the source.
A system built for clean output resolves the tension quietly. It normalises the total, or recalculates it, and delivers a record that validates. That behaviour destroys precisely the evidence a reviewer, an auditor or a dispute process needs, and it converts a detectable problem into an undetectable one.
A system built for audit does the opposite. It preserves what the document says and flags that the internal arithmetic fails. It cites both the lines and the total, and routes the case to a person. The discrepancy is the finding; hiding it is the failure.
This principle, surface rather than fix, extends beyond arithmetic. Ambiguous fields, multiple candidate answers, values the model could not ground: each is information the workflow should carry forward, not smooth over. Building that behaviour requires knowing where in the pipeline problems arise, which is a debugging question with a structural answer.
Design the extraction pipeline so failures have addresses
Start by naming the places a failure can come from.
Extraction failures can originate at several stages: reading the document, reconstructing its tables, interpreting the schema, or answering questions over the result. In our evaluation work each observable failure was mapped to a specific stage through a five-view debugging framework. The views cover layout, differences, matching, schema and question answering. A defect arrives with an address instead of a mystery.
The same staging discipline applies to human checkpoints. In reconciliation work, verifying a single document is a different act from comparing documents against each other. The two are best separated by an explicit human gate. Extraction mistakes then get caught as extraction mistakes, instead of masquerading as business findings such as cost overruns.
For a leader evaluating systems, the design test is expressible in four questions. Does every value carry a citation to its source? Does the system preserve and flag documents that disagree with themselves? Can a failure be attributed to a pipeline stage? Is there a human gate between extraction and business judgement?
A system that answers yes to all four is designed for audit. A system that answers with an accuracy percentage is answering a different question.
Closing
Accuracy determines how often a document AI system is right. Traceability determines whether anyone can trust it, review it economically, and defend its output to an auditor. The evaluation evidence shows why the second property matters more now. No measured approach was accurate enough to retire review, so the workflow around review is where value is won or lost. Insist on citations as part of the deliverable, on discrepancies surfaced rather than fixed, and on failures that have addresses. Put the four design questions to your next vendor. And if the answer comes back as an accuracy percentage, start with an evaluation rather than a build: run your own document mix, including the pages with the least structured tables, against the approaches you are considering, and let the results decide what the workflow can safely assume. The economics and the evidence behind this standard are set out in the first two posts of this series.
