Text-Claim-to-Table-Evidence Cross-Format Verification Prompt

This prompt is designed for verification engineers and AI pipeline builders who need to programmatically check natural language claims against structured tabular evidence. The core job is to take a list of textual assertions and a source table, then produce a structured, cell-level verdict for each claim. This is not a general-purpose question-answering prompt; it is a precision verification tool for workflows where the evidence is already retrieved and formatted as a table, and the output must be machine-readable for downstream routing, scoring, or human review.

Use this prompt when you have a pre-extracted set of atomic claims and a single source table that should contain the relevant evidence. The prompt is ideal for audit workflows, financial report reconciliation, scientific claim verification against published datasets, and any scenario where a human-readable statement must be traced to a specific row, column, and cell. It enforces numerical tolerance checks, unit normalization, and aggregation-mismatch detection, making it suitable for quantitative claims. Do not use this prompt for open-ended retrieval, multi-table joins, or claims that require logical inference beyond direct cell lookup. The prompt assumes the evidence is present and the primary task is matching and validation, not search.

Before integrating this prompt into a production harness, you must define clear failure boundaries. The prompt will struggle with implicit claims that require interpreting table headers, complex multi-step calculations, or claims that span multiple rows without explicit aggregation. It is also sensitive to table formatting; malformed CSV, merged cells, or ambiguous column names will degrade accuracy. Plan for a validation layer that checks the output schema, verifies cell references exist in the source table, and flags any verdicts with low confidence or missing citations. For high-stakes domains like financial auditing or clinical data verification, always route claims with aggregation mismatches or unit conflicts to a human reviewer with the full evidence packet.

The ideal user is a technical builder integrating this prompt into a larger verification pipeline. You should already have a claim extraction step and a table normalization step upstream. The output of this prompt is designed to feed into a scoring, triage, or reporting system. If you are a business user looking for a one-off fact-check, this structured playbook is overkill; use a simpler direct-query prompt instead. If you are building a product where verification results must be auditable and explainable, this prompt provides the citation discipline and structured output you need.

This prompt template is designed to be copied directly into your verification harness. It accepts a list of textual claims and a tabular evidence source, then produces a structured verdict for each claim. The template uses square-bracket placeholders that you must replace with your actual inputs, constraints, and output schema before execution. Every placeholder is designed to be filled programmatically by your application layer—never by asking the model to guess missing values.

textCopy
You are a cross-format verification engine. Your task is to check each textual claim in [CLAIMS_LIST] against the tabular evidence provided in [TABLE_DATA].

For each claim, produce a verification record that follows [OUTPUT_SCHEMA] exactly.

## Evidence Table
[TABLE_DATA]

## Claims to Verify
[CLAIMS_LIST]

## Verification Rules
- Match claims to specific cells using [ROW_IDENTIFIER] and [COLUMN_IDENTIFIER] references.
- Apply a numerical tolerance of [TOLERANCE] when comparing numeric values.
- Normalize units according to [UNIT_NORMALIZATION_RULES] before comparison.
- If a claim aggregates multiple cells, verify the aggregation logic using [AGGREGATION_METHOD].
- Flag any claim that cannot be matched to evidence as [UNVERIFIABLE_LABEL].
- Flag any claim where the evidence contradicts the claim as [CONTRADICTED_LABEL].
- Flag any claim where aggregation produces a mismatch beyond tolerance as [AGGREGATION_MISMATCH_LABEL].

## Constraints
[CONSTRAINTS]

## Output Format
Return a JSON object with a "verifications" array. Each element must match [OUTPUT_SCHEMA]. Do not include commentary outside the JSON.

## Examples
[EXAMPLES]

