Data Quality and Completeness Impact Verification Prompt

This prompt is designed for engineers and analysts who need to verify whether a numerical claim remains valid given the quality and completeness of the underlying data. The primary job-to-be-done is producing a structured impact assessment that answers: 'If the data has known gaps, staleness, duplicates, or aggregation issues, how much should I trust this specific number?' Use this when you have a concrete numerical claim, a description of the dataset it came from, and a list of suspected or confirmed data quality defects. The output should inform a go/no-go decision on publishing the claim, trigger a data repair workflow, or provide an audit trail for why a claim was qualified or suppressed.

The ideal user is a data engineer, analytics engineer, or verification pipeline operator who already has visibility into data lineage, freshness metrics, and completeness statistics. You need to provide the prompt with: the exact claim text, the source dataset identifier, a structured list of quality issues (missing rows, duplicate records, stale partitions, aggregation logic), and the tolerance window for acceptable deviation. The prompt is not a replacement for data profiling tools or automated data quality monitors. It is a reasoning layer that sits between those monitors and the decision to trust a downstream claim. Do not use this prompt when you lack concrete quality metrics or when the claim is purely qualitative. It also fails when the quality issues are so severe that no reasonable imputation or sensitivity analysis can bound the uncertainty—in those cases, the correct output is a refusal to assess, not a forced confidence score.

This prompt works best inside a verification pipeline where data quality checks have already run and produced structured defect records. Wire it after automated profiling but before human review. The prompt expects square-bracket placeholders for the claim, dataset context, quality defect list, and output schema. If your pipeline cannot produce a structured defect list, start with a data profiling step first. Avoid using this prompt for real-time dashboards where latency constraints prevent thorough sensitivity analysis. For high-stakes claims in regulated domains, always route the output to human review and retain the full prompt-response pair as audit evidence.

This prompt template is designed to be copied directly into your application or evaluation harness. It instructs the model to act as a verification engineer, systematically evaluating how missing data, duplicates, staleness, and aggregation choices could undermine a specific numerical claim. The square-bracket placeholders let you inject your own data profile, the claim under review, and your organization's quality thresholds without rewriting the core logic.

textCopy
You are a data quality verification engineer. Your task is to assess how data quality and completeness issues could affect the validity of a specific numerical claim.

## CLAIM TO VERIFY
[CLAIM]

## DATA PROFILE
[SOURCE_DATA_PROFILE]

## DATA QUALITY RULES
[QUALITY_RULES]

## CONSTRAINTS
- For each quality dimension (completeness, uniqueness, freshness, consistency, accuracy), state whether it is a risk to the claim.
- For each risk identified, estimate the direction and magnitude of potential bias (e.g., "could inflate the reported value by 5-10%").
- If imputation or fill methods were used, evaluate whether the chosen method is appropriate and how alternative methods would change the result.
- Flag any claim that becomes unsupportable if a specific data gap exceeds the thresholds defined in the quality rules.
- Use the provided tolerance windows when assessing numerical impact.
- Do not invent data. If the data profile is insufficient to assess a dimension, state that explicitly.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "claim_id": "string",
  "overall_assessment": "supported | partially_supported | unsupported",
  "quality_dimension_impacts": [
    {
      "dimension": "completeness | uniqueness | freshness | consistency | accuracy",
      "risk_level": "none | low | medium | high | critical",
      "potential_bias_direction": "overestimate | underestimate | unknown | none",
      "estimated_magnitude": "string explaining the estimated impact range",
      "threshold_breach": true | false,
      "evidence": "string citing specific data profile details"
    }
  ],
  "imputation_method_evaluation": {
    "method_used": "string | null",
    "appropriateness": "appropriate | questionable | inappropriate | not_applicable",
    "alternative_methods_and_impact": "string describing how alternatives would shift the result"
  },
  "unsupportable_if": [
    "string describing conditions that would invalidate the claim"
  ],
  "recommended_remediation": [
    "string describing concrete steps to close data gaps"
  ],
  "requires_human_review": true | false,
  "human_review_reason": "string explaining why, or null"
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each placeholder with your specific context. [CLAIM] should contain the exact numerical assertion being checked, including its value, unit, time period, and source. [SOURCE_DATA_PROFILE] must describe the dataset's shape, column definitions, known gaps, collection methodology, and any preprocessing steps applied. [QUALITY_RULES] should encode your organization's thresholds—for example, 'maximum acceptable missing rate per column: 5%' or 'data must be no older than 24 hours for operational claims.' [FEW_SHOT_EXAMPLES] is critical for consistency; provide at least two worked examples showing how a claim should be assessed when data quality is good versus when it is poor. [RISK_LEVEL] should be set to 'low', 'medium', 'high', or 'critical' to calibrate the model's sensitivity—higher risk levels should trigger human review for borderline cases.

