Your document AI needs a review budget, not just a better score

A document extractor can improve its average score while the person using it still spends the afternoon checking every file. The missing product question is how much checking the system can safely remove. That question includes the model, the review queue, the evidence interface, and the mistakes people make after seeing a convincing answer.

LlamaIndex’s October 15 ExtractBench Pro announcement is a useful prompt to revisit that question. Its 100 synthesized documents cover six difficult document patterns. The evaluation adds the share of documents achieving perfect Value F1, alongside value and grounding scores. Failed or over-time documents receive zero under a 30-minute limit. These are publisher-reported benchmark conditions, not results reproduced by Build Lab.

For a small team building document automation, the useful next experiment is more specific than choosing a leaderboard winner: under a fixed reviewer-time budget, which combination of queue policy and evidence presentation leaves fewer consequential errors in accepted records?

This article proposes that experiment. No extractors, reviewers, or customer workflows were tested for it. All quantities in the worked example are invented arithmetic, and the protocol’s suggested sample sizes are discovery choices, not validated safety thresholds.

Start with the record someone must use

Consider a hypothetical product called Dispatch Desk. A small operations team uploads service reports and receives draft maintenance records. Each record needs the equipment identifier, service date, completed work, a measurement with its unit, and a recommended next visit. Staff confirm records before they enter a scheduling system. This is a sandbox scenario; the experiment must never create real maintenance orders.

A wrong optional comment might be inconvenient. Attaching a correct measurement to the wrong machine could change the next action. Before comparing systems, the team must define which errors make a record unusable and who can resolve an ambiguous source. The product owner and a domain reviewer should agree on this definition without seeing candidate outputs.

Use two outcome labels. A strictly correct document has every required extracted value correct under a frozen schema. An action-ready record satisfies the product’s narrower acceptance contract: every action-relevant field is correct, required evidence is sufficient, and unresolved ambiguity prevents acceptance. An optional descriptive field can therefore make the first label fail while the second passes. Report both; never rename the second as the benchmark’s perfect-document metric.

The original ExtractBench paper separates extracted-value quality from source traceability. That distinction helps define the contract, but the maintenance product’s action rules remain the team’s responsibility. A public benchmark cannot decide which field changes a customer’s next action.

Keep value, evidence, and release outcomes separate

Value F1 summarizes precision and recall over extracted items. It is not a probability that the next record is usable. A high aggregate can conceal an omitted identifier or a relationship assigned to the wrong row. A perfect-document measure asks a different question, with a document rather than an individual item as its unit.

Grounding concerns whether the claimed source supports the answer. The ExtractBench repository describes page-level and word-level grounding metrics; correct values alone do not satisfy them. Their published matching rules are benchmark rules, not a universal definition of sufficient evidence for your product.

For Dispatch Desk, a quoted measurement might need its row heading and unit legend as well as the number. A tight crop around the number can be accurate yet insufficient for a reviewer to establish which machine it belongs to. Treat this as an evidence requirement to annotate, not a reason to secretly alter the benchmark scorer.

Keep a third outcome for what ultimately leaves review. A correct model answer can become incorrect during editing; an incorrect answer can be repaired or left unresolved. Preserve original output, reviewer edits, final decision, and adjudicated result separately. Otherwise, a report of excellent final accuracy can conceal a model that required extensive reconstruction, or a quick review interface that encouraged incorrect acceptance.

Freeze outputs before testing human review

The proposed study separates offline screening from two human trials. Offline analysis compares routing and automatic-accept errors; it cannot establish review time or final reviewed accuracy. A queue trial then compares three policies using one fixed interface. A separate interface trial holds the selected queue fixed. This prevents an attractive interface from getting credit for an easier queue.

Start with 60 authorized, de-identified documents if the team can annotate them properly. This is a practical discovery target, not a power calculation. Select them from a documented intake interval before running the extractor. Record excluded files and reasons. Include common layouts, repeated records, cross-page rules, ambiguous sources, and documents the product must refuse. Preserve the intake mix in one group and deliberately challenging examples in another; do not pool their rates as though they were representative traffic.

