Assumption Disclosure and Confirmation Prompt Template

This prompt is for AI product builders who need their assistant to proceed under uncertainty when a full clarification loop is too costly, slow, or disruptive to the user experience. The job-to-be-done is generating a response that transparently states what the assistant is assuming, acts on that assumption, and embeds a lightweight confirmation mechanism so the user can correct the assumption in a single turn. The ideal user is an engineering lead or developer integrating an LLM into a customer support copilot, a task-oriented agent, or any multi-turn product where latency and context budget matter more than perfect certainty on every parameter.

Use this template when the cost of asking a clarification question—measured in user friction, context window consumption, or task interruption—exceeds the risk of being wrong. This is common in high-velocity support workflows, voice assistants where back-and-forth is painful, and agentic systems that must make progress with incomplete information. Do not use this prompt when the decision carries safety, financial, legal, or irreversible consequences. In those cases, a full clarification loop with human approval is required. Also avoid this prompt when the user has explicitly asked for precision or when the domain is so ambiguous that the assumption is likely to be a guess rather than a reasonable inference from context.

The prompt requires several inputs to function correctly: the user's original request, relevant conversation history, any retrieved evidence or tool outputs, and a defined risk level that controls how aggressively the assistant should assume versus ask. The output is a structured response containing the disclosed assumption, the action taken based on that assumption, and a clear opt-out path for the user. Before shipping, validate that the assumption is grounded in available context, the confirmation mechanism is genuinely easy for the user to act on, and the system correctly handles the user's correction in the subsequent turn. The most common failure mode is an assumption that reads as a confident statement of fact rather than a disclosed inference, which erodes trust. Test for this by having evaluators check whether a reasonable user would recognize the assumption as provisional.

This template is designed for a specific conversational state: the assistant has identified an ambiguity but, based on a cost-benefit decision, has chosen to proceed under an explicit assumption rather than ask a clarifying question. The prompt instructs the model to synthesize the assumption from the available context, state it clearly to the user, and embed a lightweight, non-disruptive confirmation mechanism directly in the response. The goal is to maintain conversational momentum while creating a clear audit trail and an easy off-ramp for the user to correct the assumption if it's wrong.

textCopy
SYSTEM: You are an AI assistant that sometimes needs to make assumptions to keep a conversation moving. When you do, you must state the assumption clearly and provide a simple way for the user to confirm or correct it without derailing the conversation.

USER: [CONVERSATION_HISTORY]

Based on the conversation above, the user's latest request is ambiguous in the following way: [AMBIGUITY_DESCRIPTION].

Given the context, the most reasonable assumption to make is: [PROPOSED_ASSUMPTION].

Your task is to generate a response that:
1. Directly addresses the user's request based on the proposed assumption.
2. Begins or ends with a single, concise sentence that transparently states the assumption you are making.
3. Includes a lightweight confirmation mechanism. This should be a brief, bracketed instruction at the end of the response, like "[If this assumption is incorrect, please clarify and I'll update my response.]"
4. Does not ask an open-ended question or halt the workflow. The primary response must be delivered.

CONSTRAINTS:
- The assumption statement must be specific, not generic (e.g., "I'm assuming the 'Q3 report' refers to the financial summary, not the marketing deck.").
- The confirmation mechanism must not require a response for the user to get value.
- Do not apologize for making an assumption.

OUTPUT_SCHEMA:
{
  "assumption_statement": "string",
  "primary_response": "string",
  "confirmation_mechanism": "string"
}

To adapt this template, replace the [CONVERSATION_HISTORY], [AMBIGUITY_DESCRIPTION], and [PROPOSED_ASSUMPTION] placeholders with data from your application's state manager. The [PROPOSED_ASSUMPTION] is the critical piece of logic that should be generated by an upstream classification or decision prompt, not by this template itself. This prompt's job is to format that decision into a user-facing response. For high-risk domains, add a [RISK_LEVEL] field and adjust the CONSTRAINTS to require a more forceful correction mechanism, such as asking for an explicit "yes/no" confirmation before proceeding with the next step. Always validate the output against the OUTPUT_SCHEMA to ensure the confirmation mechanism is present and the assumption is stated before the response is delivered to the user.

The assumption disclosure prompt is designed to be invoked as a conditional step in a chat pipeline, not as the default response path. Before calling this prompt, the application should evaluate whether the primary intent handler or tool chain has produced a result below a configurable confidence threshold. A typical trigger condition is when the top intent classification score falls below 0.7 or when a slot-filling agent has missing required parameters and the cost of a full clarification loop exceeds the cost of a disclosed assumption. The application should inject the model's current understanding, the specific ambiguity, and the proposed assumption into the [AMBIGUITY_CONTEXT] and [PROPOSED_ASSUMPTION] placeholders before generation.

Post-processing must validate the model's output against a strict schema before surfacing it to the user. At minimum, extract and verify three components: the assumption statement, the confirmation mechanism, and the opt-out path. The confirmation mechanism should be machine-actionable—prefer structured outputs like "confirmation_action": "reply YES to proceed" or a confirm/change button payload. If the model fails to include an explicit opt-out instruction (e.g., 'If this is incorrect, please correct me'), the harness should either reject the output and retry with a stronger constraint or append a default opt-out clause. Log the assumption, the confidence score that triggered it, and the user's eventual confirmation or correction for offline evaluation of the assumption accuracy rate. A high correction rate on assumptions indicates the confidence threshold should be raised or the ambiguity context is insufficient.

For high-stakes domains such as healthcare or finance, never surface an assumption without a human review step. In these cases, route the generated assumption to an internal review queue and present the user with a holding message ('Checking a few details before I proceed'). The assumption should only be shown after approval. For lower-stakes applications, you can surface the assumption directly but must track the assumption_correction_rate metric. If this rate exceeds 15% over a rolling window, automatically escalate to a full clarification prompt instead. Avoid chaining multiple assumptions in a single response—if the model's output contains more than one assumption statement, discard it and fall back to a targeted clarification question to prevent compounding errors.