Before deploying this prompt, validate that the output JSON conforms to the schema using a structural validator. For high-risk domains such as financial reporting or clinical data, always set requires_human_review to true when any dimension scores 'high' or 'critical' risk, and route those outputs to a review queue. Common failure modes include the model hallucinating data gaps not present in the profile, overestimating impact magnitude when tolerance windows are narrow, and failing to distinguish between 'data is missing' and 'data was never collected.' Build eval cases that test each of these failure modes explicitly, and log every assessment with the prompt version, input profile, and model identifier for auditability.

This prompt is designed to sit inside a verification pipeline after a numerical claim has been extracted and matched to a candidate dataset, but before a final verification verdict is rendered. The harness must supply the claim text, the dataset (or a representative schema and summary statistics), and a list of known or suspected data quality issues. The model's job is to assess whether those quality issues materially change the claim's support level—not to re-verify the claim from scratch. Wire this as a synchronous call within a broader orchestration layer (e.g., a task queue or workflow engine) that already has access to dataset profiles, freshness metadata, and completeness statistics.

Input assembly: Before calling the prompt, assemble the [CLAIM] with its original context, the [DATASET_SCHEMA] including column names, types, and row counts, and a [QUALITY_ISSUES] list drawn from upstream data profiling tools (e.g., Great Expectations, dbt tests, or custom anomaly detectors). Each issue should include the affected field, the issue type (missing, duplicate, stale, outlier, or aggregation artifact), and a severity estimate. If the dataset is too large to inline, pass summary statistics (null percentages, duplication rates, last-refresh timestamps, distribution moments) instead of raw rows. The [SENSITIVITY_THRESHOLD] parameter controls how much impact is required to flag a claim as unreliable—start with a default of 10% relative change in the claim's key metric and tune based on domain risk tolerance.

Validation and retry logic: Parse the model's JSON output against a strict schema that requires impact_assessment (one of none, minor, moderate, severe), sensitivity_results (a list of what-if scenarios with metric deltas), and imputation_method_evaluation (ranked alternatives with trade-offs). If the output fails schema validation, retry once with the validation error message appended to the prompt as a correction hint. If the second attempt also fails, route to a human reviewer with the raw output and schema violation details. For high-stakes claims (e.g., financial reporting, clinical data), always require human sign-off when impact_assessment is moderate or severe, regardless of schema validity.

Model choice and latency budget: This prompt requires strong reasoning over structured data descriptions and statistical concepts. Use a model with demonstrated quantitative reasoning capability (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set a timeout of 30 seconds for standard claims and 60 seconds for claims involving multiple quality dimensions or large schema descriptions. If the model times out, split the quality issues into separate calls and aggregate results with a simple max-severity rule. Log every call with the claim ID, dataset version hash, quality issue fingerprint, model response, and reviewer decision for audit trail purposes.

What to avoid: Do not use this prompt as a standalone verification step—it only assesses quality impact, not claim truth. Do not pass raw PII or full datasets into the prompt; use aggregated statistics and schema descriptions. Do not skip the imputation method evaluation section even if the dataset appears clean; stale or incomplete data can still produce misleadingly precise claims. Finally, avoid wiring this prompt directly into a user-facing dashboard without a human review buffer for severe impact findings—the model can identify risks but should not be the final arbiter of whether a claim is safe to publish.