For this suggested 60-document discovery design, reserve 20 documents for development, 24 for the queue trial, and 16 for the interface trial. Keep the human-trial banks disjoint. Divide documents by template or source family between development and held-out banks; variants of one report must stay together. Use development files to clarify schema, evidence needs, and queue rules. Lock those choices before viewing held-out outcomes. A single team member should not tune the queue on the same labels later used to claim an improvement.

Run one frozen extractor configuration, save every output and timeout, and retain configuration identifiers. Changing models between review conditions would change the thing being reviewed. Version the source documents, schemas, expected values, evidence regions, ambiguity rules, and consequential-error labels. Restrict access to the answer key; reviewers should not see it during a trial.

Build a queue that can be wrong in measurable ways

A confidence threshold is an understandable starting policy. Amazon Textract’s guidance recommends considering both confidence and application sensitivity when routing uncertain results for scrutiny. That guidance does not establish one threshold for every extractor or document family.

Record exactly what a confidence value refers to. Microsoft’s Document Intelligence documentation distinguishes word, field, and document-type signals and notes that not every field returns a score. A missing score must have an explicit handling rule. Do not silently convert it to certainty, or average unrelated score types into a new probability.

Compare three candidate queues using identical outputs. The first routes by a documented confidence rule. The second adds structural warnings: missing required fields, mismatched row counts, conflicting units, and unsupported source references. The third uses the second policy but reserves part of its review time for a random audit of the records it would otherwise accept.

These are proposed product policies, not descriptions of any vendor’s default behavior. Choose thresholds and warning precedence on the development group. Log why each document was routed and which fields triggered it. Define stable tie-breaking, such as intake order, before the run. A queue that only sends obvious failures to humans can look efficient while repeatedly missing confident errors from one unfamiliar template.

Compare policies at the same budget

The budget is reviewer time, not the number of files opened. Ten short forms and ten dense reports do not consume the same resource. Set a plausible session budget from the team’s actual staffing constraint and explain why that constraint matters. For an initial discovery session, 30 minutes may be convenient; it has no safety significance and is unrelated to the benchmark’s per-document timeout.

The offline queue comparison cannot know true review durations yet. Use development-session timings only for screening and ordering estimates. For the queue trial, recruit six target reviewers and form three matched eight-document sets, A, B, and C, from the 24-document bank. Label the policies P1 (confidence), P2 (confidence plus warnings), and P3 (P2 plus random audit). All sessions use the same answer-first interface and the same time limit. Assign sessions in the following order; each person encounters each document only once, while every set meets every policy across people.

Apply each policy to the entire assigned set, including automatic acceptances, rather than substituting easier documents when review is slow. For P3, freeze an audit-time allocation on development data and select its audit pool before looking at truth. Report actual completion and elapsed time per session, then compare matched sets across policies. Six reviewers and small sets support directional discovery, not a precise causal effect or deployment guarantee. Do not quietly delete slow cases to make a policy fit. When time expires, unfinished reviews remain unresolved, with their elapsed time counted.

For each policy report automatic-accept coverage, the fraction of eligible documents accepted without review; escaped consequential-error rate among those automatic acceptances; and the record error rate across all final accepted records after review. For both error rates, the numerator counts records containing at least one consequential error, each record at most once. Report field-error counts separately. Give numerators and denominators beside every rate. Also report time per action-ready record, unresolved backlog, timeouts, and the volume of unsupported documents.

Selective classification research formalizes the trade between accepting more predictions and rejecting uncertain cases. It motivates plotting error against coverage. Its statistical guarantees do not transfer to this proposed document workflow: there is no calibrated rejector or validated distribution assumption here. Display the team’s observed points without turning a small pilot into a risk guarantee.

Test whether the interface helps people verify

Once offline screening and the queue trial identify a promising queue, hold that queue fixed and compare two review presentations. Both must provide the complete document, equivalent navigation, identical extracted values, and the same ability to edit, defer, or reject. The intervention is when the candidate answer becomes visible.

