Reading Order Recovery Prompt for Complex PDF Layouts

This prompt is designed for document ingestion engineers who need to recover the intended human reading order from PDFs with mixed layouts—documents containing multi-column body text, sidebars, pull quotes, inset boxes, and callout regions. The job-to-be-done is converting a set of visually positioned text blocks into a single linear text sequence that preserves the author's intended narrative flow. This is a layout-correction step that sits between raw text extraction and downstream tasks like chunking, embedding, or structured extraction. Without reading order recovery, multi-column documents produce interleaved garbage that silently corrupts retrieval quality and breaks any pipeline that assumes coherent paragraph sequences.

Use this prompt when your PDF extraction pipeline produces text blocks with positional metadata (bounding boxes, page coordinates, column hints) but the raw extraction order is wrong. The prompt requires inputs that include the extracted text blocks, their page positions, and any available layout classification labels (e.g., 'body', 'sidebar', 'header', 'callout'). You should also provide the expected output schema—typically a JSON array of text blocks in corrected reading order with their original positions preserved for traceability. The prompt works best with models that can reason spatially and follow strict ordering constraints. It is not a replacement for a layout parser; it is a correction layer that applies human reading conventions to already-extracted regions.

Do not use this prompt when the document has a single, uninterrupted text flow with no layout complexity—simple left-to-right, top-to-bottom extraction is sufficient and cheaper. Do not use it when you lack positional metadata; the model cannot recover reading order from plain text alone. Do not use it as a substitute for OCR or text extraction; it operates on already-extracted blocks. For documents where reading order is genuinely ambiguous (e.g., artistic layouts, infographics, or documents where multiple valid reading paths exist), flag the output as uncertain and route for human review rather than forcing a single linearization. The next step after reading order recovery is typically validation against known failure modes: sidebar text interrupting body flow, callout text placed before its anchor paragraph, and footnotes separated from their referents.

The following prompt template is designed to be dropped into your document processing pipeline when you need to linearize complex PDF layouts into a single, coherent text stream. It expects pre-extracted text blocks with positional metadata—typically the output of a PDF parser or OCR engine that provides bounding box coordinates, page numbers, and font size hints. The prompt instructs the model to reconstruct the author-intended reading order, not the raw extraction order, which is critical for downstream tasks like chunking, summarization, and retrieval-augmented generation where interleaved column text or misplaced callout boxes silently corrupt results.

textCopy
You are a document layout analyst. Your task is to reconstruct the intended human reading order from a set of text blocks extracted from a PDF page with a complex layout.

## INPUT
You will receive a JSON array of text blocks. Each block has:
- `block_id`: unique identifier
- `text`: the text content of the block
- `page`: page number
- `bbox`: bounding box coordinates [x0, y0, x1, y1] in points, where (0,0) is the top-left corner of the page
- `font_size`: approximate font size in points
- `font_style`: one of ["bold", "italic", "regular"]

[INPUT]

## CONTEXT
This document is a [DOCUMENT_TYPE] with the following layout characteristics:
[LAYOUT_DESCRIPTION]

Known layout features to account for:
[LAYOUT_FEATURES]

