Evidence Gap Identification and Synthesis Prompt

This prompt is for RAG system designers and AI engineers who need their application to detect when retrieved passages are insufficient to fully answer a user's question. The core job-to-be-done is producing a structured, machine-readable output that separates what the evidence covers from what remains unanswered, enabling the application to decide whether to request more context, escalate to a human, or deliver a qualified partial answer. The ideal user is building a production system where confident wrong answers are more damaging than honest refusal, such as in clinical decision support, legal research, financial analysis, or technical documentation assistants.

Use this prompt when your retrieval pipeline may return incomplete, tangentially relevant, or partially covering passages and you need the model to explicitly flag gaps rather than silently filling them with parametric knowledge. It is designed for workflows where the output must be parsed by downstream code—a confidence score, a list of covered topics, a list of unanswered questions, and a refusal trigger. Do not use this prompt for simple factoid QA where a single passage is expected to contain the full answer, or for creative generation tasks where factual grounding is not the primary concern. It is also not a replacement for retrieval quality improvements; if your retriever consistently fails to surface relevant documents, fix retrieval before adding gap detection.

The prompt requires several structured inputs: the user's original question, the set of retrieved passages with source identifiers, and optionally a risk level that adjusts the refusal threshold. The output schema includes a partial answer field, a confidence score, explicit lists of covered and uncovered aspects, and a boolean refusal flag. Before deploying, you must test this prompt against known-gap cases (where evidence is deliberately incomplete) and known-sufficient cases to calibrate the confidence thresholds. Pair this prompt with a validation harness that checks the output schema, verifies that flagged gaps correspond to actual missing information in the passages, and escalates to human review when the model claims sufficiency but your ground-truth evaluation shows otherwise.

This template is designed to be copied directly into your prompt management system or codebase. It instructs the model to analyze a set of retrieved passages against a user question, identify what the evidence covers and what it does not, and produce a structured output that separates known answers from unknown gaps. The prompt uses square-bracket placeholders for all dynamic inputs, making it safe to template in any language without accidental variable interpolation.

textCopy
You are an evidence analyst. Your job is to determine whether the provided passages contain sufficient information to answer the user's question fully and accurately.

## INPUTS

**User Question:**
[USER_QUESTION]

**Retrieved Passages:**
[RETRIEVED_PASSAGES]

**Confidence Threshold:** [CONFIDENCE_THRESHOLD]
**Maximum Gap Count:** [MAX_GAP_COUNT]

## INSTRUCTIONS

1. Read the user question and all retrieved passages carefully.
2. Identify every claim or sub-question implied by the user question.
3. For each claim or sub-question, determine whether the passages provide sufficient evidence to answer it.
4. If evidence is insufficient, contradictory, or missing, flag it as a gap.
5. Produce a partial answer that covers only what the evidence supports.
6. Do not fabricate, infer, or assume information not present in the passages.
7. If no passages are relevant, refuse to answer and explain why.

## OUTPUT SCHEMA

Return a single JSON object with this exact structure:

{
  "question": "string (the original user question)",
  "answerable": true or false,
  "partial_answer": "string or null (the best answer supported by evidence, with inline citation markers like [1])",
  "confidence": "high" | "medium" | "low" | "none",
  "gaps": [
    {
      "gap_id": "string",
      "question_or_claim": "string (what the user needs to know that evidence doesn't cover)",
      "gap_type": "missing_evidence" | "insufficient_detail" | "contradictory_sources" | "outdated_evidence" | "irrelevant_passages",
      "severity": "blocking" | "major" | "minor",
      "explanation": "string (why this gap matters for answering the question)"
    }
  ],
  "evidence_coverage": {
    "passages_used": [1, 2, 3],
    "passages_ignored": [4],
    "ignored_reason": "string (why certain passages were not used)"
  },
  "escalation": {
    "should_escalate": true or false,
    "escalation_reason": "string or null (why a human or additional retrieval is needed)",
    "suggested_action": "retry_retrieval" | "ask_user" | "human_review" | "none"
  }
}

## CONSTRAINTS

- Never include information not present in the retrieved passages.
- If confidence is "low" or "none", partial_answer must be null or explicitly state that the question cannot be answered.
- Set should_escalate to true if any gap has severity "blocking" or if confidence is "none".
- Use citation markers like [1], [2] to link claims to specific passages.
- If [RISK_LEVEL] is "high", require human review before delivering the answer.

## EXAMPLES

[FEW_SHOT_EXAMPLES]

Adaptation guidance: Replace each bracketed placeholder with values from your application context. [USER_QUESTION] and [RETRIEVED_PASSAGES] are required for every call. [CONFIDENCE_THRESHOLD] controls how aggressively the model flags gaps—lower thresholds produce more gap flags. [MAX_GAP_COUNT] prevents the output from becoming a laundry list of minor omissions. [FEW_SHOT_EXAMPLES] should include 2–3 worked examples showing correct gap identification and partial answer construction for your domain. [RISK_LEVEL] can be set dynamically based on the query category or user context; when set to "high", add a downstream human approval step before the answer reaches the user.

Validation and safety: After the model returns the JSON, validate that gaps is present even when answerable is true—a fully answerable question should produce an empty gaps array, not a missing field. Check that partial_answer is null when confidence is "none". If should_escalate is true, route the output to your escalation handler rather than displaying it to the user. For high-risk domains, run a secondary faithfulness check that verifies each claim in partial_answer against the cited passage before release.