Causal Chain Reconstruction Prompt from Retrieved Context

This prompt is designed for investigative RAG systems that must reconstruct a causal chain of events from fragmented evidence across multiple documents. It is built for root cause analysis, incident postmortems, fraud investigation, and any workflow where understanding why something happened is more important than retrieving a single fact. The prompt instructs the model to distinguish correlation from causation, assign confidence levels to each causal link, and produce a directed causal graph or narrative with explicit source grounding. Use this when your system needs to answer questions like 'What sequence of failures led to the outage?' or 'What chain of events caused the supply chain disruption?' rather than simple factoid questions. This prompt assumes you have already retrieved a set of potentially relevant documents and need the model to synthesize a causal structure from them.

The ideal user is an AI engineer or product team building a system where the cost of a wrong causal attribution is high. This includes site reliability engineers conducting postmortems, fraud analysts reconstructing transaction sequences, or supply chain operators diagnosing disruption root causes. The prompt requires a specific set of inputs: a clear causal question, a set of retrieved documents that contain timestamped events or causal statements, and a defined output schema for the causal graph. Without timestamped or causally-linked evidence in the retrieved context, the model will be forced to speculate, which defeats the purpose. You must also provide explicit constraints that prevent the model from inventing causal links not present in the source material.

Do not use this prompt for simple fact retrieval, summarization, or single-hop Q&A. If the user's question can be answered by extracting a single span of text, a standard RAG answer prompt is more appropriate and less expensive. Avoid this prompt when the retrieved documents lack temporal information or explicit causal language; the model will produce a plausible-sounding but unsupported narrative. In high-risk domains like healthcare or legal investigation, the output of this prompt is a starting point for human analysis, not a final conclusion. Always pair this prompt with a validation harness that checks whether each causal link in the output is directly supported by at least one cited source passage. The next section provides the copy-ready template you can adapt for your own retrieval pipeline.

This prompt template is designed for root cause analysis and investigative RAG workflows where you need to assemble a coherent causal narrative from evidence scattered across multiple documents. It forces the model to distinguish between correlation and causation, assign confidence levels to each link in the chain, and produce a structured output suitable for downstream processing or human review. Replace each square-bracket placeholder with your specific inputs before sending to the model. The template is model-agnostic but assumes you have already retrieved relevant context chunks and assembled them into the [RETRIEVED_CONTEXT] variable.

textCopy
You are an investigative analyst reconstructing causal chains from retrieved evidence. Your task is to identify a sequence of events where each event causally contributes to the next, producing a directed causal graph or narrative. You must distinguish correlation from causation and assign confidence levels based on evidence strength.

## INPUTS

### Retrieved Context

[RETRIEVED_CONTEXT]

codeCopy

### Investigation Question
[INVESTIGATION_QUESTION]

