Intelligent Document Operations
An AI-assisted intake-to-transaction system that preserves review and audit evidence.
- Reference architecture
- Concept
- Application evidence
- Local slice implemented
- Data
- 15 fabricated text fixtures
- Test boundary
- Local rules and browser controls
Values come from the document.
Authority comes from the system.
The working slice makes that distinction tangible. Its parser reads allowlisted labels, its fixed register resolves identifiers, and a person must approve the exact revision before a local record can be created.
No PDF/OCR, model inference, real identity service, server authorization or destination API is implemented. The local role selector is not authentication.
Implemented local control path
- InputFabricated documentText supplies values, never permission.
- InterpretationSix labeled fieldsExact matches with source lines. No inference.
- AuthorityRules + reference registerMissing values and unknown IDs hold the order.
- DecisionExplicit human approvalOne field revision. Edits or revocation clear it.
- ActionGuarded local commitFailure stays visible. A retry is explicit.
- EvidenceReconciled memory recordRepeat commit returns the existing record.
A failed or revoked attempt cannot advance itself.
Inspect the boundary.
Try the failure cases.
Begin with an ordinary fixture, or choose one of the control tests. Nothing leaves this exercise. The ledger and event history reset when you reset or reload the page.
Loading the local workbench. The control path and full reference argument remain available below.
Try to make it
do the wrong thing.
The result matters more than the happy path. These are exercises in the implemented local slice, not evidence about an AI model or a production integration.
Write without approval
Run extraction, then attempt a commit before approval. Expect a visible refusal and no new ledger record.
Inspect: latest event + ledgerFail, retry, repeat
Choose “Failed adapter, then retry.” Approve once. The first attempt writes nothing; retry creates one record; repeat commit creates no additional record.
Inspect: attempts + destination IDChange the decision
Approve a revision, then correct a field or revoke approval. Commit must require a new explicit approval.
Inspect: field revision + audit historyChallenge the source
Try an unknown identifier or the malicious instruction fixture. Unknown IDs hold approval; document text cannot grant permission. Observer controls stay read-only.
Inspect: validation + role controls
What this establishes.
What it leaves open.
Inspectable here
- Source-linked fields, correction reasons and revision history.
- Deterministic validation and explicit approval guards.
- One synchronous local failure, explicit retry and session-scoped duplicate prevention.
- In-memory record reconciliation against the reviewed snapshot.
Still requires a real system
- Inference quality, calibrated confidence and document parsing.
- Authenticated identities, tenant isolation and server-side authorization.
- Durable jobs, persistent audit evidence and real API contracts.
- Concurrency, ambiguous remote acknowledgements and distributed retry behavior.
The known hostile note is a supplied fixture, not a general prompt-injection detector. One line item and CAD are supported. Local state-machine tests do not establish production security, accuracy, throughput or client outcomes.
A document arrives as a PDF, an attached email, or a scanned quotation request. Someone has to interpret the content, identify the right customer and items, determine what is missing, confirm that business rules are met, and produce a structured transaction in an existing system. The model is useful in the middle of that process. It is not the process itself.
This reference application is designed to show the difference between a file extraction demo and a complete operational product. It combines ingestion, classification, extraction, validation, contextual retrieval, human review, committed API actions, exception handling and a visible history of what happened. The workflow deliberately includes failures and unknowns.
What the interface should show
Intake queue. The reviewer sees the originating document, customer identity, current status, assigned owner, elapsed time and the confidence of each extracted field. A claim that the system is 97% accurate must not appear without a real evaluation corpus and a documented definition of accuracy.
Evidence beside extracted data. A suggested quantity, part number or invoice term links to its source span. Users can accept, change or reject individual values and leave a reason. The software records the source, the suggestion, the reviewer and the final decision separately.
Rule and reference matching. The application distinguishes text interpretation from business checks. The model may suggest that 'part XYZ' corresponds to an internal catalog item. The authoritative catalog API decides whether that item exists. A pricing rule service, not the language model, determines whether a discount is permitted.
Exception workbench. Ambiguous or conflicting requests must be reviewable. The interface surfaces why a transaction cannot proceed: an unknown customer, two plausible part matches, missing approval, failed destination API or duplicate submission. It does not hide these states behind a success animation.
Commit ledger. Once approved, the application writes to a simulated operational system, returns the destination identifier, prevents duplicate commits through idempotency keys and allows reconciliation. An explicit record of who approved what is visible.
Reference system architecture
- Upload and webhook ingestion with file type/size limits, malware safeguards and a request identity.
- Durable job state machine: received → classified → extracted → validated → review required → approved → committed → reconciled.
- File parser and document extraction adapter with pluggable model/provider.
- Normalized extraction schema with per-field confidence signals that are empirically calibrated, never presented as certainty.
- Deterministic validation, reference lookups, duplicate checks and source citations.
- Reviewer UI with roles, edit history, diff and explicit approval.
- Destination API adapter with typed contracts, retries, idempotency, dead-letter queue and reconciliation.
- Structured logs, trace IDs, redacted observations, cost accounting and an evaluation harness.
Trust boundary: A document can contain adversarial text such as 'ignore previous instructions' or a request to issue a credit. Document content is untrusted input. It never grants tool permissions or changes server-side policy.
Synthetic demonstration dataset
Use synthetic business entities and fully fabricated documents: six ordinary purchase orders, three missing-data cases, two mismatched identifiers, one duplicate transaction, one malicious instruction embedded in a supplier note, one failed write followed by retry, and one approval revocation. Make dataset generation deterministic with a seed and label it synthetic in the UI. Publish the test matrix; do not pretend it reflects a client's performance.
What to test before calling it a working demo
- A human must authorize every irreversible write; the model cannot bypass the approval state.
- The application must refuse a transaction when an authoritative identifier cannot be resolved.
- Two identical retries must create at most one destination record.
- A deliberately malformed document must show an actionable review state, not an endless spinner.
- A prompt-injection string in the PDF must not alter tool permissions or bypass review.
- Audit history must show the original document, model suggestion, reviewer correction and committed result.
- Keyboard-only users must complete a full review and approval cycle.
- A reviewer must be able to identify which fields came from the document and which from a system of record.
Where custom engineering is justified
A basic OCR service may already capture the text. The custom opportunity exists when information must flow through company-specific validation, approvals and operational systems, and the organization needs an interface designed for its exact work. If a commercial workflow platform already satisfies those requirements, configuration and integration may be preferable to a custom build.