Multi-Page Element Stitching Prompt Template

This prompt is designed for document ingestion engineers who need to reconstruct continuous elements—paragraphs, tables, lists, and callout boxes—that have been split across page boundaries during PDF text extraction. The core job-to-be-done is transforming a stream of layout-aware text fragments with page metadata into a single, logically coherent document where split elements are merged and page-break locations are explicitly annotated. The ideal user is a backend engineer or pipeline architect building a production document processing system, not an end-user manually cleaning up a single PDF. You should use this prompt when your extraction pipeline produces per-page or per-region text blocks and you need to reassemble them before chunking, indexing, or structured extraction downstream.

The prompt requires structured input containing text fragments with their page numbers, bounding box coordinates, font metadata, and element-type classifications (e.g., 'paragraph', 'table-row', 'list-item', 'callout'). Without this layout-aware metadata, the model cannot reliably distinguish a genuine continuation from a coincidental text similarity. The output contract is strict: a JSON array of stitched elements, each with a merged_from array of source fragments, a page_break_positions list indicating where breaks occurred, and a continuation_confidence score. This structured output is designed to be machine-readable so your pipeline can log merge decisions, flag low-confidence stitches for human review, and preserve provenance for audit trails. You should wire a JSON schema validator directly after the model response to catch malformed output before it corrupts downstream chunking or retrieval.

Do not use this prompt when you lack reliable page-boundary metadata, when the document is a single-page flyer, or when your extraction pipeline already produces correctly ordered continuous text. This prompt is also inappropriate for real-time chat interfaces where a user is asking questions about a document—it is a batch ingestion component, not a conversational tool. If your document contains complex mixed-orientation pages, right-to-left scripts, or heavily degraded OCR output, you should run those through specialized layout correction prompts first and feed the cleaned output into this stitching step. Finally, if the cost of a false merge is extremely high—such as in legal contract clause assembly or financial statement reconstruction—you must route low-confidence stitches to a human review queue rather than relying solely on the model's confidence score.

This prompt template is designed for ingestion pipelines that process multi-page documents where paragraphs, tables, lists, and callout boxes frequently break across page boundaries. The template accepts layout-aware extraction output—typically text blocks with bounding box coordinates, page numbers, and element-type labels—and stitches split elements back together into continuous logical units. The output preserves the original page-break locations as annotations, enabling downstream consumers to trace content back to source pages while working with complete semantic units.

textCopy
You are a document structure reconstruction engine. Your task is to identify and merge document elements that span page breaks.

## INPUT
You will receive layout-aware extraction output containing text blocks with the following fields per block:
- page_number: integer
- element_type: one of [paragraph, table_row, list_item, callout_box, heading, caption, footnote]
- text: string content of the block
- bbox: [x0, y0, x1, y1] coordinates in page space
- font_metadata: {family, size, style}
- block_sequence: integer position on the page

Input data:
[LAYOUT_BLOCKS]

## TASK
1. Identify elements that are continuations from the previous page or continue onto the next page.
2. Merge split elements into single continuous elements.
3. Annotate each merge point with the page boundary location.
4. Preserve the original element type and reading order.

## STITCHING RULES
- **Paragraph continuation**: Merge when the last block on page N and first block on page N+1 share font metadata, element_type is paragraph, and the page N block ends mid-sentence (no terminal punctuation) OR the page N+1 block starts with a lowercase letter.
- **Table continuation**: Merge when consecutive pages contain table_row blocks with matching column counts and consistent column alignment (x-coordinate overlap within [TOLERANCE] pixels). Include a header-row repeat check.
- **List continuation**: Merge when list_item blocks continue numbering or bullet pattern across page boundary, with matching indentation levels.
- **Callout box continuation**: Merge when callout_box blocks on consecutive pages share background shading, border style, or explicit "continued" markers.
- **Do NOT merge**: Headings, captions, or footnotes across pages unless explicit continuation markers exist.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "stitched_elements": [
    {
      "element_id": "string",
      "element_type": "string",
      "merged_from_blocks": [block_indices],
      "continuous_text": "string",
      "page_break_annotations": [
        {"after_page": integer, "before_page": integer, "break_position": integer}
      ],
      "confidence": 0.0-1.0,
      "stitching_evidence": ["reason strings"]
    }
  ],
  "unmerged_blocks": [block_indices],
  "warnings": ["string descriptions of ambiguous cases"]
}

