Designing the Boundary Between AI Document Extraction and Export Permission: Lessons from Aplos

AI document extraction tools often give the impression that the generated field values are the single source of truth. But the developers of Aplos Document Desk explicitly proposed a key design principle in their technical blog: an extraction result is not equivalent to export permission. Model-generated drafts must go through an independent review state transition before they are allowed to enter the CSV export flow. Behind this seemingly simple boundary lies deep thinking about document processing reliability, permission control, and separation of responsibilities.

Why Extraction Results Cannot Be Trusted Directly

The Aplos team points out that a seemingly reasonable value can still be wrong. Dates have multiple interpretations, totals can appear more than once, and credit notes can turn into positive numbers because the parser dropped a sign. These problems are especially insidious in AI extraction—the model will not proactively flag “I’m not sure”; it always outputs the most plausible candidate value.

Therefore, Aplos designs extraction and review as two independent stages. Each field returned by the extractor comes with the original cited text and anchor location, and the application layer verifies whether the cited text actually appears in the source document. But the team also candidly admits that citation matching can only prove that the text exists; it cannot prove that the text corresponds to the correct field, let alone that OCR accurately read the original image.

For monetary fields, simple substring matching is far from enough. If the document says (156.60), finding 156.60 within it does not support a determination of a positive amount. Aplos’s wrapper layer checks the surrounding printed signs and rejects positive candidate values extracted from negative source amounts.

Citation anchor refers to the location information for a value in the source document that the extractor provides along with the field value—usually including the original text snippet, page number, and coordinates. Its value lies in enabling downstream applications to trace and verify: does the extracted value really come from the document, rather than being a hallucination or patchwork by the model? But anchors have clear limits to their capability. Text matching can only prove that “this string of characters exists in the document”; it cannot prove that “this string of characters is the correct source for that field.” For example, an invoice may contain both a contract number and an invoice number, and the two may have similar formats. The anchor can locate the string, but it cannot determine semantic ownership. In OCR scenarios, the anchor may even point to the recognized text layer rather than the original image pixels, so OCR misreadings themselves will not be captured by the anchor. This is why Aplos emphasizes that “citation matching does not equal correct extraction.”

Review as a Server-Side State Transition

In Aplos’s implementation, review is not a front-end interaction event, but a server-side state transition. A document starts as queued or processing, becomes a draft, and then enters states such as reviewed or excluded through an explicit reviewer action. Required-field errors block approval, while warnings such as duplicates or inconsistent totals require the reviewer to confirm and leave a note.

Every update carries a version number, and the server rejects stale changes. Saving edits resets the review status. More importantly—and you may not have noticed—duplicate determination depends on batch context: if the supplier or reference number changes, creating a potential duplicate with a previously reviewed document, then the previous review is invalidated. The green checkmark must describe the current data, not an old version.

The simplified state transition is as follows:

uploaded -> queued -> processing -> draft
draft -> reviewed, after required checks and explicit confirmation
draft -> excluded
reviewed -> draft, after a change that needs renewed review

This is explanatory pseudocode; the production implementation also handles interruptions, expiration, and bounded retries.

The “Sealing” Mechanism Before Export

Preparation for export happens inside a database transaction. Every included document must have been reviewed, while excluded documents are omitted. The server builds the CSV in one pass, saves its bytes and hash, and links the batch to that export job. Repeated preparation requests return the existing job. Once sealed, the batch cannot silently change the file being purchased.

Payment fulfillment uses the existing server-side verification path. A successful browser redirect alone does not grant download permission. A verified payment must match the target account, mode, product, price, quantity, amount, currency, and export job.

This design clearly separates three easily confused facts: the model returned the field, a human reviewed the field, and payment authorized access to a specific artifact. The three are independent and do not substitute for one another.

Hash sealing is the key technical means here. After building the CSV, the server computes a cryptographic hash (such as SHA-256) over its byte content and persists that hash together with the export job. After that, any change to the batch contents—whether adding documents, modifying fields, or adjusting exclusion status—will produce a different hash and thus be detectable. This is similar to an “immutable commitment” in blockchain: the hash itself does not prevent modification, but it makes modification discoverable. In practice, payment fulfillment verifies not merely that “an export job exists,” but that “a verified payment exists for an export job consistent with the current batch hash.” This prevents users from secretly replacing the CSV contents after payment but before download, and also prevents concurrent operations from causing a downloaded file to differ from the one at payment time. For financial document scenarios, this byte-level locking is the foundation of audit traceability.

Testing Focus: Transitions, Not Just the Extractor

The Aplos team’s test cases are not limited to clean invoices. They check ambiguous dates, negative amounts, duplicate files, supplier/reference conflicts, stale updates, post-review edits, pre-review exports, pre-payment downloads, and cross-session source access.

Development evaluation uses the team’s own synthetic documents. This helps expose implementation defects, but it cannot establish accuracy on customer documents, review speed, or performance compared with competitors. Every included document still requires human review.

Currently, Aplos Document Desk supports small batches of English invoices, receipts, and credit notes, and exports document totals. It does not extract line items or perform accounting bookkeeping. Previews are free, and reviewed CSV batches of up to twenty documents cost $9.

Synthetic documents are samples artificially constructed by the development team for testing purposes, rather than data from real customers. Their advantage is controllability: ambiguous dates, negative amounts, duplicate entries, and other edge cases can be precisely injected, without privacy compliance issues. But synthetic documents have a fundamental limitation—they reflect the anomalies developers “think” will occur, not the distribution that “actually” exists in customer documents. The layouts, fonts, language mixing, scan quality, stamp occlusion, and other characteristics of real invoices often far exceed the coverage of synthetic samples. Therefore, Aplos clearly distinguishes “implementation correctness” (verifiable by synthetic tests) from “business accuracy” (which requires real documents and human review to evaluate). This distinction applies to all AI extraction products: passing tests does not equal high accuracy; it only shows that the system does not collapse under known anomalies.

Three Implications for the Industry

First, the reliability boundary of AI extraction requires productized design. Simply pursuing extraction accuracy is not enough; more important is acknowledging uncertainty at the architectural level and managing risk through state machines, evidence chains, and explicit review.

Second, permission separation is the foundation of compliance. Extraction, review, and payment are each independently verified, avoiding the hidden danger of “once one stage passes, everything is released.” This is especially important in financial document scenarios.

Third, testing should cover anomalous transitions across the entire workflow. From ambiguous dates to cross-session source access, true robustness is reflected in the system’s ability to handle edge states, not in extraction precision on clean inputs.

Aplos’s practice provides an architectural paradigm worth referencing: between AI capabilities and business rules, use clear state boundaries to define the scope of trust. The value of this methodology may far exceed mere extraction model optimization.

One-line Summary

AI document extraction results require independent review and sealing mechanisms before export; trust boundaries should be productized.

Paragraph Summary

Aplos Document Desk proposes the design principle that “an extraction result should not also be permission to export,” separating AI extraction from export permission. Fields returned by the extractor come with cited text and anchors, but citation matching can only prove that the text exists, not that the field is correct or OCR is accurate. Review is implemented as a server-side state transition, moving from draft to reviewed or excluded through explicit confirmation, with version numbers preventing stale changes and duplicate determination depending on batch context. Before export, CSV bytes and a hash are sealed through a database transaction, and payment fulfillment must match the account, product, price, and export job. Testing focuses on anomalous transitions such as ambiguous dates, negative amounts, and stale updates, rather than extraction precision alone. This architecture clearly separates three independent facts: model extraction, human review, and payment authorization.