Source-Aware Output Contract Prompt (JSON with Citations)

This prompt is for engineering teams building citation-enabled APIs that must return structured JSON with auditable source references. Use it when every factual claim in the output must be traceable to a specific source passage, and when downstream systems consume the response as a typed object rather than free text. This prompt belongs in production RAG pipelines, document intelligence APIs, compliance review systems, and any workflow where an unsupported claim is a product defect.

The ideal user is a developer or AI engineer who has already solved retrieval and now needs the model to synthesize multiple source passages into a single, structured answer. The required context includes retrieved documents with stable identifiers, a defined JSON schema for the output, and clear rules for when to cite, abstain, or express uncertainty. This prompt assumes you are not asking the model to perform retrieval, judge source authority from scratch, or decide the output schema on the fly.

Do not use this prompt for conversational chat, creative writing, or tasks where source grounding is optional. It is a poor fit for low-latency, single-turn Q&A where a plain text answer with markdown links is acceptable. Avoid it when the cost of generating and validating structured JSON outweighs the benefit of downstream machine readability. If your application only needs a human-readable answer with occasional references, a simpler RAG citation prompt without a strict output contract will be cheaper, faster, and easier to debug.

This template is designed for placement in the system message of a chat completion request. It instructs the model to produce a structured JSON response where every factual claim is backed by a citation to a provided source passage. The user message should contain the query and the retrieved source passages formatted as specified in the [CONTEXT] placeholder. Before integrating this into your application, replace all square-bracket placeholders with runtime values and ensure your output validation layer can parse and enforce the schema described in [OUTPUT_SCHEMA].

codeCopy
SYSTEM
You are an evidence-grounded assistant operating under a strict output contract. Your response must be a single valid JSON object conforming to the schema below. You are forbidden from generating any factual claim that is not directly supported by a source passage provided in the user message. If the provided context is insufficient to answer the query fully or partially, you must indicate this in the output rather than fabricate information.

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## CITATION RULES
- Every claim in the `answer` field must have a corresponding entry in the `citations` array.
- Each citation object must include the `source_id` of the passage, the `quote` text used, and a `relevance` explanation.
- If a claim synthesizes information from multiple sources, list all relevant source_ids in the `source_ids` array for that claim.
- Do not cite sources that do not directly support the claim.
- If no source supports a claim, do not make the claim. Instead, use the `gaps` field to note missing evidence.

## CONSTRAINTS
[CONSTRAINTS]

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

USER
Query: [QUERY]

Source Passages:
[CONTEXT]

Adapt this template by first defining your [OUTPUT_SCHEMA] as a concrete JSON Schema or a detailed field-by-field description. For high-risk domains such as healthcare or finance, set [RISK_LEVEL] to high and ensure your application layer enforces human review for any response where the gaps array is non-empty or where citation confidence falls below a defined threshold. The [CONSTRAINTS] placeholder should include domain-specific rules, such as prohibited topics, tone requirements, or length limits. The [EXAMPLES] placeholder is critical for model performance; provide at least two few-shot examples that demonstrate the exact JSON structure, including edge cases like insufficient context and multi-source claims. After the model responds, always validate the JSON structure against your schema, verify that every source_id in the citations matches a provided passage, and log any validation failures for prompt refinement.

This prompt is designed to be called from an application layer that manages retrieval, prompt assembly, and output validation. The model is not responsible for fetching sources; it receives a pre-assembled context block containing retrieved passages with unique identifiers. The application must construct the [CONTEXT] variable by mapping each retrieved chunk to a stable ID (e.g., chunk_id from your vector store or document index) and including enough metadata for the model to produce accurate citations. A typical assembly flow: (1) run retrieval, (2) deduplicate and rank passages, (3) assign each passage a short reference ID, (4) inject the passages into the [CONTEXT] placeholder, (5) inject the user query into [QUERY], (6) inject the JSON schema into [OUTPUT_SCHEMA], and (7) send the assembled prompt to the model.

After receiving the model response, validate the JSON structure before surfacing it to users or downstream systems. At minimum, confirm that: the top-level object parses without error; the claims array is present and non-empty; each claim object contains claim_text, citation_ids, and confidence fields; every citation_id in the claims array resolves to an entry in the citations array; and each citation contains a source_id that matches a passage ID you provided in the context. If validation fails, do not show the raw output. Instead, log the failure with the prompt version, model, and raw response, then either retry with a repair prompt or escalate for human review depending on the [RISK_LEVEL] configuration. For high-risk domains, always require human approval before any output is shown to end users.

Implement a retry strategy that distinguishes between format failures and content failures. A format failure (invalid JSON, missing required fields) can be retried up to two times with a repair prompt that includes the original instructions, the malformed output, and a specific error message. A content failure (citation ID not found in context, confidence below threshold) should trigger a different path: log the issue, optionally re-retrieve with expanded queries, and regenerate. Never retry more than three times total; after that, surface a controlled fallback message. Log every attempt with a correlation ID, the model used, token counts, latency, and validation results. This trace data is essential for debugging citation drift, hallucination patterns, and retrieval gaps over time.

Model choice matters for this prompt. Use a model with strong JSON mode or structured output support (e.g., GPT-4o with response_format set to json_schema, or Claude 3.5 Sonnet with tool-use mode forcing a typed output). Avoid models that frequently drop closing braces or hallucinate field names under long context. If you must use a weaker model, add a post-processing step that attempts to repair truncated JSON before validation. For latency-sensitive applications, consider streaming the response into a buffer and validating only after the full JSON is received. Do not stream partial claims to users; citation integrity requires the complete object.

Finally, build an eval harness that runs offline against a golden dataset of queries, retrieved contexts, and expected citation mappings. Measure citation precision (do cited sources actually support the claim?), citation recall (are all supported claims cited?), and hallucination rate (claims with no valid citation). Run these evals on every prompt change before deployment. In production, sample a percentage of outputs for human review, especially for [RISK_LEVEL] high configurations. The goal is not just a working prompt but a verifiable pipeline where every claim can be traced back to evidence.