### Output Schema
You must produce valid JSON matching this schema:
```json
{
  "causal_chain": [
    {
      "step_id": "string (e.g., 'C1', 'C2')",
      "event_description": "string (concise description of what occurred)",
      "timestamp": "string or null (when this event occurred, if known)",
      "source_passages": ["string (exact quote or passage ID from context)"],
      "causal_relationship_to_next": {
        "mechanism": "string (how this event caused the next: 'direct cause', 'contributing factor', 'necessary precondition', 'triggering event')",
        "confidence": "high | medium | low",
        "evidence_summary": "string (brief justification for the causal link)"
      },
      "is_root_cause": false
    }
  ],
  "correlations_without_causation": [
    {
      "event_a": "string",
      "event_b": "string",
      "observed_correlation": "string",
      "why_not_causal": "string (evidence or reasoning for rejecting causation)",
      "source_passages": ["string"]
    }
  ],
  "alternative_chains": [
    {
      "description": "string (alternative causal explanation)",
      "supporting_evidence": ["string"],
      "confidence": "high | medium | low"
    }
  ],
  "evidence_gaps": [
    {
      "gap_description": "string (what missing evidence would strengthen or refute the chain)",
      "suggested_retrieval_query": "string (query to find the missing evidence)"
    }
  ],
  "overall_confidence": "high | medium | low",
  "narrative_summary": "string (a prose summary of the most likely causal chain, with confidence caveats)"
}

CONSTRAINTS

[CONSTRAINTS]

EXAMPLES

[EXAMPLES]

INSTRUCTIONS

1. Read all retrieved context carefully. Identify events that appear causally related to the investigation question.
2. For each causal link, explicitly state the mechanism (direct cause, contributing factor, necessary precondition, triggering event). Do not assert causation without clear evidence.
3. Flag correlations that might appear causal but lack supporting evidence. Explain why causation is rejected.
4. If the evidence supports multiple possible causal chains, include the most plausible alternatives with their supporting evidence.
5. Identify specific evidence gaps that prevent higher confidence. Suggest retrieval queries to fill those gaps.
6. Assign confidence levels honestly. Use 'low' when evidence is circumstantial or sparse. Use 'high' only when multiple sources converge on the same causal mechanism.
7. Every event and causal claim must cite specific source passages from the retrieved context.
8. If the retrieved context contains no usable causal evidence, return an empty causal_chain array and explain the insufficiency in the narrative_summary.

RISK LEVEL

[RISK_LEVEL]

If RISK_LEVEL is 'high', you must additionally flag any causal claims that could have significant consequences if incorrect, and recommend human review before action.

To adapt this template for your specific use case, start by populating [RETRIEVED_CONTEXT] with the document chunks your retrieval pipeline returns. The context should be pre-filtered for relevance to the investigation question. The [CONSTRAINTS] placeholder lets you add domain-specific rules—for example, in a manufacturing context you might require that every causal link references a specific sensor reading or log entry. The [EXAMPLES] placeholder is critical for few-shot performance: provide one or two worked examples showing a well-constructed causal chain with proper confidence assignments and correlation-vs-causation distinctions. For the [RISK_LEVEL] field, set it to 'high' when the causal analysis will inform decisions with safety, financial, or legal consequences; this activates additional cautionary output requirements. After generating the output, validate the JSON structure programmatically and verify that every source_passage reference exists in your original retrieved context to catch hallucinated citations.

Integrating the Causal Chain Reconstruction prompt into an application requires treating it as a multi-step pipeline rather than a single model call. The core workflow begins with a user query (e.g., 'What caused the outage on March 12?') and a retrieval step that fetches relevant documents from your knowledge base. These documents are injected into the [CONTEXT] placeholder. The prompt then produces a structured output—ideally a JSON object containing a list of events, their causal relationships, and confidence scores. This output must be parsed and validated before it reaches a user or triggers any downstream action. The harness should enforce a strict schema on the model's response, using a library like Pydantic or Zod to validate the presence of required fields (events, causal_links, confidence_scores) and their data types immediately after the model returns.

A robust implementation must include a validation and retry layer. After parsing the initial JSON, run a set of automated checks: confirm that every causal_link references valid event_ids present in the output, verify that no event has a confidence score below a configurable threshold (e.g., 0.6), and check that the graph is acyclic to prevent circular logic. If validation fails, construct a retry prompt that feeds the original context and the specific validation errors back to the model, instructing it to correct the structure. Limit retries to a maximum of two attempts to control latency and cost. For high-stakes domains like incident postmortems or financial audits, always route the final validated output to a human review queue. The reviewer should see the original source documents alongside the reconstructed causal graph to quickly verify the model's reasoning. Log every attempt, including the raw model output, validation errors, and retry count, to enable prompt debugging and performance analysis over time.

Model choice significantly impacts this prompt's reliability. Use a model with strong reasoning capabilities and a large context window, as the prompt requires synthesizing information from potentially dozens of retrieved chunks. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are suitable starting points. For cost-sensitive or high-volume applications, consider a two-tier routing strategy: use a faster, cheaper model for an initial draft and a more powerful model for validation and refinement of low-confidence outputs. Avoid using this prompt in real-time chat without a loading state, as the chain-of-thought reasoning can introduce several seconds of latency. Finally, never feed raw, unsanitized documents directly into the context window. Pre-process retrieved chunks to remove irrelevant metadata, truncate to a maximum token limit per source, and deduplicate near-identical passages to ensure the model focuses on the most salient evidence for causal inference.