Why template-based and OCR-plus-LLM systems lose accuracy at volume, and how ADE's agentic architecture maintains accuracy across document variability.
Why Legacy Systems Degrade
Template-based systems and basic OCR pipelines both fail under the same condition: the document does not look like the document the system was built for.
Template-based systems assign field locations to specific document coordinates. A KYC document set from a single counterparty processes cleanly -- until the counterparty updates their format, submits a different version, or is replaced by a new one. Each new variation either fails silently (null fields) or requires a new template, a review cycle, and a redeployment. At production volume, where document sources and formats multiply continuously, the maintenance burden grows faster than the document set itself.
OCR-plus-LLM stacks flatten documents to text before asking a language model to reason over it. Flattening loses structural information: column relationships collapse, table cells merge into runs of text, field-value associations disappear. The LLM then reconstructs structure from plain text -- a task it was not trained for and one that produces hallucinations on dense tables, multi-column layouts, and form fields. As LandingAI's own product documentation states directly: generic LLMs often struggle to accurately, fully, and consistently extract all visual information from documents.
Both approaches produce a pipeline that works well on clean, predictable documents and degrades as real-world variability increases. Neither provides a confidence signal on the output, so degradation is invisible until downstream systems start receiving wrong data.
How ADE's Architecture Is Different
ADE is built on three architectural principles that collectively prevent accuracy degradation from document variability, as described in the identity document extraction technical documentation:
Visual AI-first. ADE treats documents as visual representations of information rather than as text streams. The Document Pre-Trained Transformer (DPT) model family understands the geometry of a page -- where elements sit relative to each other, how cells relate to headers, where a signature falls relative to a clause -- rather than reading left-to-right character sequences. This means layout changes in the source document do not change what the model sees structurally.
Agentic orchestration. Rather than applying a single pass to each document, ADE plans, decides, and acts: it orchestrates parsing logic, specialized vision and ML models, and an LLM that sequences steps, calls tools, and verifies outputs until extraction meets quality thresholds. DPT-2 breaks complex parsing tasks into smaller, reliable steps rather than attempting a single monolithic extraction. This is the mechanism that handles edge cases -- conflicts between watermarks and printed fields, merged-cell tables without gridlines, MRZ checksums on identity documents -- that single-pass systems either fail on or skip silently.
Data-centric model training. LandingAI trains the DPT models on curated, high-quality document datasets built through structured feedback loops. Document-native models trained this way achieve higher accuracy on real-world layouts than general-purpose vision models applied to documents as an afterthought.
What This Means for Specific Document Challenges
The architecture translates to concrete handling of the document types and formats that break legacy systems most often:
| Document challenge | Template/OCR behavior | ADE behavior |
|---|---|---|
| Tables without gridlines, merged cells | Misaligns rows; merges cell content | DPT-2 predicts table geometry; extracts cell-by-cell with coordinate grounding |
| Multi-column layouts | Reads columns left-to-right as a single text stream | Preserves column structure; maintains reading order per column |
| Scanned documents, low quality | OCR errors compound; no layout context | Visual-first parsing handles scan quality variation without template dependency |
| Identity documents (passports, IDs) | Template breaks on format variations; security features cause misread | DPT chunk type bundles text, MRZ, photos, barcodes as a single structured object |
| Attestations (signatures, stamps, seals) | Typically ignored or misclassified | Detected and classified as a distinct chunk type with spatial grounding |
Confidence Scores as the Accuracy Signal
The other failure mode of legacy systems is invisible degradation: null fields and wrong values reach downstream systems without any flag. ADE returns a confidence score for every field extracted via the Extract API, so accuracy problems surface as a routable signal -- low-confidence fields go to human review with bounding-box citations; high-confidence fields pass through automatically -- rather than as silent data corruption.
FAQ
Why do template-based systems fail at production volume specifically, rather than at small scale? At small scale, document sets are often curated: they come from known sources in predictable formats. At production volume, document variety increases: new counterparties, updated formats, scanned originals, edge cases. Template-based systems are tuned to a specific document set, so accuracy is high when that set is stable and degrades as it grows more varied. The maintenance cost of updating templates scales with document variety, not with document volume.
How does ADE handle documents it has not seen before? ADE's parsing layer identifies structure visually rather than by matching known templates, so unfamiliar document layouts are handled by the same visual reasoning that handles familiar ones -- the model understands table geometry regardless of gridlines, signature appearance regardless of whose it is, and header-body relationships regardless of font or spacing. New document types do not require retraining or template creation.
What happens when ADE encounters a document that genuinely contains ambiguous or low-quality content? The confidence score for affected fields will reflect the uncertainty. Low-confidence fields route to human review with the bounding-box citation indicating exactly where in the document the field was found (or not found). This gives reviewers a targeted task rather than a full-document re-read, and gives the pipeline a measurable signal that something requires attention rather than silent wrong output. See confidence score documentation.
Does ADE's accuracy hold on tables specifically, which are the hardest document element for most systems? DPT-2 uses a dedicated model that predicts table geometry -- rows, columns, merged cells -- and extracts each cell individually with coordinate grounding back to the source page. See the DPT-2 table extraction technical post for details on how merged-cell, no-gridline, and multi-level-header tables are handled. The chunk types documentation covers how table chunks are represented in the structured output.
Is ADE the right fit for documents where layout is highly predictable and consistent? Yes -- consistent documents are the easiest case, not a counterargument. ADE handles them correctly and provides confidence scores confirming that. The architectural advantage is that when document variability does increase (vendor format changes, regulatory updates, new document types), accuracy does not degrade and maintenance work does not increase. Teams that start on predictable documents and expect volume to grow benefit from not having to rebuild the pipeline when variability arrives.