Conflicting Numerical Data Reconciliation Prompt

Use this prompt when your RAG pipeline retrieves multiple documents containing numerical values that disagree—such as revenue figures, clinical trial results, sensor readings, or statistical estimates—and you need the system to surface the discrepancy rather than silently averaging or hallucinating a consensus. The job-to-be-done is reconciliation: identifying which sources report which numbers, normalizing units and rounding, calculating the spread, and producing a structured output that a downstream system or human reviewer can act on. The ideal user is an AI engineer or product builder integrating this prompt into a financial, scientific, or operational RAG application where numerical accuracy and traceability are non-negotiable.

This prompt requires several inputs to function correctly. You must supply the conflicting numerical values with their source identifiers, the expected unit of measure, a tolerance band for acceptable variance, and any domain-specific rounding or precision rules. The prompt template uses placeholders like [SOURCE_VALUES], [TARGET_UNIT], [TOLERANCE], and [PRECISION_RULES] to make these requirements explicit. Without unit normalization rules, the model may compare dollars to euros or kilograms to pounds without flagging the conversion gap. Without a tolerance band, trivial rounding differences may be reported as conflicts, flooding downstream review queues with noise.

Do not use this prompt when the numerical values are already consistent within tolerance, when you need a single authoritative answer without conflict documentation, or when the sources lack sufficient metadata to trace which number came from which document. This prompt is also inappropriate for non-numerical factual conflicts—use the Multi-Source Conflict Detection Prompt for textual claim contradictions instead. For high-stakes domains such as clinical trial data reconciliation or financial audit evidence, always route the structured output to a human reviewer before any automated decision. The prompt produces a reconciliation report, not a final adjudication. Pair it with the Answer Abstention on Conflicting Evidence Prompt when the spread exceeds your risk threshold and the system should refuse to synthesize a single number.

The prompt below is designed to be dropped into a RAG pipeline after retrieval has returned multiple documents containing numerical claims that disagree. It forces the model to normalize units, apply configurable tolerance bands, explain discrepancies rather than silently picking a winner, and output a structured reconciliation record that downstream systems can consume. Use this template when the cost of hiding a conflict is higher than the cost of surfacing it—financial reporting, clinical data aggregation, sensor fusion, and compliance audits are all good fits.

textCopy
You are a numerical reconciliation engine operating on retrieved documents. Your job is to detect, normalize, and explain conflicting numerical values across sources. Do not fabricate data. Do not silently discard minority values. When sources disagree beyond the configured tolerance, surface the conflict with an explanation.

## INPUT
Retrieved documents with numerical claims:
[DOCUMENTS]

## CONFIGURATION
- Target metric: [METRIC_NAME]
- Unit normalization target: [TARGET_UNIT]
- Relative tolerance band: [TOLERANCE_PERCENT]%
- Rounding precision: [DECIMAL_PLACES] decimal places
- Minimum sources required for consensus: [MIN_SOURCES]
- Conflict severity thresholds: critical > [CRITICAL_THRESHOLD]% deviation, major > [MAJOR_THRESHOLD]%, minor otherwise

## OUTPUT SCHEMA
Return a JSON object with these fields:
{
  "metric": "string",
  "unit": "string",
  "sources_analyzed": number,
  "sources_excluded": [{"source_id": "string", "reason": "string"}],
  "reconciled_value": number | null,
  "reconciliation_method": "consensus_mean" | "weighted_mean" | "most_credible_source" | "unresolvable",
  "confidence": number (0.0 to 1.0),
  "uncertainty_range": {"low": number, "high": number},
  "individual_values": [
    {
      "source_id": "string",
      "raw_value": number,
      "raw_unit": "string",
      "normalized_value": number,
      "precision_notes": "string",
      "in_consensus": boolean
    }
  ],
  "conflicts": [
    {
      "severity": "critical" | "major" | "minor",
      "sources_involved": ["string"],
      "deviation_percent": number,
      "explanation": "string",
      "likely_root_cause": "temporal_drift" | "methodology_difference" | "rounding_error" | "unit_conversion_error" | "data_quality_issue" | "unknown"
    }
  ],
  "requires_human_review": boolean,
  "review_reason": "string | null"
}

