Numerical Claim Verification Prompt

Use this prompt when an AI system generates or reports numerical values that must be verified against a source of truth. This is a model-graded evaluation prompt designed for finance, analytics, and data-heavy applications where a single incorrect digit can break downstream decisions. The prompt compares a target claim against source data, applying tolerance-aware logic to detect value errors, unit mismatches, rounding inconsistencies, and fabricated statistics. It belongs in automated evaluation pipelines, CI/CD gates for RAG systems, and any workflow where numerical groundedness is a hard requirement before an output reaches a user or database.

The ideal user is an AI engineer or technical decision maker who already has a system producing numerical outputs—such as a financial report generator, an analytics chatbot, or a RAG pipeline answering quantitative questions—and needs an automated gate to catch errors before they propagate. The prompt requires two concrete inputs: a target claim containing the numerical assertion to verify, and source data that serves as the authoritative reference. It works best when the source data is structured or semi-structured (tables, JSON, clearly formatted text) and the claim is specific enough to match against it. Do not use this prompt for subjective assessments, qualitative fact-checking, or scenarios where the source data itself is ambiguous or incomplete.

This prompt is not a replacement for schema validation, unit tests, or deterministic calculation checks. If you can verify a number with a simple equality check or a database query, do that first. Reserve this prompt for cases where the claim and source are in natural language, where tolerance matters, or where unit conversion and rounding logic require semantic reasoning. In high-stakes domains like financial reporting or clinical data, always route verification failures to a human review queue rather than auto-correcting values. The prompt is a detection tool, not an auto-repair tool. Pair it with logging that captures the claim, source, and verdict for audit trails.

This prompt template is designed to be copied directly into your evaluation harness or LLM invocation pipeline. It instructs the model to act as a numerical verification judge, comparing a set of target claims against provided source data. The prompt enforces structured output, explicit tolerance handling, and detailed reasoning for every comparison. Before using it, ensure you have identified the specific numerical claims to verify, gathered the authoritative source data, and defined your acceptable tolerance thresholds for each metric type.

textCopy
You are a numerical claim verification system. Your task is to compare numerical claims against provided source data and determine whether each claim is accurate, inaccurate, or unverifiable.

## INPUT
[CLAIMS]
[SOURCE_DATA]

## TOLERANCE CONFIGURATION
- Percentage values: ±[TOLERANCE_PERCENT] percentage points
- Currency values: ±[TOLERANCE_CURRENCY] in the reported currency
- Counts and integers: exact match required unless otherwise specified
- Custom tolerances: [CUSTOM_TOLERANCES]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "verification_results": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "claimed_value": "number or string",
      "source_value": "number or string or null",
      "source_reference": "string or null",
      "verdict": "accurate|inaccurate|unverifiable",
      "deviation": "number or null",
      "deviation_unit": "absolute|percentage_points|percent_change|null",
      "within_tolerance": "boolean or null",
      "reasoning": "string explaining the comparison, tolerance application, and verdict"
    }
  ],
  "summary": {
    "total_claims": "number",
    "accurate": "number",
    "inaccurate": "number",
    "unverifiable": "number",
    "overall_reliability_note": "string"
  }
}

## CONSTRAINTS
- For each claim, locate the corresponding value in the source data. If the value cannot be found, mark it as unverifiable.
- Apply the correct tolerance from the tolerance configuration based on the value type.
- Calculate deviation precisely. For percentages, report deviation in percentage points. For other values, report absolute deviation and percent change where meaningful.
- If a claim involves a calculation or derived metric, verify the computation logic against the source data.
- Flag any unit mismatches explicitly in the reasoning field.
- Flag any apparent rounding issues that could explain minor deviations.
- Do not invent source values. If the source data is ambiguous, mark the claim as unverifiable and explain why.
- If the source data contains conflicting values for the same metric, report the conflict and mark the claim as unverifiable.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your workflow, replace each square-bracket placeholder with runtime values. The [CLAIMS] field should contain a structured list of claims with unique IDs. The [SOURCE_DATA] field must include the authoritative dataset, document, or reference values. Configure tolerances based on your domain's acceptable error margins—financial reporting may require tighter tolerances than market sizing estimates. The [EXAMPLES] placeholder is critical for few-shot calibration; include at least two examples showing accurate, inaccurate, and unverifiable verdicts with correct tolerance application. Set [RISK_LEVEL] to high if the verification output drives automated decisions, which should trigger human review for any inaccurate or unverifiable claims. For production deployments, validate the output JSON against the schema before accepting results, and log all verification runs with the prompt version, input claims, and verdicts for audit trails.

The Numerical Claim Verification Prompt is designed to operate as a structured evaluation step within a larger pipeline, not as a standalone chat interaction. To integrate it, you'll need to programmatically assemble the prompt with the [SOURCE_DATA], [CLAIM], and [TOLERANCE_CONFIG] variables, then parse the structured JSON output for downstream decision-making. The prompt expects the source data to be provided as structured text—typically a CSV excerpt, a JSON payload, or a formatted table—and the claim to be a single, self-contained numerical assertion. The tolerance configuration should specify acceptable percentage or absolute deviation for each metric being verified, as financial and analytical use cases rarely require exact equality.

For production use, implement a validation layer that parses the model's JSON response and checks for the required fields: claim_verdict, extracted_value, source_value, deviation, and tolerance_check. If the output fails schema validation, retry once with a repair prompt that includes the original response and the specific validation errors. Log every verification attempt—including the input claim, source data snapshot, model response, and final verdict—to create an audit trail for compliance and debugging. For high-stakes financial or clinical applications, route any verdict marked "uncertain" or where the deviation falls within a configurable gray zone to a human review queue rather than accepting the model's binary pass/fail decision automatically.

Model choice matters significantly for this task. Use a model with strong numerical reasoning capabilities and explicit support for structured JSON output modes. Avoid models that tend to hallucinate calculations or paraphrase numbers. If your pipeline processes high volumes of claims, implement batching where multiple claims against the same source data are verified in a single request to reduce latency and cost. For evaluation pipelines, pair this prompt with a golden dataset of known claim-source pairs to measure precision and recall of the verification verdicts, and monitor for drift in the model's tolerance sensitivity over time.