Unsupported Claim Correction Prompt

This prompt is a post-generation recovery step for accuracy-critical RAG and document-intelligence pipelines. It is not a first-pass answer generator. Use it when a model has already produced an answer that contains factual claims not directly supported by the provided evidence. The prompt instructs the model to act as a strict auditor: extract every discrete claim from the original answer, cross-reference each claim against the source passages, flag claims that lack evidence, and regenerate a corrected answer where every assertion is grounded or explicitly abstained. The ideal user is an engineering lead or AI reliability engineer building a cited-answer system for compliance, legal, finance, healthcare, or enterprise search—domains where an unsupported claim reaching the user is a product failure, not a minor flaw.

This prompt belongs inside a validation loop, not a standalone chat interface. Trigger it programmatically when a citation-coverage check, hallucination detector, or source-to-claim alignment scorer falls below a defined threshold. The upstream system must supply: the original generated answer, the complete set of retrieved source passages with identifiers, and the specific failure signal that triggered recovery. Do not use this prompt for real-time chat where latency budgets are under 500ms; the extraction-audit-regeneration cycle adds meaningful processing time. Do not use it when the original answer contains zero factual claims—an abstention or purely conversational response does not need claim-level auditing. Do not use it as a substitute for improving retrieval quality; if every answer triggers recovery, fix retrieval first.

Before wiring this into production, define your recovery budget. A single pass through this prompt usually corrects most unsupported claims, but some edge cases—ambiguous source passages, conflicting evidence, or claims that are partially supported—may require a second pass or escalation to human review. Set a maximum retry count (typically 2) and a clear escalation path. Log every recovery invocation with the original answer, the failure signal, the extracted claims, the alignment results, and the regenerated output. These logs become your audit trail and your debugging dataset for improving upstream retrieval and generation. If the domain is regulated, ensure a human reviews any answer that required recovery before it reaches the end user, even if the prompt reports full grounding.

This prompt template is designed to be dropped into a post-generation validation step within a RAG or document-intelligence pipeline. It takes the original model output and the provided evidence context, then identifies every factual claim that lacks direct source support. The template forces the model to either ground each claim with a specific source passage or remove it, producing a corrected output that is safe for compliance-sensitive applications. Use this when your product requires auditable traceability between generated text and retrieved evidence.

Below is the copy-ready prompt. Replace every square-bracket placeholder with your application's specific values before sending it to the model. The [CLAIMS] placeholder expects a list of discrete factual assertions extracted from the original output. The [EVIDENCE_PASSAGES] placeholder expects the full set of retrieved source documents or chunks. The [ABSTENTION_POLICY] placeholder defines what the model should do when evidence is insufficient—typically either remove the claim or insert a clearly marked abstention statement. The [OUTPUT_FORMAT] placeholder should specify the exact JSON schema or structured format your downstream parser expects.

textCopy
You are an evidence-grounding auditor. Your task is to review a set of claims against provided source passages and produce a corrected output where every retained claim is directly supported by cited evidence.

## INPUT

**Claims to verify:**
[CLAIMS]

**Source evidence passages:**
[EVIDENCE_PASSAGES]

## INSTRUCTIONS

1. For each claim in the input, determine whether it is directly supported by at least one source passage.
2. A claim is "supported" only if the source passage contains the same factual assertion. Paraphrasing is acceptable; inference or extrapolation is not.
3. For each supported claim, provide the exact source passage text that supports it and a brief explanation of the alignment.
4. For each unsupported claim, apply the following abstention policy: [ABSTENTION_POLICY]
5. Do not add any new claims that were not present in the input.
6. Do not modify the meaning of any claim when grounding it.

## OUTPUT

Return your results in the following format:
[OUTPUT_FORMAT]

## CONSTRAINTS

- Every retained claim must have a verifiable source citation.
- If a claim appears supported but the source passage is ambiguous, treat it as unsupported.
- Do not fabricate citations or source passages.
- Flag any claims where you have low confidence in the alignment.

After copying this template, wire it into your validation harness so that the original model output is first decomposed into discrete claims before being passed to this prompt. A common failure mode is passing the full generated paragraph without claim extraction, which causes the model to miss embedded unsupported assertions. Also ensure that [EVIDENCE_PASSAGES] includes all retrieved context, not just the top-k results, because claims may be supported by lower-ranked passages that a truncated context window would omit. For high-stakes domains, always route outputs with any unsupported claims to human review before they reach end users.

The Unsupported Claim Correction Prompt is not a standalone fix; it is a recovery step inside a larger evidence-grounding harness. The typical integration point is after an initial answer generation and a claim-to-source alignment check. When the alignment check flags claims with no supporting passage or with alignment scores below a configured threshold, the flagged claims and their surrounding context are routed into this correction prompt. The prompt's job is to either re-ground each claim against the provided evidence or replace it with an explicit abstention. The harness should treat this prompt as a constrained regeneration step, not a free-form edit, because the output must preserve the structure and citations of the original answer wherever possible.

Wire the prompt into an application by building a recovery pipeline with clear validation gates. After the correction prompt returns a revised answer, run the same claim-extraction and source-mapping validator that detected the original problem. Compare the before and after alignment scores. If unsupported claims remain, increment a retry counter. A typical production harness allows up to 2 correction retries before escalating. On the second retry, pass the remaining unsupported claims and the validator's specific failure reasons back into the prompt's [UNSUPPORTED_CLAIMS] and [VALIDATION_ERRORS] placeholders. If the third attempt still fails, route the answer to a human review queue with the original evidence, the flagged claims, and the correction history attached. Log every attempt, the alignment scores, and the final disposition for observability.

Model choice matters here. This prompt requires strong instruction-following and precise claim manipulation, not creative generation. Claude 3.5 Sonnet or GPT-4o are appropriate defaults. Avoid smaller or older models that may drop citations or hallucinate new claims during correction. Set temperature to 0 or very low (0.1) to maximize reproducibility. If your system uses structured output APIs, define an output schema that includes the corrected answer text and a corrections_applied array listing each claim, its original status, and the action taken (grounded, removed, abstained). This schema makes downstream validation deterministic. For RAG systems with retrieval retry capability, consider chaining this prompt after an Evidence Gap Identification and Fill Prompt so that the correction step has the best available evidence before attempting re-grounding.

The highest-risk failure mode is silent re-hallucination: the correction prompt generates a new claim that sounds plausible but still lacks source support. Mitigate this by always running the alignment validator after correction, never trusting the prompt's self-report of corrections. A secondary risk is over-abstention, where the prompt removes borderline claims that a human reviewer would accept. Tune this by adjusting the [CONSTRAINTS] placeholder with explicit guidance on when to abstain versus when to ground with a lower-confidence note. For regulated or high-stakes domains, always require human review of any answer that required correction, even if the validator passes it on the retry. The correction event itself is a signal that the initial generation was unreliable.