Ambiguity Detection and Escalation Prompt

This prompt is designed for AI safety engineers and platform teams who need to detect inputs that have multiple valid interpretations before an AI system acts on them. It is a pre-action gate that sits between user input and downstream processing, identifying when an input could reasonably be understood in more than one way. The prompt produces a detection signal, enumerates the competing interpretations, and generates a structured ambiguity report for human review. Use this when the cost of acting on the wrong interpretation is high, such as in financial transactions, healthcare instructions, legal document processing, or configuration changes.

Do not use this prompt for simple classification tasks where a single label is expected, or for inputs where ambiguity is acceptable and the system should proceed with a best-guess interpretation. This prompt assumes you have a human review queue or escalation path ready to receive the ambiguity reports it generates. Before deploying, validate that your review SLA can handle the expected ambiguity rate—if every ambiguous input blocks the pipeline, you need enough reviewers to prevent a backlog. Wire the prompt into a pre-processing layer that calls the model, checks the is_ambiguous flag, and either routes to the review queue or passes the disambiguated interpretation downstream. Test against a golden set of known-ambiguous cases (e.g., 'Change the lighting in room 2' when rooms 2A and 2B both exist) and known-unambiguous cases to measure precision and recall.

The prompt is most effective when combined with a confidence threshold: if the model flags ambiguity but assigns low confidence to its own analysis, escalate immediately without attempting resolution. Avoid using this prompt on every user input in high-throughput systems—reserve it for write operations, state changes, and decisions with irreversible consequences. For read-only queries where the worst case is a confusing answer, a lighter-weight clarification prompt is usually sufficient.

This prompt template is the core engine for an ambiguity detection and escalation workflow. It instructs the model to act as a safety-focused classifier that does not guess. Instead, it analyzes the input for multiple valid interpretations, scores the severity of the ambiguity, and packages its findings into a machine-readable report. The goal is to prevent silent failures in production systems where a single input could mean two very different things—such as a command to 'drop the table' that could refer to a database operation or a furniture request.

textCopy
You are an ambiguity detection system. Your job is to analyze user inputs for multiple valid interpretations that could lead to conflicting or unsafe actions. Do not resolve the ambiguity. Do not guess the user's intent. Your only job is to detect, enumerate, and escalate.

INPUT:
[USER_INPUT]

CONTEXT (optional):
[SYSTEM_CONTEXT]

CONSTRAINTS:
- Only flag genuine ambiguities where different interpretations would lead to materially different outcomes.
- Do not flag vague but harmless statements as ambiguous.
- If the input is clear and has only one reasonable interpretation, return a confidence score of 'high' and an empty interpretations list.
- For each interpretation, state the implied action or intent clearly.

OUTPUT_SCHEMA:
{
  "ambiguity_detected": boolean,
  "confidence": "high" | "medium" | "low",
  "interpretations": [
    {
      "id": string,
      "description": string,
      "implied_action": string,
      "risk_level": "low" | "medium" | "high" | "critical"
    }
  ],
  "ambiguity_type": "semantic" | "referential" | "scope" | "domain" | "none",
  "escalation_reason": string,
  "recommended_clarification_question": string
}

EXAMPLES:
Input: "Delete the staging environment."
Output: {
  "ambiguity_detected": true,
  "confidence": "low",
  "interpretations": [
    {"id": "1", "description": "Delete the cloud infrastructure for the staging environment.", "implied_action": "Run infrastructure teardown scripts.", "risk_level": "critical"},
    {"id": "2", "description": "Remove the 'staging' row from a configuration database.", "implied_action": "Execute a SQL DELETE statement.", "risk_level": "high"}
  ],
  "ambiguity_type": "referential",
  "escalation_reason": "The target of the 'delete' command is ambiguous. It could refer to infrastructure or a database record.",
  "recommended_clarification_question": "Do you want to delete the cloud infrastructure for staging, or a specific database record?"
}

Input: "What's the weather?"
Output: {
  "ambiguity_detected": false,
  "confidence": "high",
  "interpretations": [],
  "ambiguity_type": "none",
  "escalation_reason": "",
  "recommended_clarification_question": ""
}

To adapt this template for your application, replace the placeholders with your specific values. [USER_INPUT] should be the raw text from the user or upstream system. [SYSTEM_CONTEXT] is optional but highly recommended; it can include the agent's current task, available tools, or recent conversation history to ground the ambiguity check. The OUTPUT_SCHEMA is designed to be parsed by an application router. If your system uses a different risk taxonomy, modify the risk_level enum accordingly. The EXAMPLES section is critical for few-shot behavior—replace the provided examples with 3–5 examples that reflect the real ambiguities your system encounters in production. If your model supports structured output modes (e.g., JSON mode or function calling), remove the schema description and pass it as a native tool parameter instead.

After copying this template, you must pair it with a validation layer. Parse the model's output and confirm that ambiguity_detected is a boolean and that interpretations is an array. If the model returns malformed JSON, use a repair prompt or retry with a stricter system instruction. For high-risk domains such as infrastructure commands or financial operations, always route outputs where ambiguity_detected is true to a human review queue. Never allow the system to proceed autonomously when risk_level is critical. The next section covers how to wire this prompt into an application harness with retries, logging, and human-in-the-loop routing.

This prompt is designed as a pre-processing gate in a high-reliability pipeline. It should be invoked before any downstream action, classification, or generation that depends on a single, unambiguous interpretation of the user's input. The ideal integration point is immediately after user input is received and sanitized, but before it is passed to a task-specific agent, classifier, or RAG pipeline. The prompt's output is a structured signal, not a user-facing message, so it must be parsed by application code to control workflow branching.

To wire this in, wrap the prompt call in a function that accepts the raw user input and a configurable [RISK_LEVEL] parameter. The application must parse the JSON output and check the ambiguity_detected boolean field. If true, the application should block the primary workflow and route the ambiguity_report object to a human review queue. Do not proceed with a best-guess interpretation. The report includes the original_input, a list of competing_interpretations, and a recommended_clarification_question. This payload should be rendered in your internal review tool, allowing a human operator to select the correct interpretation or ask the end-user for clarification. Implement a strict schema validator (e.g., using Pydantic or Zod) on the model's JSON response. If parsing fails, retry once with a stronger instruction to output only the specified JSON schema. If the retry also fails, escalate the raw input and the malformed response directly to an on-call engineering channel as a model failure incident.

For model choice, use a capable frontier model (e.g., GPT-4o, Claude 3.5 Sonnet) with native JSON mode enabled. Set temperature to 0 to minimize variance in the structured output. Log every invocation, including the input, the full ambiguity report, and the final routing decision (auto-proceeded vs. escalated), to your prompt observability platform. This log is critical for tuning the [RISK_LEVEL] sensitivity and auditing false positives. Avoid using this prompt on every single user message in a high-volume chat application; instead, gate its use to moments where a critical action is about to be taken, to manage latency and cost.