Self-Correction Instruction Prompt for Missing Citations

This prompt is for RAG system builders and AI engineers who need every factual claim in a generated response to be backed by a retrievable source. It instructs the model to perform a self-review pass over its own output, identify claims that lack supporting citations, and either attach the correct source or flag the claim as unsupported. Use this when downstream consumers of your AI output—compliance reviewers, end users, audit systems—require traceable evidence for every assertion. The prompt is designed to be inserted as a second-pass instruction after the model has already drafted an answer with access to retrieved context.

Do not use this as a substitute for retrieval quality improvements. If your retriever consistently fails to surface relevant documents, fix retrieval before adding self-correction. This prompt assumes you already have retrieved context available and that the model can reference it during the review step. It works best when the initial generation step includes citation instructions, so the model is already oriented toward source-backed claims. The self-correction pass then catches what the first pass missed—unsupported generalizations, inferred facts, or claims that drifted beyond the provided evidence.

Before deploying this prompt, validate that your retrieval pipeline returns documents with stable identifiers (chunk IDs, URLs, or section references) that the model can cite. If your context chunks lack persistent IDs, the model will struggle to attach meaningful citations during the correction pass. Also consider the latency budget: this prompt adds a full second inference call, which may be unacceptable for real-time applications. For high-stakes domains like healthcare, legal, or finance, pair this prompt with a human review step rather than treating self-correction as a final guarantee. Start by running this prompt against a golden dataset of known claim-evidence pairs and measure both citation recall (are all claims cited?) and citation precision (do the cited sources actually support the claim?).

This prompt is designed to be pasted as a follow-up message immediately after the model generates its initial response in a RAG pipeline. It instructs the model to act as a strict auditor, comparing every factual claim in its previous output against the provided source context. The goal is to close the gap between fluent generation and verifiable grounding, a critical step before the output reaches a user interface, a compliance reviewer, or a downstream parser that expects citation metadata.

textCopy
Review your previous response against the [SOURCE_CONTEXT] provided below. Perform the following steps:

1. Identify every factual claim, statistic, date, name, or technical statement in your response.
2. For each claim, determine if it is directly supported by a passage in the [SOURCE_CONTEXT].
3. If a claim is supported, add an inline citation immediately after the claim in the format [Source: [SOURCE_ID]]. Use the exact source identifier from the context.
4. If a claim is NOT supported by the [SOURCE_CONTEXT], wrap the claim in an <UNSUPPORTED> tag and append a brief note explaining why it could not be verified.
5. If you are uncertain about a claim's support, wrap it in an <UNCERTAIN> tag and explain the ambiguity.
6. Do not remove or alter any text that is not a factual claim. Preserve the original structure and tone.
7. Output the fully revised response with citations, <UNSUPPORTED>, and <UNCERTAIN> tags.

[SOURCE_CONTEXT]:
[DOCUMENTS]

To adapt this template, replace [DOCUMENTS] with the exact retrieved passages, each prefixed with a unique [SOURCE_ID] such as [DOC_1], [DOC_2], etc. Ensure your application layer injects these identifiers consistently. If your RAG pipeline does not produce stable IDs, generate them at retrieval time. The [SOURCE_CONTEXT] placeholder should contain the full text of the retrieved chunks, not summaries. For high-stakes domains like healthcare or finance, add an explicit instruction: If more than [THRESHOLD]% of claims are flagged as <UNSUPPORTED>, append a warning at the top of the response: 'WARNING: This response contains a high proportion of unverified claims. Human review required.' This prompt works best with models that have strong instruction-following capabilities. Test it against a golden dataset of responses with known citation gaps to calibrate your [THRESHOLD] before production use.

The self-correction prompt is not a standalone artifact—it is a post-generation repair step that runs after the model produces its initial answer. In a production RAG pipeline, you should structure this as a two-pass flow: first, generate the answer with citations from retrieved context; second, pass that answer through the self-correction prompt to identify unsupported claims and either add missing citations or flag them explicitly. This separation keeps the primary generation fast and focused while the correction pass handles citation hygiene. The correction prompt expects the original answer, the retrieved source documents, and any citation format rules as inputs.

Validation and retry logic must sit between the correction output and the end user. After the correction pass, run a deterministic check: parse the corrected answer for citation markers, verify that each citation points to a real source ID present in the retrieved context, and flag any claims that remain uncited or cite nonexistent sources. If the correction pass fails to resolve all issues—or introduces new ones like hallucinated citations—feed the validation errors back into a retry loop with a maximum of two additional correction attempts. On the third failure, escalate to a human review queue with the original answer, the correction history, and the specific validation failures attached. Log every correction attempt, including the model's reasoning about which claims it flagged and why, so you can audit false positives and false negatives over time.

Model choice matters here. Self-correction tasks require strong instruction-following and the ability to compare claims against source text. Use a capable model like GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro for the correction pass, even if you use a smaller model for initial generation. The correction prompt should be treated as a system-level instruction that cannot be overridden by user input—place it in the system message or the highest-priority instruction layer. For high-stakes domains like healthcare or legal, always require human sign-off on any answer where the correction pass flagged more than zero unsupported claims, regardless of whether the model claims to have resolved them. Never ship a corrected answer directly to users without running the deterministic citation validation step first.