Source Provenance Chain Prompt for RAG Systems

This prompt is designed for audit and compliance engineers who must demonstrate to internal reviewers, regulators, or downstream systems that a generated answer is fully grounded. It is not a general question-answering prompt. It assumes you already have a working RAG pipeline that produces answers with citations. The job-to-be-done is post-generation verification: taking the answer, its citations, and the retrieval results, then constructing a backward trace that links each claim through the retrieval step, the specific chunk selected, and the original document metadata. The output is a structured provenance chain artifact suitable for logging, audit review, or automated compliance checks.

Use this prompt when the cost of an unsupported claim is high—regulatory filings, legal document review, financial audit summaries, or clinical documentation. It is appropriate when you need to prove that every material statement in an answer can be mapped to a known source, and when you need to flag any broken links where a citation cannot be matched to a retrieval result. Do not use this prompt for real-time chat where latency matters more than auditability, or for creative generation tasks where factual grounding is not required. It is also not a substitute for a properly instrumented RAG pipeline; if your retrieval system does not preserve chunk IDs, document metadata, and retrieval scores, this prompt cannot reconstruct what was lost.

Before invoking this prompt, ensure your pipeline captures the full retrieval context: the original query, the list of retrieved chunks with their document IDs and metadata, the final answer, and the citations the model produced. The prompt will cross-reference these artifacts and flag gaps. After generation, validate the output against a schema that enforces the provenance chain structure. For high-risk domains, route outputs with broken provenance links to human review rather than silently accepting them. The next section provides the copy-ready prompt template you can adapt to your specific document schema and citation format.

The following prompt template is designed to be injected into your model's context window after retrieval and before answer generation. It forces the model to construct an explicit provenance chain for every claim, linking the final answer back through the specific chunk, retrieval query, and source document. This is not a conversational prompt—it is a structured audit artifact generator. Use it when you need a verifiable trail for compliance review, debugging retrieval failures, or proving to a regulator that no information was hallucinated. Do not use this prompt for latency-sensitive user-facing chat where a full chain would overwhelm the response.

textCopy
You are an audit-grade provenance tracer. Your only job is to produce a structured provenance chain for every factual claim you would make in response to the user's question.

## INPUTS
- USER_QUESTION: [USER_QUESTION]
- RETRIEVED_CHUNKS: [RETRIEVED_CHUNKS]
- CHUNK_METADATA: [CHUNK_METADATA]
- RETRIEVAL_QUERIES_USED: [RETRIEVAL_QUERIES_USED]
- SOURCE_DOCUMENT_IDS: [SOURCE_DOCUMENT_IDS]

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "provenance_chain": [
    {
      "claim_id": "string (unique identifier for this claim)",
      "claim_text": "string (the exact factual statement)",
      "supporting_chunk_id": "string (ID from CHUNK_METADATA)",
      "supporting_chunk_text": "string (the exact text from RETRIEVED_CHUNKS)",
      "retrieval_query_used": "string (which query retrieved this chunk)",
      "source_document_id": "string (from SOURCE_DOCUMENT_IDS)",
      "confidence": "high|medium|low",
      "chain_completeness": "complete|broken_missing_chunk|broken_missing_query|broken_missing_document"
    }
  ],
  "unanswerable_claims": [
    {
      "claim_text": "string (claim that cannot be sourced)",
      "reason": "no_evidence_found|contradictory_evidence|insufficient_context"
    }
  ],
  "completeness_check": {
    "total_claims": "number",
    "sourced_claims": "number",
    "broken_links": "number",
    "overall_chain_health": "healthy|partial|broken"
  }
}

## CONSTRAINTS
1. Every claim in the answer MUST appear in the provenance_chain array.
2. If a claim cannot be linked to a specific chunk, query, and document, place it in unanswerable_claims.
3. Do not invent chunk IDs, document IDs, or query strings. Use only values provided in the INPUTS.
4. If a chunk was retrieved by multiple queries, list the most specific query.
5. Mark chain_completeness as "broken_missing_chunk" if the chunk ID is absent, "broken_missing_query" if the retrieval query is absent, and "broken_missing_document" if the source document ID is absent.
6. Set confidence to "low" if the chunk text only partially supports the claim.

## RISK LEVEL: [RISK_LEVEL]
- If RISK_LEVEL is "high", you MUST NOT output any claim with broken links. Place all broken-link claims in unanswerable_claims.
- If RISK_LEVEL is "medium", you may output claims with "low" confidence but must flag them.
- If RISK_LEVEL is "low", you may output all claims but must still populate the completeness_check accurately.

To adapt this template, wire your RAG pipeline's retrieval logs into the placeholders. [RETRIEVED_CHUNKS] should contain the raw text of every chunk passed to the model. [CHUNK_METADATA] must include unique chunk IDs, parent document IDs, and the retrieval query that fetched each chunk. If your retriever does not natively track which query produced which chunk, add that mapping in your orchestration layer before populating [CHUNK_METADATA]. The [RISK_LEVEL] placeholder should be set based on the downstream use case: "high" for regulatory filings and audit responses, "medium" for internal compliance checks, and "low" for exploratory research where broken links are acceptable but must be logged. After the model returns the JSON, validate it against the schema before allowing any downstream system to consume the provenance chain. A single missing claim_id or invented document_id is a compliance failure, not a formatting error.

The Source Provenance Chain prompt is not a standalone Q&A prompt—it is a post-retrieval audit layer that sits between your retrieval system and your final answer generation. In a production harness, you call this prompt after retrieval returns candidate chunks but before you generate the user-facing answer. The prompt receives the original query, the retrieved chunks with their metadata (document ID, chunk index, retrieval score, and source path), and any intermediate query rewrites or filter decisions. Its job is to produce a structured provenance chain that traces every piece of evidence from origin document through retrieval step to final chunk selection. This chain becomes the audit artifact you store alongside the generated answer, enabling downstream compliance review, debugging of retrieval failures, and user-facing citation display.

Wire this prompt into your RAG pipeline as a dedicated provenance step with strict input validation. Before calling the model, validate that every chunk in [RETRIEVED_CHUNKS] carries required metadata fields: doc_id, chunk_index, retrieval_method (e.g., vector, keyword, hybrid), retrieval_score, and source_path. If any chunk is missing these fields, reject the batch and log a schema violation before the model ever sees it. On the output side, parse the model's JSON response and validate that every claim in the provenance chain references a chunk that actually exists in the input set—this catches hallucinated chunk references. If the model produces a provenance link to a chunk ID not present in the input, flag the entire chain for human review and do not attach it to the user-facing answer. For high-compliance domains, implement a dual-write pattern: store both the raw model output and the validated provenance chain so auditors can inspect any validation corrections.

Model choice matters here. This prompt requires strong instruction-following and structured JSON output, so prefer models with proven schema adherence (GPT-4o, Claude 3.5 Sonnet, or fine-tuned variants). Avoid smaller models that tend to drop required fields or hallucinate chunk references under complex provenance constraints. Set temperature=0 to maximize deterministic output, and configure your harness to retry once with the same input if the initial response fails JSON schema validation. If the retry also fails, escalate to a human reviewer with the raw retrieval context and the failed outputs rather than silently dropping the provenance step. Log every provenance chain with a unique chain_id, the model version, retrieval parameters, and validation status for audit readiness. Finally, implement a completeness gate: before any answer reaches the user, confirm that a validated provenance chain exists and that its completeness_check field shows no broken links. If the chain is incomplete, suppress the answer and return a fallback indicating that provenance could not be verified.