Design Extraction, Validation, Confidence, and Duplicate Controls

What you will complete

Complete field validation, confidence, duplicate, exception, ownership, and override rules for the selected family.

Use four independent questions

1. Is the file supported, complete, and readable?
2. What value did the extractor return, with what evidence and confidence?
3. Does that value satisfy deterministic business rules?
4. Has the same source or business document already been handled?

File checks cover type, extension, size, encryption, emptiness, and page support. Extraction checks cover fields and source spans. Deterministic checks cover required values, data types, arithmetic, lookups, relationships, and allowed ranges. Duplicate checks compare both source identity and business identity.

Keep exception codes specific. “Failed” does not tell an owner what to do. Codes such as unsupported type, missing invoice number, conflicting total, unknown supplier, duplicate source, duplicate business key, approval timeout, and destination timeout can map to different owners and recovery paths.

Use confidence to route, not authorize

Confidence is a model signal. Its meaning and calibration vary by platform, model, field, and document set. A threshold copied from documentation is an example, not a universal policy. Leave thresholds blank until you test representative files and decide the cost of each error.

Set rules per field where consequences differ. A description may tolerate review sampling while a bank account, amount, identity, or date remains always-review. Passing confidence does not bypass arithmetic, duplicate, supplier, or approval controls. Failing confidence does not prove the value is wrong; it creates a review reason.

Record threshold version and test evidence. When the model or corpus changes, recalibrate rather than assuming an old value still applies.

Worked example: three invoices, three decisions

Fictional example: INV-TP-2401 extracts cleanly and 400.00 + 52.00 equals 452.00. It becomes ready for review, not automatically approved. A second copy stops before review because its source hash or vendor-plus-invoice-number key matches the existing record.

INV-TP-2404 from fictional Prairie Bolt & Fastener Ltd contains subtotal 210.00, tax 10.50, and printed total 185.00. The extractor may read every value correctly. The deterministic rule still raises conflicting_total because 210.00 + 10.50 equals 220.50. The system preserves 185.00 as the printed value and asks a person to resolve the document.

A missing invoice number remains null and raises missing_invoice_no. The test policy rejects it by default. A real business may define an override, but that path needs separate authority, justification, and tests.

Complete Workbook Section 3

1. Write file acceptance and rejection rules.
2. Define deterministic rules for each required field and relationship.
3. Leave confidence thresholds blank or cite the corpus used to calibrate them.
4. Choose source and business duplicate keys.
5. For each exception, name status, owner, allowed actions, draft-write effect, and required evidence.

Use Section 3 of the workbook.

Control failures to avoid

• Using one document-level score for every field and consequence.
• Treating high confidence as approval.
• Checking exact file duplicates while missing rescanned business duplicates.
• Silently replacing a supplier total with calculated arithmetic.
• Allowing exceptions to continue because the queue is inconvenient.

Module 4 turns these controls into a review queue where a named person can inspect the source, uncertainty, and current version.

Check your application