Citation-to-Evidence Alignment Prompt Template

This prompt is designed for RAG product teams and documentation engineers who face a specific production failure: a model-generated answer includes citations that point to the wrong source chunk, or a cited passage does not actually support the claim it is attached to. The job-to-be-done is not initial answer generation, but post-hoc repair of the alignment between claims and their cited evidence. The ideal user is an engineering lead or ML engineer integrating this prompt into a validation and repair loop within a RAG pipeline, where citation fidelity is a hard requirement for user trust, compliance, or auditability.

Use this prompt when your system has already produced a grounded answer with inline citations, but a downstream validator or human reviewer has flagged mismatches. Required inputs include the original claim-answer text, the full set of cited source chunks, and a mapping of citation markers to their intended chunks. Do not use this prompt for initial answer generation, for fixing malformed JSON citation structures, or for removing entirely hallucinated citations that have no source in the corpus—those are separate repair workflows. This prompt is also not a substitute for a retrieval quality overhaul; if your retriever consistently returns irrelevant chunks, fix retrieval before attempting alignment repair.

The prompt works by instructing the model to act as a strict evidence auditor: for each citation, it must verify that the cited chunk contains the factual content of the claim, realign the citation to the correct chunk if mismatched, and flag any claim that lacks supporting evidence anywhere in the provided corpus. The output is a repaired answer with corrected citation markers and a structured audit log. Before deploying, you must pair this prompt with a validation harness that checks the output against a schema, runs a secondary citation-to-source fidelity eval, and escalates unresolved mismatches for human review. In high-stakes domains like legal, healthcare, or finance, human approval on the final alignment report is mandatory.

This prompt template is designed for RAG pipelines where the model has already produced a response with inline citations, but those citations may point to the wrong source chunk, misrepresent the evidence, or fail to support the claim they accompany. The template takes the original response, the full set of retrieved source chunks, and a set of alignment rules, then produces a corrected response with verified citation-to-evidence mappings and an audit log of changes. Use this when citation accuracy is a hard requirement—such as in legal, medical, financial, or compliance-facing products—and when downstream systems or users depend on traceable, faithful attributions.

textCopy
You are a citation alignment auditor. Your task is to verify that every cited claim in a model-generated response is actually supported by the source chunk it references. You will receive the original response with inline citations, the full set of retrieved source chunks with their IDs, and a set of alignment rules.

## INPUT
- Original Response: [ORIGINAL_RESPONSE]
- Source Chunks: [SOURCE_CHUNKS]
  (Each chunk has an ID, text content, and optional metadata like title, date, or section.)
- Alignment Rules: [ALIGNMENT_RULES]
  (Rules may include: minimum quote overlap threshold, allowed paraphrase distance, required evidence type, or domain-specific constraints.)

## TASK
For every citation marker in the original response:
1. Locate the referenced source chunk by ID.
2. Extract the specific claim that the citation is attached to.
3. Determine whether the source chunk actually contains evidence that supports that claim.
4. Classify the citation as: SUPPORTED, MISALIGNED (points to wrong chunk), WEAK (partial support), or UNSUPPORTED (no evidence found).
5. For MISALIGNED citations, search all available source chunks to find the correct supporting chunk. If found, remap the citation. If not found, mark as UNSUPPORTED.
6. For UNSUPPORTED claims, either remove the citation marker and add an [UNSUPPORTED] flag, or replace the claim with an abstention statement, depending on the [ABSTENTION_POLICY].

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "aligned_response": "The full response text with corrected citation markers and flags.",
  "alignment_report": [
    {
      "citation_id": "original citation marker or reference ID",
      "claim_text": "The exact claim text the citation is attached to",
      "original_source_id": "ID of the originally cited chunk",
      "original_status": "SUPPORTED | MISALIGNED | WEAK | UNSUPPORTED",
      "corrected_source_id": "ID of the correct chunk, or null",
      "corrected_status": "SUPPORTED | WEAK | UNSUPPORTED",
      "explanation": "Brief explanation of the alignment decision"
    }
  ],
  "summary": {
    "total_citations": 0,
    "supported": 0,
    "misaligned_and_fixed": 0,
    "weak": 0,
    "unsupported": 0
  }
}

