Retrieved Fact vs Live Fact Comparison Prompt

This prompt is designed for a single, high-stakes job: comparing a fact retrieved from a static knowledge base against a fresh result from a live data source to detect discrepancies. The ideal user is an AI engineer or backend developer building a Retrieval-Augmented Generation (RAG) pipeline for a copilot or agent where information changes faster than the indexing cycle. You need this when your system caches or indexes facts from a primary source (like a database, API, or document store) and must later verify if that fact is still true at query time. The core value is preventing confident, wrong answers that erode user trust—a common failure mode when a knowledge base drifts from reality.

Use this prompt when you have both a previously retrieved fact and a fresh, live query result available in the same turn. The prompt requires two explicit inputs: [RETRIEVED_FACT] (the claim, its source, and retrieval timestamp) and [LIVE_FACT] (the fresh query result, its source, and query timestamp). It is not a general fact-checker, a hallucination detector, or a retrieval query generator. Do not use it when you lack a live source to query, when the fact is subjective, or when the cost of a live query outweighs the risk of staleness. For high-risk domains like healthcare, finance, or legal, the output must be treated as a signal for human review, not an automated override.

The prompt outputs a structured comparison with a match status, the conflicting values, and a resolution recommendation. This output is designed to be machine-readable so your application can route it: a 'match' can skip refresh logic, a 'conflict' can trigger a context update or user warning, and an 'uncertain' result can escalate for human review. Before deploying, you must evaluate this prompt on a golden dataset of known-changed facts to measure detection recall and on known-stable facts to measure false-positive rate. The next section provides the copy-ready template and explains how to adapt the placeholders for your specific data contracts.

This prompt template is the core of the Retrieved Fact vs Live Fact Comparison workflow. It is designed to be dropped into a RAG pipeline where a static knowledge base fact and a fresh live data source result are available. The prompt forces a structured comparison, outputting a match status, the conflicting values, and a resolution recommendation. Use this template when you have a specific fact from a prior retrieval that you suspect may be stale and a corresponding live query result to check it against.

codeCopy
You are a fact verification specialist. Your task is to compare a previously retrieved fact against a fresh result from a live data source. Determine if they match, conflict, or if the comparison is indeterminate.

[RETRIEVED_FACT]: The fact retrieved from the static knowledge base.
[LIVE_FACT]: The corresponding result from a live query.
[FACT_CONTEXT]: A brief description of what this fact represents (e.g., 'customer subscription status', 'current software version').
[COMPARISON_RULES]: Specific rules for comparison, such as 'numeric values must match exactly' or 'dates within 24 hours are considered a match'.

Analyze the two facts and output a JSON object with the following schema:
{
  "match_status": "match" | "conflict" | "indeterminate",
  "retrieved_value": "The value from [RETRIEVED_FACT]",
  "live_value": "The value from [LIVE_FACT]",
  "conflict_detail": "A concise explanation of the discrepancy, if any. Null if status is 'match'.",
  "resolution_recommendation": "use_live" | "use_retrieved" | "flag_for_review" | "re_query",
  "resolution_reasoning": "A brief justification for the recommendation.",
  "confidence": 0.0-1.0
}

[OUTPUT_SCHEMA]: You must output only the JSON object. Do not include any other text.
[CONSTRAINTS]: If the live fact is unavailable or an error was returned, set match_status to 'indeterminate' and recommend 're_query'. If the facts are semantically identical but formatted differently, they are a 'match'.

To adapt this template, replace the square-bracket placeholders with your application's specific data and logic. The [COMPARISON_RULES] placeholder is critical for tuning precision; for example, you might define that a version string like 'v2.1.0' and '2.1' are a match. The [FACT_CONTEXT] helps the model disambiguate values. After generating the output, always validate the JSON structure and the match_status enum before allowing the result to influence downstream logic. For high-risk decisions, such as financial or healthcare data, the flag_for_review recommendation must trigger a human-in-the-loop step, not an automated overwrite.

The Retrieved Fact vs Live Fact Comparison Prompt is designed to sit at a critical junction in your RAG pipeline: the point where a previously retrieved fact must be reconciled with a fresh live query. This is not a standalone prompt but a verification gate that should be called after a live data fetch returns a result that may conflict with cached or previously retrieved context. The harness must treat this prompt as a structured comparison function—it takes two known inputs (the retrieved fact and the live fact) and produces a structured discrepancy report. Do not use this prompt to perform the live query itself; that belongs to your application's tool-calling or API layer. The prompt's job is comparison, arbitration, and resolution recommendation, not data retrieval.

Wiring the prompt into your application requires a clear contract between your retrieval system and the comparison step. First, extract the specific claim or fact from your RAG context that needs verification—this becomes the [RETRIEVED_FACT] input. Structure it as a single, self-contained assertion with its source citation and retrieval timestamp. Second, execute your live data query through your application's existing tool or API infrastructure and format the result as the [LIVE_FACT] input, including the query timestamp and data source. The prompt's [COMPARISON_CRITERIA] field should specify what constitutes a match versus a discrepancy for your domain—numeric tolerance for financial data, semantic equivalence for text, or exact match for identifiers. Validation layer: Before the prompt output reaches any downstream system, validate that the match_status field is one of your expected enum values (match, discrepancy, uncertain, live_unavailable), that conflicting values are populated when status is discrepancy, and that the resolution_recommendation field contains an actionable next step. Reject and retry any output that fails schema validation.

Model choice and retry strategy matter here because false negatives (flagging a discrepancy where none exists) erode trust and trigger unnecessary re-verification loops, while false positives (missing a real discrepancy) allow stale facts to propagate. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent. Set temperature=0 to maximize deterministic comparison behavior. Implement a retry budget of 2 attempts for schema validation failures, but do not retry on uncertain status outputs—those should be escalated to a human review queue or logged for offline analysis. For high-stakes domains (finance, healthcare, compliance), always route discrepancy and uncertain results through a human approval step before updating the assistant's active context. Log every comparison result with the retrieved fact, live fact, match status, timestamp delta, and resolution recommendation to build an audit trail and to measure detection recall against known-changed facts over time.

Testing and evaluation must be built into the harness before deployment. Maintain a golden dataset of known-changed facts where you control both the stale retrieved version and the correct live version. Measure detection recall: what percentage of known discrepancies does the prompt correctly flag? Measure precision: what percentage of flagged discrepancies are real? Pay special attention to boundary cases—facts that changed within seconds of the comparison, facts where only a subordinate clause changed, and facts where the live source is temporarily unavailable. Your harness should also track latency from live query to comparison output, as this prompt adds a sequential step to your RAG pipeline. If latency exceeds your SLA, consider batching multiple fact comparisons into a single prompt call or implementing a fast-path that skips comparison for facts with retrieval timestamps under a freshness threshold. Finally, expose the match_status and resolution_recommendation fields to your observability stack so you can alert on sudden increases in discrepancy rates, which may indicate a broken live data source rather than actual fact changes.