This prompt is designed for AI architects and engineers building auditable Q&A systems on top of Retrieval-Augmented Generation (RAG). Its core job is to force the model to construct an explicit, step-by-step reasoning chain that links specific retrieved passages to intermediate conclusions before producing a final answer. The ideal user is someone who needs a traceable, debuggable reasoning path—not just a correct answer—to satisfy internal QA, compliance, or user-trust requirements. You should use this prompt when the cost of an incorrect or unverifiable answer is high, such as in legal research, clinical decision support, or financial analysis, and when you need to programmatically verify that every inferential hop is grounded in a source.

To use this prompt effectively, you must provide a set of pre-retrieved document chunks as [CONTEXT]. The prompt is not a retrieval planner; it assumes the evidence is already gathered and deduplicated. It works best when the question requires synthesizing information from multiple documents or when the answer depends on a logical chain rather than a single extracted fact. Do not use this prompt for simple factoid lookups where a single passage contains the answer, as the overhead of constructing a chain adds latency and token cost without proportional value. Similarly, avoid it in low-latency, high-throughput chat systems where a verbose reasoning trace would degrade the user experience.

The primary output is a structured reasoning chain—a sequence of claims, each explicitly citing a source passage—followed by a final answer. This output is designed to be machine-parsed for downstream evaluation. Before deploying, you must pair this prompt with an evaluation harness that checks for chain completeness, source fidelity, and logical validity. A common failure mode is the model fabricating a plausible-sounding logical connection that is not actually stated in the provided context. Your eval must catch this. Proceed by integrating this prompt into a pipeline where the output is logged, audited, and potentially reviewed by a human before being surfaced in high-risk applications.

This template is the core instruction set for an LLM to act as an auditable reasoning engine. It forces the model to externalize its reasoning by building a chain where each step is a discrete conclusion explicitly grounded in one or more source passages. The primary goal is traceability: a human or an automated evaluator must be able to follow the path from the question, through the evidence, to the final answer without guessing which source supports which claim. Use this template when the cost of an incorrect or unverifiable answer is high, such as in compliance, legal research, or clinical decision support.

codeCopy
You are an expert reasoning engine. Your task is to answer a complex question by constructing an explicit, step-by-step evidence chain from the provided context.

# INPUT
Question: [QUESTION]
Retrieved Context:
---
[RETRIEVED_CONTEXT]
---

# INSTRUCTIONS
1. **Analyze the Question:** Identify the core entities, events, and relationships required to answer the question.
2. **Construct the Evidence Chain:** Build a numbered list of reasoning steps. Each step must be a single, logical inference.
3. **Ground Every Step:** For each step, you MUST cite the specific source passage(s) from the context that support it using the format `[Source: <source_id>]`. If a step combines multiple sources, cite all of them.
4. **Identify Gaps:** If the context is insufficient to complete a necessary step, explicitly state the gap as a step: "GAP: Information about [missing fact] is not present in the provided context."
5. **Synthesize Final Answer:** After the chain, provide a concise final answer that directly addresses the question. The answer must be fully supported by the preceding evidence chain.

# OUTPUT FORMAT
```json
{
  "question": "[restate the original question]",
  "evidence_chain": [
    {
      "step_number": 1,
      "inference": "[a single logical conclusion drawn from the context]",
      "source_ids": ["source_1", "source_2"]
    },
    {
      "step_number": 2,
      "inference": "GAP: [description of missing information]",
      "source_ids": []
    }
  ],
  "final_answer": "[concise answer grounded in the chain]",
  "confidence": "high|medium|low",
  "uncertainty_notes": "[optional explanation if confidence is not high]"
}

CONSTRAINTS

• Do not include any information in the final answer that is not justified by a step in the evidence chain.
• If a gap prevents a high-confidence answer, set confidence to 'low' or 'medium' and explain why in uncertainty_notes.
• Never fabricate source IDs. Only use IDs exactly as they appear in the provided context.

To adapt this template, start by replacing the [RETRIEVED_CONTEXT] placeholder with your actual retrieval results. Ensure each passage has a unique, stable source_id that survives across your pipeline. The [QUESTION] placeholder should receive the user's original, unmodified query. The JSON output schema is designed for programmatic consumption; you can validate it in your application layer before showing the answer to a user. For high-risk domains, add a [RISK_LEVEL] placeholder and a corresponding instruction to escalate to human review if confidence is 'low' or if more than a specified number of gaps are detected. The [CONSTRAINTS] section is your primary lever for policy: you can add rules like 'Do not speculate about medical diagnoses' or 'Limit final answer to 100 words' without altering the core reasoning structure.

The Evidence Chain Construction Prompt is not a standalone endpoint—it is a reasoning engine that sits between retrieval and the final answer. In a production harness, this prompt should receive a pre-assembled context block containing all retrieved passages relevant to the user's question, along with any previously established intermediate facts. The application layer is responsible for calling retrieval, deduplicating and ranking passages, and injecting them into the [RETRIEVED_CONTEXT] placeholder. Do not rely on the model to decide which documents to use; that selection should happen in the retrieval pipeline before this prompt is invoked.

Wire this prompt into a multi-step workflow: (1) retrieve candidate passages, (2) rank and filter to a manageable context window, (3) invoke the evidence chain prompt to produce a structured reasoning trace, (4) validate the output against a schema that requires each reasoning step to include a source_id matching a passage in the input, and (5) pass the validated chain to a final synthesis prompt or directly to the user if the chain itself is the desired output. For high-stakes domains, insert a human review step between steps 4 and 5 when the model's confidence markers or the validator's source-coverage score fall below a defined threshold. Log every invocation with the prompt version, retrieved passage IDs, generated chain, and validation result for auditability.

Validation is the critical harness component. Implement a post-generation check that parses the JSON output and verifies: every evidence object references a source_id present in the input passages, no step contains claims absent from its cited source, and the final conclusion is reachable by following the chain. Use a secondary LLM call with a dedicated faithfulness evaluation prompt for automated checks, but keep a deterministic structural validator as a fast first pass. Set a retry budget of 2 attempts with escalating temperature (0.0 then 0.2) if validation fails. If the chain still fails after retries, fall back to a simpler direct-answer prompt and flag the interaction for review. Avoid wiring this prompt into synchronous user-facing flows without a timeout and a degraded-mode fallback—multi-hop reasoning can be slow.