Confidence Interval and Margin of Error Verification Prompt

This prompt is for verification engineers, data analysts, and AI pipeline builders who need to programmatically validate claims about confidence intervals, margins of error, and uncertainty quantification. Use it when a source document, report, or model output asserts an interval estimate and you must verify that the confidence level, construction method, and interpretation are internally consistent and mathematically sound. The primary job-to-be-done is automated audit: you have a stated claim (e.g., 'the 95% confidence interval is 48% to 52%') and supporting evidence (sample size, standard error, distribution assumptions), and you need a structured verdict on whether the claim holds up against that evidence.

This prompt is not a general statistics tutor. It assumes you already have the claimed interval, the claimed confidence level, and the underlying sample data or summary statistics. It does not compute intervals from raw data; it verifies whether a stated interval aligns with the evidence provided. Common triggers include audit workflows checking survey methodology, automated fact-checking of research claims, and QA pipelines for AI-generated statistical summaries. The prompt works best when you can supply the original claim verbatim, the numerical evidence, and the expected confidence level—without these three inputs, verification quality degrades sharply.

Do not use this prompt when you need to calculate a confidence interval from scratch, when the underlying data distribution is unknown and must be inferred, or when the claim involves Bayesian credible intervals without a specified prior. It is also unsuitable for verifying prediction intervals, tolerance intervals, or bootstrap intervals unless you explicitly adapt the [CONSTRAINTS] block to specify the interval type. For high-stakes domains like clinical trial reporting or regulatory filings, always route the prompt output through human review and cross-reference against the original statistical software output rather than treating the model's verification as authoritative.

This prompt template provides a structured verification harness for checking claims about confidence intervals, margins of error, and uncertainty quantification. It is designed to be copied directly into your verification pipeline, with square-bracket placeholders that you replace with the specific claim, source data, and evaluation parameters before sending to the model. The template enforces a rigorous output schema that separates interval construction verification from interpretation correctness, ensuring your verification results are machine-readable and auditable.

textCopy
You are a statistical verification specialist. Your task is to verify a claim about a confidence interval or margin of error against provided source data and methodological context.

## CLAIM TO VERIFY
[CLAIM_TEXT]

## SOURCE DATA
[DATA_TABLE_OR_SUMMARY_STATISTICS]

## METHODOLOGICAL CONTEXT
- Sample size: [SAMPLE_SIZE]
- Sampling method: [SAMPLING_METHOD]
- Confidence level claimed: [CONFIDENCE_LEVEL]
- Population parameter estimated: [PARAMETER_TYPE]
- Interval type (confidence, prediction, tolerance): [INTERVAL_TYPE]
- Distribution assumptions: [DISTRIBUTION_ASSUMPTIONS]

## VERIFICATION INSTRUCTIONS
1. Recalculate the interval using the provided data and standard formulas appropriate for the stated sampling method and distribution assumptions.
2. Compare the recalculated interval to the claimed interval. Apply a tolerance of [TOLERANCE] for rounding differences.
3. Verify that the confidence level interpretation is correct: a [CONFIDENCE_LEVEL]% confidence interval means that if the sampling procedure were repeated many times, approximately [CONFIDENCE_LEVEL]% of the constructed intervals would contain the true population parameter.
4. Check for common errors: confusion between confidence and prediction intervals, asymmetric interval mishandling, incorrect standard error calculation, and misinterpretation of the interval as a probability statement about the parameter.
5. Flag any unsupported assumptions or missing methodological details that prevent full verification.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "verification_result": "VERIFIED" | "UNVERIFIED" | "CONTRADICTED" | "INSUFFICIENT_EVIDENCE",
  "recalculated_interval": {
    "lower_bound": number | null,
    "upper_bound": number | null,
    "margin_of_error": number | null
  },
  "claimed_interval": {
    "lower_bound": number | null,
    "upper_bound": number | null,
    "margin_of_error": number | null
  },
  "interval_match": boolean | null,
  "confidence_level_verified": boolean,
  "interpretation_errors": [
    {
      "error_type": "CONFIDENCE_PREDICTION_CONFUSION" | "PROBABILITY_MISINTERPRETATION" | "ASYMMETRIC_INTERVAL_ERROR" | "SE_CALCULATION_ERROR" | "OTHER",
      "description": "string",
      "severity": "CRITICAL" | "MAJOR" | "MINOR"
    }
  ],
  "assumption_violations": ["string"],
  "missing_information": ["string"],
  "verification_notes": "string"
}

## CONSTRAINTS
- Do not invent data or assumptions. If information is missing, mark the claim as INSUFFICIENT_EVIDENCE and list what is needed.
- Use standard statistical formulas. Document which formula you applied in verification_notes.
- If the interval type is asymmetric (e.g., bootstrap percentile intervals), note this in verification_notes and explain how the comparison was performed.
- For survey-based claims, check whether the margin of error accounts for design effects if the sampling method is complex.

To adapt this template for your verification pipeline, replace each square-bracket placeholder with concrete values from the claim you are checking. The [DATA_TABLE_OR_SUMMARY_STATISTICS] placeholder should contain the raw or summary data needed for recalculation—this could be a CSV snippet, a table of summary statistics, or a structured description of the data. The [TOLERANCE] value should reflect your acceptable rounding error (typically 0.01 for percentages or a small fraction of the standard error). If your verification workflow involves multiple claims, wrap this prompt in a batch processing loop that iterates over claims and collects structured outputs for downstream aggregation.

Before deploying this prompt in production, test it against known-good and known-bad interval claims to calibrate the tolerance window and verify that the model correctly distinguishes between confidence, prediction, and tolerance intervals. Pay particular attention to asymmetric interval handling—many models default to symmetric interval assumptions and will misclassify valid bootstrap or profile likelihood intervals as errors. If your use case involves regulated reporting (e.g., clinical trial results, official statistics), always route UNVERIFIED and CONTRADICTED results to a human reviewer with the full verification payload attached.

This prompt is designed to be called as a verification step after claim extraction, not as a standalone user-facing chatbot. Wrap it in a function that validates inputs before sending, parses the JSON output, and routes failures to human review. The function should accept a claim object containing the claim text, the reported interval bounds, the stated confidence level, the sample size if available, and any source context. Before calling the model, validate that the claim text is non-empty, the interval bounds are numeric and ordered (lower < upper), and the confidence level is between 0 and 1. Reject malformed inputs at the application layer rather than relying on the model to catch them.

For batch verification pipelines, run this prompt per claim and aggregate results into a verification report. Set temperature to 0 for deterministic outputs. Use structured output mode if your model provider supports it; otherwise, append a strict JSON schema instruction to the prompt. Log every verification result with the claim ID, timestamp, model version, and raw response for audit trails. If the model returns verification_status: insufficient_data, do not retry with the same inputs; escalate to a human analyst with the claim source text and available evidence packaged together. Retries are only appropriate for transient model errors, not for insufficient-evidence outcomes.

When integrating with upstream claim extraction, ensure the claim object includes the original source text span so the verification prompt can check whether the interval was reported as symmetric or asymmetric, whether the confidence level was explicitly stated, and whether the claim confuses confidence intervals with prediction intervals. Downstream, route verification_status: verified claims to automated reporting, verification_status: contradicted claims to a contradiction resolution queue, and verification_status: insufficient_data claims to human review with a pre-populated review packet containing the claim, source text, and any evidence snippets retrieved. Avoid building automated retry loops around insufficient-data outcomes; they waste tokens and delay human review.