In the answer-first condition, show the extracted value beside its claimed evidence immediately. In the evidence-first condition, initially show the source region and its surrounding context for an action-relevant field. Ask the reviewer to record an initial reading or choose “cannot determine,” then reveal the extracted value and allow a final decision. Include the initial-reading time in the budget. Do not make uncertainty require extra justification while acceptance takes one click.

This intervention is a hypothesis about independent checking. Buçinca and colleagues found that cognitive forcing reduced overreliance in their study, with subjective-experience tradeoffs. That result does not demonstrate that this interface will improve document review. The added step might instead waste time or encourage superficial compliance.

Nor should the team conclude that explanations are always harmful. Vasconcelos and colleagues show that verification costs and benefits can affect reliance, and that explanations can help under particular conditions. An accessible source jump may be more useful than hiding an answer. Measure whether this specific intervention improves correction and acceptance decisions within the available time.

Counterbalance people and cases without teaching the answers

For the separate interface trial, use four target reviewers and the untouched 16-document bank. They may come from the six-person queue trial, but must not have seen these cases or their answer keys. Explain that the product is being evaluated, not their job performance. Obtain permission for session recording if used, and avoid sensitive customer files. This study can expose failure mechanisms; it cannot establish population-wide effects from a few participants.

Create two matched eight-document sets, D and E, using layout complexity, action-relevant field count, and adjudicated error type. Use the same selected queue and time budget in every session. The four assignments are D/answer-first then E/evidence-first; D/evidence-first then E/answer-first; E/answer-first then D/evidence-first; and E/evidence-first then D/answer-first. Every case meets both interfaces across reviewers, with order balanced. No person sees a case twice: remembering a hidden unit exception would make the second presentation artificially easy. Record dropouts or assignment deviations; do not silently treat an unbalanced study as balanced.

Give equal practice on separate documents. Use neutral instructions: verify the record, correct it if warranted, or defer when the source is insufficient. Never suggest that every test document contains an error. Include correct outputs, inconsequential errors, consequential errors, and unresolvable cases so indiscriminate rejection does not appear successful.

Keep natural model errors separate from deliberately seeded probes. Seeded wrong units or swapped identifiers can ensure that both interfaces encounter the same failure type, but their frequency is chosen by the experimenter. Report their detection rates as stress-test results. They cannot estimate the extractor’s production error frequency. A probe must preserve a plausible source and should not become a puzzle with an obvious artificial typo.

Use a review-budget worksheet

The reusable artifact is a document-level ledger linked to field-level evidence. Copy the following columns into a spreadsheet or a database. Store detailed source content separately under the team’s access policy; the ledger should use document identifiers rather than exposing customer text to everyone who needs summary results.

For raw extractor timeouts, record whether the intended product falls back to manual transcription, asks for a clearer upload, or refuses the job. Measure that actual handling cost separately. A missing output must not disappear from the denominator simply because the interface had nothing to display.

LlamaIndex’s extraction-agent API reference exposes configuration options for citations and confidence. If using that service, preserve the effective configuration with the output. Availability of a setting is not proof that every field has useful confidence or sufficient evidence. The worksheet must retain the returned state, including missing values, rather than assume the requested setting guarantees them.

Read the arithmetic before declaring a winner

Here is invented arithmetic to demonstrate the denominators. Suppose a held-out group contains 40 eligible documents. A policy automatically accepts 24, and independent annotation identifies three records containing consequential errors among those 24. Automatic-accept coverage is 24/40, or 60%. The observed escaped-error rate for automatic acceptance is 3/24, or 12.5%.

Suppose reviewers finish eight of the other 16 documents during a 30-minute session, accepting six after verification or correction. Two are rejected, and eight remain unresolved. There are now 30 final accepted records. If the six reviewed acceptances contain no remaining consequential error, the final accepted-record error rate is 3/30, or 10%. That does not mean 90% of intake is safely automated: only 30 of 40 documents were accepted, six required human work, and the three automatic mistakes still escaped.

