Route incoming documents with a reviewable decision trail

Start with the record the team needs, not the scanner

Imagine a service desk receiving a request form, an equipment photograph and an unrelated document in one submission. The useful outcome is not “text extracted.” It is one correctly typed request with fields the team can check, a clear decision about missing or conflicting information and a traceable handoff. Write the intended record type, required fields, authorized destination and the first business action it could trigger before selecting a processor.

Define the intake states in ordinary language: received, held for file checks, awaiting classification, awaiting extraction, needs correction, awaiting review, approved, routed, reconciled or rejected. A processor result is a proposal within those states. Keep the original file and processing output restricted to the people who need them; record an opaque reference and version rather than copying document contents into a public tracker or analytics.

This starts after safe file receipt. The secure-file-upload guide owns permitted formats, scanning, storage, access and retention. This page owns the interpretation and business handoff of a file that has passed those ingress controls. The small-business lead-form guide owns which questions to ask a prospective customer, consent context and form success states. A typed form may skip OCR, but a document-driven service case still needs the field, validation and routing decisions below.

Classify the document and preserve page boundaries

List only document classes that change the required fields, reviewer or destination: for example, service request, supporting photograph, existing-job correction and out-of-scope material. Include an explicit “unknown” route. Decide whether a packet can contain several logical documents and whether each page belongs to exactly one item. A mistaken split can attach a field to the wrong request, so a disputed page boundary must be reviewable before extraction is treated as final.

Google Document AI describes a custom classifier that assigns a class from a defined set, commonly before an extraction processor. Its splitter output represents subdocuments as entities with a type, confidence and page references. Those are useful coordinates for a review screen; they are not an instruction to accept every classification. Record the proposed class, page range, processor and version, and the reviewer’s correction when the class or boundary is wrong. Test mixed packets, rotated pages, duplicates, blank pages and a document that belongs to no approved class.

Keep every extracted field tied to its source

For each destination field, write the source field or mark, expected type, whether it is required, and the exact source location a reviewer can inspect. Retain both the literal value and any normalized value, such as a standardized date, so a correction does not erase what the document said. Keep the source document reference, page, text or key-value anchor where available, processor version and extraction status with the draft record. A reviewer should be able to open the right page from a flagged field without searching the whole packet.

Google’s Form Parser can return key-value pairs, tables, selection marks and text; its Document response provides text and page anchors. Amazon Textract AnalyzeDocument returns linked key and value blocks, words, lines and geometry. These products demonstrate possible evidence, not a requirement to use either vendor. Some inputs have no reliable field location or readable value. Represent that as missing or uncertain rather than filling it from a plausible guess. If generative AI participates, treat instructions embedded in a customer document as untrusted content; OWASP describes prompt injection as a way that input can redirect model behavior.

Run business rules separately from extraction

OCR can read “Friday” accurately while the request still lacks a date, conflicts with another page or refers to a closed job. Specify rules at the destination boundary: required values, allowed formats and ranges, parent-record match, cross-field consistency, duplicate detection and whether a correction requires a new document. Validate server-side even if the upload screen or processor appeared to check the field. OWASP’s Input Validation guidance recommends field-specific rules and validation when data crosses a trust boundary, including from internal systems.

Give each failed rule an outcome: reject an impossible value, request missing information, or hold a discrepancy for an authorized reviewer. Do not silently “clean” a value into a different meaning. Keep an error code, source reference and proposed correction in the restricted case. The source-of-record guide decides which system owns a field after handoff; this intake guide decides whether the incoming candidate is ready to enter that system.

Send uncertainty to a reviewer who can stop the action

Route a case for review when its class is unknown, a page split is disputed, a required field is missing, two sources disagree, a rule fails or an extraction cannot be checked from the source. Confidence may help prioritize cases, but it is a processor estimate, not proof of truth. Microsoft’s Document Intelligence transparency note recommends evaluating representative documents for the intended use before setting a confidence threshold and keeping human intervention possible. There is no universal threshold for this workflow; a high score does not override a failed business rule or a consequential action gate.

The review queue needs a named role and deputy, source view, flagged fields, permitted decisions, due time and escalation route. The reviewer can correct with a reason, ask the sender for more information, reject the item or approve the final record. Preserve the original candidate, changed value, decision maker, decision time and version in the restricted operational system. If no reviewer is available, the item stays pending with an owner; it does not become approved when a timer expires.

Enforce a technical hold between the draft and the downstream action. Creating a job, sending a confirmation, changing an existing record or exporting to another tool must require the approved record version and current authorization. A visible “needs review” label alone cannot stop an automated integration. The AI human-review guide covers this output-to-action principle across many AI workflows; here it is applied field by field to a document packet and its source evidence.

Route one approved version and verify the destination

After approval, map the final fields to a destination record and record the destination’s accepted identifier and version when it exposes one. Otherwise, retain the approved intake version and the destination readback as separate evidence. Check whether the request already exists before creating another one. Use a stable intake reference for retries, and verify the destination state after an accepted write; an API acknowledgment is not evidence that every field landed correctly. Amazon Textract documents a separate start, completion and result retrieval sequence for asynchronous analysis: a completed extraction job is still distinct from acceptance by the business destination. If a correction follows approval, reopen the decision and send a versioned amendment rather than quietly overwriting the earlier source trail.

Keep a visible exception for a timeout, rejected write, duplicate, conflicting destination value or missing acknowledgment. The failure-recovery guide owns retry schedules, alerts and operator restoration for the wider automation. This guide requires that each document’s intake reference resolve to one verified destination outcome or an owned exception, so the team can reconcile the packet without guessing. Do not claim a customer message was delivered merely because the document was processed.

Fill the matrix and rehearse the awkward cases

Download the ungated CSV. Its first data row is a blank template. The other rows are a clearly hypothetical service-request packet and test cases; they contain no real person, client or measured outcome. Use one row for each class, field, rule or exception that changes an intake decision. Keep a working copy with actual records in an authorized private system, never in this public download.

The illustrative tests include a mixed packet, an unknown document, a missing date, a conflicting job reference, an instruction hidden in document text, a reviewer outage, a duplicate retry and a destination mismatch. The intended outcomes are holds, corrections or verified routing according to the row. Try these with synthetic documents and actual integration behavior before release. Add your own representative document variations, then review missed classifications, field corrections, review workload and unmatched destination records after launch.

• Intake item and test case | Proposed class and page scope | Target field | Source anchor and literal value | Normalized draft value | Required rule and cross-check | Uncertainty or exception | Accountable reviewer and decision | Downstream hold condition | Approved record version | Destination and idempotency reference | Reconciliation evidence and status.
• Record a deliberate “not applicable” when a column does not fit a class; leave unknown facts pending. Keep actual names, document text and private IDs in the restricted case record.