Evidence Gap Analysis Prompt Template

This prompt is for planning modules in autonomous and semi-autonomous agent systems that must identify what evidence is missing before execution can proceed safely. It analyzes a proposed plan against currently available evidence, identifies critical gaps, and produces a prioritized evidence collection plan with specific information requests. Use this prompt when your agent has generated a plan but needs to verify that it has sufficient evidence to execute each step without making dangerous assumptions.

This is not a plan generation prompt. It assumes a plan already exists and focuses exclusively on the gap between what the plan requires and what evidence is currently available. Run this before committing to irreversible actions, before spending tokens on multi-step execution, and whenever new context or tool outputs could invalidate prior assumptions. The prompt works best when the plan is already decomposed into discrete steps with clear preconditions, and when you have a structured inventory of currently available evidence sources. Do not use this prompt for initial plan creation, for evaluating plan quality in isolation, or for post-execution forensics—those are separate workflows with different output contracts.

The ideal user is an agent runtime or orchestration layer that needs a gating check between planning and execution. Wire this into your agent loop after plan generation but before the first tool call or state mutation. If your agent operates in a domain where incorrect actions have financial, safety, or compliance consequences, pair this prompt with a human approval step for any gaps scored above a configurable criticality threshold. For lower-risk workflows, you can use the output to drive automated evidence collection before proceeding. Avoid running this prompt on plans that are purely informational or read-only, as the overhead of gap analysis may exceed the value when no irreversible state changes are at stake.

This template is designed to be dropped into an agent planning module before execution begins. It forces the model to treat the proposed plan as a hypothesis that must survive evidence scrutiny, not as a set of instructions to blindly follow. The prompt requires the model to enumerate what it knows, what it assumes, and what it must verify before proceeding. Use this when the cost of wrong execution is high—destructive operations, compliance-sensitive workflows, or multi-step plans where early errors compound. Do not use this for trivial, read-only, or fully deterministic tasks where evidence gaps cannot exist.

textCopy
You are an evidence-gap analyst for an autonomous agent planning system. Your job is to examine a proposed execution plan against all available evidence and identify what critical information is missing before safe execution can proceed.

## INPUTS

[PROPOSED_PLAN]
(A structured, multi-step plan with step IDs, descriptions, dependencies, and expected outputs. Include any tool specifications or resource requirements.)

[AVAILABLE_EVIDENCE]
(A structured inventory of all evidence currently available, including source, timestamp, content summary, and reliability rating for each item. Mark any evidence that may be stale.)

[EXECUTION_CONTEXT]
(Operational context including: risk tolerance level [LOW|MEDIUM|HIGH|CRITICAL], whether any steps are irreversible, human-in-the-loop availability, and time constraints.)

[ASSUMPTION_INVENTORY]
(Optional. A pre-existing list of assumptions extracted from the goal and plan. If not provided, you must surface implicit assumptions during analysis.)

## OUTPUT SCHEMA

Return a valid JSON object with this structure:

{
  "plan_id": "string",
  "analysis_timestamp": "ISO8601",
  "overall_assessment": {
    "execution_readiness": "READY | PROCEED_WITH_CAUTION | BLOCKED",
    "critical_gap_count": "integer",
    "summary": "One-sentence assessment of whether the plan can proceed safely."
  },
  "evidence_gaps": [
    {
      "gap_id": "string",
      "affected_step_ids": ["step_id"],
      "gap_description": "What specific information is missing.",
      "criticality": "BLOCKING | HIGH | MEDIUM | LOW",
      "criticality_rationale": "Why this gap matters for safe execution.",
      "assumptions_at_risk": ["assumption_id or description"],
      "consequence_if_unresolved": "What happens if we proceed without this evidence.",
      "evidence_to_collect": "Specific information needed to close this gap.",
      "collection_method": "How to obtain this evidence (tool call, human query, retrieval, etc.).",
      "acceptable_proxy_evidence": "What partial or indirect evidence would be sufficient if direct evidence is unavailable."
    }
  ],
  "prioritized_collection_plan": [
    {
      "priority": "integer starting at 1",
      "gap_id": "string",
      "collection_action": "Concrete next action to collect this evidence.",
      "estimated_effort": "LOW | MEDIUM | HIGH",
      "blocks_other_gaps": ["gap_id"],
      "can_parallelize": "boolean"
    }
  ],
  "steps_safe_to_execute_now": ["step_id"],
  "steps_blocked": ["step_id"],
  "recommended_next_action": "PROCEED_WITH_SAFE_STEPS | COLLECT_EVIDENCE | ESCALATE_TO_HUMAN | ABORT"
}

## CONSTRAINTS