## CONSTRAINTS
- Do not alter the substantive meaning of any claim unless it is unsupported and the abstention policy requires replacement.
- Do not invent source chunks. Only use chunks provided in [SOURCE_CHUNKS].
- If a claim is supported by a source chunk but the original citation pointed elsewhere, fix the citation ID but preserve the claim text.
- If multiple chunks support the same claim, prefer the one with the most direct evidence (closest textual match).
- For WEAK citations, keep the citation but add a [WEAK EVIDENCE] flag in the aligned response.
- For UNSUPPORTED citations, follow the abstention policy: [ABSTENTION_POLICY] (options: "flag_only", "remove_claim", "replace_with_abstention").
- Preserve all formatting, structure, and non-citation text from the original response.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by defining your abstention policy. In high-stakes domains like healthcare or legal review, prefer replace_with_abstention so users never see unsupported claims presented as fact. In research or exploratory contexts, flag_only may be sufficient. Next, populate the alignment rules with domain-specific constraints—for example, requiring exact quote matches for regulatory filings or allowing paraphrased support for summarization use cases. If your source chunks include metadata like publication dates or authority scores, add those as tiebreakers in the alignment rules. Finally, wire the output into your application by parsing the alignment_report for logging and monitoring, and surface the aligned_response to users only when the summary.unsupported count is below your quality threshold.

This prompt is designed to operate as a post-generation repair step in a RAG pipeline, not as the primary answer-generation prompt. After your system retrieves chunks, generates an answer with citations, and passes initial format validation, this prompt acts as a verification and realignment layer. The typical integration point is between your answer generator and the final output renderer or database write. You will need the original user query, the full generated answer with inline citation markers, and the complete set of retrieved source chunks with their unique identifiers to run this prompt effectively.

Wiring the prompt into an application requires a structured input object. Build a JSON payload with three required fields: query (the original user question), answer_with_citations (the model's full response including citation markers like [1] or [doc_3]), and retrieved_chunks (an array of objects, each with chunk_id, text, and optional metadata like document title or page number). The prompt expects these as [QUERY], [ANSWER_WITH_CITATIONS], and [RETRIEVED_CHUNKS] placeholders. On the output side, parse the model's response into a structured object containing: aligned_answer (the repaired text with corrected citation markers), alignment_report (a per-citation mapping of original marker to verified chunk with a status of aligned, realigned, or removed), and unsupported_claims (an array of claim strings that could not be matched to any retrieved chunk). Validate this output schema before allowing it to proceed downstream—reject any response that does not parse into these three fields and retry with a stricter schema instruction.

Validation and retry logic is critical because this prompt operates on potentially hallucinated citations. Implement a three-pass validation gate. First, check that every citation marker in the aligned_answer has a corresponding entry in the alignment_report with a non-removed status. Second, verify that every realigned citation points to a chunk_id that actually exists in your original retrieved_chunks array—reject outputs that invent new chunk IDs. Third, if unsupported_claims is non-empty, route the output to a human review queue rather than automatically publishing. For retries, use a maximum of two attempts with escalating temperature (0.0 then 0.2) and include the validation failure reason in the retry prompt as [PREVIOUS_FAILURE_REASON]. If both attempts fail validation, log the failure, surface the original answer with a low-confidence flag, and do not silently drop the output.

Model choice and latency considerations matter here. This is a verification task that requires careful reading and comparison, not creative generation. Use a model with strong instruction-following and long-context handling—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Set temperature to 0.0 for deterministic alignment. Expect latency of 2-5 seconds for answers with 10-20 citations and 20-50 retrieved chunks. For high-throughput systems, batch multiple answers into a single request where possible, or run this verification asynchronously after the user-facing response is streamed, updating the citation confidence post-hoc. Tool use is not required for the core alignment task, but you may wire a secondary tool call for fetching missing source metadata if the prompt flags chunks with incomplete provenance.

Logging and observability should capture the full alignment trace. Log the input query, the original answer, the retrieved chunk IDs, the alignment report, and the final aligned answer. This trace is essential for debugging when users report incorrect citations. Track metrics: alignment_success_rate (percentage of citations that pass validation on first attempt), realignment_rate (how often citations are moved to a different chunk), unsupported_claim_rate (how often claims lack any evidence), and human_escalation_rate. These metrics will tell you whether your retrieval quality or your answer-generation prompt needs improvement upstream. If realignment_rate exceeds 20%, your retrieval step is likely returning irrelevant chunks. If unsupported_claim_rate exceeds 10%, your answer generator is fabricating claims beyond the evidence.

What to avoid: Do not use this prompt as a substitute for improving your retrieval or generation prompts. If you find yourself realigning more than a quarter of citations, invest in better chunking strategies, embedding models, or retrieval parameters. Do not skip the human review gate for unsupported_claims in high-stakes domains like healthcare, legal, or finance—an unsupported claim presented as fact is a liability. Finally, do not expose the raw alignment report to end users; use it internally for quality monitoring and present only the cleaned aligned_answer with confidence indicators where appropriate.