Ambiguous Input Escalation Decision Prompt

This prompt is designed for operations engineers and platform builders who are implementing a human-in-the-loop triage system. Its core job is to act as a deterministic policy layer that sits after your initial classification pipeline has already flagged an input as ambiguous. Instead of making a guess or failing silently, this prompt weighs the severity of the ambiguity, the potential business or safety impact of a wrong decision, and the context available to produce a structured, auditable escalation decision. The primary user is someone who needs to replace ad-hoc routing rules with a consistent, reviewable policy that prevents misrouted tickets, misclassified incidents, or mishandled sensitive requests.

You should use this prompt when your system has already detected ambiguity—for example, via a dedicated Ambiguity Detection Prompt or a low confidence score from a classifier—and you need to decide whether to escalate to a human queue. It is particularly valuable in high-stakes domains like security incident triage, compliance review, or sensitive customer support, where the cost of an incorrect automated action is high. The prompt requires specific inputs to function correctly: the original ambiguous user input, the classification attempts and their confidence scores, the detected ambiguity spans, and a defined [RISK_LEVEL] for the domain. It is not a general-purpose classifier and should not be used as the first line of defense for all user inputs, as it assumes ambiguity has already been established.

Do not use this prompt for real-time, low-latency conversational flows where a human cannot be looped in within an acceptable response time. In such cases, a fallback to a clarification question or a safe default action is more appropriate. Additionally, avoid using this prompt without a clear definition of what constitutes a 'high-impact' error in your specific domain; the prompt's effectiveness depends on a well-calibrated [RISK_LEVEL] and [IMPACT_DEFINITION] context. The next step after implementing this prompt is to build the evaluation harness that checks for over-escalation (wasting human time on trivial ambiguities) and under-escalation (allowing critical ambiguous inputs to be processed automatically), ensuring the policy remains correctly tuned over time.

This prompt template is the core decision engine for your human-in-the-loop triage system. It takes an ambiguous input, its classification metadata, and your operational context, then produces a structured escalation decision. The template is designed to be copied directly into your prompt management system, with square-bracket placeholders that your application must populate before each inference call. Do not send the template with unresolved placeholders to the model.

textCopy
You are an escalation decision engine for an AI triage system. Your job is to decide whether an ambiguous user input should be escalated to a human reviewer or handled automatically.

## INPUT
User Input: [USER_INPUT]
Classification Attempt: [CLASSIFICATION_LABEL]
Confidence Score: [CONFIDENCE_SCORE] (0.0 to 1.0)
Ambiguity Severity: [AMBIGUITY_SEVERITY] (low, medium, high, critical)
Detected Intents: [DETECTED_INTENTS]

## CONTEXT
User Tier: [USER_TIER]
Request Type: [REQUEST_TYPE]
Historical Escalation Rate for This Intent: [HISTORICAL_ESCALATION_RATE]
Available Human Reviewer Capacity: [REVIEWER_CAPACITY] (available, limited, none)

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with these exact fields:
{
  "decision": "escalate" | "do_not_escalate",
  "reasoning": "string explaining the key factors that drove the decision",
  "escalation_priority": "low" | "medium" | "high" | "critical",
  "handoff_summary": "string summarizing what the human reviewer needs to know",
  "uncertainty_points": ["specific things the classifier was uncertain about"],
  "suggested_reviewer_role": "string indicating which team or role should handle this"
}

## DECISION RULES
1. Escalate if ambiguity severity is "critical" regardless of other factors.
2. Escalate if confidence score is below [CONFIDENCE_THRESHOLD] and ambiguity severity is "high".
3. Escalate if the input contains [HIGH_RISK_SIGNALS] even with moderate confidence.
4. Do not escalate if confidence is above [HIGH_CONFIDENCE_THRESHOLD] and ambiguity severity is "low".
5. Do not escalate if reviewer capacity is "none" unless ambiguity severity is "critical".
6. When in doubt, prefer escalation for [REGULATED_DOMAINS] or inputs affecting [HIGH_IMPACT_ACTIONS].

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Return only the JSON object. No other text.

To adapt this template, replace each square-bracket placeholder with live data from your classification pipeline and operational context. The [CONSTRAINTS] placeholder should contain domain-specific rules like regulatory requirements, SLA boundaries, or business policies. The [FEW_SHOT_EXAMPLES] placeholder should include 2-4 example input-output pairs that demonstrate correct escalation and non-escalation decisions for your specific domain. The [HIGH_RISK_SIGNALS] placeholder should list keywords, patterns, or metadata flags that indicate elevated risk in your context, such as "account deletion request," "billing dispute," or "medical symptom description."

Before deploying this prompt, validate that your application layer populates every placeholder and that the output JSON is parsed and validated against the schema. If the model returns malformed JSON, implement a retry with the error message appended to the prompt. For high-stakes domains, always log the full prompt, response, and decision metadata for audit purposes. Never skip human review for inputs where the model's escalation decision contradicts your operational policies.

This prompt is designed to sit at a critical decision point in your triage pipeline: after ambiguity has been detected and scored, but before a final routing or escalation action is taken. The harness should treat the prompt as a deterministic decision function that consumes structured ambiguity metadata and produces a structured escalation verdict. Because the decision directly affects operational load (human reviewer time) and user experience (unnecessary clarification loops), the harness must enforce strict input validation, output schema compliance, and audit logging on every invocation. Do not call this prompt directly from user-facing code without a wrapper that handles timeouts, malformed responses, and missing fields.

Integration pattern: Wrap the prompt in a service function that accepts an AmbiguityAssessment object (containing ambiguity_severity, potential_impact, available_context, classification_confidence, and input_summary) and returns an EscalationDecision object with escalate_to_human (boolean), escalation_reason (string), recommended_reviewer_role (string or null), and handoff_packet (structured summary for the human reviewer). The function should: (1) validate all input fields are present and within expected ranges before calling the model; (2) parse the model response against the output schema using a JSON validator; (3) on parse failure, retry once with a repair prompt that includes the raw output and the schema; (4) if the retry also fails, default to escalate_to_human: true with reason "automated_decision_failed" and log the incident. For high-throughput systems, consider using a cheaper, faster model (e.g., GPT-4o-mini, Claude Haiku) for this decision prompt, since the task is structured classification rather than open-ended reasoning.

Eval harness and guardrails: Before deploying, build a test suite with at least 50 labeled cases covering clear-escalate, clear-no-escalate, and boundary scenarios. Measure over-escalation rate (false positives where the prompt escalates when a human would not), under-escalation rate (false negatives where the prompt fails to escalate a genuinely ambiguous and high-impact input), and decision latency. Set operational thresholds: under-escalation should be near zero for high-risk domains; over-escalation should be monitored as a cost and reviewer-fatigue metric. Log every decision with the full input, output, model version, and timestamp. If the prompt is used in regulated contexts, ensure the handoff packet includes the original user input verbatim and the specific ambiguity spans that triggered the decision. Never allow the model to modify the original user input in the handoff packet—that field should be passed through from the upstream ambiguity detector without model mediation.

Next steps: After deploying the harness, monitor the escalation rate over the first week and compare against your pre-deployment baseline. If over-escalation exceeds 20% of total decisions, review the ambiguity severity grading upstream—the problem may be in the detector, not the decision prompt. If under-escalation occurs at all in high-severity cases, add those examples to your eval set and consider tightening the escalation criteria in the prompt's [CONSTRAINTS] block. Wire the handoff_packet output directly into your human review queue system so reviewers receive consistent, structured context without needing to reconstruct the decision logic themselves.