Source Metadata Inclusion Prompt Template

This prompt is for RAG system builders who need generated answers to carry document metadata alongside citations. When a user asks a question over a knowledge base of policy documents, research reports, or regulated records, the answer must not only cite the source but also surface its author, publication date, version, and classification level. The ideal user is an AI engineer or product team operating in compliance, legal, clinical, or enterprise search contexts where every claim must be traceable to a specific document version with full provenance. You need this prompt when downstream systems or human reviewers must audit answers without opening the original documents, or when access-control rules require filtering answers based on document classification labels.

Before using this template, confirm that your retrieval pipeline can supply structured metadata alongside each chunk. The prompt expects fields such as author, publication_date, version, and classification_level to be available in the context window. If your vector database or search index stores only raw text without these fields, the prompt will hallucinate metadata or produce empty fields. Wire this prompt into a RAG harness that enriches retrieved chunks with document-level metadata before assembly. For high-stakes domains, add a post-generation validation step that checks every citation's metadata fields against the original retrieval payload and flags missing or mismatched entries. Use a structured output contract—preferably JSON with a citations array—so your application can parse and display metadata deterministically.

Do not use this prompt for casual Q&A where metadata adds noise, or for systems that cannot supply structured metadata alongside retrieved chunks. Avoid it when your users need fast, conversational answers without audit trails, or when document metadata is unreliable, incomplete, or irrelevant to the question domain. If your retrieval pipeline returns overlapping or redundant chunks, deduplicate and rank them before passing context to this prompt; otherwise, the model may produce citation bloat with repeated metadata. For systems where classification labels drive access control, implement a pre-generation filter that removes chunks above the user's clearance level rather than relying on the model to enforce policy. Start by testing with a small set of annotated documents and a golden dataset of expected citation-metadata pairs before deploying to production.

This template is designed for RAG systems where document metadata—such as author, date, version, and classification level—must travel with every cited source. Instead of treating metadata as optional decoration, the prompt treats it as a required field for any claim that references a retrieved document. Use this when your downstream consumers (auditors, compliance reviewers, or access-control systems) need to verify not just what was said, but who said it, when, and under what classification constraints.

textCopy
You are an answer-generation assistant with access to a set of retrieved source documents. Each source document includes both content and metadata fields. Your job is to produce answers that are fully grounded in the provided sources, with every factual claim linked to a specific source and its associated metadata.

## INPUTS
You will receive:
- [USER_QUESTION]: The user's question.
- [RETRIEVED_DOCUMENTS]: A list of source documents, each containing:
  - `doc_id`: A unique document identifier.
  - `content`: The document text.
  - `metadata`: An object containing at minimum `author`, `date`, `version`, and `classification`. Additional fields such as `department`, `source_type`, or `access_scope` may be present.
- [ACCESS_LEVEL]: The classification level the current user is authorized to view (e.g., `public`, `internal`, `confidential`, `restricted`).

