Escalation Decision Trace Prompt

This prompt is designed for support operations teams, compliance officers, and QA engineers who need a traceable, structured record of why an AI-driven escalation happened. The core job-to-be-done is post-hoc audit, not real-time routing. Use it when you have a complete conversation segment that ends with a confirmed escalation action, and you need to produce a single, defensible document that links the escalation trigger to specific policy conditions, identifies the routing target, and inventories the context that was handed off. The ideal user is someone responsible for proving that the escalation system worked as designed—or for finding the precise point where it didn't.

To use this prompt effectively, you must provide three concrete inputs: the full conversation transcript segment ending in escalation, the exact escalation action taken (e.g., 'routed to Tier 2 billing'), and the governing escalation policy document. The prompt does not decide whether to escalate; it assumes the decision has already been made and focuses entirely on reconstructing the decision trace. Do not use this prompt for real-time escalation routing, for conversations that did not result in escalation, or for scenarios where the escalation policy is unavailable. Without the policy document, the trace cannot validate whether the detected conditions match the approved triggers, making the output speculative rather than auditable.

The output is a structured record containing the escalation trigger, the detected conditions with policy citations, the escalation target, and a complete handoff context inventory. This record should be stored alongside the conversation for compliance review, used in QA sampling to verify escalation accuracy, or fed into a downstream analytics system to track escalation patterns. Before relying on this prompt in production, validate its outputs against a golden set of manually traced escalations to ensure it correctly identifies triggers and does not hallucinate policy citations. The next step after generating a trace is to route it for human review if any field is flagged as low-confidence or if the detected conditions do not cleanly map to a policy clause.

The following prompt template is designed to be dropped directly into your AI orchestration layer. It instructs the model to analyze a conversation segment that ends in an escalation and produce a single, structured JSON object with no additional commentary. This output serves as an auditable record for support operations teams, capturing why the escalation happened, what conditions were met, where the conversation was routed, and what context was handed off. Before each call, replace every square-bracket placeholder with live data from your application's state.

textCopy
You are an audit system for a customer support platform. Your task is to analyze a conversation segment that ends with an escalation action. Produce a single JSON object that traces the escalation decision. Do not include any text outside the JSON object.

## INPUT
[CONVERSATION_TRANSCRIPT]

## ESCALATION POLICIES
[ESCALATION_POLICIES]

## OUTPUT SCHEMA
{
  "escalation_trigger": {
    "turn_id": "string (the turn where escalation was initiated)",
    "trigger_type": "enum [explicit_user_request, policy_violation, sentiment_threshold, capability_gap, auth_required, risk_threshold, other]",
    "trigger_summary": "string (a concise, factual description of the triggering event)"
  },
  "detected_conditions": [
    {
      "condition_name": "string (the name of the policy condition or rule that was met)",
      "evidence": "string (the exact quote or turn reference that satisfied the condition)",
      "confidence": "number (0.0 to 1.0)"
    }
  ],
  "escalation_target": {
    "target_queue_or_team": "string",
    "target_tier": "enum [tier_1, tier_2, tier_3, specialist, manager, external]",
    "routing_reason": "string (why this specific target was chosen over alternatives)"
  },
  "handoff_context": {
    "summary_for_agent": "string (a concise summary of the issue and what has been tried)",
    "customer_sentiment": "enum [frustrated, confused, neutral, satisfied, urgent]",
    "unresolved_questions": ["string"],
    "actions_already_taken": ["string"],
    "relevant_policy_citations": ["string"]
  },
  "risk_assessment": {
    "risk_level": "enum [low, medium, high, critical]",
    "risk_factors": ["string"],
    "requires_supervisor_review": "boolean"
  }
}

## CONSTRAINTS
- Do not invent conditions or evidence not present in the transcript or policies.
- If a condition is ambiguous, set confidence below 0.7 and note the ambiguity in the evidence field.
- The handoff summary must be self-contained and actionable for a human agent with no prior context.
- If the escalation target is unclear from the policies, set the target to "unknown" and flag it in risk_factors.

To adapt this template for your environment, start by mapping your internal escalation policies into the [ESCALATION_POLICIES] placeholder. This should be a structured list of rules, such as "Escalate to Tier 2 Billing if the user mentions 'fraud' or 'unauthorized charge'." The [CONVERSATION_TRANSCRIPT] should be the full text of the session, with turns clearly labeled by role and turn ID. The output schema is intentionally strict; you should validate the returned JSON against this schema in your application layer before writing it to your audit log. If the model returns a target_queue_or_team of "unknown" or a risk_level of "high" or "critical," route the record for immediate human review rather than relying solely on the automated trace.

The Escalation Decision Trace Prompt is designed to sit inside a post-escalation audit workflow, not a real-time escalation path. After a conversation is escalated—whether by a human agent, an automated routing rule, or an AI triage step—this prompt reconstructs the decision trace for review. The harness should invoke the prompt asynchronously, passing the full conversation segment ending in the escalation event, along with the escalation target (team, queue, or system) and any policy documents that define escalation criteria. The output is a structured JSON record that becomes part of the audit trail, not a live routing decision.

Wire the prompt into a pipeline that performs pre-validation before calling the model: confirm the conversation segment contains at least one user turn and one escalation action, verify the escalation target field is non-empty, and check that policy documents are accessible and not truncated. After the model returns, run post-validation on the output JSON: ensure all required fields (escalation_trigger, detected_conditions, escalation_target, handoff_context, missing_context_flags) are present and non-null, validate that detected_conditions is a non-empty array with each entry containing a condition and evidence_turn_index, and confirm handoff_context includes at minimum a summary, unresolved_items, and customer_sentiment block. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_OUTPUT_ERRORS]. After two failures, route to a human review queue with the raw conversation and partial output attached.

For model choice, use a model with strong structured output adherence and long-context handling—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Enable structured output mode (JSON mode with a supplied schema) rather than relying on prompt-level format instructions alone. Log every invocation: the prompt version, model ID, input token count, output token count, validation pass/fail, retry count, and the final output or escalation to human review. Store the validated trace alongside the conversation record in your audit database. Do not use this prompt to make real-time escalation decisions—it is an audit artifact generator, and its output should be reviewed, not executed. For high-risk domains (finance, healthcare, legal), require human sign-off on every trace before it is considered final, and never expose the raw model output to end users without review.