Evidence Synthesis for Decision Support Prompt

This prompt is designed for decision-support system builders who need to convert multiple retrieved evidence passages into a structured decision brief. The output is not a single answer but a balanced presentation of options, each supported by specific evidence, with explicit trade-offs and confidence levels. Use this when your users face consequential choices and need to see the evidence landscape rather than a single recommendation. This prompt belongs in the synthesis layer of a RAG pipeline, after retrieval and relevance filtering, and before human review in high-stakes domains. It assumes you have already retrieved and ranked relevant passages.

The ideal user is a product engineer or AI architect building a system where the cost of a wrong answer is high: clinical decision support, legal research, investment analysis, policy evaluation, or vendor selection. The prompt works best when you have 3–15 evidence passages that vary in strength, recency, or perspective. It requires that each passage has a source identifier and that you can pass a risk level parameter to control how aggressively the model should express uncertainty. The prompt explicitly instructs the model to avoid false consensus, to flag when evidence is thin, and to separate factual claims from interpretive judgments.

Do not use this prompt when the decision is trivial, when only one option exists, or when the evidence is unanimous and uncontested. In those cases, a standard RAG answer generation prompt with citations is faster and simpler. Also avoid this prompt when latency is critical and you cannot afford the extra tokens required for multi-option synthesis. If your retrieval pipeline cannot provide source-level metadata or passage IDs, the prompt's attribution and confidence-calibration instructions will produce unreliable output. For regulated domains, always route the output through human review before it reaches the end user, and log the full prompt, retrieved passages, and generated brief for audit. Wire this prompt behind a validation step that checks for the presence of at least two options, evidence citations per option, and an explicit uncertainty section before the output is surfaced.

This template is designed for decision-support systems that must transform multiple evidence passages into an actionable recommendation. It forces the model to present options, map evidence to each option, surface trade-offs explicitly, and communicate uncertainty rather than hiding it. The template uses square-bracket placeholders that your application must populate before sending the request. Every placeholder maps to a specific input source: retrieved passages, user context, risk tolerance, and output schema requirements.

textCopy
You are a decision-support analyst synthesizing evidence into an actionable brief.

## INPUT

**Decision Question:** [DECISION_QUESTION]

**Evidence Passages:**
[EVIDENCE_PASSAGES]

**Decision Context:** [DECISION_CONTEXT]

**Risk Tolerance:** [RISK_TOLERANCE]

**Constraints:** [CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "decision_brief": {
    "question": "string (restate the decision question)",
    "options": [
      {
        "option_label": "string (Option A, Option B, etc.)",
        "option_name": "string (descriptive name)",
        "description": "string (what this option entails)",
        "supporting_evidence": [
          {
            "source_id": "string (reference to evidence passage)",
            "evidence_summary": "string (what the evidence says)",
            "strength": "strong | moderate | weak",
            "relevance_rationale": "string (why this evidence matters for this option)"
          }
        ],
        "counter_evidence": [
          {
            "source_id": "string",
            "evidence_summary": "string",
            "strength": "strong | moderate | weak",
            "relevance_rationale": "string"
          }
        ],
        "trade_offs": [
          {
            "trade_off_type": "string (e.g., cost, time, risk, quality)",
            "description": "string (what is gained and what is sacrificed)",
            "severity": "high | medium | low"
          }
        ],
        "confidence_level": "high | moderate | low",
        "confidence_rationale": "string (what drives confidence up or down)"
      }
    ],
    "recommendation": {
      "selected_option": "string (option_label)",
      "rationale": "string (why this option is recommended given the evidence and context)",
      "key_risks": ["string"],
      "mitigations": ["string"],
      "decision_triggers": ["string (conditions that would change the recommendation)"]
    },
    "uncertainty_summary": {
      "evidence_gaps": ["string (what evidence is missing)"],
      "assumptions": ["string (assumptions made in the analysis)"],
      "sensitivity_points": ["string (factors that could swing the decision)"]
    }
  }
}

## RULES

1. Every option must cite at least one evidence passage as supporting evidence.
2. If evidence contradicts an option, include it under counter_evidence. Do not suppress contradictory evidence.
3. If evidence is insufficient to distinguish between options, state this explicitly in confidence_rationale and uncertainty_summary.
4. Do not fabricate evidence. If a claim cannot be traced to a provided passage, do not include it.
5. For high-risk decisions where evidence is weak or conflicting, set confidence_level to "low" and flag the need for human review.
6. Trade-offs must be concrete and tied to evidence, not generic.
7. If [RISK_TOLERANCE] is "low," prioritize options with stronger evidence and fewer assumptions.
8. If [CONSTRAINTS] include hard limits (budget, timeline, regulatory), filter or flag options that violate them.

To adapt this template for your system, replace each placeholder with data from your retrieval pipeline and application context. [EVIDENCE_PASSAGES] should include source identifiers that your system can trace back to original documents for audit. [DECISION_CONTEXT] should capture user role, domain, and any prior decisions. [RISK_TOLERANCE] should be a structured value your application derives from the use case, not free text. After generating the output, validate the JSON schema, verify that every supporting_evidence entry maps to a real passage, and run a faithfulness check comparing claims in the brief against the source passages. For high-stakes domains, route outputs with confidence_level "low" or evidence_gaps to a human reviewer before presenting them to the decision-maker.

This prompt is designed to be the final synthesis step in a retrieval-augmented generation (RAG) pipeline, not a standalone chat interaction. The application layer is responsible for assembling the [EVIDENCE_PASSAGES], [DECISION_QUESTION], [DECISION_CRITERIA], and [STAKEHOLDER_CONTEXT] before the prompt is rendered. The model should never see raw, unranked search results. Upstream retrieval must produce a deduplicated, relevance-filtered, and source-authority-scored set of passages. If your pipeline includes a separate evidence ranking or conflict detection step, pass those annotations into the [EVIDENCE_PASSAGES] structure so the synthesis prompt can reason about source agreement, contradiction, and confidence without rediscovering those signals.

Wire the prompt into a structured output API call with a defined JSON schema. The [OUTPUT_SCHEMA] placeholder should be replaced with a concrete schema that includes fields for options (array of decision alternatives), supporting_evidence (per-option evidence mapping with source IDs and excerpt spans), trade_offs (per-option risks, costs, and uncertainties), confidence_level (per-option categorical or numeric confidence), and unresolved_gaps (questions the evidence cannot answer). Validate the response against this schema immediately after generation. If validation fails, retry once with the validation error message appended to the prompt as a correction instruction. If the second attempt also fails, log the failure, surface the partial output with an incomplete flag, and escalate for human review. For high-stakes domains such as clinical, legal, or financial decision support, always route outputs through a human approval queue before any downstream action is taken.

Model choice matters for this workflow. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that are prone to flattening nuance, fabricating consensus, or dropping evidence-source links. Set the temperature low (0.0–0.2) to reduce variability in confidence expressions and evidence attribution. Log every prompt instance, the retrieved passage set, the raw model response, the validation result, and the final approved output. This trace is essential for debugging hallucination, bias drift, or evidence-weighting failures. If your application surfaces these decision briefs to end users, include a visible link to the source passages and a clear indication of the confidence level so users can calibrate their trust appropriately.