## OUTPUT REQUIREMENTS
Produce a JSON object with the following structure:
```json
{
  "answer": "The synthesized answer text with inline citation markers.",
  "citations": [
    {
      "citation_id": "[1]",
      "doc_id": "source_doc_identifier",
      "metadata": {
        "author": "Author Name",
        "date": "YYYY-MM-DD",
        "version": "1.2",
        "classification": "internal"
      },
      "relevance": "Brief explanation of why this source supports the answer."
    }
  ],
  "metadata_completeness": {
    "all_cited_sources_have_metadata": true,
    "missing_metadata_fields": []
  },
  "access_filter_applied": true,
  "excluded_sources": [
    {
      "doc_id": "excluded_doc_id",
      "reason": "Classification 'restricted' exceeds user access level 'internal'"
    }
  ]
}

RULES

1. Metadata is mandatory. Every citation in the citations array must include the full metadata object from the source document. If a source document is missing any of the required metadata fields (author, date, version, classification), do not cite it. Instead, list it in a metadata_gaps field and explain what is missing.
2. Access-control filtering. Before using any source, compare its classification field against the provided [ACCESS_LEVEL]. Exclude any source whose classification exceeds the user's access level. List all excluded sources with reasons in the excluded_sources array.
3. Citation format. Use bracketed numeric citation markers in the answer text (e.g., [1], [2]). Each marker must correspond to an entry in the citations array.
4. No fabrication. If the retrieved documents do not contain sufficient information to answer the question, set answer to null and populate a cannot_answer_reason field explaining what is missing.
5. Metadata completeness check. After generating the answer, verify that every cited source has all required metadata fields populated. Report the result in metadata_completeness.
6. Uncertainty disclosure. If sources conflict on a factual point, include a conflicts array describing the disagreement, citing both sources with their metadata.

CONSTRAINTS

• Do not invent metadata. Only use metadata fields present in the provided source documents.
• Do not include sources in the answer that were excluded by the access filter.
• If [ACCESS_LEVEL] is not provided, default to internal and note this assumption in the output.
• Maximum verbatim quote length: [MAX_QUOTE_LENGTH] characters per citation.

To adapt this template, replace the square-bracket placeholders with your application's actual values. [USER_QUESTION] and [RETRIEVED_DOCUMENTS] should be populated by your retrieval pipeline before the prompt is assembled. [ACCESS_LEVEL] should come from your authentication layer—never hardcode it or accept it from the user. [MAX_QUOTE_LENGTH] should be set based on your fair-use policy or legal guidance. If your document metadata schema differs from the required fields listed here, update the metadata object description and the completeness check logic accordingly. For production deployments, add a post-generation validation step that confirms every doc_id in the citations array actually exists in the retrieved set and that no excluded sources leaked through.

The Source Metadata Inclusion Prompt Template is designed to sit between your retrieval step and your answer generation step in a RAG pipeline. It expects retrieved chunks that carry structured metadata—fields like author, date, version, classification, and source_id—and it instructs the model to surface that metadata alongside every cited claim. The prompt is not a standalone Q&A system; it is a formatting and attribution layer that depends on upstream retrieval quality and downstream validation. Before wiring it in, confirm that your retrieval index actually stores and returns the metadata fields the prompt references. If your chunks arrive without classification or version, the model will either hallucinate those fields or leave them blank, and neither outcome is acceptable in audit-heavy domains.

Wire the prompt into your application as a post-retrieval, pre-response step. Your application code should: (1) receive the user query, (2) execute retrieval and return a list of chunks with their metadata payloads, (3) assemble the prompt by injecting the retrieved chunks into the [RETRIEVED_CONTEXT] placeholder and the user query into [USER_QUERY], (4) call the model, and (5) validate the response before returning it to the user. Validation must include a metadata completeness check: for every citation in the answer, confirm that the cited source_id exists in the retrieved context and that the metadata fields displayed (author, date, classification) match the original chunk metadata. If a citation references a source not in the retrieval set, flag the answer for human review or trigger a retry. For high-stakes deployments, add an access-control-aware filter in step 5: if the user's clearance level is lower than the classification of a cited source, either redact that citation and its associated claim, or abort the response and escalate. This filter must run in application code, not in the prompt, because prompt-based access control is not reliable enough for compliance boundaries.

Model choice matters here. The prompt requires the model to copy metadata fields verbatim from the context into the answer. Smaller or older models frequently transpose dates, drop version numbers, or confuse author names when they appear across multiple chunks. Use a model with strong instruction-following and copy-precision benchmarks. If you observe metadata transposition errors in production, add a post-generation field-level diff check: extract each cited metadata tuple from the answer, look up the original tuple from the retrieval payload, and flag any mismatch. Log every mismatch with the answer ID, the expected value, and the actual value. These logs become your regression test cases when you change models or prompt versions.

For retry logic, distinguish between two failure modes. If the model fails to include any citations at all, retry with a stricter version of the prompt that adds [CONSTRAINTS] like 'You must cite at least one source per claim. If no source supports a claim, do not make the claim.' If the model includes citations but gets the metadata wrong, do not retry with the same prompt—the error is likely a model capability issue, not a prompt clarity issue. Instead, route the response to a metadata repair prompt that takes the original answer and the correct metadata as input and rewrites only the citation blocks. This is cheaper and more reliable than regenerating the entire answer.

Finally, instrument the pipeline with observability hooks. Log the retrieval set, the assembled prompt, the raw model response, the validation results, and any human-review decisions. In audit-heavy environments, store these as an answer provenance record that links the user query to the exact chunks, metadata, and model output. This record is what your compliance team will ask for when a cited source turns out to be outdated or misclassified. The prompt is only one link in that chain—the harness around it is what makes the system auditable.