Human-in-the-Loop Handoff Policy Prompt

This prompt is for AI product teams building high-stakes workflows where autonomous action carries unacceptable risk. Use it when you need an explicit, testable escalation policy that defines exactly when the assistant must stop, request human review, or hand off entirely. The ideal user is an engineering lead or product manager who needs to encode a consistent, auditable handoff policy into a system prompt or use it as a reference for implementing application-layer escalation logic. This is not a prompt for casual chatbots or low-risk content generation. It belongs in regulated domains, financial operations, healthcare triage, legal intake, security alert review, and any workflow where a wrong autonomous decision creates liability, safety risk, or compliance exposure.

Before using this prompt, you must have a clear map of your risk taxonomy. You need to know which action categories (e.g., financial_transfer, clinical_assertion, access_control_change) require human approval, what confidence thresholds trigger escalation, and what context must be preserved in the handoff payload. The prompt template forces you to make these decisions explicit as structured conditions, not vague guidelines. If your team cannot yet define these thresholds, start with a risk assessment workshop before attempting to generate the policy. The output is a structured policy document you inject into your system prompt or use as a reference for implementing application-layer escalation logic.

Do not use this prompt when the cost of a wrong answer is low, when the workflow is purely informational, or when you are building a prototype without real users. Over-escalation in low-risk contexts erodes user trust and creates operational bottlenecks. If you need a general safety refusal policy without structured handoff logic, use the Refusal Policy Injection Prompt instead. After generating the policy, the next step is to wire it into your application harness with validation checks, logging, and a human review queue. The Implementation Harness section of this playbook covers that integration path.

The following prompt template encodes a complete Human-in-the-Loop (HITL) handoff policy. It defines trigger conditions, the required handoff format, and rules for preserving context during escalation. This template is designed to be injected into your system instructions or policy generation workflow. Every square-bracket placeholder must be replaced with your domain-specific values before deployment. The policy is structured to be testable: each trigger condition maps to a specific, observable behavior that can be validated in an eval harness.

textCopy
You are an AI assistant operating under a strict Human-in-the-Loop (HITL) escalation policy. Your primary directive is to complete tasks autonomously within defined boundaries and to escalate to a human reviewer immediately when any trigger condition is met.

## Escalation Trigger Conditions
You MUST escalate to a human reviewer via the handoff format below when ANY of the following are true:

1.  **Risk Threshold Exceeded:** The user's request or the required action falls into one of these high-risk categories: [HIGH_RISK_CATEGORIES].
2.  **Low Confidence:** Your internal confidence score for the core action or answer is below [CONFIDENCE_THRESHOLD] (e.g., 0.85).
3.  **Domain Constraint Violation:** The request requires actions explicitly prohibited in [DOMAIN_CONSTRAINTS_DOCUMENT].
4.  **Irreversible Action:** The request involves an irreversible action such as [IRREVERSIBLE_ACTION_EXAMPLES].
5.  **Ambiguous Request After [N] Clarification Turns:** The user's intent remains unclear after [N] attempts to clarify.

## Handoff Format
When escalating, you MUST stop all autonomous action and output the following structured handoff object. Do not include any other text.

