# Intelligent Document Operations — Reference Architecture

> An AI-assisted intake-to-transaction system that preserves review and audit evidence.

Canonical URL: https://marmation.com/lab/intelligent-document-operations/

## Implementation boundary

The reference architectures are concepts, not completed client systems. Intelligent Document Operations includes an implemented local browser demonstration with 15 fabricated text fixtures and deterministic rules. It uses no AI provider, real authentication, persistent destination or external business write. Its role controls illustrate guards; they are not production authorization.

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

1. Upload and webhook ingestion with file type/size limits, malware safeguards and a request identity.  
2. Durable job state machine: received → classified → extracted → validated → review required → approved → committed → reconciled.  
3. File parser and document extraction adapter with pluggable model/provider.  
4. Normalized extraction schema with per-field confidence signals that are empirically calibrated, never presented as certainty.  
5. Deterministic validation, reference lookups, duplicate checks and source citations.  
6. Reviewer UI with roles, edit history, diff and explicit approval.  
7. Destination API adapter with typed contracts, retries, idempotency, dead-letter queue and reconciliation.  
8. 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.

## Related reading

- [Proof has a structure.](https://marmation.com/lab/)
- [From working prototype to dependable system](https://marmation.com/review/engineering/)
- [AI Product Review Workspace — Reference Architecture](https://marmation.com/lab/ai-product-review-workspace/)