Escalation Reason Documentation Prompt

This prompt is designed for audit and governance teams who need to transform a low-confidence model output or an automated escalation trigger into a structured, human-readable record. The core job-to-be-done is generating a defensible audit trail that captures why an AI system handed off control, what evidence informed that decision, and what a human reviewer should do next. The ideal user is an AI platform engineer or compliance officer integrating this prompt into a production harness where every escalation must be explainable to internal and external reviewers.

Use this prompt when your system has already made a binary escalate-or-proceed decision, and you now need to document the rationale. The required inputs are the original user query, the model's draft response, the confidence score that triggered the escalation, and the specific policy or threshold that was breached. Do not use this prompt to make the escalation decision itself—it is a documentation step, not a decision gate. It is also inappropriate for real-time user-facing communication; the output is an internal record, not a customer message.

The prompt is most valuable in regulated or high-stakes domains where auditors may later ask, 'Why did the AI escalate this case?' It forces the model to cite the exact trigger condition, decompose the confidence data into its constituent signals, and recommend a concrete follow-up action. Before deploying, ensure you have a validation step that checks the generated record for completeness: a missing trigger condition or a vague follow-up recommendation should fail the record and trigger a retry. Always log the raw escalation payload alongside the generated documentation so reviewers can trace the record back to its source data.

This template produces a structured escalation record that captures the trigger condition, confidence data, decision rationale, and recommended follow-up actions. It is designed for audit and governance teams who need consistent, traceable documentation when an AI system escalates a task to human review. The prompt forces explicit reasoning about why escalation occurred, what evidence supported the decision, and what the reviewer should examine first. Use this template when your escalation workflow requires a permanent record that downstream auditors, compliance reviewers, or operations analysts can inspect without reconstructing the original context.

textCopy
You are an escalation documentation specialist. Your task is to produce a structured escalation record from the provided inputs. The record must be complete, clear, and suitable for audit review.

## INPUTS
- Original Request: [ORIGINAL_REQUEST]
- Model Output or Draft: [MODEL_OUTPUT]
- Escalation Trigger: [TRIGGER_CONDITION]
- Confidence Data: [CONFIDENCE_DATA]
- Retry History: [RETRY_HISTORY]
- Applicable Policy References: [POLICY_REFERENCES]
- Risk Level: [RISK_LEVEL]

## OUTPUT SCHEMA
Produce a JSON object with the following fields:
{
  "escalation_id": "string (unique identifier)",
  "timestamp": "string (ISO 8601)",
  "trigger": {
    "condition": "string (the specific condition that triggered escalation)",
    "threshold_breached": "string (which threshold or rule was violated)",
    "severity": "string (low | medium | high | critical)"
  },
  "confidence_assessment": {
    "overall_score": "number (0.0 to 1.0)",
    "breakdown": [
      {
        "component": "string (what was assessed)",
        "score": "number (0.0 to 1.0)",
        "rationale": "string (why this score was assigned)"
      }
    ],
    "key_uncertainties": ["string (specific areas of low confidence)"]
  },
  "decision_rationale": {
    "summary": "string (concise explanation of why escalation was chosen)",
    "alternatives_considered": ["string (other paths considered and why rejected)"],
    "evidence_cited": ["string (specific evidence supporting the decision)"]
  },
  "recommended_follow_up": {
    "priority": "string (immediate | within_1_hour | within_24_hours | routine)",
    "reviewer_instructions": "string (specific guidance for the human reviewer)",
    "required_actions": ["string (concrete actions the reviewer must take)"],
    "deadline": "string (ISO 8601 or null if none)"
  },
  "audit_trail": {
    "retry_count": "number (total retry attempts before escalation)",
    "last_error": "string (final error or condition before escalation)",
    "policy_clauses_invoked": ["string (specific policy sections that apply)"]
  }
}

## CONSTRAINTS
- Every field marked "string" must be non-empty unless explicitly nullable.
- Confidence scores must be justified with specific evidence, not generic statements.
- The decision_rationale.summary must explain why escalation was necessary, not just that it occurred.
- If retry history is empty, set retry_count to 0 and last_error to "N/A".
- Do not fabricate evidence. If a field lacks supporting data, mark it as "insufficient_data" and note the gap in key_uncertainties.
- The reviewer_instructions must be actionable and specific, not vague guidance like "review the output."

## EXAMPLES
[EXAMPLES]

## OUTPUT
Produce only the JSON object. No preamble, no commentary.

Adapt this template by replacing each square-bracket placeholder with data from your escalation pipeline. The [CONFIDENCE_DATA] placeholder should receive structured confidence information—not a raw log line—so the model can populate the confidence_assessment breakdown accurately. If your system tracks confidence at multiple granularities (token-level, span-level, claim-level), include all of them and let the model select the most relevant for the record. The [EXAMPLES] placeholder is critical for consistency: provide at least two few-shot examples showing correct escalation records for different trigger conditions and risk levels. Without examples, the model may produce inconsistent severity classifications or vague reviewer instructions. After generating the record, validate the JSON schema and check that all required fields are present and non-empty where required. For high-risk domains, route the completed record through a human review step before filing it in the audit system.

The Escalation Reason Documentation Prompt is designed to be called at the moment an escalation decision is made, not after the fact. Wire it into your application's escalation handler so that the structured record is generated synchronously with the handoff event. The prompt expects the original trigger condition, confidence data, decision rationale, and any relevant context from the failed interaction. Treat the output as an auditable artifact: store it immutably alongside the escalation event in your logging or governance database, and never allow the model to retroactively edit a previously generated record.

Implement a strict validation layer before accepting the model's output. The generated escalation record must contain all required fields—trigger condition, confidence score, decision rationale, and recommended follow-up—and each field must be non-empty and match its expected type. Use a JSON Schema validator in your application code to reject malformed outputs and trigger a single retry with the same input plus the validation error message appended as a [CONSTRAINTS] amendment. If the retry also fails validation, log the raw output and escalate to a human reviewer via a dead-letter queue rather than entering an infinite retry loop. For high-risk domains, add a mandatory human approval step: the record is held in a pending_review state until an authorized operator confirms or amends the rationale and follow-up actions.

Model choice matters for this workflow. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or an equivalent. Avoid smaller or older models that may drop required fields or hallucinate confidence values not present in the input. Set temperature=0 to maximize determinism and audit-trail consistency. If your governance requirements demand full reproducibility, log the complete model request—including the prompt template, input variables, and model version—alongside the generated record. This creates a verifiable chain from trigger event to documented decision. Do not use this prompt for real-time user-facing explanations; it is an internal governance artifact, and its language should be precise and machine-readable rather than conversational.