Scanned Document OCR Correction Prompt Template

This prompt is designed for document pipeline engineers who need to repair OCR-extracted text from scanned documents before it flows into downstream systems like RAG indexes, structured extraction pipelines, or archival databases. The core job-to-be-done is turning error-prone raw OCR output into clean, faithful text that preserves the original document's meaning, structure, and domain-specific terminology. The ideal user is someone building a production ingestion pipeline where OCR errors—split words, misread characters, garbled tables, or corrupted proper nouns—will break entity extraction, search relevance, or compliance audits if left uncorrected.

Use this prompt when you have raw text output from an OCR engine (Tesseract, AWS Textract, Azure Document Intelligence, or similar) and you need a corrected version that is safe for machine consumption. The prompt is most effective when you can supply domain-specific dictionaries (e.g., a list of valid product codes, legal terms, or medical vocabulary) and format-aware correction rules (e.g., 'invoice numbers match pattern INV-\d{6}'). It expects you to provide the raw OCR text, an optional context snippet describing the document type, and a set of constraints that define what a valid correction looks like. The output includes corrected text, a confidence score per correction, and explicit flags for spans where the model is uncertain—giving your pipeline the signals it needs to decide whether to auto-accept, queue for human review, or escalate.

Do not use this prompt when the OCR quality is so degraded that the source text is effectively unrecoverable without visual re-inspection of the original scan. This prompt corrects text, not images; it cannot see the original document. If the raw OCR output is missing entire paragraphs, has swapped page order, or contains unreadable glyphs with no linguistic signal, the correction will be speculative at best. In those cases, re-scanning or using a layout-aware OCR model with visual features is the right first step. Similarly, do not use this prompt as a substitute for structured field extraction—it produces corrected running text, not typed JSON records. For extraction, pair this prompt upstream of a schema extraction prompt that consumes the cleaned output.

Before deploying, build a validation harness that compares corrected output against a golden dataset of manually verified document pairs. Measure character error rate (CER) and word error rate (WER) reduction, but also track the rate of uncertain flags—if more than 15% of corrections are flagged as low confidence, your pipeline likely needs better upstream OCR or a narrower domain dictionary. Always log the raw input, corrected output, confidence scores, and flag counts per document for auditability. In regulated domains like healthcare or legal, route all flagged corrections to a human review queue and never auto-accept corrections on documents where errors could cause harm.

This prompt template is designed to be dropped into your document processing pipeline immediately after the OCR engine and before any downstream extraction or classification steps. It expects raw OCR output—complete with its typical artifacts: split words, misrecognized characters, merged columns, and garbled headers—and returns a structured correction payload that your application can validate and route. The template uses square-bracket placeholders so you can swap in your own domain dictionaries, output schemas, and risk thresholds without rewriting the core instruction logic.

textCopy
You are a document correction engine. Your task is to repair OCR errors in the provided text while preserving the original meaning, structure, and formatting intent.

[CONTEXT]
Document type: [DOCUMENT_TYPE]
Domain: [DOMAIN]
Expected sections: [EXPECTED_SECTIONS]

[DOMAIN_DICTIONARY]
Correct terms, proper nouns, and expected vocabulary for this domain:
[DICTIONARY_ENTRIES]

[INPUT]
Raw OCR text:
[OCR_TEXT]

[OUTPUT_SCHEMA]
Return a valid JSON object with this exact structure:
{
  "corrected_text": "the full corrected document text",
  "corrections": [
    {
      "original_span": "the OCR text that was corrected",
      "corrected_span": "the replacement text",
      "position": {"start": 0, "end": 0},
      "confidence": 0.0,
      "correction_type": "spelling|word_split|word_merge|number_fix|punctuation|layout_recovery|domain_term|case_fix"
    }
  ],
  "uncertain_spans": [
    {
      "span": "text the model is unsure about",
      "position": {"start": 0, "end": 0},
      "reason": "why confidence is low",
      "suggested_action": "human_review|dictionary_check|context_clarify"
    }
  ],
  "layout_notes": ["description of recovered columns, tables, or section breaks"],
  "overall_confidence": 0.0
}

