# AI Document Extraction in Production: Parse, Extract, Validate, Review

> How to run AI document extraction as a production pipeline: separate parsing from schema-constrained field extraction, choose OCR, a vision model or a hybrid, validate values, route doubtful ones to a human, version the schema, and work out cost per page.

Guide: Document extraction pipelines in production (pillar)
Published: 2026-10-25 · Updated: 2026-10-25 · 5392 words · ~7171 tokens (estimate)
Canonical: https://changegamer.ai/articles/ai-document-extraction-pipeline-in-production
JSON: https://changegamer.ai/api/articles/ai-document-extraction-pipeline-in-production.json

## In short

- AI document extraction works best as two separate stages: Stage A parses raw files into faithful text and structure, and Stage B pulls specific fields into a validated schema, and merging them is the most frequent architecture mistake.
- Schema-constrained decoding guarantees that a document extraction response has the right shape, not that the values are right, so totals, dates and identifiers still need checking in your own code.
- Cost per page for document extraction is a worksheet, not a price: parse fee, model tokens, retries and the share of pages a human must review all enter, and only the reader can fill in the last three.
- A document extraction pipeline should send a field to a human reviewer when a deterministic check fails, a required field is missing or the model refuses, and any numeric confidence cut-off must be calibrated on labelled documents.
- Text inside a parsed document is untrusted input, because OCR faithfully transcribes hidden instructions, so extraction calls should run with no tools and write only through a validated record.
- As of October 2026 ChangeGamer runs no production document-extraction pipeline and publishes no throughput, accuracy or cost figure for one, so this guide is synthesized from its reference corpus.

---

AI document extraction fails quietly: the pipeline returns well-formed JSON, the dashboard stays green, and a total is wrong by a digit that nobody checks until the books do not balance. This guide is the hub of a cluster on running extraction as a production system. It covers the split between reading a page and filling a schema, the choice between OCR, a vision model and a hybrid, the provider mechanics of schema-constrained output, validation, human review, schema versioning, cost per page and the choice between open-source and managed tooling.

The scope is the extraction pipeline only. Chunking and retrieval belong to [how to chunk documents for RAG](/articles/chunking-documents-for-rag) and the [RAG ingestion pipeline](/articles/rag-ingestion-pipeline). Generic structured-output and tool-call mechanics belong to [structured outputs versus tool calling](/articles/structured-outputs-vs-tool-calling) and [tool-calling contracts for AI agents](/articles/tool-calling-contracts-for-ai-agents). Defense in depth against injection belongs to [prompt injection defense in depth for agents](/articles/prompt-injection-defense-in-depth-for-agents). The reference page behind most of this guide is [Document Extraction and Parsing for Agents](/resources/document-extraction-for-agents), updated 2026-09-28. It states the contract; this article is about the decisions around it.

A note on evidence. The corpus gives no accuracy benchmark for any parser and, apart from the Mistral OCR figures quoted in the cost section, no price. This article invents none. Where a statement is the author's reasoning rather than a corpus claim, it is labelled as inference.

## What is a document extraction pipeline, and why does it have two stages?

A document extraction pipeline has two stages with different jobs: Stage A converts raw bytes (PDF, DOCX, image) into a faithful Markdown or JSON representation, and Stage B pulls specific fields, such as an invoice total, a signatory name or table rows, into a validated schema. The reference page lists treating those two stages as one as the single most frequent architecture misstep, in two directions: attempting field extraction on a document that was never cleanly parsed, or running a heavy extraction pipeline over files that only ever needed a Markdown conversion for retrieval.

The distinction matters because the stages fail differently and are fixed with different tools.

| | Stage A: parse | Stage B: extract |
|---|---|---|
| Input | Raw file: PDF, scan, image, office document | Parsed text or structure, or the page image itself |
| Output | Faithful representation: text, headings, tables, reading order | A typed record matching a schema you own |
| Typical failure | Lost reading order, flattened tables, missed text in a rotated scan | Missing field, wrong value, invented value, schema-valid but false |
| Fixed by | A different parser, a higher resolution, a layout model | A better schema, validation code, review, a different model |
| Reusable across tasks? | Yes, one parse can serve search, summaries and extraction | No, each schema is its own contract |