To adapt this template for production, replace each placeholder with concrete values from your pipeline. [CLAIMS_LIST] should be a pre-extracted array of atomic claims from your claim decomposition step. [TABLE_DATA] should be the raw tabular source, formatted as markdown tables, CSV, or JSON depending on your model's strengths. [OUTPUT_SCHEMA] must be a strict JSON Schema definition that includes fields for claim_id, verdict, matched_cells, tolerance_check_result, aggregation_check_result, and flags. Set [TOLERANCE] to a domain-appropriate value—0.0 for exact matches in financial reconciliation, or a percentage for statistical claims. Define [UNIT_NORMALIZATION_RULES] explicitly, such as "convert all currency values to USD using exchange rates from [DATE]" or "normalize all percentages to decimal form." The [EXAMPLES] placeholder should contain at least two few-shot examples showing correct cell-reference formatting and tolerance application. If your risk level is high, add a human-review routing instruction in [CONSTRAINTS] that triggers when confidence is below a threshold.

This prompt is designed as a single step within a larger verification pipeline. It expects a pre-extracted textual claim and a pre-parsed, structured table as input. The application layer is responsible for claim decomposition, table parsing, and unit normalization before this prompt is called. Do not send raw documents or unparsed spreadsheets directly to this prompt; the model's ability to reason over raw table formats is inconsistent, and you will lose the cell-level citation precision that makes this workflow auditable. The prompt should be treated as a stateless function: one claim, one table, one verdict per call. Batching multiple claims in a single request is possible but increases the risk of cross-claim confusion and makes per-claim retry logic harder to implement.

Input Preparation: Before calling the prompt, normalize the table into a markdown or JSON structure with explicit row and column headers. Parse the textual claim into an atomic, self-contained statement that does not reference other claims. Normalize units in both the claim and the table to a common representation (e.g., 'million USD' vs 'USD × 10^6'). If the claim contains an aggregation (sum, average, percentage), pre-compute the expected value from the table in your application code and pass it as a separate [EXPECTED_AGGREGATION] field. The model should verify your calculation, not perform it from scratch. For numerical claims, define a tolerance window in the [TOLERANCE] field based on the precision of the source data (e.g., ±0.5 for rounded integers, ±0.1% for financial figures).

Output Validation and Retries: The prompt returns a structured JSON verdict. Your harness must validate this output against a strict schema before accepting it. Check that every cell_reference field contains a valid row and column identifier that exists in the input table. If the model returns a cell reference that does not exist, reject the output and retry with an error message appended to the prompt context. Implement a maximum of two retries for schema violations. For UNVERIFIABLE verdicts, log the specific reason code and route to a human review queue if the claim is high-priority. For CONTRADICTED verdicts, flag the specific cells for downstream remediation. Never silently accept a verdict that lacks cell-level citations when the claim type requires them.

Model Choice and Latency: This prompt requires strong instruction-following and structured output capabilities. Use a model with native JSON mode or function-calling support to enforce the output schema. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable. Avoid smaller or older models that may hallucinate cell references or skip the numerical tolerance check. Set temperature=0 to maximize reproducibility. Expect latency of 2-5 seconds per claim-table pair. For batch verification, parallelize calls rather than sending large multi-claim requests. Implement a circuit breaker that pauses processing if the error rate exceeds 10% within a rolling window, indicating a possible prompt drift or model behavior change.

Human Review Integration: Route all CONTRADICTED verdicts and any UNVERIFIABLE verdicts with reason code AGGREGATION_MISMATCH or UNIT_AMBIGUITY to a human review queue. Package the original claim, the full table, the model's verdict, and the specific cell references into a structured review packet. The reviewer should confirm or overturn the machine verdict within your review UI, and their decision should be logged as ground truth for future eval dataset construction. For SUPPORTED verdicts, sample 5-10% for human spot-checking to detect false positives. This sampling rate can decrease over time as your eval scores demonstrate reliability, but never drop below 1% for high-stakes verification domains.

Logging and Observability: Log every prompt call with the claim ID, table source hash, model version, prompt template version, raw response, parsed verdict, and validation status. This audit trail is essential for debugging false positives and for demonstrating verification rigor to compliance stakeholders. Track the distribution of verdict types over time; a sudden shift toward UNVERIFIABLE may indicate a data quality issue upstream, while a spike in CONTRADICTED may signal a change in the source content. Set up alerts on schema validation failure rate and on the ratio of retries to successful calls. These metrics will catch prompt regressions before they corrupt your verification pipeline.