Assumption Inventory Generation Prompt Template

This prompt is a planning pre-processor for autonomous and semi-autonomous agent systems. Its job is to extract every implicit and explicit assumption from a goal statement and its surrounding context before any execution step is taken. The output is a structured inventory of assumptions, each with a unique ID, category, and initial confidence estimate. Use this prompt when an agent receives a new objective and you need to surface what the system is taking for granted before it builds a plan. The ideal user is an AI engineer or agent architect building a planning module who needs to prevent confident but wrong execution caused by unstated assumptions.

This is not a plan generation prompt. It does not sequence tasks, assign tools, or produce execution steps. It belongs immediately after goal ingestion and before any decomposition or tool selection. If your agent pipeline already has a goal clarification step, insert this prompt between clarification and plan generation. Do not use this prompt when the goal is trivial, fully deterministic, or when the cost of assumption failure is negligible. Do not use it as a substitute for a formal risk assessment or compliance review in regulated domains—those require human-in-the-loop workflows and evidence grounding beyond what this prompt provides.

Before wiring this into production, define what constitutes a valid assumption inventory for your domain. A good output should surface assumptions about tool availability, data freshness, user intent, environmental state, and permission boundaries. If the model produces an inventory with fewer than three assumptions for a non-trivial goal, treat that as a likely failure mode indicating the prompt needs more context or stronger instructions. Pair this prompt with the Assumption-to-Evidence Mapping Prompt Template to trace each assumption to supporting evidence, and with the Pre-Flight Assumption Check Prompt Template to validate assumptions before execution begins.

This prompt is designed as a pre-processing step for agent planning workflows. Before an agent builds an execution plan, it should surface every assumption embedded in the goal and available context. Unstated assumptions are the primary source of confident but wrong execution, so this inventory becomes the foundation for downstream validation, conflict detection, and evidence mapping. The prompt expects a goal statement and optional context, and it returns a structured inventory that other prompts in the Uncertainty Handling and Assumption Tracking group can consume directly.

textCopy
You are an assumption extraction specialist. Your job is to read a goal statement and available context, then produce a complete inventory of every assumption—both explicit and implicit—that would need to hold true for the goal to be achieved successfully.

## INPUT

**Goal Statement:**
[GOAL_STATEMENT]

**Available Context:**
[CONTEXT]

## INSTRUCTIONS

1. Extract every assumption required for the goal to succeed. Include assumptions about:
   - **Factual state:** What is true about the world, system, data, or environment right now.
   - **Stability:** What will remain true throughout execution.
   - **Causal relationships:** What actions will produce what outcomes.
   - **Tool and capability availability:** What tools, APIs, permissions, or access will be available.
   - **User intent and preferences:** What the user actually wants, prioritizes, or considers acceptable.
   - **Constraints and boundaries:** What limits, rules, or policies apply.
   - **Dependencies:** What external systems, people, or processes will behave as expected.
   - **Missing information:** What is not stated but would change the plan if different.

2. For each assumption, assign:
   - A unique **assumption_id** using the format `ASM-XXX` where XXX is a zero-padded number starting at 001.
   - A **category** from the list above.
   - A **confidence** score between 0.0 and 1.0 reflecting how likely the assumption is to be true based on available evidence (1.0 = explicitly confirmed, 0.5 = plausible but unverified, 0.0 = pure guess).
   - A **rationale** explaining why this assumption matters and what evidence supports or contradicts it.
   - A **risk_if_wrong** statement describing what breaks if this assumption is false.

3. Be exhaustive. Prefer over-extraction to under-extraction. Flag assumptions that seem obvious—those are the ones that cause the most damage when wrong.

4. If the context contains contradictions or ambiguous statements, extract competing assumptions and note the conflict.

## OUTPUT SCHEMA

Return a single JSON object with this structure:

```json
{
  "goal_summary": "A one-sentence restatement of the goal as understood.",
  "assumptions": [
    {
      "assumption_id": "ASM-001",
      "category": "factual_state | stability | causal_relationship | tool_capability | user_intent | constraint | dependency | missing_information",
      "statement": "The assumption stated as a clear, falsifiable claim.",
      "confidence": 0.0,
      "rationale": "Why this assumption matters and what evidence supports or contradicts it.",
      "risk_if_wrong": "What breaks in the plan if this assumption is false.",
      "is_explicit": true,
      "source": "Where in the goal or context this assumption originates, or 'implicit' if unstated."
    }
  ],
  "conflicts": [
    {
      "assumption_ids": ["ASM-XXX", "ASM-YYY"],
      "description": "Description of the contradiction between these assumptions."
    }
  ],
  "critical_gaps": [
    "A question that must be answered before execution can proceed safely."
  ]
}

CONSTRAINTS

• Do not invent facts not present in the goal or context.
• Do not skip assumptions because they seem obvious.
• If confidence is below 0.3, mark the assumption as requiring verification before execution.
• If the goal statement is ambiguous, extract assumptions for each plausible interpretation and note the ambiguity in critical_gaps.
• Return ONLY valid JSON. No markdown fences, no commentary outside the JSON object.

To adapt this prompt for your system, replace [GOAL_STATEMENT] with the user's objective or task description, and [CONTEXT] with any available supporting information such as tool descriptions, environment state, user preferences, or prior conversation history. If no context is available, pass an empty string or a note like 'No additional context provided.' The output schema is designed to be machine-readable by downstream validation prompts such as the Pre-Flight Assumption Check or Assumption-to-Evidence Mapping templates. For high-risk domains where missed assumptions could cause irreversible damage, add a [RISK_LEVEL] parameter that adjusts the confidence threshold for flagging assumptions as requiring verification, and route low-confidence assumptions to a human reviewer before plan execution begins.

The Assumption Inventory prompt is designed as a pre-processor in an agent planning pipeline. It should execute before any plan generation or task decomposition step. The typical wiring pattern is: receive a user goal and available context → call this prompt to extract assumptions → validate the output against the expected schema → feed the structured assumption inventory into downstream planning prompts. This prompt is stateless and idempotent for the same inputs, so caching the output per (goal_hash, context_hash) is a safe cost optimization when the context hasn't changed.

Schema validation is mandatory before passing the output downstream. The expected output is a JSON object with an assumptions array where each entry must contain assumption_id (string), category (enum: factual, causal, temporal, resource, permission, user_intent, environmental, definitional), statement (string), source (enum: explicit, implicit, inferred), confidence (float 0.0–1.0), and depends_on (array of assumption_id strings). Implement a post-processing validator that rejects malformed outputs, missing required fields, duplicate IDs, self-referential dependencies, and confidence values outside range. On validation failure, retry once with the validation error message appended to the prompt as a correction hint. If the retry also fails, log the failure, surface the partial output with a warning flag, and route to a human review queue rather than silently proceeding with broken assumptions.

Model choice and latency budget matter here. This prompt benefits from models with strong reasoning and structured output discipline. For production, prefer a model that supports strict JSON mode or structured output constraints (e.g., GPT-4o with response_format, Claude 3.5 Sonnet with tool-use-shaped output). Set a timeout of 10–15 seconds for the assumption extraction call. If the goal statement is long or the context is dense, consider chunking the context and running the prompt once per chunk, then merging and deduplicating assumption inventories in a second pass. Log every assumption inventory with the input goal hash, model version, timestamp, and validation status. This audit trail is essential for debugging downstream planning failures—when a plan goes wrong, the first question is always 'what assumptions were we operating under?'

Tool integration and RAG are not required for the core prompt, but a production harness should connect the output to an assumption store or vector database. After validation, write each assumption to a persistent store keyed by session or plan ID. Downstream prompts (Pre-Flight Assumption Check, Assumption Drift Monitoring, Evidence Gap Analysis) query this store. For high-risk domains, add a human-in-the-loop gate: if any assumption has confidence below 0.6 and category is permission or user_intent, pause the pipeline and surface those assumptions for human confirmation before plan generation proceeds. Avoid the temptation to skip this gate—confident but wrong execution almost always traces back to an unverified implicit assumption that the model confidently hallucinated.