## INSTRUCTIONS
1. Analyze the spatial arrangement of all text blocks on each page.
2. Identify the main body text flow. In multi-column layouts, read the left column completely before starting the right column, unless visual cues indicate otherwise.
3. Identify sidebars, pull quotes, callout boxes, and inset text. These are typically offset from the main flow, have different font sizes or styles, or are enclosed in visible borders.
4. For each sidebar or callout, determine its anchor point in the main body text—the paragraph or sentence it relates to. Place the sidebar content immediately after its anchor paragraph, enclosed in [SIDEBAR_START] and [SIDEBAR_END] markers.
5. Place footnotes immediately after the paragraph containing their reference marker, enclosed in [FOOTNOTE_START] and [FOOTNOTE_END] markers.
6. Headers and footers that repeat across pages should be included only once, at the start or end of the document respectively, unless they contain page-specific information like section titles.
7. Preserve all original text exactly. Do not paraphrase, summarize, or modify wording.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "pages": [
    {
      "page_number": 1,
      "reading_order": [
        {
          "sequence": 1,
          "block_id": "b1",
          "content_type": "body_text" | "sidebar" | "callout" | "footnote" | "header" | "footer",
          "text": "exact text content",
          "anchor_block_id": null | "b3"
        }
      ]
    }
  ],
  "global_reading_order": "full concatenated text with markers",
  "uncertain_regions": [
    {
      "page": 1,
      "block_ids": ["b5", "b6"],
      "reason": "ambiguous column boundary"
    }
  ]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific document context. The [DOCUMENT_TYPE] should describe the document category—such as "legal contract," "academic paper," or "financial report"—which helps the model apply domain-appropriate layout conventions. The [LAYOUT_DESCRIPTION] and [LAYOUT_FEATURES] fields are where you specify known structural elements: single-column vs. multi-column, presence of sidebars, typical callout box placement, and whether footnotes appear at page bottom or document end. The [CONSTRAINTS] placeholder should include any domain-specific rules, such as "never reorder clauses in a contract" or "preserve equation numbering sequence." The [EXAMPLES] placeholder is critical for few-shot performance—provide at least two annotated page examples showing correct reading order resolution for your document type. The [RISK_LEVEL] field should be set to "high" for legal, medical, or financial documents where ordering errors could change meaning, triggering downstream human review requirements.

When integrating this prompt into a production pipeline, always validate the output against the original block count to ensure no text was dropped during reordering. Run a spot-check eval comparing the global_reading_order field against a human-annotated ground truth for at least 20 representative pages from your document corpus. Pay particular attention to uncertain_regions—these are the model's explicit signals that it encountered ambiguous layout boundaries, and they should trigger either a human review step or a higher-confidence re-extraction pass with additional spatial context. For high-risk document types, never ship the linearized output directly to downstream consumers without first logging the uncertainty regions and, where feasible, routing pages with unresolved ambiguities for manual verification.

The reading order recovery prompt is a post-extraction correction step, not a raw text extractor. It expects already-extracted text blocks with positional metadata (bounding boxes, page numbers, and region labels) as input. The typical pipeline flow is: raw PDF → layout detection → text extraction per region → reading order recovery → downstream chunking or structured extraction. Do not feed raw PDF bytes or OCR output directly into this prompt; the model needs spatial context to reason about reading order.

Validation is mandatory before downstream consumption. After the prompt returns a linearized text sequence, run at least three checks: (1) Continuity check — verify that no extracted text block was dropped by comparing input block count to output coverage. (2) Anchor proximity check — confirm that callout boxes, sidebars, and footnotes appear within a configurable token window of their anchor text in the main body. (3) Page boundary integrity — ensure text from page N does not appear before text from page N-1 unless the document layout explicitly requires it (e.g., a sidebar that references a previous page). Log all validation failures with the specific block IDs and page coordinates that triggered them.

Retry logic should be bounded and diagnostic. If validation fails, construct a retry prompt that includes the original input plus the specific validation error messages and the IDs of the offending blocks. Limit retries to two attempts. On the second failure, route the document to a human review queue with the original layout visualization, the model's two attempts, and the validation report. Do not silently accept a partially-correct reading order — downstream chunking and retrieval quality depend on correct linearization, and corrupted reading order is a silent data quality failure that compounds through the pipeline.

Model selection matters for this task. Use a model with strong spatial reasoning and long-context handling (e.g., GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Smaller or older models frequently misorder multi-column text and place callout content at arbitrary positions. If processing high-volume document streams, consider a tiered approach: use a fast, cheaper model for simple single-column documents (validated by a layout classifier upstream) and route complex multi-column or mixed-layout documents to a more capable model with this prompt.

Log everything for observability. For each document processed, record: the layout zone count, the model used, the number of retry attempts, validation pass/fail status, and the human review outcome if escalated. This data lets you measure the prompt's real-world accuracy, identify document types that consistently fail, and build a regression test suite from production failures. When you update the prompt template, replay the logged failure cases first.