Give the exception somewhere useful to go
A clear scan can still produce a troublesome business record. The date may conflict with an amendment. The recipient may have changed. A missing page may contain the one field needed to finish the job. Better text extraction will not answer every one of those questions.
A review desk should tell the operator what is missing, why it matters, and what they can do about it. The fictional document package below has three exceptions. Each needs a different action, and each action leaves a different state for the next person who opens the work.
Illustrative example · fictional document package
Three exceptions in one package
Request missing evidence, resolve a date conflict, or change a recipient and see why the revised draft needs review.
Choose a checkpoint
Delivery address
Address details continue
on page 2.
Proposed record
- Address
- Incomplete
- Check
- Required source unavailable
The address continues on an absent page. Obtain that page before completing the address.
Start with the output someone needs
Before choosing fields to extract, identify the action the document supports. A draft summary may tolerate an unresolved optional detail. A package prepared for an external recipient may require a complete address, a verified date, and the correct attachments. The required checks follow from that purpose.
In the first example, the address continues onto a page that was not received. There is no honest value to insert. The operator can request the missing page and leave the item waiting for its source. A blank, a guessed address, and a requested document should remain distinguishable in the record.
Keep the received file and its page references available beside the proposed values. If a replacement arrives, associate the new extraction with that version. A colleague should be able to tell which file a value came from without comparing filenames from memory.
Readable text can fail a business check
The second example contains two clearly printed dates. The original document and the amendment disagree. Extraction can succeed on both pages while the proposed record remains unresolved. The reviewer needs the relationship between those documents, including which one is authoritative for this action.
Use deterministic checks for rules that are known: required fields, accepted identifiers, date relationships, and repeated submissions. Keep interpretation close to its source when it needs a person. Microsoft’s guidance on extraction confidence is useful here because confidence describes an extraction result; it does not establish that the resulting business instruction is appropriate.
When the operator chooses the amendment in our example, the proposed date changes and the conflict is marked resolved. That resolution records a reason. It does not automatically approve the whole package. Other checks and the final review still have their own work to do.
An edit changes what the approval means
The third exception begins with an approved draft. A new delivery instruction changes the recipient. The old approval covered the earlier content and destination, so the revised draft needs review. Carrying forward the old approval would make the record say that somebody checked an instruction they never saw.
Bind approval to the particular draft, including the recipient and relevant attachments. Record the decision, the version, and who made it. Keep corrections distinguishable from generated suggestions so another operator can understand how the final content was reached.
A local demonstration can make this boundary visible: change the sample recipient, watch the approved version become a new draft, then review that draft. A real product must enforce the same relationship in the service that performs the write or send. A disabled button on its own cannot establish the rule.
Name the failed check, then test the awkward cases
A queue full of vague “low confidence” warnings gives people a second search problem. Name the failed check and assign the work to someone who can resolve it. Missing material may need the sender; a conflict with an existing record may need the case owner. The interface should supply the relevant source and the proposed correction in the same view.
Evaluate that experience with ordinary documents and awkward ones. Include repeated files, missing pages, inconsistent dates, and a recipient changed after approval. Track unsupported values and reviewer corrections separately. Also check whether the reason shown was useful and whether the reviewer had enough evidence to act.
Keep execution visible after review. A prepared package, an attempted send, and a delivery provider’s response are separate states. If delivery fails after approval, the operator needs to recover delivery while preserving the approved content. Start with one document family and exercise those cases before expanding the workflow.