## CONSTRAINTS
- Never merge across more than [MAX_CONSECUTIVE_PAGES] pages without flagging a warning.
- If confidence is below [CONFIDENCE_THRESHOLD], include the element in both stitched_elements AND warnings with a flag for human review.
- Preserve original block indices for traceability.
- Handle empty pages and page-number gaps gracefully.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[HUMAN_REVIEW_TRIGGER]: Require human review when confidence < 0.7, when table column counts change mid-merge, or when more than 3 consecutive pages are stitched.

To adapt this template for your pipeline, replace the bracketed placeholders with your specific values. Set [TOLERANCE] based on your PDF extraction tool's coordinate precision—typically 5-15 pixels for scanned documents and 2-5 pixels for digital PDFs. [MAX_CONSECUTIVE_PAGES] should reflect your document types; legal contracts rarely span more than 2 pages for a single element, while technical manuals may have tables spanning 5+ pages. [CONFIDENCE_THRESHOLD] of 0.7 is a reasonable default, but lower it to 0.5 for noisy OCR output or raise it to 0.85 for clean digital documents. The [FEW_SHOT_EXAMPLES] placeholder should contain 2-3 annotated examples showing correct merges and deliberate non-merges. The [HUMAN_REVIEW_TRIGGER] section should be customized to your operational tolerance for errors—false merges are typically more damaging than orphaned continuations, so bias toward conservative merging if your downstream consumers cannot tolerate merged-paragraph errors.

Before deploying this prompt, build a validation harness that checks: (1) no block appears in both stitched_elements and unmerged_blocks, (2) all original block indices are accounted for, (3) page_break_annotations reference consecutive page numbers, and (4) confidence scores are present for every stitched element. Run this prompt against a golden dataset of 20-50 documents with known page-break locations to establish baseline precision and recall. Common failure modes include false merges of similar-looking but distinct paragraphs, missed continuations when the first word on a new page is capitalized, and table-header confusion when headers repeat mid-page. Plan to iterate on the stitching rules after reviewing production traces.

The multi-page element stitching prompt operates as a post-extraction correction step in a document ingestion pipeline. After a layout-aware extraction engine produces per-page text blocks with bounding box coordinates, font metadata, and element type classifications, the stitching prompt receives a sequence of elements spanning a page break boundary. The harness should batch elements in sliding windows of two to three pages, passing the last few elements of page N alongside the first few elements of page N+1. This windowed approach prevents token waste from processing entire documents at once while ensuring the model has sufficient context to determine whether a paragraph, table row, list item, or callout box continues across the break.

Validation layer. The harness must validate the model's output against a strict schema before accepting any merge decision. Each stitched element should include a merge_decision enum (merge, no_merge, uncertain), a merged_text field when applicable, a confidence score between 0.0 and 1.0, and a page_break_annotation marking where the break occurred. Reject outputs that claim a merge but produce identical text to the input, that merge elements of different types (e.g., stitching a paragraph to a table row), or that produce confidence scores below a configurable threshold. For uncertain decisions, route the element pair to a human review queue with the source page images rendered side by side. Log every merge decision with the input element IDs, output decision, confidence, and the model version used for traceability.

Retry and escalation logic. When the model returns malformed JSON, missing required fields, or schema-invalid output, retry once with the same input and an explicit instruction to correct the format error. If the retry also fails, fall back to a conservative no-merge default and flag the element pair for downstream review. Do not retry more than twice on the same window—cost and latency accumulate quickly in high-volume ingestion pipelines. For uncertain decisions that exceed a volume threshold (e.g., more than 5% of page breaks in a document), pause the pipeline and alert an operator rather than silently producing low-confidence merges that corrupt downstream retrieval or structured extraction.

Model choice and performance. This task benefits from models with strong instruction-following and structured output capabilities. Use a model that supports JSON mode or structured output constraints natively to reduce parsing failures. For high-volume pipelines, consider a smaller fine-tuned model if the layout extraction engine provides consistent element formatting. Cache the prompt prefix containing the schema and instructions across calls to reduce per-request token costs. Measure pipeline performance on three metrics: merge precision (did we merge only when correct?), merge recall (did we catch all true continuations?), and orphan rate (elements left unmerged that should have been stitched). Run these evals against a golden dataset of documents with known page-break continuations before deploying any prompt or model change.

Integration points. Wire the stitching step after layout extraction and before chunking or structured extraction. If your pipeline already produces markdown or JSON from each page, the stitcher should operate on the structured representation rather than raw text to preserve element type metadata. Downstream, the page-break annotations enable chunking strategies that respect element boundaries and retrieval systems that can cite continuous passages across page breaks without fabricating content. Avoid running stitching on documents where the layout extractor already handles page breaks correctly—add a pre-check that counts elements ending mid-sentence at page bottoms and only invoke the stitching prompt when the count exceeds a threshold.