Human Review Trigger Prompt for Ambiguous Inputs

This prompt is for operations engineers and platform builders who need a deterministic, auditable decision point before routing an ambiguous user input to a human reviewer. It sits downstream of a classification step that has already flagged the input as low-confidence, multi-intent, or underspecified. The prompt's job is not to reclassify the input. Its job is to decide whether the ambiguity is severe enough to justify human intervention, and if so, to produce a structured handoff packet that a reviewer can act on without redoing the triage work. Use this prompt when your system already has a confidence score, an ambiguity flag, or a set of competing classification hypotheses.

Do not use this prompt as a standalone classifier or as a substitute for a safety policy engine. It is not designed to detect policy violations, abusive content, or out-of-scope requests; those should be handled by dedicated upstream guards. The prompt assumes the input has already passed safety and scope checks and that the only remaining question is whether the system's uncertainty warrants a human's attention. Wiring this prompt into a path that receives raw, unclassified inputs will produce unreliable escalation decisions because the prompt relies on pre-computed ambiguity signals to make its judgment.

Before integrating this prompt, ensure your upstream classification pipeline outputs at minimum a confidence score and an ambiguity flag. For best results, also provide the top competing classification hypotheses and the specific spans or features that caused the uncertainty. The prompt's value is in standardizing the escalation decision and packaging the evidence so a human reviewer can immediately understand why the system was uncertain and what needs to be resolved. The next section provides the copy-ready template you can adapt to your specific taxonomy and escalation policies.

This prompt template is designed to be placed in your system instructions or sent as a user message when your primary classification pipeline returns a low-confidence or ambiguous result. It acts as a gate before automated processing continues, forcing an explicit decision about human escalation. The model is instructed to analyze the original input, the failed classification attempts, and the specific points of uncertainty, then produce a structured decision and, if escalation is triggered, a complete handoff packet for a human reviewer.

codeCopy
You are an escalation decision engine. Your task is to analyze an ambiguous user input and the failed classification attempts to determine if human review is required.

## INPUT DATA
- Original User Input: [USER_INPUT]
- Classification Attempts: [CLASSIFICATION_ATTEMPTS]
- Uncertainty Points: [UNCERTAINTY_POINTS]
- Current Confidence Score: [CONFIDENCE_SCORE]
- Risk Level of Domain: [RISK_LEVEL]

## DECISION CRITERIA
1.  **Escalate to Human** if:
    - The risk level is "high" and confidence is below [HIGH_RISK_THRESHOLD].
    - The input contains conflicting signals that cannot be resolved without domain expertise.
    - The cost of a misclassification (e.g., financial, safety, legal) is higher than the cost of a human review.
    - The input is a novel edge case not covered by existing automated workflows.
2.  **Do Not Escalate** if:
    - The ambiguity is minor and can be resolved with a single, safe clarifying question.
    - The input can be safely routed to a general-purpose fallback queue with low risk.
    - The confidence score is above the threshold for the given risk level.

## REQUIRED OUTPUT SCHEMA
{
  "decision": "escalate" | "do_not_escalate",
  "reasoning": "A concise explanation for the decision, referencing the specific criteria met.",
  "handoff_packet": {
    "original_input": "[The original user input]",
    "classification_summary": "A summary of what the classifiers attempted and their outputs.",
    "key_uncertainties": ["A list of the specific points causing ambiguity."],
    "suggested_review_questions": ["Questions a human reviewer should investigate first."],
    "priority": "high" | "medium" | "low"
  }
}

## CONSTRAINTS
- If the decision is "do_not_escalate", set the "handoff_packet" field to null.
- Do not invent information not present in the input data.
- Prioritize precision over recall; it is better to escalate a borderline case than to miss a critical one.

To adapt this template, replace the square-bracket placeholders with data from your application's classification pipeline. [USER_INPUT] is the raw text from the end user. [CLASSIFICATION_ATTEMPTS] should be a structured log of the top-k intents and their scores from your primary classifier. [UNCERTAINTY_POINTS] is a list of the specific spans or conflicting signals identified by an ambiguity detection prompt. [RISK_LEVEL] and [HIGH_RISK_THRESHOLD] must be defined by your application's policy; a financial transaction system will have a much lower escalation threshold than a content tagging system. After the model responds, validate the JSON output against the schema before routing the handoff packet to your human review queue or allowing the automated fallback to proceed. Log every decision to build an audit trail for tuning your escalation thresholds over time.

This prompt is not a standalone classifier; it is a decision gate that sits between your ambiguity detection system and your human review queue. The implementation harness must treat the prompt's output as a structured control signal, not a suggestion. The primary integration points are: (1) assembling the handoff packet from upstream classification attempts, (2) enforcing the trigger decision with a hard routing rule, (3) logging every decision for audit and calibration, and (4) handling model failures without silently dropping ambiguous inputs into automated processing.

Pre-processing requires gathering three inputs before calling the prompt: the original user input, the full classification attempt history (model, labels, confidence scores, and timestamps), and the specific ambiguity points detected (spans, conflicting signals, missing information). Package these into a structured context object rather than concatenating raw text. Post-processing must validate the output schema strictly: confirm that trigger_human_review is a boolean, that handoff_packet contains all required fields (original_input, classification_attempts, uncertainty_points, recommended_reviewer_role), and that trigger_reason is non-empty when the trigger is true. If validation fails, do not default to automated processing—escalate to a human operator with a malformed-output error. Retry logic should be limited: retry once on schema validation failure with a stricter output constraint instruction, but never retry on a valid trigger_human_review: false decision. Retrying a negative decision introduces inconsistency and undermines the audit trail.

Routing integration must be deterministic. When trigger_human_review is true, the application must place the handoff packet into the designated review queue and block any automated downstream processing for that input. When false, route to the standard fallback path (clarification question, general queue, or rejection). Logging requirements are critical for governance: log the full prompt input, raw model output, validated decision, timestamp, model version, and the eventual human reviewer disposition if triggered. This creates a closed loop for evaluating whether the trigger prompt is making correct escalation decisions over time. Model choice matters: use a model with strong instruction-following and structured output capability (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that may produce inconsistent boolean outputs or hallucinate handoff packet fields. For high-throughput systems, consider batching ambiguity assessments and running this prompt only on inputs that cross a severity threshold, reducing cost and latency. Human-in-the-loop integration should include a feedback mechanism: when a reviewer resolves a case, capture whether the escalation was appropriate. Feed this signal back into your eval suite to detect over-escalation or under-escalation drift over time.