Escalation Reason Explanation Generation Prompt

This prompt is for platform engineers building the transparency layer between an automated triage system and a human review queue. Its job is to generate a concise, structured explanation of why an item was escalated, not to make the escalation decision itself. Use it when your upstream classifier or risk-scoring prompt has already flagged an item for human review, and you need to produce a handoff payload that lets a reviewer understand the decision, prioritize their work, and act without re-investigating the original signals. The ideal user is an engineer integrating this prompt into a production handoff layer, where the output is consumed by a human-facing review UI or a downstream case management system.

The prompt requires specific upstream context to be useful. You must provide the raw escalation signals (e.g., risk scores, triggered policy flags, sentiment values), the specific criteria that were met, and a summary of the item itself. Without this, the prompt will produce vague, unhelpful explanations that force the reviewer to do the work your classifier already did. The output should be a structured JSON object containing a clear reason summary, the triggered criteria, a severity or priority indicator, and a pointer to the evidence the reviewer should examine first. This structure ensures the explanation is machine-readable for queue prioritization and human-readable for fast comprehension.

Do not use this prompt to make the escalation decision. It assumes the decision is already made and only explains it. Using it as a classifier will produce confident-sounding but ungrounded justifications for decisions it wasn't designed to make. Also, avoid this prompt when the upstream decision is so simple that a one-line reason code is sufficient; this prompt is for multi-factor escalations where the reasoning is non-obvious. Finally, in regulated domains, always include a human review step to validate the generated explanation against the original evidence before it reaches the reviewer, ensuring no hallucinated justifications enter the audit trail.

This prompt template is designed to be the final step in your escalation pipeline, activated immediately after a decision to escalate has been made. Its sole job is to translate the technical signals that triggered the escalation—such as risk scores, policy flags, or confidence thresholds—into a clear, structured summary for a human reviewer. The output is not a decision, but a justification artifact that reduces the reviewer's time-to-comprehension and ensures consistent, auditable handoffs. Copy this template directly into your prompt library and inject the required variables from your upstream routing and risk-scoring systems.

markdownCopy
You are an escalation reasoning engine for an AI operations platform. Your task is to produce a concise, human-readable explanation for why a specific item was escalated for human review. You must not make a new decision or second-guess the escalation. Your only job is to explain the triggering factors clearly.

## Input Data
- **Item ID:** [ITEM_ID]
- **Item Summary:** [ITEM_SUMMARY]
- **Escalation Trigger Signals:** [TRIGGER_SIGNALS]
- **Risk Score:** [RISK_SCORE]
- **Confidence Score:** [CONFIDENCE_SCORE]
- **Applicable Policies:** [POLICIES_TRIGGERED]
- **Reviewer Role:** [REVIEWER_ROLE]

## Output Schema
Produce a JSON object with the following fields:
- `escalation_reason_summary`: A one-sentence summary of the primary reason for escalation.
- `triggered_criteria`: A list of specific criteria or signals that were breached, with a brief explanation for each.
- `reviewer_focus_areas`: A list of 1-3 specific aspects the human reviewer should prioritize.
- `risk_context`: A brief note on the potential impact if this item were handled incorrectly.
- `detail_level`: Must be set to "[DETAIL_LEVEL]" (e.g., "concise" for a first-line reviewer, "comprehensive" for an auditor).

## Constraints
- Do not invent information not present in the input signals.
- Use plain, professional language appropriate for the reviewer role.
- If the escalation was triggered by multiple weak signals, explain their combined effect rather than treating them in isolation.
- If the confidence score is low, explicitly state that uncertainty is a contributing factor.
- Never suggest that the escalation was a mistake or that the item should be re-routed.

To adapt this template, start by mapping your upstream system's output fields to the placeholders. The [TRIGGER_SIGNALS] field should be a structured list of the specific flags, scores, or rules that were breached, not a raw log dump. The [DETAIL_LEVEL] variable should be set dynamically based on the [REVIEWER_ROLE]: a first-line support agent needs a concise summary, while a compliance auditor requires a comprehensive breakdown. After generating the explanation, validate the output against the schema and run an evaluation check to ensure the escalation_reason_summary does not contradict the triggered_criteria. A common failure mode is the model summarizing the item's content instead of the reason for escalation; your eval must explicitly check for this distinction.

The Escalation Reason Explanation Generation Prompt is designed to sit at the boundary between automated classification and human review. It should be invoked immediately after an escalation decision is made by an upstream classifier, router, or risk scorer. The prompt receives the original input, the escalation trigger metadata (which criteria fired, confidence scores, policy flags), and the target reviewer role. Its output is a structured explanation payload that gets attached to the review queue item before a human sees it. This prompt is not a classifier itself—it explains decisions already made. Wiring it incorrectly, such as invoking it without the upstream decision context or using it to make the escalation decision, will produce vague explanations that undermine reviewer trust and slow down triage.

The implementation should wrap the prompt in a function with a strict input schema: original_input (string, required), escalation_triggers (array of objects with criterion, confidence, evidence_excerpt, required), reviewer_role (enum: triage_agent, specialist_reviewer, compliance_officer, team_lead, required), and output_detail_level (enum: concise, standard, comprehensive, default standard). Validate all inputs before model invocation—missing trigger evidence or an unrecognized reviewer role should fail fast with a clear error, not produce a hallucinated explanation. The model call should use a low temperature (0.1–0.3) to keep explanations consistent across repeated invocations. Set a token budget appropriate for your review UI; 300–500 tokens is usually sufficient for a scannable explanation. Implement a retry wrapper with exponential backoff (max 3 attempts) that catches malformed JSON, missing required fields in the output, or empty explanation strings. After successful parsing, run a completeness validator that checks: (1) every escalation trigger in the input is addressed in the explanation, (2) the explanation references specific evidence rather than vague summaries, (3) the detail level matches the requested setting. If validation fails, retry with the validation errors appended to the prompt as correction instructions.

Log every invocation with the input hash, escalation trigger count, reviewer role, output token count, validation pass/fail status, and retry count. Do not log the full original input or explanation content if it contains PII or sensitive data—log hashes or metadata only. For high-risk domains (healthcare, finance, legal), route the generated explanation through a human approval step before it reaches the reviewer queue. This means the explanation itself gets a quick sanity check: does it accurately reflect the escalation criteria? Is it free of hallucinated policy references? A simple thumbs-up/thumbs-down review with a correction field is sufficient. Track approval rates and common correction patterns to improve the prompt over time. Avoid wiring this prompt directly into customer-facing surfaces—the explanation is for internal reviewers, not end users. If you need a customer-facing reason, build a separate prompt with a different tone and detail profile, and never expose internal escalation criteria or confidence scores externally.