Statistical Claim Verification Prompt Template

This prompt is designed for data analysts, verification engineers, and pipeline builders who need to programmatically check whether a quantitative claim is supported by provided source data. It handles tolerance windows, unit normalization, calculation verification, and structured pass/fail/marginally-supported verdicts. Use this when you have a specific numerical assertion and a dataset or reference value to check it against. This is not a general-purpose data analysis prompt; it assumes the claim has already been extracted and the evidence has already been retrieved. The prompt belongs in the verification step of a fact-checking pipeline, after claim extraction and evidence matching.

The ideal user has already isolated a single, atomic numerical claim—such as 'revenue grew 12% year-over-year' or 'the median response time is 340ms'—and has retrieved the relevant source data or reference values needed to verify it. The prompt expects structured inputs: the claim text, the evidence data (with units and time periods), and a tolerance specification that defines acceptable deviation. It does not perform retrieval, claim extraction, or source authority assessment. Those steps must happen upstream. If you need to extract claims from a document, match them to evidence, or assess source credibility, use the appropriate upstream prompts from the claim extraction and evidence matching playbooks instead.

Do not use this prompt when the claim is qualitative, opinion-based, or predictive without a defined evaluation horizon. It is not suitable for verifying statements like 'our product is the best on the market' or 'we expect growth to accelerate.' It also should not be used when the evidence is incomplete, when units cannot be normalized to a common basis, or when the tolerance window cannot be specified in advance. In regulated or high-risk domains—such as financial reporting, clinical data, or safety-critical metrics—always route the verification output to human review and maintain an audit trail of the claim, evidence, tolerance, and verdict. The prompt produces a structured result, not a final decision.

This prompt template is designed to be copied directly into your prompt layer and adapted for your specific verification workflow. It takes a statistical claim, source data, and verification parameters as inputs, then produces a structured verification result. The template uses square-bracket placeholders that your application must replace with actual values before sending the request to the model. Each placeholder represents a distinct input that shapes how the model evaluates the claim.

textCopy
You are a statistical claim verification assistant. Your task is to evaluate a quantitative claim against provided source data and produce a structured verification result.

## CLAIM TO VERIFY
[CLAIM_TEXT]

## SOURCE DATA
[DATA_SOURCE]

## VERIFICATION PARAMETERS
- Tolerance: [TOLERANCE_PERCENT]% relative difference allowed
- Units: [EXPECTED_UNITS]
- Confidence level required: [CONFIDENCE_LEVEL]
- Comparison type: [COMPARISON_TYPE] (exact_match | directional | range_check | calculation_verify)

## OUTPUT SCHEMA
Return a JSON object with these fields:
{
  "claim_id": "[CLAIM_ID]",
  "verification_result": "supported" | "contradicted" | "insufficient_evidence" | "calculation_error" | "unit_mismatch",
  "computed_value": number | null,
  "claimed_value": number | null,
  "absolute_difference": number | null,
  "relative_difference_percent": number | null,
  "within_tolerance": boolean | null,
  "units_detected": "string",
  "units_normalized_to": "string",
  "calculation_steps": ["step1", "step2"],
  "evidence_excerpt": "string",
  "confidence_score": 0.0-1.0,
  "limitations": ["limitation1"],
  "requires_human_review": boolean
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Parse the claim to identify the asserted value, metric, and any comparison or trend language.
2. Extract the relevant data points from the source data.
3. Normalize units before comparison. If units cannot be normalized, flag as unit_mismatch.
4. Perform any required calculations to derive the computed value from source data.
5. Compare computed value to claimed value using the specified tolerance.
6. If the source data is insufficient to verify the claim, set verification_result to "insufficient_evidence".
7. If the claim contains a calculation error in how it was derived from the same source data, set verification_result to "calculation_error".
8. Set requires_human_review to true if confidence_score is below [HUMAN_REVIEW_THRESHOLD] or if [RISK_LEVEL] is "high".
9. Include all calculation steps so the result is auditable.
10. Do not invent data. If evidence is missing, say so.

To adapt this template, replace each square-bracket placeholder with values from your application context. For [CLAIM_TEXT], provide the exact claim string. For [DATA_SOURCE], include the raw data, table, or dataset the claim references. Set [TOLERANCE_PERCENT] based on your domain's acceptable error margin—financial audits might use 0.1%, while market size estimates might allow 5%. The [CONSTRAINTS] placeholder should contain domain-specific rules like rounding conventions, acceptable source age, or required calculation methods. For [EXAMPLES], include one or two few-shot examples showing correct verification outputs for claims similar to what you expect in production. The [RISK_LEVEL] and [HUMAN_REVIEW_THRESHOLD] placeholders control when the workflow escalates to a human reviewer. Always validate the model's output against the schema before accepting it, and log both the prompt and response for audit trails when verifying claims with compliance implications.

This prompt is designed to be called as a step within a larger verification pipeline, not as a standalone chat interaction. The application layer is responsible for extracting the claim, retrieving the source data, and assembling the [CLAIM] and [SOURCE_DATA] variables before invoking the model. The model's output is a structured JSON object that downstream systems consume for automated decision-making, routing, or audit logging. Treat the prompt as a deterministic function: given the same inputs and model version, the output schema should be stable enough for programmatic parsing.

Implement a validation layer immediately after the model response. Parse the JSON output and check for the presence of required fields: claim_id, verification_status, calculated_value, tolerance_window, unit_match, and evidence. If the JSON is malformed, retry once with a repair prompt that includes the raw output and a strict schema reminder. For numerical fields, validate that calculated_value is a number, tolerance_window is a positive number, and unit_match is a boolean. If verification_status is UNVERIFIABLE or CONTRADICTED, route the claim to a human review queue with the full prompt context and model output attached. Log every verification attempt—including the model, prompt version, input claim, source data hash, output, and validation result—to enable regression testing and audit trails.

Model choice matters for numerical reasoning. Prefer models with strong quantitative performance and consistent JSON output, such as gpt-4o or claude-3-opus. Avoid models known to hallucinate calculations or struggle with unit conversions. Set the temperature to 0 for deterministic outputs. If your source data is large, pre-process it to extract only the relevant rows, columns, or summary statistics needed for the specific claim, rather than passing entire datasets. For claims involving currency or time-sensitive rates, include the conversion rate and its effective date in the [SOURCE_DATA] block to prevent the model from using stale internal knowledge. Never allow the model to perform live data retrieval; all evidence must be provided in the prompt to maintain a closed, auditable verification boundary.