Somewhere between the elegance of a clean API and the chaos of the real world sits a scanned PDF: a contract with a handwritten amendment in the margin, an invoice whose line-item table breaks across three pages, a claim form photographed at an angle in bad light by someone standing in a parking lot. Most of the world's commercially important information still lives in documents like these. Document intelligence is the discipline of turning them into something a machine can act on — and it is quietly where a large share of agentic AI's realized value actually lives.
The last analog bottleneck
Every industry that has been digitized still runs on paper somewhere. Insurance claims arrive as photographs of forms. Freight moves on bills of lading. Mortgages close on stacks of statements, appraisals, and disclosures. Healthcare exchanges faxes — actual faxes — at a volume that would embarrass a 1997 office. These are not legacy pockets awaiting cleanup; they are the connective tissue between organizations that will never share a database, and they persist because a document is the only interchange format that every party already accepts.
The economic shape of this is stark. Companies employ enormous numbers of people whose job is to look at a document, find six fields, and type them into a system. The work is repetitive enough to be miserable and variable enough to resist the rule-based automation of the last two decades. Every attempt to fix it with templates has foundered on the same rock: the moment you have a template for one vendor's invoice, the second vendor sends a different layout, and the third sends a photograph of the second.
What changed is that models can now read a page the way a person does — seeing the layout, understanding that the number in the bottom right of a box labeled Total is the total, tolerating a coffee stain and a skewed scan. That capability does not eliminate the pipeline. It relocates the difficulty from parsing to verification, from writing extraction rules to deciding what to trust. This post is about that relocated difficulty and how to build systems that survive it.
What document intelligence actually means
The phrase covers a stack of related problems that are worth separating, because teams routinely solve one and assume they have solved the others. At the bottom is text recovery: getting characters off a page, whether from an embedded text layer or from pixels. Above it sits layout understanding: knowing that these characters form a table cell, that heading, this footnote, and that the reading order runs down two columns rather than straight across.
Above that sits information extraction: mapping recovered content onto a schema you care about — invoice number, due date, counterparty, effective date, the eleven fields your downstream system requires. Higher still sits document reasoning: answering questions that require synthesizing across pages or across documents, like whether this amendment supersedes that clause, or whether the totals on the invoice reconcile with the purchase order and the receiving report.
At the top sits action: doing something because of what was read. Approving the payment, flagging the discrepancy, opening the case, updating the ledger. Only the top layer produces business value; every layer below it is infrastructure. The common failure is to invest heavily in the bottom of the stack, achieve excellent character accuracy, and then discover that the thing standing between you and automation was never the characters — it was the confidence to act without a human checking first.
Why documents are harder than they look
A document is a rendering, not a data structure. It was produced by someone who wanted a human to understand it, using conventions that live entirely in the reader's head. Alignment implies association. Proximity implies grouping. A line under a number means it is a subtotal. Bold means important. Whitespace does the work that a schema would do in a database, and none of it is declared anywhere.
Worse, the conventions vary by domain, by country, and by vendor. Dates are ambiguous across locales in ways that silently corrupt data — a payment due on 03/04 is due in March or April depending on who printed it. Currency symbols are omitted when everyone in the room knows the currency. Negative amounts appear in parentheses, in red, with a trailing minus sign, or with the word Credit nearby. Names are abbreviated. Addresses are wrapped. Page numbers restart when documents are stapled together.
Then there is the physical layer. Scans are skewed, cropped, upside down, or duplexed with blank backs. Photographs have shadows, glare, and fingers. Faxes lose resolution to the point where an 8 and a 3 become the same smudge. Multi-document PDFs arrive as a single 400-page file containing forty unrelated documents with no separator other than a change of letterhead. Any pipeline that has not planned for this will spend its first month in production learning about it.
The OCR era and what it could not do
Optical character recognition is old, mature, and genuinely good at what it does. Modern engines recover printed text at accuracy rates that look excellent on a slide — well above ninety-nine percent per character on clean input. The trouble is that per-character accuracy is the wrong metric for a business process. A single wrong digit in an account number invalidates the entire extraction, and a document with two thousand characters at ninety-nine percent accuracy contains, on average, twenty errors.
The deeper limitation was structural. Classical OCR returns a stream of words with bounding boxes and no notion of what those words mean to each other. To turn that stream into fields, teams built template systems: for this vendor, the invoice number lives in the rectangle three centimeters from the top and eleven from the left. These systems worked beautifully for the vendors they were built for and not at all for anyone else, which meant an eternal backlog of template requests and a maintenance burden that grew linearly with the number of counterparties.
The escape hatch was rules plus regular expressions plus a great deal of institutional knowledge encoded in code that nobody wanted to touch. It automated the head of the distribution and left the tail to humans, which is a defensible outcome — but the tail in most document workflows is enormous, and the marginal cost of extending coverage kept rising just as the marginal value kept falling. That curve is what modern models bent.
Layout is meaning
The pivotal insight of the last generation of document models is that spatial position is semantic information and should be fed to the model as such. A word's coordinates on the page tell you as much about its role as the word itself. Approaches that encode two-dimensional position alongside token identity — and later, approaches that simply let a vision encoder look at the page — outperformed text-only pipelines dramatically on exactly the tasks that mattered: forms, tables, and anything where the label and its value are related by geometry rather than by grammar.
This is why feeding a naively extracted text dump into a language model disappoints so reliably. Flattening a two-column page into a single stream interleaves unrelated sentences. Flattening a table destroys the row-column correspondence that carried all the meaning. The model then does its best with scrambled input and produces a confident answer built on a misreading, which is the worst of both worlds: wrong, and fluent about it.
The practical consequence is that your parsing layer should preserve structure, not discard it. Whatever representation you hand to the model — annotated markup, a serialization that keeps table boundaries explicit, or the page image itself — it must encode the geometry that a human reader uses. Teams that upgrade nothing else but their parser, moving from raw text extraction to a layout-preserving one, routinely see extraction accuracy jump by double-digit percentages with no change to the model or the prompt.
Vision-language models change the shape of the problem
Multimodal models that accept page images directly collapse several pipeline stages into one. There is no separate OCR step whose errors propagate downstream, no separate layout analyzer, no serialization format to argue about. You show the model the page and ask for the fields. For many document types this now works well enough on the first try that the old pipeline looks like an artifact of a previous era, which in a meaningful sense it is.
The gains are largest exactly where classical systems struggled: unfamiliar layouts, handwritten annotations, documents that mix printed and written content, and anything requiring judgment about which of three plausible date fields is the one you asked for. A model that has seen millions of documents brings priors about how invoices work, and those priors substitute for the template you would otherwise have had to author.
The costs are real too. Page images consume far more tokens than text, so a fifty-page document becomes an expensive request. Resolution matters enormously — downsampling an image until small print becomes illegible produces confident nonsense rather than an error. And the failure mode shifts from missing data to invented data: a text pipeline that cannot find a field returns nothing, while a vision model that cannot read a field may produce something plausible. This single difference is why verification, discussed at length below, stops being optional.
A pipeline that survives contact with reality
Despite the temptation to reduce everything to one model call, production systems converge on a recognizable sequence. Ingest normalizes whatever arrives — email attachments, scanner drops, API uploads — into a canonical form with a stable identifier and an immutable original. Preprocessing handles the physical layer: deskew, denoise, correct orientation, split multi-document files at detected boundaries, and reject the pages that are genuinely blank so you do not pay to look at them.
Classification comes next and earns its keep more than any other stage. Knowing that a document is an invoice rather than a purchase order lets you select the right schema, the right prompt, the right validation rules, and the right downstream route. Misclassification is uniquely destructive because every subsequent stage does competent work on the wrong premise, and the resulting errors look like extraction failures rather than routing failures, sending debugging effort in exactly the wrong direction.
Then extraction against a schema, validation against business rules and external systems, confidence scoring, and a routing decision: automatic acceptance, targeted human review, or full manual handling. Finally, action and archival, with the extracted data linked permanently back to the source region it came from. Each stage should be independently observable, because the question you will ask most often in production is not whether the pipeline failed but where.
Splitting and chunking documents that have structure
Retrieval systems taught everyone to chunk text at fixed token counts with a little overlap. Applied to documents, this is close to malpractice. A fixed-size window cheerfully cuts a table in half, separates a clause from its heading, and orphans the definition of a term from every place the term is used. The retrieved chunk then arrives at the model without the context that made it interpretable.
Structure-aware splitting respects the document's own boundaries: sections, articles, clauses, table units, form regions. A contract chunks naturally at clause level with the section heading and defining preamble attached to each piece. A financial statement chunks at statement level, keeping a table and its footnotes together because the footnotes are frequently where the meaning hides. The unit of chunking should be the unit a human would quote.
Long documents also need a navigational layer above the chunks. Extracting a table of contents, or synthesizing one, lets an agent jump to the relevant article instead of retrieving semantically similar fragments from six unrelated sections. For a two-hundred-page agreement, the difference between searching and navigating is the difference between an answer that cites the right clause and one that confidently cites a similar clause from an appendix that does not apply.
Schemas: deciding what you want before you ask
The quality of a document extraction system is bounded by the quality of its schema. Vague field names invite vague answers: a field called amount on an invoice with a subtotal, a tax line, a shipping charge, and a total is an invitation for the model to pick one arbitrarily and for the picks to vary between runs. Precise names, explicit types, units, and formats remove that ambiguity before it can cause harm.
Descriptions carry more weight than most teams expect. Telling the model that invoice_total means the final amount payable including tax and shipping, expressed in the document's own currency, resolves the exact confusion that would otherwise generate a support ticket. Enumerated values for categorical fields prevent the slow drift where the same concept arrives as Paid, PAID, and paid-in-full across three months of data. Optionality should be explicit, and there must be a sanctioned way to say the field is absent.
That last point deserves emphasis. If your schema requires every field, the model will fill every field, including the ones the document does not contain. A required due date on a receipt that has no due date produces a fabricated date rather than an admission. Nullable fields with an explicit not-present convention convert a silent data corruption into a visible gap, and visible gaps are things a workflow can route around.
Tables, the perennial problem
Tables are where document intelligence goes to be humbled. They span pages with headers that repeat or do not. They merge cells to express hierarchy. They nest subtotals among line items. They use indentation as a grouping mechanism with no other marker. They put units in the header, or in the first row, or nowhere. And they are almost always the part of the document that carries the money.
Several tactics help. Extract tables as a distinct stage with their own prompt and their own output shape, rather than as one field among many in a general extraction. Ask for the header row explicitly and separately from the body, so a misaligned header does not silently shift every value one column left. Where a table spans pages, stitch it before extraction rather than after, because a model that sees only page two cannot know what the columns mean.
Then verify arithmetically. Line items that should sum to a subtotal, subtotals that should sum with tax to a total, quantities times unit prices that should equal extended amounts — these are free, deterministic checks that catch a large fraction of table errors without any model involvement at all. A pipeline that extracts a table and does not attempt to reconcile it is leaving its cheapest quality signal unused.
Handwriting, signatures, and the marks people make
Printed text is the easy case. Real documents carry handwriting: a corrected figure with initials beside it, a checkbox filled with an ambiguous mark, a margin note that changes the meaning of the clause it sits next to, a signature block that determines whether the whole thing is binding. Handwriting recognition has improved enormously, but it remains materially less reliable than print, and its errors are less predictable.
The right posture is to treat handwritten content as a different confidence class rather than as more text. A pipeline can extract printed fields with high automation and route any document containing detected handwriting into a review queue, or at least flag the specific regions. This is not defeatism; it is triage. The handwritten portion is typically a small fraction of the page and a large fraction of the risk, and separating the two lets you automate the rest.
Signatures and stamps deserve their own handling because the question asked of them is usually presence rather than content. Is this signed? Is it dated? Is the corporate seal applied? These are detection problems with clean binary answers and correspondingly clean evaluation, and they are frequently the actual gate on a business process. A model that reads every clause of a contract perfectly but cannot reliably tell you whether page fourteen was initialed has not solved the workflow.
Reasoning across pages and across documents
Many of the questions that matter cannot be answered from a single region. Does the delivery address on the invoice match the one on the purchase order? Does this amendment change the termination notice period established in the master agreement? Is the total across twelve monthly statements consistent with the annual summary? These require holding several places in mind at once, and they are where document intelligence graduates from extraction to genuine reasoning.
The engineering answer is to make cross-references explicit rather than hoping the model reconstructs them. Extract each document into structured form first, then reason over the structured forms, where a comparison is a cheap deterministic operation instead of an act of literary interpretation. Where the reasoning must happen over raw content, retrieve the specific relevant passages from each document and present them together with clear labels about which document each came from.
Document families need identity management of their own. A claim is not one document; it is a bundle that accretes over weeks. A loan file is dozens of artifacts with dependencies. Modeling the bundle as the unit of work — with a state machine tracking which required documents have arrived, which have been superseded, and which conflict — turns an unbounded reasoning problem into a bounded bookkeeping one, and bookkeeping is something software has always been good at.
Confidence, and knowing when you do not know
The single most valuable output of a document pipeline is not the extracted value. It is a trustworthy estimate of whether the extracted value is right. With good confidence, you can automate the confident majority and route the rest to people, which is the entire economic proposition. Without it, you must review everything, and reviewing everything means you have built an expensive way to produce suggestions.
Useful confidence comes from combining independent signals rather than from asking the model how sure it is, which produces numbers that sound calibrated and are not. Format validation asks whether the value looks like what it claims to be. Business-rule validation asks whether it is possible — a date before the contract start, a total that exceeds the credit limit, a tax rate that does not exist in that jurisdiction. Cross-field consistency asks whether the values agree with each other. External lookup asks whether the vendor exists in your master data.
Agreement-based signals are the most powerful and the most expensive. Extract the same field twice with different prompts, different models, or different input representations, and treat disagreement as a flag. Where the stakes justify it, this catches errors that no single-pass system can, because the failures of independent methods tend to be independent. Calibrate the resulting composite score against a labeled sample so that a stated ninety-five percent actually corresponds to being wrong one time in twenty, and re-calibrate after every model change.
Human review as a designed stage, not an apology
Every serious document system has humans in it, and the ones that work treat that as an architectural decision rather than a temporary embarrassment. The design questions are which items reach a person, what the person sees, how long the decision takes, and what happens to the correction afterward. Getting these right can move a review from ninety seconds to twelve, which at volume matters more than several points of model accuracy.
The interface should show the extracted value next to the exact region of the page it came from, highlighted, so the reviewer verifies rather than re-reads. It should present the fields most likely to be wrong first, ordered by confidence, and allow a single keystroke to accept a correct value. It should never ask a person to hunt for a field in a document while retyping it from scratch, which is the design that makes review feel slower than doing the work manually — because it is.
Corrections are training data and should be captured as such: the original prediction, the corrected value, the region, the reviewer, the timestamp. This corpus is the most valuable asset the system produces. It measures real-world accuracy, drives prompt and schema improvements, supplies fine-tuning examples when prompting plateaus, and reveals which document sources are systematically problematic. Teams that discard corrections after applying them are throwing away the compounding advantage of having operated the system.
Grounding: every value points back to a pixel
An extracted field without provenance is an assertion. An extracted field with a page number and a bounding box is a citation, and the difference determines whether anyone can audit your system. Grounding lets a reviewer verify in a glance, lets a dispute be resolved by looking, and lets a regulator be answered with evidence rather than with a description of your architecture.
Implementations vary in cost. Layout-aware text pipelines carry coordinates naturally, so grounding is nearly free. Vision pipelines can be asked to return bounding boxes alongside values, with mixed reliability, or grounded after the fact by searching the recovered text layer for the extracted string and taking its location. The hybrid approach — vision for extraction, text search for localization — is a common and pragmatic compromise that gets most of the benefit.
Grounding also disciplines the model. Requiring a citation for every field makes fabrication harder, because a value invented from priors has nowhere on the page to point. Some systems go further and verify the citation programmatically: if the extracted value does not appear at the claimed location, the extraction is rejected regardless of how confident it looked. That check is cheap, mechanical, and catches precisely the failure that worries everyone most.
Evaluating a document pipeline honestly
Aggregate accuracy is a comfortable number that hides everything interesting. The metrics that drive decisions are per-field, because fields differ wildly in difficulty and in consequence, and per-document-type, because a system that is excellent on your top vendor and poor on the tail will look fine in aggregate and fail in operation. Report a matrix, not a number.
Distinguish the error types, since they demand different fixes. A missing field where one existed is a recall problem. A wrong value where one existed is a precision problem and usually the most damaging. A fabricated value where no field existed is a hallucination problem and the most alarming. A correct value in the wrong field is a schema or alignment problem. Collapsing these into one accuracy figure guarantees that you will apply the wrong remedy.
Build the evaluation set from real traffic, deliberately over-sampling the ugly cases: the worst scans, the rarest layouts, the documents that generated complaints. Freeze it, label it carefully, and version it. Then measure end-to-end business outcomes alongside field accuracy — straight-through processing rate, review minutes per document, downstream correction rate — because those are the numbers that justify the system, and they can move in the wrong direction even as field accuracy improves.
Cost and latency at document scale
Documents are large, and large inputs are expensive. A single page rendered at a resolution high enough for small print can cost more tokens than an entire chat conversation, and a mortgage file runs to hundreds of pages. Multiply by the volume of an operations department and the arithmetic gets real quickly. Cost control is therefore not a late-stage optimization but a design constraint that shapes the whole pipeline.
The highest-leverage move is to avoid sending pages to expensive models unnecessarily. Classify cheaply, then route: a small model or a classical parser handles the clean, familiar, high-volume formats, while the frontier model is reserved for the difficult tail. Extract only the pages that matter — an eleven-field extraction rarely needs page ninety-four. Cache aggressively, since documents are immutable and the same file is often processed more than once by different parts of the business.
Latency shapes the product rather than the budget. Batch pipelines that run overnight can afford multiple passes, consensus extraction, and full-document reasoning. Interactive flows where a customer waits while their identity document is verified have a few seconds, which rules most of that out. Decide early which regime you are in, because the architectures diverge quickly and retrofitting an interactive experience onto a batch pipeline is a rewrite rather than a tuning exercise.
The long tail and the eighty-percent trap
Document workloads follow a brutal power law. A handful of formats account for most of the volume, and thousands of formats account for the rest. The first pilot always targets the head, succeeds impressively, and produces a plan to extend coverage to the tail on a linear schedule. The tail does not cooperate. Each additional percentage point of coverage costs more than the last, and the documents out there are weirder than the sample suggested.
The strategic response is to stop treating full coverage as the goal and start treating confident routing as the goal. A system that handles seventy percent of documents automatically, identifies the remaining thirty percent correctly, and hands them to a well-designed review queue is enormously valuable and entirely achievable. A system that attempts all hundred percent and cannot tell you which of its outputs to trust is worth less than the manual process it replaced, because now someone must check everything and the checking is harder.
Coverage then grows the right way: from operational data. The review queue tells you exactly which formats consume the most human minutes, and those are the ones worth specific investment. This is a far better prioritization signal than a survey of document types, because it weights by actual cost rather than by perceived importance, and it updates itself continuously as your document mix drifts.
Compliance, retention, and where documents are allowed to go
Documents are dense with regulated information — identity numbers, health details, financial records, the personal data of people who never agreed to have their claim form processed by a third-party model. The compliance posture must be established before the architecture, because it constrains the architecture. Which providers may see the content, in which jurisdictions, under what retention terms, and with what contractual assurances about training are not questions to answer after the pilot succeeds.
Redaction is the standard mitigation and is itself a document intelligence problem, with the uncomfortable property that a miss is unrecoverable once the content has left. Redacting before transmission means detecting sensitive regions with a local model, masking them in both the image and the text layer, and verifying the mask actually covers the pixels rather than merely drawing a rectangle over content that remains selectable underneath. That last mistake has embarrassed more than one organization publicly.
Retention rules apply to derived data as much as to originals. Extracted fields, embeddings, intermediate images, review-queue snapshots, and model logs are all copies of the document in a legal sense, and a deletion request that removes the original while leaving five derivatives scattered across a pipeline has not been honored. Build the data map when the system is small enough to map, and make deletion a first-class operation rather than a script someone writes under pressure.
Agents that act on what they read
Extraction is the input to a decision, and the interesting systems close that loop. An accounts-payable agent reads the invoice, matches it against the purchase order and the goods receipt, checks the vendor is approved and the amount is within tolerance, and either schedules payment or opens an exception with a specific reason. A claims agent assembles the bundle, checks completeness, applies policy rules, and either settles within a threshold or routes to an adjuster with the relevant pages already highlighted.
These agents inherit every concern from the wider agentic literature — tool design, guardrails, approval boundaries, observability — with one document-specific twist. Their perception layer is unreliable in a way that a database query is not, which means every action must be traceable to the evidence that motivated it. When an agent pays the wrong invoice, the investigation needs to establish whether it misread the document, misapplied the rule, or read correctly a document that was itself fraudulent. Those are three different incidents with three different fixes.
Authority should therefore scale with confidence rather than being granted uniformly. Low-value, high-confidence, fully reconciled items can proceed automatically. Anything with a confidence flag, an unmatched reference, a new counterparty, or an amount above a threshold requires a person, and the person should be presented with the agent's reasoning and its citations rather than with a raw document and a decision to make from scratch. That gradient is what makes autonomy safe enough to expand.
Fraud, tampering, and adversarial documents
Documents arrive from outside your trust boundary, which makes them an attack surface. Amounts get altered in a PDF editor. Dates get shifted. Entire invoices get fabricated from a template with a real vendor's letterhead and a criminal's bank details. As automated processing removes the human who might have noticed that something looked off, the incentive to attack the pipeline rises accordingly.
Some defenses are technical and cheap. PDF metadata and revision history reveal edits. Inconsistent font rendering within a line, mismatched compression artifacts, or text that sits at a subtly different baseline than its neighbors are signals of manipulation. Reconciliation against independent sources — does this vendor exist, is this bank account the one on file, does this purchase order exist — catches the fabrications that look perfect on the page because they were never intended to be examined at the pixel level.
Prompt injection deserves specific mention, since a document is untrusted input that a model reads. Text placed in a document, including text rendered invisibly or in tiny print, can attempt to instruct the model processing it. An extraction system that treats document content as data rather than instructions, that constrains outputs to a schema, and that never lets document content dictate a tool call is structurally resistant. One that pastes page text into a general-purpose agent prompt is not, and the exploit is as simple as a white-on-white sentence in a footer.
Failure modes worth naming
Certain accidents recur across every implementation. The confident fabrication: a required field with no source on the page, filled with something plausible, propagating silently into a ledger. The silent misclassification: a credit note processed as an invoice, doubling a payment. The units error: an amount extracted correctly and interpreted in the wrong currency because the symbol was absent and the default was wrong. The stale template: a vendor changes its layout, accuracy for that vendor collapses, and nobody notices because aggregate accuracy barely moves.
Then the operational ones. The review queue that grows faster than it is drained, so the automation that was supposed to reduce work has instead relocated it into a backlog. The confidence threshold set once during the pilot and never revisited as the model, the prompt, and the document mix all changed underneath it. The evaluation set assembled from clean examples, producing metrics that predict nothing about production because production is where the bad scans live.
And the quiet one: success that hides degradation. A pipeline running at high straight-through rates generates little feedback by construction, because confident items are not reviewed. If the confidence estimate drifts, errors flow through unexamined and are discovered months later by an auditor. The countermeasure is a permanent random sample of auto-accepted documents routed to review anyway — a small, deliberate tax that buys the only unbiased measurement you will ever have of what your automation is actually doing.
Getting started without overbuilding
The productive first project is narrow: one document type, one clear business process, a schema of no more than a dozen fields, and a labeled sample of a few hundred real documents drawn from actual traffic rather than from a tidy folder. Build the simplest thing that produces structured output with citations, measure it per field against the sample, and look hard at the errors before adding any machinery.
Next, add validation and confidence, then a review interface, then routing. Resist fine-tuning until prompting and schema work have plateaued, because most early accuracy problems are specification problems wearing a technical costume — an ambiguous field description, a missing enumerated value, a parser that flattened the table. Resist building a general document platform until you have shipped one document type end to end, since the abstractions you would invent beforehand are almost always the wrong ones.
Instrument from day one: every prediction, every confidence score, every correction, every review duration, retained and queryable. The compounding asset in this field is not the model, which will be replaced within a year, and not the prompt, which will be rewritten. It is the corrected corpus and the operational history that tell you precisely where your documents are hard. Teams that have that can adopt each new model in an afternoon and know within a day whether it helped.
The bottom line
Document intelligence is the least glamorous and most immediately profitable corner of applied AI. The problem is old, the volume is enormous, the manual cost is measurable, and the technology finally crossed the threshold where the tail of the distribution is addressable rather than merely acknowledged. Organizations sitting on rooms full of people retyping fields from PDFs are sitting on the clearest return available anywhere in this technology.
But the systems that work are not one model call. They are pipelines with classification, structure-preserving parsing, precise schemas, deterministic validation, calibrated confidence, grounded citations, and a review loop designed as carefully as the extraction. The model supplies the perception that was previously impossible. Everything around it supplies the reliability that makes perception actionable, and that surrounding machinery is where the engineering actually lives.
The mental adjustment required is small but decisive. Stop asking whether the model can read the document, because it usually can. Start asking how you will know when it could not — and what your system does in that moment. Answer that well and documents stop being the place where automation ends. They become just another input, imperfect and untrusted like every other input from the outside world, and handled accordingly.