Source Attribution and Synthesis Prompt

This prompt is for RAG application builders who need every synthesized claim linked to its origin passage. Use it when you must produce an answer with claim-level attribution, source provenance, and a mapping of which sources contributed which information. The ideal user is an engineer or AI architect who has already built a retrieval pipeline and needs to combine a set of relevant passages into a single, faithful answer where every factual statement is traceable. The core job-to-be-done is transforming a list of retrieved documents into a user-facing response that can survive an audit: if a user or reviewer asks 'where did this come from?', the answer is immediately available in the output structure.

This prompt assumes you have already retrieved a set of relevant passages and filtered out irrelevant or low-quality results. It requires that each source passage has a unique identifier that can be referenced in the output. The prompt works best when the retrieved passages are topically focused on the user's question and contain enough information to construct a complete answer. It is not a retrieval prompt, a query rewriting prompt, or a relevance scoring prompt—those steps must happen upstream before this synthesis step runs.

Do not use this prompt when retrieved passages are not yet filtered for relevance, when sources lack unique identifiers, or when the user question is better answered by refusing due to insufficient evidence. If your retrieval set contains contradictory information that requires resolution before synthesis, use a conflicting evidence resolution prompt first. If you need to verify that the final answer is faithful to the sources, pair this prompt with a synthesis faithfulness verification prompt as a post-generation eval step. For high-risk domains such as healthcare, legal, or financial applications, always include a human review step after synthesis and before the answer reaches the user.

This template is the core instruction set for the Source Attribution and Synthesis Prompt. It forces the model to act as a precise evidence synthesizer, prohibiting the introduction of external knowledge. Every factual claim in the output must be tethered to a specific source passage using inline citation markers. The template is designed to be dropped directly into a system or user message in your AI harness, with square-bracket placeholders you replace at runtime. The structured JSON output contract makes this prompt suitable for programmatic consumption in RAG pipelines, compliance review systems, and any application where hallucination is unacceptable.

Below is the copy-ready prompt template. Replace [USER_QUESTION] with the end user's query and [SOURCE_PASSAGES] with your retrieved context, ensuring each passage has a unique identifier like [S1], [S2]. The output schema is strict JSON, so pair this with a structured output mode (e.g., response_format in OpenAI, or tool-calling with a defined schema) to enforce valid JSON. For high-risk domains, add a [RISK_LEVEL] placeholder and adjust the confidence thresholds or add a human-review flag to the output schema.

textCopy
You are a precise evidence synthesizer. Your task is to answer a user question using only the provided source passages. Every factual claim you make must be attributed to at least one specific source passage using its unique identifier. You must not introduce any information not present in the provided passages.

## USER QUESTION
[USER_QUESTION]

## SOURCE PASSAGES
[SOURCE_PASSAGES]

## OUTPUT REQUIREMENTS
Produce a JSON object with the following structure:
{
  "answer": "A coherent, well-structured answer to the user question. Use inline citation markers like [S1], [S2] immediately after each claim that references a source.",
  "attribution_map": [
    {
      "claim": "A specific factual claim extracted from the answer.",
      "source_ids": ["S1"],
      "evidence_span": "The exact text from the source that supports this claim.",
      "confidence": "high | medium | low"
    }
  ],
  "source_contributions": [
    {
      "source_id": "S1",
      "contributed_claims": ["claim index or description"],
      "relevance": "primary | supporting | contextual"
    }
  ],
  "unattributed_statements": ["Any statement in the answer that could not be attributed to a source, or an empty array if none."],
  "synthesis_notes": "Brief notes on how sources were combined, any conflicts found, and confidence assessment."
}

## RULES
1. Every factual claim in the answer must have a corresponding entry in attribution_map.
2. source_ids must reference the exact identifiers provided in the source passages.
3. evidence_span must be a verbatim quote from the source passage.
4. If multiple sources support the same claim, list all relevant source_ids.
5. If sources conflict, note the conflict in synthesis_notes and present both perspectives in the answer with appropriate attribution.
6. If a source does not contribute any unique information, mark its relevance as "contextual" and explain why in synthesis_notes.
7. Set confidence to "high" when a claim is directly and unambiguously supported, "medium" when support is partial or requires inference, "low" when support is weak or tangential.
8. Do not fabricate source identifiers. Use only the identifiers provided.

To adapt this template for your application, start by hardening the output schema. Replace the illustrative JSON structure with your production schema, adding fields like request_id, model_version, or human_review_required. If your retrieval system uses a different identifier format (e.g., UUIDs, chunk hashes), update the source_ids description and the inline citation format in the answer field instructions. For applications requiring real-time streaming, consider splitting this into two calls: one for the attributed answer and a second for the attribution_map verification, or stream the answer field first and append the metadata afterward. Always validate the output against the schema before surfacing it to users, and log any unattributed_statements as a production metric.

This prompt is designed to operate inside a retrieval-augmented generation (RAG) pipeline where source passages are pre-retrieved and pre-filtered before reaching the model. The implementation harness is responsible for formatting those passages, injecting them into the prompt template, validating the model's attribution claims, and managing failure recovery. The core contract is simple: every claim the model makes must be traceable to a specific source passage, and every attribution the model asserts must be verifiable against the input it received. Without this harness, the prompt produces plausible-looking citations that may not survive audit.

Begin by formatting each retrieved passage with a unique, stable identifier before inserting it into the [CONTEXT] placeholder. Use a consistent pattern such as [source_id: doc_7f3a] prepended to each passage. After receiving the model response, run two validation checks before delivering output to users. First, confirm that every source_id in the attribution_map exists in the input passages—this catches hallucinated source references. Second, for each evidence_span in the attribution map, perform an exact substring match against the referenced source passage text. If either check fails, append the specific validation errors to the original prompt and retry. Set a hard retry limit of 2 attempts. On the third failure, return a fallback response that acknowledges the attribution failure rather than delivering unverified claims. Log every attribution failure with the input passage IDs, the model's claimed source IDs, and the mismatched evidence spans for pipeline improvement.

For production deployments, consider adding a secondary faithfulness verification prompt that runs after attribution validation passes. This prompt should check whether the synthesized answer faithfully represents the source passages without distortion, omission, or overstatement—distinct from the structural attribution checks described above. Model choice matters here: use a model with strong instruction-following for the synthesis step and a separate, potentially smaller model for the verification step to reduce cost and latency. If your application serves regulated or high-risk domains, route all outputs through human review when the faithfulness score falls below a defined threshold. Never ship attributed answers without both structural validation and a plan for semantic verification.