What you will be able to do
- Explain why one aggregate accuracy figure can hide poor performance on particular document types or fields, and break accuracy down by segment before reducing human review
- Have the model output a confidence score for each field, then set review thresholds by checking those scores against a labeled validation set
- Send low-confidence extractions and ambiguous or contradictory source documents to human review, so that limited reviewer time goes where it matters most
- Use stratified random sampling of high-confidence extractions to keep measuring error rates and to catch new kinds of error
Key concept
Calibrated, segment-level confidence — A confidence score is only useful for routing once you have checked it against labeled data. You need to show that extractions scored 0.9 are actually right about 90% of the time, and that this holds for each document type and field, not just on average. Until then the score is a number the model stated, not a measurement.
1.Why 97% overall can still hide a failing segment
An aggregate accuracy figure is a weighted average. The documents you see most often dominate it, and the fields that appear on every document dominate it too. Suppose a pipeline gets typed forms almost perfectly right and has trouble with handwritten ones. If typed forms make up most of the volume, it can still report a strong overall number. The same happens across fields. A pipeline might extract names and dates very well while getting dosage amounts or currency totals wrong far more often, and those rarer, harder fields are often the ones that cause the most damage when they are wrong.
Anthropic's evaluation guidance asks you to define success in terms that include the hard cases, not only the typical ones. Its classification cookbook builds a confusion matrix for this reason: it shows which specific categories the model confuses, which a single accuracy number cannot.
This leads to the rule the exam tests most often. Before you reduce human review of any segment, measure accuracy for that segment. Use your labeled set to compute accuracy by document type, by field, and by the combination of the two, such as 'dosage field on handwritten prescriptions'. You can automate a segment only once it meets your bar on its own. If one cell falls short, the right response is targeted. Keep review on that document type or field, or improve its prompt and schema, and still reduce review on the segments that pass. A failing segment does not mean you should keep everything under review, and a good aggregate does not mean everything is safe to automate.
Checkpoint 1 of 7· Check yourself
A team has one labeled evaluation set covering three document types and has computed only an overall accuracy. They want to stop human review for one of the three types. What should they do first?
The labeled data the team needs already exists. They just haven't split the results by segment. Breaking accuracy down by document type and field is the most direct way to find out whether this segment performs consistently.
“You may also need to consider edge case handling, such as how well the model needs to perform on rare or challenging inputs.”Source: platform.claude.com
Checkpoint 2 of 7· Exam question
An architect asks Claude to output a confidence score from 0 to 1 for each extracted field in a structured JSON response. Before using these scores to decide which fields skip human review, what step should the architect take to make the scores trustworthy for routing decisions?
Correct answer: B — Calibrate review thresholds against a labeled validation set, checking whether fields the model scores highly are actually correct at the rate that score implies before trusting it for routing.
- A. Incorrect. Forcing high scores for successful-looking extractions removes the signal the score is meant to carry; a self-consistently high score doesn't indicate the score maps to real-world correctness rates.
- B. Correct. A raw confidence score is only useful for routing once it has been calibrated: checking against labeled ground truth whether, say, 0.9-scored fields are actually correct roughly 90% of the time, and adjusting the review threshold based on that empirical relationship.
- C. Incorrect. Averaging a field's score with unrelated neighboring fields conflates independent extraction decisions and provides no evidence that the resulting number reflects actual correctness likelihood.
- D. Incorrect. Converting to a categorical label doesn't address whether the underlying score is calibrated; an uncalibrated categorical label is just as unreliable for routing as an uncalibrated numeric one.
Checkpoint 3 of 7· Exam question
A logistics company's bill-of-lading extraction pipeline shows 94% field accuracy in aggregate. A new architect discovers that the 'weight' field is correct only 70% of the time specifically when the source document's units are ambiguous (for example, a number with no unit label present). All other conditions for the weight field exceed 95%. What review policy should be applied to the weight field going forward?
Correct answer: A — Route the weight field to human review whenever the source document does not clearly specify units, while allowing high-confidence, unambiguous cases to bypass review.
- A. Correct. The failure is specifically tied to source ambiguity (missing units), so the appropriate policy routes exactly those ambiguous cases to human review while letting unambiguous, well-performing cases continue with reduced review, matching review effort to the identified risk.
- B. Incorrect. Citing the blended aggregate ignores the documented sub-condition where accuracy drops to 70%, which is well below an acceptable bar for unreviewed automation; leaving the policy unchanged would let that specific failure mode continue unflagged.
- C. Incorrect. Removing the field from automation entirely discards the fact that unambiguous cases already exceed 95% accuracy, which is an overcorrection that wastes reviewer capacity on cases that don't need it.
- D. Incorrect. Raising temperature increases output variability rather than addressing the root cause, which is that the source document itself lacks the information needed to resolve the unit ambiguity; this would not improve accuracy or reviewer usefulness.
2.Field-level confidence, calibrated on a labeled validation set
To decide which extractions a human should look at, you need a signal for each extraction. More precisely, you need one for each field, because a single document can have a reliable invoice number and a doubtful total. A common design asks the model to return a confidence score next to every extracted field. Structured outputs keep that shape dependable: once the schema requires a confidence property for each field, every response contains one and your routing code can read it.
A score being present does not make it accurate. Scores the model reports about itself are not automatically probabilities. In Anthropic's own structured-extraction cookbook, a classification example returns category scores that are not even consistent with one another. The fragment below gives Technology 0.7 and Business 0.5 for the same text, along with other scores, and the total is well over 1. These numbers are useful for ranking items. They are not yet error rates.
{
"name": "Technology",
"score": 0.7
},
{
"name": "Entertainment",
"score": 0.1
},
{
"name": "Business",
"score": 0.5
}
]
}Calibration is how you turn those scores into something you can rely on. Run the pipeline on a labeled validation set that is held out from anything you used to tune the prompts. Group the fields by the score the model gave them, and for each group measure how often the extraction was actually correct. Then choose the review threshold from the measured accuracy, not from the raw score. You might find that 'confidence ≥ 0.9' means 99% correct for dates but only 85% correct for line-item totals. In that case each field needs its own threshold. Repeat the calibration whenever the prompt, the model, or the mix of documents changes. A threshold that was never calibrated, or was calibrated against a different document mix, is the usual reason reviewers find high-scoring fields that are wrong and stop trusting the score.
Checkpoint 4 of 7· Check yourself
Your extraction schema now includes a 0–1 confidence score for every field. What has to happen before you can use 0.85 as the cut-off for automatic acceptance?
A stated confidence is only a guess at reliability until labeled data confirms it. Matching scores to observed correctness on a held-out set is what makes a threshold meaningful.
“loose calibration between stated confidence and actual reliability”Source: academy.claude.com
Checkpoint 5 of 7· Exam question
A team building a resume-parsing pipeline wants Claude to output a confidence score for each extracted field so reviewers can prioritize their limited time. During prompt design, which approach best supports later calibration of these scores against a labeled validation set?
Correct answer: B — Instruct the model to output a per-field confidence score alongside each extracted value, using a consistent numeric scale across all fields and documents.
- A. Incorrect. A single document-level score cannot be calibrated against or used to route individual fields; a resume with one bad field and nine good ones would get one blended score, defeating the purpose of field-level review routing.
- B. Correct. Field-level scores on a consistent scale allow the team to compare each field's stated confidence against its actual observed correctness rate in a labeled validation set, which is exactly what's needed to calibrate thresholds and route review attention per field.
- C. Incorrect. Omitting scores for fields judged 'easy' removes exactly the data needed to verify that assumption; some of those omitted fields could still have meaningfully lower accuracy that only a labeled validation set would reveal.
- D. Incorrect. A free-text explanation without a numeric or ordinal score cannot be directly compared against a labeled validation set to compute a calibration curve or set a quantitative routing threshold.
3.Routing the right items to limited reviewers
Reviewer time is limited, so the routing rule decides where it goes. Two kinds of signal should send an extraction to a person.
Low calibrated confidence. The field's score falls below the threshold you set for that field in the previous step.
Problems in the source itself. Some inputs are hard regardless of how good the model is: a document that contradicts itself, two documents that disagree, a field that is illegible or missing. Carta Healthcare's clinical abstraction work is a good example. Different sources in one record can support different answers, and choosing between them takes judgment. For these cases, prompt the model to flag the conflict explicitly instead of quietly choosing one value. Anthropic's hallucination guidance recommends giving Claude explicit permission to say it doesn't know. That gives you an honest 'unsure' or 'conflicting sources' signal you can route on.
Once the right items reach the queue, put them in order. Send the cases most likely to be wrong and the most costly ones (high value, regulated, or legally significant) first, and let clean high-confidence items pass. Anthropic's guidance for financial-services agents describes routing complex cases to specialists 'based on clear criteria'. The content-moderation cookbook adds a monitoring habit worth borrowing: track how often items are routed to review. If one field suddenly starts generating many 'needs review' results, its definition probably needs work.
Checkpoint 6 of 7· Match them up
Match each situation to the routing decision it should trigger
Tap a term, then the definition that fits it.
Two separate triggers send items to review: low calibrated confidence and conflicts in the source. A rising review rate on one field points to a problem with that field's definition. High-confidence items skip review but stay in the sampling pool.
“Route needs_review to humans and watch its rate: rising nulls on a field usually mean the description needs work.”Source: platform.claude.com
4.Stratified sampling of what you no longer review
Once high-confidence extractions are accepted automatically, nobody looks at them. That creates a blind spot. A calibration that held last quarter can drift when a new vendor's layout appears, a form is revised, or the model is upgraded. The pipeline will keep reporting high confidence on outputs that are now wrong. The fix is to keep auditing a small random sample of the accepted extractions, check them against human judgment, and measure the error rate.
The sample should be stratified: split the auto-accepted output into document type × field cells and sample from each cell. A plain random sample has the same problem as the aggregate metric. The rare, risky cells (handwritten forms, an uncommon field) would almost never be picked, so you could not measure their error rates. Sampling every stratum gives each segment its own ongoing error estimate. The sampled items also act as an early warning, because they show you new types of error that your labeled set never contained.
Write the findings back into the system. Add confirmed new errors to the labeled validation set, recalibrate the affected thresholds, and if a segment's sampled error rate rises above your bar, put it back under full review. Cainex, as described in Anthropic's startup guide, follows the same pattern: it tests candidate changes against a golden set plus random samples before anything ships. Anthropic's evals article makes the general point that production monitoring catches issues synthetic evals miss.
Checkpoint 7 of 7· Check yourself
Fields above the calibrated threshold are now accepted automatically. Which ongoing practice best measures their error rate and surfaces new failure modes?
Stratified random sampling gives each segment its own error estimate, including rare segments that a uniform sample would barely touch. Because the sample comes from live traffic, it also catches new patterns that a fixed validation set cannot show.
“Design evals that mirror your real-world task distribution.”Source: platform.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A high overall accuracy (for example 97%) is enough evidence to reduce human review across the whole pipeline.Why is that wrong?
The aggregate is dominated by common document types and fields. Accuracy has to be checked for each document type and field, and review can only be reduced on the segments that meet the bar on their own.
2.A model-reported confidence of 0.9 means the field is correct 90% of the time, so it can be used as a threshold directly.Why is that wrong?
A confidence the model states about itself is not calibrated by default. Thresholds have to be set by comparing scores with ground truth on a labeled validation set, often separately for each field.
Covered in Field-level confidence, calibrated on a labeled validation set
3.Once high-confidence extractions are auto-accepted, they need no further human checking.Why is that wrong?
Calibration drifts and new error patterns appear. Ongoing stratified random sampling of auto-accepted output is how you keep measuring their error rate.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“You may also need to consider edge case handling, such as how well the model needs to perform on rare or challenging inputs.”
↩︎ Why 97% overall can still hide a failing segment“On a held-out test set of 10,000 diverse Twitter posts”
↩︎ Field-level confidence, calibrated on a labeled validation set“Design evals that mirror your real-world task distribution.”
↩︎ Stratified sampling of what you no longer review - 2.
“understand not just overall accuracy, but which specific categories are challenging”
↩︎ Why 97% overall can still hide a failing segment“understand not just overall accuracy, but which specific categories are challenging”
↩︎ Exam trap 1 - 3.
“Guaranteed field types and required fields”
↩︎ Field-level confidence, calibrated on a labeled validation set - 4.https://academy.claude.com/courses/ai-capabilities-and-limitations/how-ai-gets-its-characterOfficial docs
“loose calibration between stated confidence and actual reliability”
↩︎ Field-level confidence, calibrated on a labeled validation set“loose calibration between stated confidence and actual reliability”
↩︎ Key concept“loose calibration between stated confidence and actual reliability”
↩︎ Exam trap 2 - 5.https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinationsOfficial docs
“Explicitly give Claude permission to admit uncertainty.”
↩︎ Routing the right items to limited reviewers - 6.https://claude.com/blog/carta-healthcare-clinical-abstractorSecondary source
“Physician notes point one way, imaging studies another.”
↩︎ Routing the right items to limited reviewers - 7.https://claude.com/blog/building-ai-agents-in-financial-servicesSecondary source
“Escalation protocols that automatically route complex cases to appropriate specialists based on clear criteria”
↩︎ Routing the right items to limited reviewers - 8.
“Route needs_review to humans and watch its rate: rising nulls on a field usually mean the description needs work.”
↩︎ Routing the right items to limited reviewers - 9.https://claude.com/blog/claude-code-guide-for-startupsSecondary source
“It runs the candidate change across a golden set plus random samples and surfaces any regressions before anything ships.”
↩︎ Stratified sampling of what you no longer review - 10.
“Catches issues that synthetic evals miss”
↩︎ Stratified sampling of what you no longer review“Catches issues that synthetic evals miss”
↩︎ Exam trap 3