OCR-Extracted-Claim-to-Original-Image Verification Prompt

This prompt is designed for verification teams and pipeline engineers who need to validate that a claim string extracted from an image via Optical Character Recognition (OCR) is faithful to the original visual source. The core job-to-be-done is not fact-checking the claim itself, but rather verifying the mechanical extraction step. OCR engines frequently introduce character-level errors, especially when processing multi-column layouts, handwritten text, low-resolution scans, or ambiguous glyphs like '0' vs 'O' or 'rn' vs 'm'. Using this prompt creates a structured verification record that downstream systems can use to calibrate their confidence in the extracted text before attempting to match it against evidence.

The ideal user is a pipeline operator who has already run an OCR engine and obtained a raw text string, but needs a quality gate before that string becomes a permanent record. The required context includes the original image and the OCR-derived claim string. The prompt instructs a multimodal model to perform a character-level comparison, flagging specific glyphs with low confidence, noting layout complexities that may have caused extraction errors, and providing an overall fidelity score. This is particularly critical in regulated or high-stakes domains like medical record digitization, legal document processing, or financial audit trails, where a single misread character can change a diagnosis, a contract term, or a monetary value.

Do not use this prompt as a fact-verification step. It will not tell you if the claim is true or false, only if the text was extracted correctly. It is also not a replacement for improving your OCR engine; if you have systemic extraction failures, invest in better preprocessing, higher-resolution scans, or a domain-specific OCR model. After running this verification, route claims with high fidelity scores to your evidence-matching pipeline, flag medium-confidence claims for human spot-checking, and quarantine low-confidence claims for manual re-extraction. The next step is to wire this prompt into an automated harness with structured output validation and logging, as described in the implementation section.

This template is designed for multimodal models that accept an image and a text instruction. It instructs the model to act as a forensic OCR auditor, comparing a set of pre-extracted claims against the original document image. The goal is not to re-perform OCR, but to verify the fidelity of the extraction, flagging character-level errors, ambiguous glyphs, and layout misinterpretations that could corrupt downstream data.

textCopy
You are a forensic OCR auditor. Your task is to verify a set of claims extracted from a document image against the visual evidence in that image. You must detect extraction errors, not factual errors in the document's content.

## INPUT
- **Extracted Claims:** A list of text strings that were supposedly extracted from the provided document image.
  [EXTRACTED_CLAIMS]
- **Document Image:** The original source image from which the claims were extracted.

## TASK
For each extracted claim, perform a character-level comparison against the text visible in the image. Your analysis must account for the document's layout, including multi-column text, tables, and handwritten sections.

## OUTPUT_SCHEMA
Return a JSON object with a `verifications` array. Each element must conform to this schema:
{
  "claim_index": "integer, matching the 0-based index of the claim in the input list",
  "claim_text": "string, the original claim text",
  "image_text": "string, the exact text you observe in the image for the corresponding region",
  "match_type": "string, one of: 'exact_match', 'case_mismatch', 'punctuation_mismatch', 'glyph_error', 'word_error', 'missing_text', 'hallucinated_text', 'layout_misread'",
  "character_differences": [
    {
      "position": "integer, character index in the claim_text where the error starts",
      "expected": "string, character(s) from the claim_text",
      "observed": "string, character(s) from the image_text",
      "confidence": "float between 0.0 and 1.0, your confidence in this specific difference given image quality"
    }
  ],
  "ambiguous_glyphs": [
    {
      "position": "integer, character index in the image_text",
      "possible_interpretations": ["string", "string"],
      "reason": "string, e.g., 'low resolution', 'handwriting', 'similar glyph shape'"
    }
  ],
  "layout_context": "string, description of the text's location (e.g., 'main body, paragraph 2', 'table header', 'footnote', 'handwritten margin note')",
  "overall_confidence": "float between 0.0 and 1.0, your confidence in the entire verification for this claim"
}

