Cross-Page Row Reconciliation Prompt

This prompt is designed for data engineers and pipeline operators who need to reassemble a single logical data row that has been split across a page break in a PDF. The core job is to match partial rows from two consecutive pages using a stable key field—such as an invoice line number, transaction ID, or general ledger account code—and merge their cell values into one complete record. You should use this prompt when your upstream table extraction has already produced structured JSON row arrays per page, and you now face the problem of orphaned half-rows that would otherwise create duplicate or incomplete entries in your downstream database.

The prompt requires three concrete inputs to function reliably. First, you must supply the extracted rows from the current page and the following page as two separate JSON arrays, with each row represented as an ordered list of cell values. Second, you must specify the zero-based index of the key column that should be used for matching (for example, index 0 for a transaction ID column). Third, you must provide the expected total number of columns in a complete row so the prompt can detect partial rows and validate merge results. Without a stable, unique key field that spans the page break, this prompt will produce unreliable matches and should not be used. If your tables lack a consistent row identifier across pages, you need a different approach—such as spatial proximity matching or header-pattern continuation detection—rather than key-based reconciliation.

Do not use this prompt when rows can split across more than two pages, when the key field itself is split by the page break, or when the table has merged cells that span the page boundary. In those cases, the prompt will either fail silently or produce merged rows with missing key values. For tables with multi-page row splits, chain this prompt iteratively across page pairs. For merged-cell scenarios, apply a merged cell resolution prompt first to produce a clean grid before reconciliation. Always run a row-count validation after merging: the total number of output rows should equal the sum of complete rows from both pages plus the number of successfully matched partial-row pairs. If this invariant fails, route the page pair to human review rather than silently propagating corrupted data.

This prompt template is designed to be dropped into your document processing pipeline when you have already extracted raw table data from individual PDF pages and need to reassemble logical rows that were fragmented across page boundaries. The template assumes you have page-level table representations and a set of key fields that define row identity. It instructs the model to match partial rows, merge split cells, and flag any rows that could not be reconciled, producing a structured output that your application can consume directly.

textCopy
You are a table reconciliation engine. Your task is to reassemble logical rows from a multi-page table where individual rows may split across page breaks.

## INPUT
You will receive:
1. A list of page-level table extractions, each with a page number and an array of rows.
2. A list of key fields that uniquely identify a logical row.

Page-level tables:
[PAGE_TABLES]

Key fields for row identity:
[KEY_FIELDS]

## CONSTRAINTS
- A logical row may span multiple pages. Match partial rows across pages using the key fields.
- When a row continues on a subsequent page, the continuation may omit repeated key field values. Infer the match from row position, surrounding context, and partial key matches.
- Merged cells that split across pages must be reassembled. Concatenate text content from split cell fragments with a space separator.
- If a row appears to be a repeated header row rather than a data continuation, exclude it from the merged output and note it in the `excluded_header_rows` field.
- If a row fragment cannot be matched to any other fragment with confidence, include it in the output but flag it in the `unreconciled_rows` field with the reason.
- Do not invent data. If a cell value is missing in all fragments, leave it null.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "reconciled_table": [
    {
      "row_id": "string, a stable identifier for the logical row",
      "source_pages": [1, 2],
      "cells": {
        "column_name": "value"
      },
      "reconciliation_confidence": "high | medium | low",
      "reconciliation_notes": "string explaining how fragments were matched, or null"
    }
  ],
  "unreconciled_rows": [
    {
      "page": 1,
      "row_index": 0,
      "cells": {},
      "reason": "string explaining why reconciliation failed"
    }
  ],
  "excluded_header_rows": [
    {
      "page": 2,
      "row_index": 0,
      "cells": {}
    }
  ],
  "reconciliation_summary": {
    "total_logical_rows": 0,
    "reconciled_rows": 0,
    "unreconciled_rows": 0,
    "pages_processed": 0
  }
}

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace [PAGE_TABLES] with your actual page-level extraction data, structured as an array of objects each containing a page number and a rows array. Replace [KEY_FIELDS] with the column names that together form a unique row identifier—for a general ledger this might be ["account_code", "transaction_date", "reference_number"]. The [EXAMPLES] placeholder should contain one or two worked examples showing a split row and the expected reconciled output. Set [RISK_LEVEL] to "high" if the reconciliation feeds financial reports or compliance filings, which should trigger downstream validation and human review for any unreconciled_rows. For lower-risk analytical use cases, set it to "medium" or "low" to adjust the model's conservatism in flagging uncertain matches. Before deploying, validate that your page-level extraction preserves enough row-position context for the model to reason about continuations—if your extraction pipeline strips row ordering, reconciliation accuracy will degrade sharply.

The cross-page row reconciliation prompt is not a standalone tool—it is a post-extraction assembly step that sits between raw table extraction and downstream ingestion. After your layout-aware extraction prompt has produced per-page table fragments, feed those fragments into this reconciliation prompt to merge split rows, resolve continuation markers, and produce a single normalized table. The prompt expects structured input: an array of page objects, each containing a page number and an array of row objects with key fields that can be used for matching across page boundaries.

Wiring the prompt into a pipeline requires several guard layers. First, validate the input shape before calling the model—each page must have a page_number and rows array, and each row must include the key fields specified in [MATCHING_KEY_FIELDS]. If a page fragment is missing required keys, route it to a repair step before reconciliation. After the model returns the merged table, run a row-count sanity check: the total reconciled rows should not exceed the sum of input rows across all pages, and no row should appear with duplicate key combinations unless explicitly flagged as an unresolved split. Log every reconciliation decision—matched rows, merged cells, and flagged orphans—so that downstream audit can trace each output row back to its source pages.

Model choice and retry strategy matter here. Use a model with strong structured output support and a large enough context window to hold all page fragments plus the prompt. If the table spans more pages than fit in a single context window, batch the reconciliation: process pages in overlapping windows of 3–5 pages, then reconcile the batch outputs in a second pass. On validation failure, retry once with the error details injected into [CONSTRAINTS]. If the retry also fails, escalate the affected page range to human review rather than silently dropping rows. For high-stakes use cases like general ledger extraction, require human sign-off on any row flagged as reconciliation_status: unresolved before the data reaches a financial system.

Observability is non-negotiable. Emit structured logs containing the input page count, output row count, number of merged rows, number of unresolved rows, and per-row source page ranges. If your pipeline writes to a data warehouse or ledger, include a reconciliation_run_id and reconciliation_timestamp on every output row. This lets downstream consumers distinguish between rows that were extracted cleanly from a single page and rows that were assembled across page breaks—critical context when investigating numeric discrepancies later. Finally, treat the reconciliation prompt as versioned infrastructure: any change to the matching logic, key fields, or output schema should be tested against a golden dataset of known multi-page tables before release.