```json
{
  "escalation_triggered": true,
  "trigger_reason": "[TRIGGER_CONDITION_THAT_WAS_MET]",
  "user_intent_summary": "[ONE-SENTENCE_SUMMARY_OF_USER_GOAL]",
  "context_preservation": {
    "conversation_id": "[CONVERSATION_ID]",
    "last_user_message": "[LAST_USER_MESSAGE]",
    "relevant_history": "[SUMMARY_OF_LAST_N_TURNS]",
    "collected_data": { "[KEY]": "[VALUE]" }
  },
  "recommended_human_action": "[CLEAR_NEXT_STEP_FOR_THE_REVIEWER]"
}

Context Preservation Rules

• Before escalating, compile a concise summary of the last [N] conversation turns.
• Include all data points you have collected from the user that are necessary to complete the task.
• Do not ask the user to repeat information they have already provided.

False Escalation Prevention

• Do NOT escalate for simple informational queries about [SAFE_TOPIC_EXAMPLES].
• Do NOT escalate if you can confidently and safely complete the task within the defined boundaries.
• If you are uncertain whether a trigger condition is met, escalate. It is safer to escalate a borderline case than to proceed incorrectly.

To adapt this template, start by defining your [HIGH_RISK_CATEGORIES] with precision. Vague categories like "financial advice" will cause false escalations; instead, use specific, testable definitions such as "recommending a specific securities trade" or "calculating tax liability for a non-standard deduction." Next, calibrate the [CONFIDENCE_THRESHOLD] by running a golden dataset of borderline cases through the prompt and comparing the escalation rate against human reviewer expectations. The handoff format is designed to be machine-parsable by an upstream orchestration layer, so ensure the JSON schema is enforced with a strict validator in your application code. Finally, the false escalation prevention rules are critical for user experience; regularly review production logs to identify and add new [SAFE_TOPIC_EXAMPLES] that are being incorrectly escalated.

Integrating the Human-in-the-Loop Handoff Policy Prompt into a production system requires treating the prompt's output as a structured decision signal, not just text. The prompt is designed to produce a JSON object containing an escalation_decision, a confidence_score, a risk_level, and a handoff_payload. Your application must parse this output, validate its schema, and route the conversation accordingly. The primary integration points are: (1) a pre-processing step that assembles the user input, conversation history, and domain constraints into the prompt's [CONTEXT] and [DOMAIN_CONSTRAINTS] placeholders; (2) a post-processing step that validates the JSON output and enforces the escalation decision; and (3) an observability layer that logs every decision for audit and policy tuning.

Start by implementing a strict JSON schema validator for the model's response. The expected schema includes escalation_decision (enum: ESCALATE, CONTINUE, CLARIFY), confidence_score (float 0.0-1.0), risk_level (enum: LOW, MEDIUM, HIGH, CRITICAL), and handoff_payload (object containing reason, summary, context_snapshot). If the model returns malformed JSON or missing fields, do not silently default to CONTINUE. Instead, implement a retry loop with a maximum of two additional attempts, each time feeding the raw output and a specific error message back into the model using a repair prompt. If all retries fail, the system must default to ESCALATE with a CRITICAL risk level—this is the fail-safe posture for high-stakes workflows. Log every validation failure as a handoff_policy_parse_error event for later analysis.

The escalation decision must be enforced at the application layer, not just trusted from the prompt. When the decision is ESCALATE, your system should immediately pause the AI's autonomous flow, serialize the handoff_payload into your internal ticketing or review queue, and notify the designated human reviewer. The context_snapshot within the payload should contain the last N messages, relevant user metadata, and the specific trigger condition that caused the escalation. For CLARIFY decisions, route the model's clarifying question back to the user interface and await a response before re-invoking the main workflow. For CONTINUE decisions, always log the decision alongside the confidence_score and risk_level for post-hoc review. Implement a sampling strategy where a configurable percentage of CONTINUE decisions (e.g., 5% of MEDIUM risk, 1% of LOW risk) are shadow-escalated to a review queue for human quality assurance without blocking the user.

Model choice and latency constraints are critical here. This prompt is a classification and policy-enforcement task, so prioritize models with strong instruction-following and low-latency JSON output, such as GPT-4o-mini or Claude 3.5 Haiku, for real-time chat. If using a slower, more capable model for complex risk assessment, implement a two-stage pipeline: a fast classifier for obvious LOW risk cases and a slower, more thorough model for ambiguous or MEDIUM risk cases. Set a strict timeout (e.g., 2 seconds) for the escalation check. If the model does not respond within the timeout, the system must escalate to a human as a safety net. Never allow a timeout to silently default to autonomous continuation in a high-stakes domain.

Finally, build a monitoring dashboard around the handoff_policy_decision event stream. Track the rate of ESCALATE, CONTINUE, and CLARIFY decisions over time, segmented by risk_level. Monitor for sudden spikes in escalation rates, which could indicate a prompt regression, a model behavior change, or a real-world event affecting user inputs. Set alerts for parse failure rates exceeding 1% and for any CRITICAL risk decision. Use this data to regularly review and tune the [RISK_THRESHOLDS] and [DOMAIN_CONSTRAINTS] you inject into the prompt. The goal is to minimize false escalations that burden your human review team while ensuring no genuinely high-risk interaction proceeds unattended. Start with conservative thresholds and gradually relax them as your eval dataset and production metrics demonstrate reliability.