Grounded Answer Regeneration Prompt

This prompt is a targeted recovery tool for accuracy-critical product teams who need to repair a model response that has been flagged for containing hallucinations, fabricated details, or unsupported assertions. It is designed to be used inside a post-generation validation loop, not as a general-purpose answer generator. The ideal user is an AI reliability engineer or backend developer integrating this prompt into an automated harness where a fact-checking system, an LLM judge, or a user report has identified specific ungrounded claims. The prompt takes the original flagged answer and the verified source context, then instructs the model to regenerate a corrected response using only verifiable evidence.

You should use this prompt when your product workflow already includes a detection mechanism that can flag a response as hallucinated and provide the ground-truth context that should have been used. This is common in RAG systems, cited QA products, and any application where factual accuracy is a non-negotiable requirement. The prompt includes explicit constraints for abstention when the provided evidence is insufficient, which prevents the model from replacing one hallucination with another. It is particularly effective when paired with a structured output schema that separates the corrected answer from a list of changes made, enabling downstream audit logging.

Do not use this prompt as a first-pass generation strategy. It is a repair tool, not a prevention tool. For initial answer generation, use a context-only answer constraint prompt that prevents hallucination from the start. Do not use this prompt when the source context itself is untrusted or unverified—the regeneration is only as good as the evidence you provide. Finally, avoid using this prompt in a tight loop without a retry budget; if the model fails to produce a grounded answer after two attempts, escalate to a human reviewer rather than burning compute on diminishing returns. The next section provides the copy-ready prompt template you can adapt and integrate into your validation pipeline.

This template is the core instruction set for your hallucination recovery loop. It takes a previously flagged answer and the original source context, then instructs the model to produce a corrected response that only uses verifiable evidence. The prompt is designed to be wrapped in your application's retry logic—replace every square-bracket placeholder with live data from your validator output, context store, and application state before sending it to the model.

textCopy
SYSTEM: You are a fact-correction assistant. Your only job is to regenerate an answer that is strictly grounded in the provided [CONTEXT]. You must never introduce external knowledge, even if you believe the original answer was correct. If the [CONTEXT] does not contain sufficient evidence to support a claim, you must abstain from making that claim.

USER: A previous answer was flagged for containing unsupported or fabricated claims. Your task is to produce a corrected version.

ORIGINAL FLAGGED ANSWER:
[FLAGGED_ANSWER]

SOURCE CONTEXT (the only allowed evidence):
[CONTEXT]

VIOLATIONS IDENTIFIED:
[VIOLATION_LIST]

CONSTRAINTS:
- Every factual statement in your corrected answer must have a direct match in the [CONTEXT].
- If a claim from the original answer cannot be verified, remove it entirely.
- If the [CONTEXT] is insufficient to answer the user's original question, state that clearly and explain what is missing.
- Do not rephrase unsupported claims to make them sound more plausible.
- Preserve the original answer's structure and tone where possible, but prioritize accuracy.
- Output only the corrected answer. Do not include meta-commentary about the correction process.

CORRECTED ANSWER:

Adapt this template by adjusting the CONSTRAINTS block to match your product's risk tolerance. For high-stakes domains like healthcare or legal review, add an explicit abstention instruction: If [CONTEXT] does not directly address the user's question, respond with 'INSUFFICIENT_EVIDENCE' and list the missing information. For lower-stakes applications, you might allow the model to note uncertainty while still providing a partial answer. The VIOLATION_LIST placeholder should contain the specific claims your validator flagged—this gives the model precise targets for correction rather than asking it to re-evaluate the entire answer from scratch. Wire this prompt into a retry harness that increments a counter, logs each regeneration attempt, and escalates to human review after your defined retry budget is exhausted.

The Grounded Answer Regeneration Prompt is designed to sit inside a post-generation validation loop, not as a standalone chat interface. In production, you'll typically call this prompt after an upstream hallucination detector or fact-checking validator has flagged a response as containing unsupported claims. The harness receives three inputs: the original flagged answer, the source context that was provided to the model, and the specific validator error or flagged claim list. The prompt then regenerates a corrected response that only uses verifiable evidence from the source context, with explicit abstention where evidence is insufficient.

Wiring pattern: Place this prompt behind a retry-aware API endpoint or queue worker. The caller passes original_answer, source_context, and flagged_claims (or a validator error object). Before calling the LLM, validate that source_context is non-empty—an empty context should immediately escalate to human review rather than invoking regeneration, since the model has nothing to ground against. After receiving the regenerated output, run it through the same hallucination detector that triggered the retry. If it passes, return the corrected answer. If it fails again, increment a retry counter. Retry budget: Cap at 2-3 regeneration attempts per original query. Beyond that, the harness should log the failure, preserve the last attempt, and escalate to a human review queue rather than looping indefinitely. Each retry should include the accumulated failure reasons so the model can see what it got wrong previously.

Model selection: Use a model with strong instruction-following and low hallucination rates for this task—frontier models (GPT-4, Claude 3.5 Sonnet, Gemini 2.0) are appropriate for accuracy-critical workflows. Avoid smaller or older models that may fabricate citations or ignore abstention instructions. Set temperature to 0 or near-zero to maximize determinism and reduce creative fabrication. Logging and observability: Log every regeneration attempt with: original answer, source context hash, validator error details, regenerated output, pass/fail result, retry count, and final disposition (corrected, escalated, or exhausted). This audit trail is essential for debugging systematic hallucination patterns and for compliance in regulated domains. Human review integration: When escalation occurs, present the reviewer with the original answer, the source context, the flagged claims, and all regeneration attempts side-by-side. The reviewer's decision (accept corrected version, provide manual correction, or mark context as insufficient) should be logged and can be used to improve both the hallucination detector and the regeneration prompt over time.