Human Escalation Event Logging Prompt Template

This prompt is designed for AI product teams who need to produce a structured, auditable record every time an assistant escalates an interaction to a human reviewer. The core job-to-be-done is to capture the 'why' and 'what now' of an escalation in a machine-readable format, ensuring that the handoff is complete, the risk is assessed, and the decision is traceable. The ideal user is an AI engineer or platform developer embedding this prompt into a customer support, clinical review, or high-stakes workflow where a human-in-the-loop is a non-negotiable safety and compliance requirement.

Use this prompt when the cost of a missed escalation is high—such as in regulated industries, financial transactions, or safety-critical applications. It is not a general-purpose triage prompt. Do not use it for simple routing decisions that don't require a formal audit trail, or for low-risk scenarios where a basic status code would suffice. The prompt requires a rich input context: the full conversation history, the specific system policy that triggered the escalation, and the assistant's own internal reasoning. Without this context, the generated log will be hollow and unauditable. The output is a strict JSON object, not a conversational summary, and must be validated against a defined schema before being written to your system of record.

Before implementing this prompt, ensure your application layer can provide the required [CONVERSATION_HISTORY], [TRIGGER_POLICY], and [ASSISTANT_REASONING] inputs. The prompt's value is in its strict structure; a human reviewer should be able to read the generated log and immediately understand the user's need, the risk, and the exact point of handoff without re-reading the entire transcript. The next step is to integrate this prompt into your escalation pipeline and pair it with the eval checks described in the full playbook to prevent incomplete handoffs from reaching a human queue.

The following prompt template is designed to be embedded into a system-level instruction set for an AI assistant operating in a high-stakes environment, such as customer support, healthcare triage, or financial review. Its job is to ensure that every time the assistant escalates to a human operator, a complete, structured, and auditable record is generated. This record must capture not just the fact of escalation, but the trigger condition, the assistant's risk assessment, a concise context summary, and the exact state being handed off. The template uses square-bracket placeholders so you can adapt it to your specific risk taxonomy, escalation triggers, and output schema without rewriting the core instruction.

textCopy
## Human Escalation Event Logging

When you determine that a request or conversation turn requires escalation to a human reviewer, you MUST produce a structured escalation record before ending your turn. Do not ask the user for permission to escalate; produce the record and then clearly communicate the escalation to the user.

### Escalation Triggers
You MUST escalate when any of the following conditions are met:
[ESCALATION_TRIGGERS]

### Required Output Schema
Produce a JSON object conforming to this exact structure:
{
  "escalation_id": "string, unique identifier for this event",
  "timestamp": "string, ISO 8601 UTC",
  "trigger_condition": "string, which escalation trigger was met",
  "risk_level": "string, one of: [RISK_LEVELS]",
  "risk_rationale": "string, brief explanation of why this risk level applies",
  "context_summary": "string, concise summary of the conversation state and user need",
  "handoff_state": {
    "unresolved_questions": ["string"],
    "actions_taken": ["string"],
    "pending_confirmations": ["string"],
    "relevant_policy_refs": ["string"]
  },
  "user_facing_message": "string, what you will say to the user about the escalation"
}

### Constraints
- Do not include personally identifiable information (PII) in the context_summary unless explicitly permitted by [PII_POLICY].
- If multiple triggers are met, list the primary trigger in trigger_condition and note secondary triggers in risk_rationale.
- The handoff_state must be complete enough that a human reviewer can resume without re-asking questions you already asked.
- If you are uncertain whether escalation is required, escalate and set risk_level to the lowest tier in [RISK_LEVELS] with a note in risk_rationale.

To adapt this template, replace each square-bracket placeholder with your domain-specific content. For [ESCALATION_TRIGGERS], provide a bulleted list of concrete, testable conditions such as 'User reports a safety incident,' 'Request involves a refund above $500,' or 'User explicitly demands a human.' For [RISK_LEVELS], define a small ordered set like 'low, medium, high, critical' and document what each tier means in your operational context. For [PII_POLICY], either reference an external policy document or inline a brief rule such as 'Do not log full names, email addresses, or phone numbers.' After adapting, test the prompt against a golden set of conversations that should and should not trigger escalation, and verify that the output JSON parses correctly and that handoff_state contains no unresolved placeholders or empty required fields.

The Human Escalation Event Logging prompt is designed to be called as a synchronous post-processing step immediately after an escalation decision is made by your primary assistant or routing logic. Do not embed this prompt inside the main conversation flow; instead, treat it as a structured logging sidecar that receives the conversation context, the escalation trigger, and the risk assessment as inputs. The prompt should be invoked via an API call to your model provider with response_format set to a JSON schema that matches the escalation record structure you intend to store. For high-risk domains such as healthcare, legal, or finance, this prompt must run even if the primary escalation action fails, ensuring an audit trail exists for every handoff decision.

Validation and retry logic is critical before the escalation record enters your system of record. After the model returns a JSON payload, validate that all required fields are present: escalation_id, trigger_condition, risk_level, context_summary, handoff_state, and timestamp. If any field is missing or risk_level is not one of your defined enum values (low, medium, high, critical), reject the output and retry with the same prompt, appending the validation error message to the [CONSTRAINTS] placeholder. Implement a maximum of 2 retries; if validation still fails, log the raw model output to a dead-letter queue and alert the on-call engineering channel. For handoff_state, verify that it contains the required sub-fields: assigned_queue, priority, context_package, and human_readable_summary. Missing sub-fields indicate an incomplete handoff that could delay human response time.

Model choice and tool integration should favor models with strong structured output support and low latency, since escalation logging is a blocking step in the handoff pipeline. Use gpt-4o or claude-3-5-sonnet with strict JSON mode enabled. If your escalation workflow includes tool calls (e.g., creating a ticket in Jira, paging an on-call engineer via PagerDuty), the escalation record generated by this prompt should be passed as the payload to those tools. Store the validated escalation record in your observability database with a unique correlation ID that links the escalation event to the originating conversation, the assistant's decision trace, and any subsequent human actions. This correlation ID is essential for audit reviews and policy compliance checks.

Human review gates should be configured based on the risk_level field. For critical escalations, route the escalation record to a dedicated review queue and require human acknowledgment within a defined SLA (e.g., 5 minutes). For high escalations, surface the record in a dashboard with the context_summary visible to on-call staff. For medium and low escalations, the record can be logged for audit purposes without immediate human notification. Implement a periodic audit job that samples escalation records and compares them against the original conversation transcripts to verify that the escalation trigger was correctly identified and that no escalation events were missed. This audit job should run daily in production and flag discrepancies for manual review.

What to avoid: Do not call this prompt asynchronously without a timeout; if the model call hangs, the escalation record will be lost. Do not skip validation and write raw model output directly to your audit store, as malformed records will break downstream reporting and compliance reviews. Do not use this prompt to make the escalation decision itself—it is a documentation tool, not a decision engine. The escalation decision must be made by your primary assistant or routing logic before this prompt is invoked. Finally, ensure that the context_summary field does not contain raw PII or sensitive data unless your logging infrastructure is explicitly authorized to store it; scrub or tokenize sensitive fields before writing the escalation record to persistent storage.