Escalation Reason Explanation Prompt

This prompt is for AI product teams that need to generate clear, auditable explanations every time an automated system escalates a task to a human reviewer. It transforms raw decision metadata—risk scores, policy triggers, context summaries—into a structured explanation that a user, auditor, or downstream system can consume. The core job-to-be-done is communication: turning machine-readable escalation signals into a human-readable 'why' that holds up under review. The ideal user is an engineering lead or AI architect integrating this prompt into a production escalation pipeline where consistency, traceability, and audit readiness are non-negotiable.

Use this prompt when your escalation policy is already defined and you need a consistent way to communicate the reason behind each escalation. Required context includes the escalation trigger (which policy rule fired), the risk score and its contributing factors, the relevant input or transaction summary, and any tool outputs or evidence that informed the decision. The prompt expects these inputs as structured data—do not feed it raw logs and expect it to infer the escalation logic. It is designed to format and explain decisions that have already been made, not to make new ones. Pair it with the Escalation Threshold Definition Prompt Template for policy creation; this prompt handles the downstream explanation layer.

Do not use this prompt to define the escalation policy itself, to calculate risk scores, or to decide whether escalation should occur. It is an explanation generator, not a decision engine. If you need the model to determine whether to escalate, use the Escalation Threshold Definition Prompt or Risk Score Calculation Prompt instead. Also avoid this prompt when the explanation must reference confidential data that cannot appear in audit trails—redact sensitive fields before they reach the prompt. For high-stakes domains such as healthcare, finance, or legal compliance, always route the generated explanation through a human review step before it becomes part of the permanent record. The next section provides the copy-ready template you can adapt to your escalation taxonomy.

This template is designed to be the core instruction set for your AI system when it needs to explain why an escalation occurred. It forces the model to ground its explanation in the specific decision metadata, policy references, and context you provide, rather than generating a generic or hallucinated justification. The output is structured for both end-user readability and downstream audit logging. Use this prompt as a starting point; you will need to wire it into your application's escalation handler, which should supply the required input variables.

Below is the copy-ready prompt template. It uses square-bracket placeholders for all dynamic inputs. The [OUTPUT_SCHEMA] placeholder is critical—replace it with your exact required JSON schema or a strict format description to ensure the output is machine-readable for your audit system. The [CONSTRAINTS] section is where you enforce tone, audience (e.g., 'for a non-technical end-user' vs. 'for a compliance auditor'), and length limits. The [EXAMPLES] section should be populated with 1-2 few-shot examples of good explanations for your specific domain to dramatically improve consistency.

textCopy
You are an explainability assistant for an automated decision system. Your task is to generate a clear, evidence-backed explanation for an escalation decision.

## Input Data
- **Decision Metadata:** [DECISION_METADATA]
- **Policy References:** [POLICY_REFERENCES]
- **Context of the Interaction:** [INTERACTION_CONTEXT]
- **Target Audience:** [TARGET_AUDIENCE]

## Task
Generate a human-readable explanation for why the escalation occurred. The explanation must be:
1.  **Grounded:** Directly reference the provided Decision Metadata and Policy References. Do not invent reasons.
2.  **Structured:** Follow the output schema exactly.
3.  **Audience-Appropriate:** Use language and detail suitable for the Target Audience.

## Constraints
[CONSTRAINTS]

## Examples of Good Explanations
[EXAMPLES]

## Output Schema
Generate your response in the following JSON format. Do not include any text outside the JSON object.
[OUTPUT_SCHEMA]

To adapt this template, start by defining your [OUTPUT_SCHEMA]. A robust schema should include fields like escalation_id, summary (a one-sentence reason), detailed_explanation (the full narrative), policy_ids_triggered (an array of IDs from your policy engine), and evidence_snippets (direct quotes from the [INTERACTION_CONTEXT]). Next, harden the [CONSTRAINTS] with rules like 'Do not speculate about user intent' or 'If multiple policies are triggered, list all of them.' Finally, implement a validation step in your application harness that checks the generated JSON against your schema and verifies that all cited policy_ids_triggered actually exist in the provided [POLICY_REFERENCES]. For high-stakes domains like finance or healthcare, always route the generated explanation to a human review queue before it is shown to the end user or logged as a permanent record.

This prompt is designed to sit between an escalation decision engine and the downstream systems that consume the explanation—audit logs, user-facing notifications, internal review queues, and compliance dashboards. The application layer should call this prompt only after an escalation decision has already been made by a separate policy evaluation step. Do not use this prompt to make the escalation decision itself; its job is to explain a decision that has already occurred. The required inputs are the escalation trigger event, the policy rule that was violated or matched, the risk score and contributing factors, and any relevant context from the conversation or transaction. Wire these inputs into the [ESCALATION_DECISION], [POLICY_REFERENCE], [RISK_FACTORS], and [CONTEXT] placeholders before sending the prompt to the model.

Validation and retry logic: Parse the model's JSON output immediately and validate it against a strict schema before any downstream consumption. Required fields include explanation_summary, policy_reference, decision_factors (array of objects with factor, weight, and evidence), and escalation_path. If the output fails schema validation, retry once with the same inputs plus the validation error message appended to the prompt. If the second attempt also fails, log the failure, flag the escalation for human review, and fall back to a templated explanation using the structured escalation decision data you already have. Never silently accept malformed explanations in production—an unparseable explanation is worse than no explanation because it breaks audit trails and user trust.

Model choice and latency considerations: This prompt works well with capable instruction-following models (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro). For high-throughput escalation pipelines where latency is critical, consider using a faster model (GPT-4o-mini, Claude 3 Haiku) with a stricter output schema and a post-generation validation layer. If you observe explanation quality degradation with smaller models, add a confidence gate: if the model's self-reported confidence in the explanation is below your threshold, route to a larger model or flag for human review. Logging and audit requirements: Log every explanation generation attempt—successful or failed—with the full prompt, model response, validation result, and any retry attempts. This log becomes your audit evidence for why a particular escalation was explained in a particular way. For regulated domains, ensure the log includes the model version, timestamp, and a hash of the input context for reproducibility.

Human review integration: For high-severity escalations (risk score above your defined threshold), route the generated explanation to a human reviewer before it reaches the end user or is committed to the audit record. The review interface should show the original escalation decision, the generated explanation, and the policy reference side by side. The reviewer should be able to approve, edit, or reject the explanation. Rejected explanations should trigger a manual write workflow, not another model retry. What to avoid: Do not use this prompt to generate explanations for decisions the model itself made—that creates a circular dependency where the model explains its own reasoning without ground-truth verification. Always separate the decision-making prompt from the explanation-generation prompt. Do not skip validation in production; even well-tested prompts produce malformed JSON under edge-case inputs. Do not expose raw model outputs to end users without review for high-risk escalations.