Self-Correction Prompt for Ungrounded Claims

This prompt is designed for the correction phase of a RAG pipeline, specifically after an initial answer has been generated and a grounding verification step has identified specific claims that lack support in the source evidence. Its job is to produce a revised answer by removing or explicitly caveating those ungrounded claims, without introducing new fabrications or altering the structure of well-supported content. The ideal user is an AI engineer or product developer who already has a list of failed claims from a fact-verification or hallucination-detection module and needs a reliable, automated correction step before the answer reaches the user.

Do not use this prompt as a standalone answer-generation prompt. It assumes a prior answer and a verification report exist as inputs. Using it without a verified list of ungrounded claims will likely result in the model 'fixing' a non-existent problem, potentially degrading a perfectly good answer. The prompt is also not a substitute for a robust grounding verification step; if your upstream hallucination detector has low recall, this correction step will only patch a subset of the issues. For high-stakes domains like healthcare or legal, the output of this prompt should still pass through a human review stage, as the correction itself can introduce subtle semantic drift or new, unsupported caveats.

Before integrating this prompt, ensure your pipeline produces a structured verification report that maps specific claims to their source evidence and flags failures. The prompt is most effective when the list of ungrounded claims is precise, referencing exact sentences or clauses from the original answer. If your verification step only provides a vague 'confidence score' without claim-level detail, use a claim extraction and source verification prompt first to generate the necessary granular report. The next section provides the copy-ready template you can adapt for your specific output schema and correction policy.

This template implements a self-correction loop for RAG answers that failed grounding verification. It receives the original answer alongside a structured list of claims that were flagged as unsupported by your verification step. The model's job is to produce a revised answer that removes or explicitly caveats every flagged claim without introducing new fabrications or silently dropping verified content. Use this when your verification node has already identified specific grounding failures and you need a corrected answer for the user rather than a total regeneration from scratch.

textCopy
SYSTEM: You are an answer correction specialist. Your only job is to revise a previously generated answer to remove or caveat claims that failed source verification. You must preserve all verified content exactly as written. You must not add new factual claims, examples, or details that were not present in the original answer and explicitly verified.

INPUT:
- Original answer: [ORIGINAL_ANSWER]
- Retrieved context used for verification: [RETRIEVED_CONTEXT]
- Unsupported claims (these failed verification): [UNSUPPORTED_CLAIMS_LIST]
- Verification notes: [VERIFICATION_NOTES]

INSTRUCTIONS:
1. For each unsupported claim, either remove it entirely or rewrite it with an explicit caveat that states the claim could not be verified against the provided sources.
2. Preserve all other content from the original answer without modification.
3. Maintain the original answer's structure, tone, and formatting.
4. If removing a claim creates a gap in the answer's flow, add a brief transitional phrase but do not introduce new factual content.
5. If all claims are unsupported, respond with a structured abstention: "I cannot provide a verified answer based on the available sources."
6. Output only the revised answer. Do not include explanations, commentary, or meta-analysis.

OUTPUT FORMAT: Plain text matching the original answer's style.

CONSTRAINTS:
- Do not add claims, statistics, dates, names, or factual assertions not present in the original verified content.
- Do not paraphrase verified claims in a way that changes their meaning.
- Do not speculate about why claims failed verification.
- If a caveat is added, use language like "[Note: this claim could not be verified against the provided sources]" or "[Unverified]" before the claim.

Replace each square-bracket placeholder before sending this prompt to the model. [ORIGINAL_ANSWER] should contain the full text of the answer that failed verification. [RETRIEVED_CONTEXT] should include the evidence passages used during verification so the model understands what was available. [UNSUPPORTED_CLAIMS_LIST] must be a structured list of the specific claims that your verification step flagged, ideally with the exact claim text and the reason it failed. [VERIFICATION_NOTES] can include any additional signals from your verification pipeline such as confidence scores, partial matches, or ambiguous cases. If your verification step produces a JSON payload, serialize the relevant fields into these placeholders before assembly. For high-stakes domains, route the revised answer to a human reviewer before returning it to the user and log both the original and corrected versions for audit.

The self-correction prompt for ungrounded claims is not a standalone prompt—it is a recovery step inside a grounding verification loop. The typical harness flow is: (1) generate an initial answer from retrieved context, (2) run a hallucination detection or claim extraction prompt that maps each factual claim to source evidence, (3) collect the list of claims that failed source verification, and (4) feed the original answer plus the failed-claim list into this self-correction prompt. The output is a revised answer that removes or caveats unsupported claims. This prompt should never be the first step in a pipeline; it assumes a prior verification pass has already identified specific grounding failures.

Wire this prompt into your application as a conditional recovery step, not a default path. After the hallucination detection step returns a failed_claims array, check whether the array is non-empty. If empty, bypass self-correction and return the original answer. If non-empty, construct the prompt input with three required fields: [ORIGINAL_ANSWER] (the full answer text from the initial generation), [FAILED_CLAIMS] (a structured list of claims that could not be grounded, each with the claim text and the reason verification failed), and [RETRIEVED_CONTEXT] (the original source passages, so the model can re-check whether any claim can be salvaged with a different citation). Set [CORRECTION_MODE] to either REMOVE (excise unsupported claims entirely) or CAVEAT (retain claims but add explicit uncertainty language). For high-stakes domains, default to REMOVE and require human review before CAVEAT mode is used. Log every correction event with the original answer, failed claims, revised answer, and a diff for auditability.

Build validation and retry guardrails around this step. After the self-correction prompt returns a revised answer, run the same hallucination detection prompt against the revised output to verify that all previously flagged claims were actually removed or caveated. If the revised answer still contains ungrounded claims, increment a retry counter and re-invoke self-correction with the updated failed-claim list. Set a hard retry limit (typically 2-3 attempts). If the limit is exceeded, escalate to a human review queue with the full correction history. Additionally, run a 'new fabrication' check: compare the revised answer's claims against the original answer to detect whether the correction step introduced entirely new unsupported statements. This is a known failure mode where the model fills gaps left by removed claims with fresh fabrications. If new fabrications are detected, treat this as a critical failure and escalate immediately rather than retrying.

Model choice matters for this workflow. Self-correction prompts require strong instruction-following and low hallucination rates under correction pressure. Prefer models with explicit grounding training or verified low fabrication rates in RAG benchmarks. Avoid smaller or older models that tend to 'fill silence' when asked to remove content—they often replace removed claims with plausible-sounding alternatives. For production deployments, pair this prompt with structured output constraints (request JSON with revised_answer, removed_claims, caveated_claims, and modification_summary fields) so you can programmatically verify the correction rather than relying on free-text parsing. If your pipeline uses multiple models for cost optimization, route self-correction requests to your highest-quality model regardless of the model used for initial answer generation.

When deploying in regulated or high-risk domains, add a human review gate after self-correction. The review packet should include: the user's original question, the retrieved context passages, the initial answer, the hallucination detection results, the self-correction prompt input and output, and any retry history. Human reviewers should confirm that removed claims were genuinely unsupported (not just poorly cited), that caveated claims carry appropriate uncertainty language, and that no new fabrications were introduced. Track metrics including correction trigger rate, first-pass correction success rate, retry escalation rate, new fabrication rate, and human review overturn rate. These metrics will tell you whether your grounding verification is too aggressive (flagging claims that are actually supported), too lenient (missing fabrications), or whether the self-correction step itself is introducing quality regressions.