Evidence Matching for Numerical Claims Prompt

This prompt performs a single, well-defined task: it compares an extracted numerical claim against provided source evidence and returns a structured verification result. The ideal user is a verification pipeline engineer who has already solved claim extraction and evidence retrieval. You feed this prompt a claim like 'Q3 revenue reached $4.2M, up 18% YoY' and the relevant source passages containing the reference figures, and it returns a match determination with explicit calculation steps, tolerance analysis, and unit normalization. It is not a general-purpose fact-checker, a retrieval system, or a claim extraction tool. It assumes the claim and evidence are already isolated and paired.

Use this prompt when your pipeline needs deterministic, auditable numerical comparisons. It handles the common failure cases that break naive string matching: rounded values ('23%' vs '22.8%'), unit differences ('340ms' vs '0.34 seconds'), statistical ranges ('between 15-20%' vs a claim of '18%'), and calculation verification (checking whether 'up 18% YoY' is mathematically consistent with the provided base and current values). The prompt requires a configurable tolerance window so you can tune strictness per domain—financial audits might demand ±0.5% while market intelligence might accept ±5%. It also normalizes percentage points vs. percent change, a frequent source of verification errors.

Do not use this prompt when you need to retrieve evidence, extract claims from raw text, assess source authority, or decide what counts as an authoritative reference value. Those are upstream concerns. Do not use it for non-numerical factual claims like 'the CEO resigned in March'—that requires textual entailment, not numerical comparison. Do not use it when the claim involves complex statistical reasoning beyond basic arithmetic, such as regression coefficients, p-values, or multi-variable causal claims. For those cases, route to a domain-specific verification prompt with appropriate statistical grounding. If the evidence is missing, contradictory across sources, or ambiguous, this prompt will flag those conditions rather than guessing—but it will not resolve them. Upstream evidence ranking and conflict resolution prompts should handle those cases before they reach this comparison step.

This template is designed for verification pipelines that handle quantitative assertions—statistics, percentages, financial figures, scientific measurements, and data-derived claims. Unlike general claim-evidence matching, numerical verification requires explicit tolerance windows, unit conversion awareness, and calculation traceability. The prompt expects a specific numerical claim, one or more evidence passages, and configuration parameters that define acceptable deviation thresholds. Before using this template, ensure your upstream claim extraction has isolated the numerical assertion with its full context, including any qualifiers like 'approximately,' 'at least,' or 'over.'

textCopy
You are a numerical claim verification system. Your task is to determine whether the provided evidence supports, contradicts, or is insufficient to verify the given numerical claim.

## CLAIM TO VERIFY
[CLAIM_TEXT]
- Claimed value: [CLAIMED_VALUE]
- Unit: [CLAIMED_UNIT]
- Qualifiers present: [QUALIFIERS]
- Claim context (surrounding text): [CLAIM_CONTEXT]

## EVIDENCE PROVIDED
[EVIDENCE_PASSAGES]
- Source identifier: [SOURCE_ID]
- Publication date: [PUBLICATION_DATE]
- Evidence type: [EVIDENCE_TYPE]

## VERIFICATION PARAMETERS
- Tolerance window: ±[TOLERANCE_PERCENT]% or ±[TOLERANCE_ABSOLUTE] [UNIT]
- Unit normalization required: [YES/NO]
- Rounding rules: [ROUNDING_RULES]
- Statistical range handling: [RANGE_HANDLING]
- Temporal alignment required: [YES/NO]
- Calculation verification required: [YES/NO]

## OUTPUT SCHEMA
Return a JSON object with these fields:
{
  "verdict": "supported|contradicted|insufficient_evidence|partially_supported",
  "matched_value": number or null,
  "matched_unit": string or null,
  "normalized_claim_value": number or null,
  "normalized_evidence_value": number or null,
  "deviation_percent": number or null,
  "within_tolerance": boolean,
  "evidence_excerpt": "exact quote containing the matching value",
  "evidence_location": "paragraph/section/line reference",
  "calculation_steps": ["step-by-step normalization and comparison logic"],
  "uncertainty_factors": ["list of factors affecting confidence"],
  "missing_evidence_gap": "what evidence would be needed to resolve this claim" or null,
  "confidence_score": 0.0 to 1.0
}