## CONSTRAINTS
[CONSTRAINTS]
- Do not re-interpret or fact-check the document's content. Only verify extraction fidelity.
- If the image is too low-resolution to read a glyph, mark it as ambiguous and set a low confidence score.
- Pay special attention to common OCR failure points: 'rn' vs 'm', 'cl' vs 'd', '0' vs 'O', '1' vs 'l'.
- For handwritten text, always flag glyphs as ambiguous and provide possible interpretations.
- If a claim spans multiple text regions (e.g., across a column break), flag it as a `layout_misread`.

To adapt this template, replace the [EXTRACTED_CLAIMS] placeholder with your list of strings. The [CONSTRAINTS] block can be extended with domain-specific rules, such as a glossary of expected terms to help disambiguate glyphs. For high-stakes workflows, ensure the overall_confidence and per-difference confidence scores are logged and used to route low-confidence verifications to a human review queue. The next step is to wire this prompt into a validation harness that can parse the JSON output and flag any claim where match_type is not exact_match.

This prompt is designed to operate as a verification microservice within a larger fact-checking pipeline. It should be called after OCR extraction has produced a set of claims and before those claims are routed to downstream evidence-matching or human-review stages. The primary integration point is a function that receives an OCR-extracted claim object and its source image, calls the LLM with this prompt, and processes the structured verification output. Because OCR errors can cascade into false fact-checking verdicts, this step must be treated as a gating operation: claims that fail verification should be flagged for re-extraction or human review rather than silently passed through.

Validation and retry logic is critical. The prompt requests a JSON output with character_level_confidence, ambiguous_glyph_flags, and layout_context_notes. Your harness must validate that the response parses as valid JSON, that all required fields are present, that confidence scores fall within 0.0–1.0, and that any flagged glyph positions correspond to actual character indices in the extracted claim text. On validation failure, implement a single retry with a repair prompt that includes the validation error message. If the retry also fails, escalate the claim-image pair to a human review queue with the raw OCR output, the image, and both failed LLM responses attached. Do not loop beyond one retry for cost and latency reasons.

Model choice and tool use should be deliberate. This task requires strong vision-language capabilities and precise spatial reasoning. Use a model that supports native image input (e.g., GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) rather than a text-only model with a separate OCR preprocessor. Do not provide external OCR tools to the model; the prompt's purpose is to verify an existing OCR extraction, not to re-extract text. If your pipeline uses multiple model families, route this prompt to the model with the best performance on your internal benchmark for multi-column text and handwriting recognition. Log the model version, prompt template hash, and latency for every call to support regression testing and cost attribution.

Human review integration should be triggered automatically when the prompt returns ambiguous_glyph_flags with severity high or when character_level_confidence drops below a configurable threshold (start with 0.85 and tune based on your error tolerance). The review interface should display the original image with the OCR-extracted claim overlaid, highlighting the ambiguous regions. Reviewers need a simple accept/correct/reject workflow, and their corrections should be logged as ground truth for future eval dataset construction. Never auto-accept low-confidence verifications in high-stakes domains like legal, medical, or financial content.

Cost and latency budgeting is essential for production scale. Each verification call consumes both image tokens and text tokens. Batch claims from the same image into a single prompt call where possible, sending multiple claims in a structured array to amortize the image processing cost. Set a per-image timeout (e.g., 10 seconds) and a per-batch timeout (e.g., 30 seconds). If the model exceeds the timeout, fall back to flagging all claims from that image for human review. Monitor your verification rejection rate: if more than 20% of claims are flagged for human review, investigate whether your OCR engine needs improvement or your confidence threshold is too strict.

Observability and eval integration should be built in from day one. Log every verification result with the claim ID, image hash, model response, validation status, retry count, and final disposition (passed, flagged, escalated). Build a golden dataset of 200+ image-claim pairs with known OCR errors, multi-column layouts, handwriting samples, and low-resolution edge cases. Run this eval suite on every prompt or model version change before deployment. Pay special attention to false negatives—claims the prompt marks as correct that are actually OCR errors—because these will silently corrupt downstream fact-checking. If your false negative rate exceeds 2%, tighten the confidence threshold or add explicit few-shot examples of subtle OCR failures to the prompt.