Confidence decides who looks next
Routing Document AI output with field-level confidence, so the model never decides the outcome on its own.
00 // BriefingMost of the time is the problem
Document AI is now good enough to read most business documents most of the time. "Most of the time" is the problem. A proposal form with twenty fields, nineteen of them read perfectly, can still be wrong in the one field that changes the price or the risk.
The answer is not a better model. It is an architecture where confidence decides who looks next: the model reads everything, and a person looks only at what the model doubts.
01Field-level confidence
A single score for a whole document hides the field that matters. A document read with high average confidence can still contain a date of birth the model was unsure about.
Ask your extraction step for a confidence on every field, and keep those numbers all the way through the workflow. Where the model or service does not give a usable score, build one: agreement between two extraction passes, validation against a known format, or a check against data you already hold.
Four fields come back from document AI: proposer_name at 0.98, pan at 0.97, sum_assured at 0.99 and date_of_birth at 0.71. Three flow straight through. One goes to a person.
Combine the model’s confidence with deterministic checks. A date of birth that parses but makes the applicant 140 years old should fail validation, whatever the model’s score.
02Choosing the threshold
The threshold, 0.85 in that case, is not a technical constant. It is a business trade-off between two costs: people reviewing fields that were already right, and errors slipping through that nobody checked.
- Start with a labelled sample of real documents where the correct values are known.
- For each candidate threshold, measure two numbers: how many fields go to review, and how many wrong values would pass without review.
- Choose with the business owner, field by field if needed. A wrong postcode and a wrong sum assured do not cost the same.
- Revisit it when the model, the documents or the volumes change.
Make the threshold configuration, versioned like any other rule, so it can change without a release and you can explain later which value was live.
03Calibrate before you trust a number
A confidence score is only useful if it means what it says. Many models and services return scores that are not calibrated: a field scored 0.9 is not necessarily right nine times out of ten. Before you build routing on a number, check what the number actually predicts.
- Take a labelled sample and group fields by score: 0.95 and above, 0.90 to 0.95, and so on.
- For each group, measure how often the extracted value was actually correct.
- Do it per field and per document type. Dates, amounts and names rarely behave alike, and a clean digital form is not a phone photo of a printout.
- Set thresholds on observed accuracy rather than the raw score, and repeat the check whenever anything upstream changes.
Ask one question of any score: when it says 0.9, how often is it right? If nobody can answer, the threshold is a guess.
04Designing the review step
Confidence routing only works if the review step is fast and focused. Otherwise reviewers either drown or rubber-stamp.
- Show the doubtful field next to its source: the part of the document where the model found it.
- Pre-fill the model’s value and make correcting it a single action.
- Send only the doubtful field, not the whole case.
- Route by skill: a medical disclosure to an underwriter, a smudged address to an operations reviewer.
- Measure review time and how often reviewers change the value. Both tell you whether the threshold is right.
05Recording the decision
Every routed field should leave a record you can replay later: the extracted value, the confidence, the rule and threshold version that routed it, who reviewed it, what they changed and when.
That record does two jobs. It answers the auditor’s question of how a value got into the system, and it is the best evaluation data you will ever have: real documents, real model output and a person’s correction.
Never let a low-confidence value silently become the system of record. If a field skips review because of a bug or a timeout, the workflow should stop, not guess.
06Failure modes to watch
- Clean samples, messy reality. A threshold tuned on tidy test documents fails on real scans. Tune on what production actually receives.
- Drift. A new form layout or document source can quietly shift the scores. Watch the share of fields sent to review; a sudden change is a signal.
- Anchoring. Reviewers who always see the model’s value tend to accept it. Spot-check a sample of reviews, and now and then ask for the value without showing the model’s guess.
- A queue nobody owns. Review queues need a service level and an owner, or uncertain cases simply wait.
- Reviewing forever. A field that is always low-confidence is a design problem. Fix the form, the scan quality or the source instead of paying for review on every case.