### Which documents need Stage B at all?

Only documents whose values will be acted on by software need Stage B. A knowledge-base PDF that exists to be searched needs Stage A and then retrieval, and nothing more. An invoice that triggers a payment, a contract that populates a renewal date or a form that opens an account needs both stages, because a wrong value there causes an action. As inference, the cheapest correct design for a mixed document estate is to parse everything once, store the Stage A output, and run Stage B only for the document types where a field feeds a decision.

### The skip-Stage-A shortcut

A vision-language model can read the page image directly and fill the schema in one call, skipping Stage A. The reference page says this skips parsing but costs more per page and is harder to debug when fields are missed. The debugging point is the practical one: without a stored Stage A artifact you cannot tell whether the reader failed to see a number or the extractor failed to pick it up. As inference, even a one-call design should persist the page image and the model's raw response so a failure can be replayed.

## Should you parse with OCR, a vision model or a hybrid?

Parse with traditional OCR plus layout analysis when volume is high and layouts are predictable, with a vision-language model when layouts are ambiguous and volume is low to medium, and with a hybrid when a document mixes clean text with precision-critical fields. The reference page describes three approaches, and the table below restates its trade-offs next to this guide's own inference on when each tends to win.

| Approach | What it is | Strength | Weakness | Reach for it when (inference) |
|---|---|---|---|---|
| OCR plus layout analysis | A pipeline of text detection, character recognition, layout classification, table reconstruction and reading-order recovery | Battle-tested for high-volume processing | Struggles with multi-column pages, rotated scans, overlapping regions, complex table spans | Volume is high and document templates are stable |
| Vision-language model | A multimodal model reads the page image and returns Markdown or JSON | Handles layout ambiguity that rule-based pipelines miss | Higher cost per page; harder to debug missed fields | Volume is modest, layouts vary, or the schema is known upfront |
| Parsing library or service | Tools built to emit LLM-ready Markdown or JSON, combining OCR, layout models and optional vision passes behind one API | One integration, no model orchestration of your own | You inherit the tool's failure modes and licence terms | You want a working Stage A quickly and will measure it afterwards |

### Why not decide from a benchmark?

Decide from a labelled sample of your own documents, because the corpus publishes no cross-parser accuracy ranking and the multimodal reference declines to publish benchmark rankings for vision models, noting that they shift frequently and depend heavily on task and resolution. A reasonable protocol, labelled inference: pull a representative sample that includes your ugliest scans, hand-label the target fields once, run each candidate parser plus extractor over it, and compare field-level accuracy, not page-level impressions.

### Which hard cases should the sample contain?

The sample should contain every layout the reference page names as hard, because those are where candidates diverge:

- multi-column layouts
- merged table cells
- rotated or skewed scans
- handwritten annotations
- forms with no consistent field-label placement

The multimodal reference adds two failure modes specific to vision models: small or low-contrast text, and dense tables with spanning cells. Its remedy for precision-critical fields is to combine OCR and a vision model, and to verify extracted table content against the source. That is the hybrid in practice: OCR supplies characters you can compare against, a vision model supplies layout judgement, and a disagreement between them is a signal worth routing.

### Do vision models change the cost picture?

Yes, because image input is billed in tokens that scale with resolution. The multimodal reference says image tokens cost more per pixel of information than text and that downscaling to the lowest resolution a task still needs is the primary lever. It also says token formulas differ by provider and model version, so any cost model should be built from the provider's own pricing page on the day you build it. The cost section below turns this into a worksheet.

## How do you get schema-valid fields out of a parsed document?

Define a JSON Schema for the target fields, run a model with schema-constrained decoding, and check the stop reason before parsing the result. The reference page frames Stage B as a structured-output problem, and [structured outputs and JSON mode](/resources/structured-outputs-and-json-mode) (updated 2026-09-26) holds the provider-by-provider contract. This section covers only what changes when the input is a document; the general mechanics are owned by [structured outputs versus tool calling](/articles/structured-outputs-vs-tool-calling).