## CONSTRAINTS
- Do not infer values not present in the evidence.
- Flag rounding discrepancies explicitly.
- If the claim uses 'approximately' or similar qualifiers, widen the tolerance window accordingly.
- If the evidence value is a range, check whether the claimed value falls within that range.
- If unit conversion is required, show your conversion factors and steps.
- If the evidence publication date differs significantly from the claim's temporal context, note this as an uncertainty factor.
- Never fabricate evidence excerpts or source locations.
- If no matching numerical evidence exists, set verdict to 'insufficient_evidence' and populate missing_evidence_gap.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL: low|medium|high|critical]

Adapt this template by adjusting the tolerance window based on your domain's precision requirements—financial audits may need ±0.1% while market estimates might accept ±10%. The [FEW_SHOT_EXAMPLES] placeholder should contain 2–3 worked examples showing correct normalization, tolerance application, and edge cases like rounded values or statistical ranges. For high-risk domains, set [RISK_LEVEL] to 'high' or 'critical' and ensure your harness routes uncertain outputs to human review. The output schema is designed for downstream programmatic consumption—every field is nullable where evidence may be absent, preventing silent null-to-zero bugs in your pipeline.

The numerical evidence matching prompt is not a standalone tool—it is a component inside a larger verification pipeline. In production, you will typically call this prompt after a retrieval step has returned candidate source passages and a claim extraction step has isolated the numerical assertion to verify. The prompt expects a specific numerical claim and one or more evidence passages as input, and it returns a structured comparison with tolerance analysis, unit normalization notes, and a support verdict. Wiring this correctly means building the harness around the prompt, not treating the prompt as the entire application.

Start with input validation before the model call. The claim input must contain a parseable numerical value, a unit or dimension, and enough context to understand what is being measured. If the claim is 'revenue grew 15%' without a time window or baseline, reject it before the prompt runs and request clarification. For the evidence passages, validate that each passage contains at least one numerical value and that the retrieval step returned passages with sufficient context windows—truncated snippets that cut off the number or its unit will produce garbage comparisons. Implement a pre-flight check that scans evidence for digit patterns and common unit strings (%, USD, kg, etc.) and routes empty or non-numerical evidence to a 'missing evidence' handler instead of the matching prompt.

The model call itself should be wrapped in a retry harness with structured output validation. Request JSON output with a strict schema: fields for claim_value, evidence_value, unit_match (boolean), normalized_comparison, tolerance_window, within_tolerance (boolean), support_verdict (enum: supports/contradicts/insufficient), and calculation_notes. After the model responds, validate that claim_value and evidence_value are both present and numeric, that unit_match is consistent with the normalized_comparison field, and that within_tolerance logically follows from the comparison and tolerance. If validation fails, retry with the validation errors appended to the prompt as correction feedback. Set a maximum of two retries before escalating to human review.

Tolerance configuration is the most critical operational decision. Hard-code tolerance windows by domain rather than letting the model decide: financial figures might use ±2% for revenue claims and ±5% for market size estimates; scientific measurements might use the reported significant figures to derive tolerance; demographic statistics might use ±1 percentage point for survey-derived percentages. Pass the tolerance as a [TOLERANCE_CONFIG] parameter in the prompt rather than baking it into the system instructions, so operators can adjust thresholds without changing the prompt template. Log every comparison's tolerance window alongside the verdict for auditability.

For high-stakes verification (financial reporting, clinical data, regulatory filings), route all contradicts verdicts and all insufficient verdicts on material claims to a human review queue. Package the original claim, the evidence passages, the normalized comparison, and the model's calculation notes into a review packet. Do not auto-publish contradiction flags without human confirmation when the downstream action could trigger corrections, retractions, or compliance alerts. For lower-stakes use cases like internal dashboard validation, you can auto-accept supports verdicts above a confidence threshold while still sampling a percentage for manual QA to detect drift.

Model choice matters for numerical reasoning. Prefer models with strong quantitative performance on benchmarks like GSM8K or MATH for this prompt. Weaker models will mishandle unit conversion (confusing millions and billions, misplacing decimal points) and will struggle with percentage-change versus percentage-point-change distinctions. If you must use a smaller model for cost or latency reasons, add explicit unit conversion examples to the prompt and consider pre-processing evidence to extract and normalize numerical values before the model call, reducing the reasoning burden on the LLM. Log every instance where the model performs a unit conversion so you can audit conversion errors separately from evidence matching errors.