[CONSTRAINTS]
1. Never change numbers, dates, monetary amounts, or legal references unless you are certain of the correction. Flag uncertain numeric corrections in uncertain_spans.
2. Use the domain dictionary to resolve ambiguous words. If a word matches a dictionary entry with high confidence, prefer that correction.
3. Preserve paragraph breaks, list structures, and table layouts. Note any layout recovery in layout_notes.
4. For words split across line breaks (common in OCR), merge them and record the correction with type "word_merge".
5. Flag any span where confidence is below [CONFIDENCE_THRESHOLD] in uncertain_spans with a suggested action.
6. Do not rewrite, summarize, or improve the text. Only correct OCR errors.
7. If the entire document appears to be garbled or unreadable, set overall_confidence below 0.3 and include a note in layout_notes.

[EXAMPLES]
Input: "The agr eement shall term inate on Decem ber 31 , 2025"
Output correction: "agr eement" -> "agreement" (word_merge, confidence 0.98), "term inate" -> "terminate" (word_merge, confidence 0.98), "Decem ber" -> "December" (word_merge, confidence 0.97)

Input: "Pursuant to Section l.2(a) of the Agr eement"
Output correction: "l.2(a)" -> "1.2(a)" (number_fix, confidence 0.85, flag if legal document)

Now correct the provided OCR text following these rules.

Adaptation notes: Replace [DOCUMENT_TYPE] with the specific format (invoice, contract, report, form) to activate format-aware correction rules. Populate [DOMAIN_DICTIONARY] with a list of expected proper nouns, technical terms, product names, and common abbreviations for your domain—this is the single highest-leverage field for improving correction accuracy. Set [CONFIDENCE_THRESHOLD] based on your risk tolerance; 0.7 is a reasonable starting point for most pipelines, but lower it to 0.5 for high-recall use cases or raise it to 0.9 when downstream actions are irreversible. The [EXPECTED_SECTIONS] field helps the model recognize when layout recovery is needed—list the section headers that should appear in a well-formed document of this type.

What to do next: After copying this template, run it against a golden dataset of 20–30 documents where you have both the raw OCR output and the ground-truth corrected text. Measure precision and recall on the corrections array, not just the corrected_text string—this lets you tune the confidence threshold and identify which correction types (word_merge, number_fix, etc.) cause the most errors. If overall_confidence consistently falls below your threshold for a document type, consider upgrading your OCR engine or adding pre-processing steps before routing to this prompt. For high-risk domains like legal or financial documents, always route uncertain_spans to a human review queue before the corrected text enters any downstream system.

The OCR correction prompt is not a standalone utility—it is a processing stage inside a larger document ingestion pipeline. The typical harness receives raw OCR text from an upstream extraction service (Tesseract, Azure Document Intelligence, Amazon Textract), enriches it with domain-specific dictionaries and format rules, calls the LLM, validates the corrected output, and routes low-confidence results to a human review queue before passing clean text to downstream systems like search indexes, databases, or NLP classifiers.

Validation is the most critical harness component. After the model returns corrected text and confidence scores, run a post-processing validator that checks: (1) the output text length is within a reasonable delta of the input length—large deviations suggest hallucinated insertions or deletions; (2) any [DOMAIN_DICTIONARY] terms appear in their canonical form; (3) format-specific rules are enforced, such as date patterns matching [DATE_FORMAT] or currency values conforming to [CURRENCY_FORMAT]; (4) the confidence array has an entry for every correction the model claims to have made. If validation fails, retry once with the validation errors appended to the prompt as additional [CONSTRAINTS]. If the retry also fails, route the document to a human review queue with the original OCR text, the failed corrected output, and the specific validation errors.

For model choice, prefer models with strong instruction-following and structured output support—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro all work well. Use the model's native structured output or JSON mode to enforce the {corrected_text, corrections: [{original, corrected, confidence, reason}]} schema rather than relying on prompt instructions alone. Set temperature to 0 or very low (0.1) to minimize creative rewrites. For high-throughput pipelines, batch multiple pages or documents into a single request where context windows allow, but keep batches small enough that a single failure does not block a large queue. Log every request and response pair, including the raw OCR input, the domain dictionary version used, the model and its configuration, the corrected output, validation results, and the final routing decision (auto-accepted, retried, or escalated). This audit trail is essential for debugging correction drift and for compliance in regulated industries.

When wiring this into a production system, avoid treating the LLM correction as the final step. Always run a diff between the original OCR and the corrected text to detect silent changes—corrections the model made but did not report in the corrections array. Flag any unreported change above a character-count threshold for human review. Also implement a circuit breaker: if the correction failure rate exceeds a configured threshold (e.g., 20% of documents require human review), pause automated processing and investigate whether the OCR engine, domain dictionary, or model behavior has changed. This prompt is a high-precision tool, not a fire-and-forget service.