If another policy catches one additional mistake but finishes three fewer documents, the product owner needs both outcomes. More intervention is not automatically better when the unresolved queue misses service commitments. Conversely, faster acceptance is not valuable when it moves an unacceptable error downstream.

Keep recovery work in the accounting. Record time spent reopening a record, locating the correct source, changing the scheduled draft, and notifying an internal operator in the sandbox. Do not invent monetary harm or combine unrelated consequences into a single financial estimate. Use observed minutes and clearly separated error classes until the team has defensible business data.

Audit what the queue would hide

A random audit of automatically accepted records is essential because queue-selected records are not representative. The third policy explicitly pays for that audit from the same time budget. It should not receive extra reviewer capacity while competitors spend their entire allocation on exceptions.

Draw the audit sample before inspecting hidden truth. For the discovery study, independently annotate every held-out document, including automatic acceptances, so all three queues can be compared against the same reference. The random-audit component then tests an operational policy; it is not the only source of evaluation labels.

In later production observation, when full annotation is unavailable, retain the sampling probability and pool for each audited record. An unweighted average of a heavily sampled challenge category and lightly sampled routine category is misleading. Report results within strata or use a justified weighting method with uncertainty. Never infer the whole population’s error rate from whichever rejected documents happened to receive attention.

Separate disagreement from model failure. If adjudicators disagree about the applicable unit or the source contradicts itself, resolve the contract or mark the case indeterminate. Report the count and why it was excluded from correctness scoring while retaining its handling time and unresolved status. Otherwise a seemingly objective answer key can reward unjustified certainty and penalize the reviewer who correctly paused.

Decide what to change, and where the result stops

Write the decision rules before the held-out sessions. Use the pilot to choose among concrete next actions: change the evidence interface, alter queue warnings, restrict supported document families, or collect more data. Do not use it to authorize unattended processing of consequential records. A document family with observed consequential escapes should remain under full review or be unsupported until a separately justified evaluation supports broader automation.

If evidence-first reduces wrong acceptances but consumes the budget before routine work finishes, try it only for fields whose consequences justify the cost, then retest that narrower intervention. If both interfaces fail on cross-page rules, improve the context shown or the schema contract before buying a stronger model. If the queue misses confident wrong outputs, add a tested structural signal and keep the random audit. Each response addresses a different failure mechanism.

Report person-level variation and case-level results alongside totals. Several successes from one reviewer on one template do not establish a general effect. A small sample with no observed escapes is still compatible with unseen errors. Changes in language, scan quality, document source, staffing, or extractor configuration should trigger renewed observation, not inherit the pilot’s conclusion.

This protocol fits repeated document-to-record workflows with inspectable sources and available domain reviewers. It does not validate autonomous medical, legal, or safety-critical decisions, and it cannot repair unknowable source truth. Its practical deliverable is a comparison of review work and remaining mistakes, with enough detail to decide the next experiment. For today’s builder, that is the change worth making: reserve a measured budget for verification, and test what that budget actually buys.

References

1. LlamaIndex: ExtractBench Pro announcement, October 15, 2026. Current-event trigger; publisher-reported design and results.
2. ExtractBench repository. Extraction and grounding definitions; distinct configurations.
3. ExtractBench: A Benchmark for Schema-Guided Enterprise Document Extraction. Original benchmark paper, not a new Pro-specific independent replication.
4. Amazon Textract: Best Practices. Application-sensitive confidence handling.
5. Microsoft: Interpret and improve model accuracy and confidence scores. Confidence types and missing field scores.
6. Geifman and El-Yaniv: Selective Classification for Deep Neural Networks. Risk and coverage background; its guarantees are not claimed here.
7. Buçinca, Malaya, and Gajos: To Trust or to Think. Cognitive forcing and reliance tradeoffs in the authors’ study.
8. Vasconcelos and colleagues: Explanations Can Reduce Overreliance on AI Systems During Decision-Making. Verification cost and explanation context.
9. LlamaIndex: Extraction Agents API reference. Configuration contract; no service execution performed here.