1. Every gap must be traceable to a specific plan step. No abstract or unlinked gaps.
2. Criticality scoring must reference [EXECUTION_CONTEXT] risk tolerance. A gap that is HIGH in a CRITICAL context may be BLOCKING.
3. If any BLOCKING gap exists, overall execution_readiness must be BLOCKED.
4. Do not invent evidence. If [AVAILABLE_EVIDENCE] is silent on a question, that is a gap.
5. Flag assumptions that are masquerading as evidence. If a claim in [AVAILABLE_EVIDENCE] is itself an assumption, call it out.
6. For irreversible steps, any unresolved gap of MEDIUM criticality or higher is automatically BLOCKING.
7. The prioritized_collection_plan must respect dependency order: if Gap B depends on Gap A being resolved first, Gap A gets higher priority.
8. If [ASSUMPTION_INVENTORY] is provided, cross-reference every assumption against [AVAILABLE_EVIDENCE] and flag unvalidated assumptions as gaps.
9. If evidence is older than its domain-appropriate freshness window, treat it as a gap requiring revalidation.
10. Do not recommend proceeding with steps that depend on gapped evidence, even if those steps appear low-risk in isolation.

Adaptation guidance: Replace the bracketed inputs with your system's actual data structures. The [PROPOSED_PLAN] should come from your plan generation module. The [AVAILABLE_EVIDENCE] should be assembled from your retrieval system, tool outputs, and session context. The [EXECUTION_CONTEXT] should be set by your orchestration layer based on the task's risk profile. The output schema is designed to be machine-readable by a downstream execution gate—parse overall_assessment.execution_readiness to decide whether to proceed, collect evidence, or escalate. For high-risk domains, add a human review step before acting on the recommended_next_action field. Test this prompt with plans that have deliberately missing evidence to verify it catches gaps rather than hallucinating justifications.

The Evidence Gap Analysis prompt is designed to sit between a plan generation module and an execution engine. It receives a proposed plan and the currently available evidence, then outputs a prioritized list of missing information. To integrate this into a production agent, treat the prompt as a synchronous step in a planning pipeline: the orchestrator calls plan generation, then immediately calls evidence gap analysis on the generated plan before any execution steps are dispatched. The output of this prompt should gate execution—if critical gaps are found, the agent should not proceed to execute steps that depend on missing evidence. Instead, it should trigger evidence collection, clarification requests, or human escalation.

Wire the prompt into a function with the signature analyze_evidence_gaps(plan: Plan, evidence: EvidenceInventory, thresholds: GapThresholds) -> GapAnalysisResult. The GapThresholds object should carry configurable criticality scores that map to actions: gaps above a blocking_threshold halt execution entirely, gaps between warning_threshold and blocking_threshold allow execution with explicit warnings logged, and gaps below warning_threshold are noted but do not gate execution. The GapAnalysisResult must include a structured list of gaps, each with a criticality_score (0.0–1.0), impacted_steps (list of step IDs), evidence_required (specific information needed), and a collection_strategy (one of query_user, tool_call, retrieval, human_escalation). Validate the output against this schema before acting on it. If the model returns malformed JSON or missing required fields, retry once with a repair prompt that includes the schema and the raw output. If the retry fails, escalate to a human operator with the plan and evidence inventory attached.

For logging and observability, record every gap analysis result alongside the plan version, evidence inventory hash, and threshold configuration. This trace is essential for debugging false positives (gaps flagged that were actually covered by evidence) and false negatives (missing gaps that caused downstream execution failures). Implement a feedback loop: when an execution step fails due to missing evidence that the gap analysis should have caught, log that as a missed_gap event and feed it into your eval dataset for regression testing. For model choice, use a model with strong structured output capabilities and reasoning depth—this prompt requires the model to cross-reference plan steps against evidence sources, which is more demanding than simple classification. If latency is a concern, consider running gap analysis in parallel with other pre-execution checks, but ensure the execution engine waits for the gap analysis result before dispatching any step that touches mutable resources or has irreversible side effects.

When operating in regulated or high-risk domains, add a human review step for any gap with a criticality score above 0.7 or any gap that impacts steps marked as irreversible. The human reviewer should receive the gap analysis result, the original plan, and the evidence inventory in a structured review interface. Do not allow the agent to autonomously execute evidence collection strategies that involve external systems (tool calls, database queries) for high-criticality gaps without explicit approval. Finally, configure a maximum evidence collection budget—if the agent cannot close critical gaps within a fixed number of collection attempts or a time window, it should stop and escalate rather than loop indefinitely. The gap analysis prompt is a decision-support tool, not a replacement for operational judgment about when to proceed with uncertainty.