Document intelligence: the production pattern that turns inbound documents into structured business action.

Intelligent Document Processing is the modern, LLM-augmented evolution of OCR. Where OCR is "image to text", IDP is "document to structured business action". A complete IDP pipeline has five stages: ingest the document, classify its type, extract the fields the workflow needs, validate against business rules, route to the appropriate downstream system. Exception cases are surfaced for human review. The metric that matters in production is straight-through processing (STP) — the percentage of documents resolved end-to-end without human intervention. MindMap's DocuMage routinely achieves 94% STP across heterogeneous document types in production deployments.

OCR is the first step of a document pipeline — converting an image (or PDF rendered as image) into machine-readable text. Modern OCR — Tesseract, PaddleOCR, AWS Textract, Azure Form Recognizer, Google Document AI — handles printed text reliably. But text alone is not structured data. "4,28,940" on a row labelled "AMOUNT" needs to become an integer field tied to an invoice record. That work is IDP. Teams that buy OCR and assume the rest follows discover their automation programme stalls at the first non-template document. IDP is what closes the gap.

Six categories define most enterprise IDP volume. (1) Invoices and accounts payable — supplier invoices, three-way matching, exception routing. (2) Claims documents — insurance claims, supporting documentation, schema-driven extraction. (3) Contracts and trade finance — clause discovery, counterparty identification, regulatory checking. (4) KYC and onboarding documents — ID verification, source of funds, address proof. (5) Medical records — admissions, discharge summaries, referrals with ICD-10 coding. (6) Regulatory filings — dossier preparation, source-document extraction, consistency checking. MindMap has shipped all six at production volume.

Template-based extraction works on standardised forms with known field coordinates — useful for highly structured documents like passport pages or VAT forms. It collapses on the layout-free document types (contracts, correspondence, unstructured claims) that make up the long tail of enterprise document volume. LLM-augmented extraction uses an LLM with a target schema to extract fields the way a human reader would — robust to layout variation, language variation, and partial information. The engineering pattern: prompt the model with the schema, return extracted fields plus per-field confidence scores, route low-confidence fields to human review. MindMap's DocGenie ships this pattern in production for layout-free workloads, paired with classical OCR for the structured ones.

Schema-driven extraction inverts the classical approach. Instead of training a model to identify all possible fields, the model is given the target schema at inference time and asked to populate it. The schema acts as a strong prior on what to look for. The operational payoff is iteration speed — adding a new field to an extraction workflow is a schema edit, not a model retrain. The trade-off is per-document cost (an LLM call per document is more expensive than running a trained extractor), which is why production deployments often run a cheap classifier first to route only long-tail documents to the LLM path.

Four engineering disciplines. (1) Classifier-first routing — a cheap classifier filters documents to the right extraction path, so the expensive LLM is only used where it earns its keep. (2) Schema-driven LLM extraction with per-field confidence scores — low-confidence fields get human review, high-confidence fields flow through. (3) Business-rule validation — the extracted fields are checked against business rules (totals match, dates valid, counterparty registered) before the workflow advances. (4) Exception design — the 6% that doesn't go straight-through is the value engineering: structured exception UX, clear escalation paths, audit trail. Teams that optimise for raw extraction accuracy and neglect exception design see STP plateau at 75%.

Yes — and for regulated industries this is the default. MindMap's sovereign IDP stack runs entirely inside the customer's perimeter: OCR + parsing on customer compute, LLM serving via vLLM on customer GPUs, schema + business rules in customer-owned configuration, exception UI on customer infrastructure, audit logs streamed to the customer's SIEM. The compliance posture matches the customer's sovereign LLM serving layer because they share the same cluster. PII redaction (Redacto) runs inside the perimeter so sensitive fields are masked before any downstream sharing.

MindMap Digital's standard sovereign IDP deployment is 6–9 weeks from contract to first production workflow. Week one: document inventory and pipeline design. Weeks two to three: stack deployment (OCR, classifier, LLM serving, extraction service, validation service, exception UI). Weeks four to five: workflow integration, eval-set build with customer SMEs. Weeks six to seven: pilot with hypercare. Weeks eight to nine: phased rollout to full volume. Subsequent document types on the same platform deploy in two to three weeks because the infrastructure, identity integration and exception UI are already in place.