### Is JSON mode enough for extraction?

No: JSON mode only asks the model for syntactically valid JSON, so it can omit fields, use wrong types or add keys. The structured-outputs reference says schema-constrained decoding physically prevents tokens that violate the schema, while legacy JSON mode enforces nothing, and that OpenAI labels the older mode legacy in favour of a strict `json_schema`. For extraction that gap is decisive. A missing `invoice_number` key is a parsing crash in the best case and a silently skipped record in the worst. Use JSON mode only when a provider offers nothing stronger, and keep the validation layer described below either way.

### A small extraction schema

The schema below follows the OpenAI strict-mode rules from the reference: every object sets `additionalProperties: false`, every property appears in `required`, and optional values are expressed as a type union with null. It is a sketch for an invoice, not a recommendation of fields.

```json
{
  "type": "object",
  "additionalProperties": false,
  "required": ["invoice_number", "currency", "total", "issue_date", "lines"],
  "properties": {
    "invoice_number": { "type": "string" },
    "currency": { "type": "string", "enum": ["EUR", "USD", "GBP", "OTHER"] },
    "total": { "type": ["number", "null"] },
    "issue_date": { "type": ["string", "null"] },
    "lines": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["description", "amount"],
        "properties": {
          "description": { "type": "string" },
          "amount": { "type": ["number", "null"] }
        }
      }
    }
  }
}
```

Two design choices are inference. Nullable fields let the model say "not on the page" instead of inventing a value, which is easier to review than a plausible fabrication. And an enum with an escape value such as `OTHER` keeps the model from forcing a currency it did not see.

### What do the three major providers require?

Each provider enforces a different subset of JSON Schema, and the provider-by-provider rules (OpenAI strict mode, Anthropic `output_config.format`, Gemini `responseSchema` versus `responseJsonSchema`, self-hosted grammars) are owned by [structured outputs vs tool calling](/articles/structured-outputs-vs-tool-calling) and the [structured outputs reference](/resources/structured-outputs-and-json-mode), as dated 2026-09-26. For document extraction the provider differences reduce to three practical consequences:

