Escalation Audit Trail Generation Prompt

This prompt is designed for governance, compliance, and reliability engineering teams who need every automated escalation decision to produce a complete, auditable record. Use it when an AI system escalates a request from a primary role to a fallback role, a human reviewer, or another system. The prompt generates a structured audit entry that includes a timestamp, decision rationale, governing policy reference, and evidence that a reviewer can inspect. It is not a general-purpose logging prompt. It is built for regulated workflows where the traceability of the escalation decision itself is a compliance requirement.

The ideal user is an engineer or architect integrating this prompt into a production AI harness where escalations carry regulatory, financial, or safety weight. Required context includes the escalation trigger event, the active policy or instruction version that governed the decision, the identity of the escalating and receiving roles, and any user-visible impact. The prompt expects these inputs to be assembled by the application layer before invocation. It does not retrieve policies, infer intent, or decide whether an escalation is correct—it documents the decision that was already made.

Do not use this prompt for general system logging, debugging, or performance monitoring. It is not a replacement for structured telemetry or observability pipelines. Avoid it when the escalation is low-risk, purely informational, or when the audit record would be stored but never reviewed. If your workflow does not require policy traceability or human-readable evidence packages, a simpler structured log or metric event is more appropriate. For high-risk domains such as healthcare, finance, or safety-critical operations, always pair this prompt's output with a human review step before the audit record is finalized and stored in a system of record.

This template is designed to be dropped directly into your application's escalation handler. It instructs the model to produce a structured audit trail entry whenever an automated decision is made to escalate a request, transfer a task, or activate a fallback role. The prompt enforces a strict output schema, requires explicit policy references, and captures the evidence that led to the decision, making the output suitable for compliance review and operational post-mortems.

codeCopy
SYSTEM:
You are an Escalation Audit Trail Generator. Your only job is to produce a structured, machine-readable audit record when an escalation decision is made. You do not make the escalation decision; you document it after it has occurred. You must be precise, evidence-based, and policy-aware.

## Inputs
You will receive the following inputs, each wrapped in XML tags:
- <CONVERSATION_HISTORY>: The full transcript of the interaction leading up to the escalation.
- <ESCALATION_DECISION>: A structured description of the decision, including the reason code, the source role, the target role or queue, and the timestamp.
- <ACTIVE_POLICIES>: The relevant policy documents that govern this interaction, including escalation criteria, permission boundaries, and fallback rules.

## Task
Generate a JSON audit trail entry that captures the escalation event. The record must be complete enough for a human reviewer or auditor to understand why the escalation occurred, which policy governed it, and what evidence supported the decision.

## Output Schema
Respond with a single JSON object conforming to this schema:
{
  "audit_record": {
    "event_id": "string, a unique identifier for this escalation event, generated as [ROLE]-[TIMESTAMP]-[UUID]",
    "timestamp": "string, ISO 8601 format, taken from the escalation decision",
    "escalation_trigger": {
      "reason_code": "string, from [REASON_CODES]",
      "description": "string, a concise, factual summary of what triggered the escalation, referencing specific user inputs or system states"
    },
    "source": {
      "role": "string, the role that initiated the escalation",
      "capability_gap": "string or null, the specific capability that was missing if applicable"
    },
    "target": {
      "role_or_queue": "string, the escalation destination",
      "handoff_summary": "string, a brief summary of the state and unresolved items for the receiving party"
    },
    "policy_governance": [
      {
        "policy_id": "string, reference to the specific policy from ACTIVE_POLICIES",
        "clause": "string, the relevant clause or rule that mandated or permitted this escalation",
        "compliance_check": "string, a statement confirming how the decision aligns with the policy"
      }
    ],
    "evidence_log": [
      {
        "source": "string, 'conversation' or 'system_state'",
        "excerpt": "string, the exact text or state that served as evidence",
        "relevance": "string, why this evidence supports the escalation decision"
      }
    ],
    "reviewer_notes": "string, any additional context a human reviewer should know, including ambiguities or edge cases"
  }
}

## Constraints
- Do not invent evidence. Only use excerpts from the provided CONVERSATION_HISTORY or system state.
- Every policy reference must map to a real policy in ACTIVE_POLICIES. If no policy clearly applies, state that explicitly in reviewer_notes.
- If the escalation decision lacks sufficient evidence, set the evidence_log to an empty array and flag the gap in reviewer_notes.
- Do not include conversational filler, apologies, or markdown formatting outside the JSON object.
- If [RISK_LEVEL] is 'high', you must include a `reviewer_notes` field that explicitly flags the record for mandatory human review before the escalation is finalized.

To adapt this template, replace the bracketed placeholders with your application's specific values. [REASON_CODES] should be a predefined list of escalation reason codes from your operations runbook. [RISK_LEVEL] can be dynamically injected by your harness based on the task's sensitivity. The ACTIVE_POLICIES input should be populated by your policy retrieval system, ensuring the model always grounds its governance section in the correct, versioned documents. After generation, always validate the JSON structure and confirm that every policy_id resolves to a real policy in your system before the audit record is committed to storage.

This prompt is designed to be called at the moment an escalation decision is made, not after the fact. Wire it into your escalation handler so that the audit trail is generated synchronously with the escalation event. The prompt expects a structured input payload containing the escalation trigger, the governing policy reference, the decision rationale, and the identity of the escalating role or system. If any of these inputs are missing, the audit trail will be incomplete and should be rejected before storage.

Implement a validation layer that checks the generated audit trail against a strict schema before accepting it. Required fields include escalation_id, timestamp, trigger_reason, policy_reference, decision_rationale, escalating_role, and evidence_sources. Use a JSON Schema validator or a Pydantic model to enforce field presence, types, and format constraints. If validation fails, retry the prompt once with the validation errors injected into the [CONSTRAINTS] block. After two failures, route the incomplete record to a human review queue with the raw model output and validation errors attached. Never silently store a partial audit trail.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, with response_format set to json_object or the equivalent structured output mode. Avoid smaller or older models that may drop required fields or hallucinate policy references. If your governance requirements demand full traceability, configure the model call to return log probabilities for key fields like policy_reference and decision_rationale, and store those alongside the audit record for later review.

Log every audit trail generation attempt, including the input payload, the raw model response, validation results, and the final stored record. Use structured logging with a correlation ID that ties the audit trail back to the originating escalation event and conversation trace. This is essential for downstream auditors who need to reconstruct the full decision chain. If the audit trail references external policies, include the policy version number in the policy_reference field and verify that the version was active at the time of the escalation.

Do not treat this prompt as a fire-and-forget step. Build a reconciliation job that periodically checks for escalation events that lack a corresponding audit trail record. Missing audit trails are a compliance gap and should trigger an alert. Similarly, implement a retention policy that matches your organization's audit record requirements, and ensure the audit trail storage is immutable and access-controlled. The prompt is only one link in the chain; the harness around it determines whether the audit trail is actually trustworthy.