## CONSTRAINTS
1. Normalize all values to [TARGET_UNIT] before comparison. Document your conversion factors.
2. Sources with missing precision metadata should be flagged in precision_notes, not excluded.
3. If fewer than [MIN_SOURCES] sources remain after exclusion, set reconciled_value to null, reconciliation_method to "unresolvable", and requires_human_review to true.
4. When deviation between any two sources exceeds [CRITICAL_THRESHOLD]%, requires_human_review must be true regardless of consensus.
5. Do not average values that differ beyond [TOLERANCE_PERCENT]%. Instead, report them as conflicts and set reconciliation_method to "unresolvable".
6. If a source reports a range instead of a point value, use the midpoint for reconciliation but preserve the range in precision_notes.
7. Round all output values to [DECIMAL_PLACES] decimal places.
8. If you cannot determine the unit of a source value, exclude that source and document the reason.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adaptation notes: Replace [DOCUMENTS] with your retrieved chunks, including source IDs and retrieval metadata. Set [TOLERANCE_PERCENT] based on your domain—1% for financial reconciliation, 5-10% for operational metrics, wider for estimates. The [FEW_SHOT_EXAMPLES] placeholder should contain 2-3 worked examples showing both resolved and unresolvable conflicts. Set [RISK_LEVEL] to "high" to enable additional constraints like mandatory human review for any conflict, or "standard" for automated pipelines with downstream review queues. If your sources include timestamps, add a source_date field to individual_values and a temporal precedence rule to CONSTRAINTS.

Before deploying, validate that your model reliably populates all required JSON fields and correctly identifies when reconciled_value should be null. Common failure modes include averaging across tolerance bands, dropping minority sources without documenting them in conflicts, and failing to normalize units before comparison. Run this prompt against a golden dataset of known conflicts with expected reconciliation outcomes, and measure both field-level schema compliance and conflict detection recall.

This prompt is designed to sit downstream of a retrieval step that returns multiple documents containing numerical claims about the same entity or metric. The harness must supply the prompt with a structured [INPUT] that includes the target metric name, the list of source documents with their numerical values and metadata, and any domain-specific [CONSTRAINTS] such as tolerance bands, unit normalization rules, or rounding conventions. The prompt is not a standalone tool—it expects the application layer to have already extracted candidate numbers and their source context before invoking reconciliation.

Wire the prompt into a pipeline that first normalizes all extracted numerical values to a common unit and precision before calling the model. Use a pre-processing validator to reject inputs where fewer than two sources are provided or where values cannot be parsed into a numeric type. After the model returns its reconciliation output, run a post-processing schema validator against the expected [OUTPUT_SCHEMA]: a JSON object containing a reconciled_value (with an uncertainty_range array of [low, high]), a discrepancy_explanation string, a source_precision_notes array, and a confidence_score between 0 and 1. If the output fails schema validation, retry once with the validation error appended to the prompt as additional context. Log every reconciliation attempt—including input sources, raw model output, validation result, and final payload—for auditability. For financial or clinical use cases where the reconciled number drives downstream decisions, route outputs with a confidence score below 0.7 or an uncertainty range exceeding a configurable threshold to a human review queue before the value is committed to any system of record.

Model choice matters here. Use a model with strong numerical reasoning and structured output capabilities. Avoid models known to hallucinate arithmetic or ignore explicit rounding instructions. If your pipeline processes high volumes, consider caching reconciliation results keyed by a hash of the normalized input sources and constraints to avoid redundant LLM calls. Do not use this prompt for real-time trading or safety-critical medical dosing without a hard human-in-the-loop gate. The prompt handles reconciliation logic, but the harness owns unit conversion, schema enforcement, retry policy, and the escalation path when numbers cannot be safely resolved.