- Make fields that a document may omit nullable rather than absent, because strict modes generally want every property listed as required (inference from the reference's strict-mode rules).
- Keep one schema per document type instead of one schema for everything, so a schema stays small enough to compile and cache (inference).
- Provider limits change, so check the provider documentation before depending on a specific constraint.

### What can still go wrong under a strict schema?

A strict schema can still return a non-compliant or unusable result in three cases, and each needs its own branch in code:

1. **Refusal.** On Anthropic, `stop_reason: "refusal"` overrides the schema guarantee. Treat it as a first-class outcome, not an exception.
2. **Truncation.** `stop_reason: "max_tokens"` can cut an object off mid-way. A document with a long table can hit this, so size the output budget from the largest table you expect, or split tables across calls.
3. **Constraint keywords that are accepted but not enforced.** The reference says OpenAI strict mode accepts `minimum` and `pattern` without the decoder enforcing them, and says Anthropic does not support numeric ranges. Do not rely on schema keywords for value rules. Enforce them in your own code, as the validation section shows.

### Does grammar compilation affect a document pipeline?

Yes, mildly: the first request with a new schema is slower because it is compiled to a grammar, so keep one stable schema per document type across a batch and avoid assembling schemas per document. The mechanics and mitigations are owned by [structured outputs vs tool calling](/articles/structured-outputs-vs-tool-calling).

## Why is a schema-valid answer not a correct answer?

A schema-valid answer is not a correct answer because constrained decoding fixes the shape of the response, not the truth of the values inside it. The structured-outputs reference guarantees compliance with the schema, given no refusal and no truncation; it makes no claim about whether `total` matches the page. The reference page for extraction separately says parsed output should not be trusted blindly, and recommends cross-validating high-stakes values.

### Layers of validation

Validate in layers, cheapest first, so most bad records fail before a human or a second model is involved. The list is the author's framework (inference), built from the failure modes above.

1. **Shape.** Parse the response against the schema again in your own code. A second check is cheap and catches provider or SDK surprises.
2. **Type and range.** Dates parse, amounts are non-negative where they must be, currency codes belong to a known list. These are the rules that `minimum` and `pattern` would have expressed.
3. **Internal consistency.** Line items sum to the stated subtotal, subtotal plus tax equals total, a due date is not before the issue date.
4. **Source grounding.** The extracted string or number appears in the parsed text, or within a tolerance of it. A value that appears nowhere in Stage A output was not read from the page.
5. **External reference.** The vendor exists in your master data, the purchase-order number exists, the IBAN passes its checksum.

### A consistency check you can run

The script below implements layers 2 and 3 for the invoice sketch above, using only the standard library. Save it as `check.py` and run it; the sample record is invented for the demonstration.

```bash
cat > check.py <<'EOF'
import json, sys
from datetime import date
from decimal import Decimal

def check(rec):
    errors = []
    if rec["total"] is None:
        errors.append("total missing")
    amounts = [l["amount"] for l in rec["lines"]]
    if None in amounts:
        errors.append("a line amount is missing")
    elif rec["total"] is not None:
        s = sum(Decimal(str(a)) for a in amounts)
        if s != Decimal(str(rec["total"])):
            errors.append(f"lines sum to {s}, total says {rec['total']}")
    if rec["issue_date"] is not None:
        try:
            date.fromisoformat(rec["issue_date"])
        except ValueError:
            errors.append("issue_date is not ISO 8601")
    return errors

rec = json.load(sys.stdin)
errs = check(rec)
print("OK" if not errs else "REVIEW: " + "; ".join(errs))
sys.exit(1 if errs else 0)
EOF
echo '{"invoice_number":"A-1","currency":"EUR","total":120.5,"issue_date":"2026-10-01","lines":[{"description":"x","amount":100},{"description":"y","amount":20}]}' | python3 check.py
```

This sample prints `REVIEW: lines sum to 120, total says 120.5`, which is the point: the record is schema-valid and still wrong. Decimal arithmetic avoids float rounding noise in money comparisons.

### Tables and forms need their own rules

Tables are where Stage A and Stage B interact most, so validate them against the source rather than against the model's output alone. The multimodal reference warns that complex spanning cells and merged headers are prone to misalignment or omission and says to verify extracted table content against the source. As inference, count rows and columns in the Stage A structure before extraction and again in the extracted record, and fail the document when they differ. For forms, check that every field you expected to find was either filled or explicitly marked absent, since a form with no consistent label placement is one of the hard cases the reference names.

## When should an extraction go to a human reviewer?

An extraction should go to a human when a deterministic check fails, when a required field is missing, when the model refuses, or when a confidence signal you have calibrated falls below your cut-off. The reference page says to cross-validate high-stakes values (financial, medical, legal) against OCR confidence scores and to route low-confidence results to a human review queue. It gives no threshold, and neither does this guide: any number would be invented.

### Calibrate the threshold, do not borrow one

Treat any confidence cut-off as a hypothesis until it is measured on labelled documents. The following procedure is labelled inference:

1. Take a labelled sample and record, for each extracted field, whether it was correct and what confidence signal accompanied it.
2. Sort fields by that signal and find the point above which the error rate is acceptable for the field's consequence.
3. Set a stricter cut-off for fields that move money or identity than for fields that only label a record.
4. Re-measure after every parser, model or schema change, because the signal's meaning moves with them.

OCR 4 is reported, per the reference page's secondary sources, to return inline confidence scores. That is a signal about character recognition, not about whether the extractor picked the right number from the page, so as inference it should be one input to routing and never the only one.

### What a review item should contain

A reviewer should receive the page image, the extracted record, the specific check that failed and the Stage A text around the doubtful value. Without the page image they are re-keying from memory; without the failed check they cannot tell what to look at. The same design questions arise in any queue of agent output, and [human review queues for support agents](/articles/support-agent-human-review-queues) is a related treatment on this site. It concerns support conversations, not documents, so apply its sampling and sign-off ideas by analogy only (inference).

### Close the loop

Every reviewer correction is a labelled example. As inference, store corrections with the document hash, the schema version and the parser version, so the next calibration run and the next regression set come from real disagreements rather than invented cases.

## How do you version an extraction schema?

Version an extraction schema like an API contract: give it an explicit version, never edit a published version in place, and record the version on every extracted record. This section is the author's reasoning (inference), apart from the grammar-cache fact, which is sourced: the structured-outputs reference states that on Anthropic a schema change invalidates the grammar cache and adds first-request latency.

### What counts as a breaking change?

A change is breaking if a downstream consumer could misread an old record or reject a new one. As inference:

| Change | Breaking? | Why |
|---|---|---|
| Add an optional, nullable field | Usually no | Old consumers ignore it; old records read as null |
| Rename a field | Yes | Consumers key on the name |
| Change a field's type or unit (cents to euros) | Yes | Silent misreads, the worst kind |
| Widen an enum | Depends | Consumers with exhaustive switches fail |
| Tighten a validation rule | No for the schema, yes for the review rate | More records route to humans |

### Pin the parser and model with the schema

An extraction result depends on the parser, the model and the prompt as well as the schema, so record all four on each record. The [shipping agents to production](/resources/shipping-agents-to-production) checklist versions code, prompt template, model pin and tool contracts under a composite tag; carrying the same discipline to extraction means a rollback is unambiguous. Migrate old records by re-running Stage B from the stored Stage A artifact, which is a further reason to keep that artifact (inference).

## What does document extraction cost per page?

Cost per page is the sum of four things you can name: the parse fee, the model tokens spent on extraction, the cost of retries, and the cost of the pages a person must review. For document-parsing vendors the corpus contains prices for exactly one family, Mistral's, so this section gives a worksheet rather than a comparison table and leaves every other price blank for you to fill from the vendor's own page on the day you build the model.

### The worksheet

Per accepted document, the inputs are:

| Line | Formula (inference) | Source of the number |
|---|---|---|
| Parse | pages x parse price per page | Vendor pricing page, or your own compute cost if self-hosted |
| Extraction | (input tokens x input price + output tokens x output price) x calls per document | Provider pricing page; token counts from a pilot run |
| Retries | extraction cost x expected extra calls per document | Your pilot's retry and truncation rate |
| Review | share of documents reviewed x reviewer minutes x cost per minute | Your calibrated threshold and your staffing cost |

As inference, the review line often dominates once volume is real, because it is a person's time. A cheaper parser that raises the review share can raise the total, and a dearer parser that lowers it can cut it. Which direction holds for you is an empirical question.

### The one set of prices in the corpus

The reference page records Mistral OCR 4, which it says shipped on 23 June 2026, at $4 per 1,000 pages on the standard API, up from $2 for OCR 3, and $2 per 1,000 pages on the Batch API, up from $1. It also records a separate Mistral product, Document AI (schema-driven extraction inside Mistral Studio, not Google's product of the same name), at $5 per 1,000 pages. Treat all of these as secondary-source facts, corroborated by web search across independent outlets and not primary-fetched, as recorded in the 2026-09-28 corpus pass; the reference page says to re-verify against the vendor before relying on them.

### An illustrative example, not a quote

The arithmetic below uses the standard Mistral OCR 4 price from above and invented volumes. It is illustrative, not a quote, and not a forecast of any bill.

```bash
# Illustrative only: 10-page documents, 5,000 documents a month.
# Price: $4 per 1,000 pages (OCR 4 standard, secondary source, as of Sep 2026).
python3 - <<'EOF'
pages_per_doc, docs = 10, 5000
price_per_page = 4 / 1000
parse = pages_per_doc * docs * price_per_page
print(f"parse only: ${parse:,.2f} per month, ${parse/docs:.3f} per document")
EOF
```

That prints `parse only: $200.00 per month, $0.040 per document`. It leaves out the extraction model, retries, review, storage and engineering time, which is why the parse line alone is not a cost per page.

## Should you self-host open-source parsers or buy a managed service?

Self-host when data cannot leave your infrastructure or volume makes per-page fees dominate; buy managed when you want a working Stage A without operating models. The reference page lists both camps. The table shows what it says about each, plus the licence caveats that matter for a business. Star counts and the cloud-vendor section were not re-verified in the reference's 2026-09-28 pass, so they are omitted or hedged here.

| Option | Type | What the reference says | Caveat |
|---|---|---|---|
| Docling | Open source, MIT | Converts many formats to Markdown or JSON; TableFormer for table structure; reading-order detection | Re-confirmed reachable and actively published on 2026-09-28 |
| Marker | GPL-3.0 code, Open Rail-M weights | Converts documents to Markdown or JSON, optional JSON Schema extraction | Weights free for research and startups under $2M revenue; commercial licence beyond that |
| Surya OCR | Apache 2.0 code, Open Rail-M weights | OCR, layout, reading order and table recognition in 90+ languages; the backbone inside Marker | Weights free for research and startups under $5M revenue |
| Unstructured | Open source, Apache 2.0; hosted platform too | Partitions 40+ document types into typed elements | Widely used for RAG ingestion |
| MinerU | Custom Apache-2.0-based licence | VLM plus OCR dual engine; tables as HTML, formulas as LaTeX | Read the licence text before commercial use |
| LlamaParse | Managed SaaS | Four processing tiers; Markdown and structured JSON; a free tier of about 1,000 pages a month | Backing-model detail is dated May 2025 in the reference |
| AWS Textract, Azure AI Document Intelligence, Google Document AI | Cloud APIs | Layout-aware OCR returning structured JSON; Azure and Google add prebuilt and custom extractors | Cloud section not re-verified 2026-09-28; no prices in the corpus |
| Mistral OCR, Reducto | Managed SaaS | Layout-aware OCR; Reducto adds parse, split and extract endpoints | Mistral self-hosting is reportedly offered, not independently verified |

### How do licences change the decision?

Licence thresholds are the part most often missed. A weights licence that is free below a revenue line and paid above it is a cost that appears when the company succeeds, so put the threshold in the decision record beside the technical comparison. As inference, an Apache or MIT licence on the code does not settle the question when the model weights carry a different licence; read both.

### What about Mistral self-hosting?

Mistral is reportedly offering OCR 4 as a self-hosted container for organizations with data-residency needs, but this is not independently verified. The reference page sources it only to secondary outlets and says mistral.ai and docs.mistral.ai were blocked during its pass. If it matters to your decision, confirm it with the vendor in writing.

### Data handling

Sending customer documents to a managed parser or model provider is a data-protection decision, not just a procurement one. The [Data Privacy and PII for Agents](/resources/data-privacy-for-agents) reference covers context ingestion, retention tiers and erasure in general terms, and [data privacy and PII for AI agents](/articles/data-privacy-and-pii-for-ai-agents) is the article treatment. Neither names a rule for document pipelines specifically; take legal advice for your jurisdiction.

## How should extracted data reach the system of record?

Extracted data should reach the system of record only through a validated, idempotent write that carries the document identity, so a retry cannot create a second record and a bad record cannot get in at all. This section is the author's reasoning (inference); the corpus covers the building blocks in other places and names no document-specific write pattern.

1. **Write extracted records to a staging table, not the ledger.** Promote a record only after validation passes or a reviewer approves it.
2. **Key every write on the document.** Use a hash of the file or a source identifier as an idempotency key, so reprocessing the same file updates rather than duplicates. The mechanics are in [retries and idempotency for AI agents](/articles/retries-and-idempotency-for-ai-agents).
3. **Store provenance next to the values.** Keep the document hash, page numbers, parser version, model version and schema version on the record. [Audit trails for AI agents](/articles/audit-trails-for-ai-agents) covers what an audit record should hold.
4. **Never let the extraction call write directly.** The call returns a record; separate code, with its own permissions, performs the write.
5. **Handle duplicates and amendments.** A re-sent invoice with a corrected total is not the same as a retry; decide in advance whether it supersedes or flags the earlier record.

## What can a hostile document do to an extraction pipeline?

A hostile document can carry instructions in text that OCR faithfully transcribes, and a model reading that text may treat them as commands. The reference page says a booby-trapped PDF's hidden instruction-style wording is transcribed like any other text and advises stripping or escaping anything that looks like an embedded command before it reaches model context. The multimodal reference adds that text rendered inside an image can carry instructions in the same way.

### Contain it by design

The strongest control is architectural: an extraction call should have no tools, so the worst a successful injection can do is corrupt one record, which validation and review then face. The [prompt injection design patterns](/resources/prompt-injection-design-patterns) reference gives named architectural patterns for this, and the full defense-in-depth programme belongs to [prompt injection defense in depth for agents](/articles/prompt-injection-defense-in-depth-for-agents). The extraction-specific corollary (inference) is that a document being parsed should never share a context with credentials or tool access, and that fields such as "approved by" or "payment instructions" deserve extra checks, since an attacker benefits from altering them.

## Where do chunking and retrieval fit?

Chunking and retrieval start after Stage A, when the parsed Markdown is split and indexed, and they are a separate system with their own failure modes. The reference page notes that clean structure at parse time is the biggest lever on retrieval quality, which is why the parser choice here matters to search too. For splitting strategy, read [how to chunk documents for RAG](/articles/chunking-documents-for-rag); for the ingestion side, read the [RAG ingestion pipeline](/articles/rag-ingestion-pipeline). This cluster does not repeat their mechanics.

## What does ChangeGamer know first-hand about document pipelines?

As of October 2026 ChangeGamer runs no production document-extraction pipeline, so it has no throughput, accuracy or cost figure to offer, and every recommendation above comes from its reference corpus plus labelled inference. What it does have is first-hand experience of the same discipline applied to its own published content, which maps onto extraction in three ways.

- **Build-time gates on structure.** The site's build fails on duplicate target queries, dead internal links, a missing pillar link, and the post-build `verify-invariants.mjs` script enforces a 900-word floor on sub-articles. That is the same idea as schema validation: bad structure is rejected before it ships, not noticed afterwards.
- **A containment check on its own corpus.** A shingle check compares each article's five-word runs against premium resources, failing at 20% overlap and warning at 10%. It is a deterministic check on output, the kind of layer-4 source-grounding test described above, not a statistical one.
- **A post-build invariant script.** After the build, `verify-invariants.mjs` checks the published surfaces. A second line of defense that runs on the artifact, not on the process that made it, is exactly what an extraction pipeline needs after the model call.

The 2026-09-28 corpus pass is the clearest parallel. It re-verified the open-source packages by their PyPI release versions, which was possible, while most GitHub HTML pages, the cloud-vendor documentation hosts and the Mistral hosts refused the connection. The corpus page recorded what it could and could not confirm instead of filling the gap. A pipeline should do the same: when a field cannot be verified, mark it unverified and route it, rather than emit a confident value.

## How do you launch an extraction pipeline safely?

Launch an extraction pipeline in shadow mode first, with every record validated and reviewed against human-keyed values before anything is written to a system of record. The sequence below is the author's checklist (inference), assembled from the sections above.

1. Assemble a labelled sample, including the hard cases listed earlier, and hold part of it back as a test set.
2. Choose Stage A on field-level accuracy over that sample, not on vendor claims.
3. Write the schema with nullable fields and an escape value for enums, and freeze it as version 1.
4. Add the validation layers and make every failure produce a reason code.
5. Calibrate review routing on the labelled data; start stricter than you think necessary.
6. Run the worksheet with pilot numbers and set a monthly budget alarm.
7. Strip tool access from extraction calls and confirm writes go through a staging table with idempotency keys.
8. Run in shadow for a defined period, compare with human-keyed values, then move a single document type live.
9. Keep the Stage A artifact and the page image for every document, within your retention rules.
10. Write a rollback note: which version of parser, model and schema returns you to the last good state.

## How do the pieces of this cluster fit together?

The cluster is organized around the stages above, and as of 25 October 2026 only this pillar is published. Planned articles are listed as plain text and will be linked as they ship; the mapping is the author's plan, not a commitment to dates.

| Planned topic (not yet published) | Decision it will settle | Previewed in this guide |
|---|---|---|
| OCR versus vision model versus hybrid parsing | Which Stage A to buy or run | Parsing section |
| Schema-constrained field extraction | Provider settings and failure branches | Schema section |
| Table and form validation | Row counts, totals and field presence | Validation section |
| Human-review fallback for extraction | What to route, and how to calibrate | Review section |
| Extraction schema versioning | Compatible changes and migration | Versioning section |
| Cost per page | A filled-in worksheet method | Cost section |
| Open source versus managed parsing | Licence, residency and operations | Open-source section |
| Feeding a system of record | Staging, idempotency and provenance | System-of-record section |

For the adjacent systems, read [how to chunk documents for RAG](/articles/chunking-documents-for-rag) and the [RAG ingestion pipeline](/articles/rag-ingestion-pipeline) for retrieval, [structured outputs versus tool calling](/articles/structured-outputs-vs-tool-calling) for output mechanics, and [prompt injection defense in depth for agents](/articles/prompt-injection-defense-in-depth-for-agents) for security.

## Where should you read next?

Read the reference pages first, because they are the contract: [Document Extraction and Parsing for Agents](/resources/document-extraction-for-agents), [Structured Outputs and JSON Mode](/resources/structured-outputs-and-json-mode), [Multimodal Agents](/resources/multimodal-agents), [Reliable Tool Calling and Structured Outputs](/resources/reliable-tool-calling), [Prompt Injection Design Patterns](/resources/prompt-injection-design-patterns) and [Data Privacy and PII for Agents](/resources/data-privacy-for-agents). Then work through the sequence in the launch checklist above, starting with the labelled sample.

## Frequently asked questions

### What is AI document extraction?

AI document extraction is the process of turning PDFs, scans, images and forms into structured data, such as an invoice total or a signatory name, using OCR, vision-language models or both. A production pipeline separates reading the page from filling a schema, then validates the result before anything downstream trusts it.

### Is JSON mode enough to extract fields from a document?

JSON mode is not enough for field extraction, because plain JSON mode only asks the model for syntactically valid JSON, so fields can be missing, mistyped or extra. Schema-constrained structured outputs fix the shape, but neither mode checks that a value is correct, so a validation layer in your own code is still required.

### Should I use OCR or a vision model to parse documents?

Use traditional OCR with layout analysis for high-volume, predictable documents, a vision-language model for complex or ambiguous layouts at low to medium volume, and a hybrid when precision-critical fields sit inside messy pages. Decide on a labelled sample of your own documents, because published comparisons depend on the layout.

### How much does AI document extraction cost per page?

AI document extraction cost per page depends on four inputs: the parse fee per page, the model tokens spent on extraction, the retry rate, and the share of pages that need human review. The only document-parsing vendor prices in this site's corpus are Mistral OCR 4 at $4 per 1,000 pages ($2 on batch), reported by secondary sources as recorded in the 2026-09-28 corpus pass.

### Does this site run its own document extraction pipeline?

ChangeGamer does not run one: as of October 2026 it operates no production document-extraction pipeline and has no throughput, accuracy or cost figures for one. The guide is synthesized from the site's reference corpus and labels the author's own reasoning as inference.


---

## Everything in this guide


## Reference resources

- https://changegamer.ai/resources/document-extraction-for-agents.md
- https://changegamer.ai/resources/structured-outputs-and-json-mode.md
- https://changegamer.ai/resources/multimodal-agents.md
- https://changegamer.ai/resources/reliable-tool-calling.md
- https://changegamer.ai/resources/prompt-injection-design-patterns.md
- https://changegamer.ai/resources/data-privacy-for-agents.md
- https://changegamer.ai/resources/shipping-agents-to-production.md

All guides: https://changegamer.ai/api/articles.json · Reference corpus: https://changegamer.ai/llms.txt
Licensing: https://changegamer.ai/api/pricing.json (offer catalog) · https://changegamer.ai/api/payment.json (payment methods, HTTP 402 flow) · access guide: https://changegamer.ai/resources/access-and-pricing.md