OpenParser is used to automate back-office workflows that extract data from documents. Customers need the data to be correct, but reviewing every field by hand removes much of the benefit. AI should handle reliable values and send only uncertain ones to a person.
If a document contains 20 fields and only one handwritten field is hard to read, a reviewer should verify that one while the other 19 continue end to end. Making this distinction requires field-level confidence: a document-level score cannot tell us which value needs review or why.
Why self-reported confidence is unreliable
Asking an extraction model to score its own answer is not reliable. It produces both the value and the score, and it cannot see mistakes made earlier in the pipeline.
Suppose a lease contains an address written as 80369 Efnen Burg, but OCR reads it as 80369 Efren Burg. The extraction model receives Efren as input. The extraction model isn't wrong in the narrow sense: it extracted exactly what it was given. The problem is that it has no visibility into the reliability of its input.
Asking the OCR model for a confidence score doesn't completely solve this either. Now we have an OCR score and an extraction score, but they are disconnected. What we really need is confidence attached to the value, with a trace showing how that value was produced.
Lineage tracks confidence step by step
Our document processing pipeline has three main stages: parse the document, extract the fields, and transform them into the format required downstream.
That is why we built Lineage, a protocol that tracks the source and confidence of every output value step by step. Each field keeps its own path:
- Parse: Turn the document into structured text and retain word-level confidence when the OCR model provides it.
- Extract: Attach an exact citation to the value and check that the cited words appear in the parse.
- Transform: Record how a cited value became the final output. A deterministic validator gives it full confidence only when it can prove the transformation. Otherwise, it keeps a coarse confidence level or remains unscored.
- Review: Add the operator's decision to the same field path before anything is exported.
For example, a lease says 20 day of May 2025, while the schema expects an ISO date:
{
"type": "string",
"format": "date",
"description": "Date when the lease commences in ISO format YYYY-MM-DD"
}
The parser reads the source words and carries their OCR confidence. Extraction cites those exact words, and source alignment checks that the citation exists in the parse. The transform produces 2025-05-20, and a deterministic date validator checks that the cited text converts to that exact value.
Confidence follows the weakest link
For our purposes, we use a conservative rule: the field confidence is limited by the weakest step in its lineage.
field_confidence = min(parse_confidence, extract_confidence, transform_confidence)
For the date above, parse confidence might be 0.99, while extraction and transformation confidence are both 1.00. The resulting field confidence is 0.99, so there is no need to send it for review.
If the validator cannot prove a transformation, we do not assign it 1.00. The transform keeps a coarse model ordinal or remains unscored instead of presenting a self-reported number as a precise probability.
For the address from the OCR example, parse confidence is 0.52, while extraction and transformation confidence are both 1.00. The resulting field confidence remains 0.52. The extraction may be correct relative to the OCR output, but the field is still uncertain because the uncertainty entered during parsing.
This is the important distinction: confidence follows the data, not the model.
Using confidence for human review
Once confidence is available per field, it can also determine when a human operator needs to get involved.
Suppose a document has 50 extracted fields and one has a confidence of 0.52. Instead of sending the whole document to a reviewer, we can route only that field for review.
The review interface can take the operator directly to the source region and show the lineage behind the value:
leased_premises.address
80369 Efren Burg
^^^^^
Parse 0.52
Extract 1.00
Transform N/A
Traditional review tools show the extracted value and perhaps a confidence score, but the operator still has to search the document for the original text and work out where the error occurred. With lineage, opening the flagged field takes the operator straight to its source region and shows every step that produced it.
The operator can immediately see that the extraction matched the parsed text, but the parser was uncertain about that text. They can compare the value with the original document, correct it if necessary, and continue without searching through the rest of the document.
Try the interactive demo
The demo pairs each extracted field with the original document and its lineage. A reviewer can select a flagged field, jump straight to the source region, and see which processing step lowered its confidence. This makes it possible to verify or correct one value without reviewing the entire document.
Open the interactive review demo on openparser.dev
Human review where it matters
We built Lineage for workflows that need high correctness with as little manual work as possible. Every field carries its source, processing steps, and confidence. Reliable fields continue automatically. Uncertain fields go to a reviewer with the evidence needed to verify or correct them.