Escalation Decision Audit Prompt

This prompt is designed for AI governance, compliance, and safety engineering teams who need to systematically audit past escalation decisions made by an AI system or human operators. The primary job-to-be-done is producing a structured, evidence-backed assessment of whether a specific escalation action was correct, timely, and aligned with the defined policy. The ideal user is a technical reviewer or auditor who can provide the original context, the decision that was made, and the governing policy text. This is not a prompt for making real-time escalation decisions; it is a retrospective analysis tool for building an audit trail and identifying systemic weaknesses in your escalation framework.

You should use this prompt when you have a log of past decisions and need to verify compliance, prepare evidence for an external review, or calibrate your escalation thresholds. The prompt requires three concrete inputs to function: the full context of the situation at the time of the decision, the exact escalation action that was taken, and the relevant policy text that was supposed to govern the decision. Without all three, the audit will be speculative and low-quality. Do not use this prompt for real-time decision-making, as it is optimized for careful, post-hoc analysis, not low-latency execution. It is also unsuitable for auditing decisions where the governing policy is vague or unwritten; the prompt's value comes from comparing a concrete action against a concrete rule.

The output is a structured audit assessment, not a simple pass/fail flag. It will include a decision evaluation, a policy alignment check, and actionable improvement recommendations. Because this workflow is high-risk—audit findings can have legal, financial, and reputational consequences—you must treat the model's output as a draft for human review. The prompt includes placeholders for grounding evidence, and you should wire the output into a human-in-the-loop review queue before any finding is finalized. The next step after generating this audit is to have a qualified human reviewer validate the assessment, attach the source evidence, and log the final finding in your governance system of record.

This prompt template is designed to be dropped into an audit review pipeline where a model must assess whether a prior escalation decision was compliant, well-reasoned, and aligned with the organization's defined policy. It expects structured input containing the original decision context, the policy rules that applied at the time, and the actual action taken. The output is a structured audit assessment, not a simple pass/fail flag, so downstream systems can log the rationale, flag borderline cases for human review, and track policy alignment trends over time.

textCopy
You are an escalation policy auditor. Your task is to review a past escalation decision and produce a structured audit assessment.

## INPUT
- Case Data: [CASE_DATA]
- Active Policy at Time of Decision: [POLICY_RULES]
- Decision Taken: [DECISION_TAKEN]
- Decision Rationale Provided: [DECISION_RATIONALE]

## OUTPUT SCHEMA
Return a valid JSON object with the following fields:
{
  "decision_id": "string",
  "audit_outcome": "compliant | non_compliant | borderline | insufficient_evidence",
  "policy_rules_evaluated": [
    {
      "rule_id": "string",
      "rule_text": "string",
      "alignment": "aligned | misaligned | not_applicable",
      "evidence": "string"
    }
  ],
  "decision_quality_assessment": {
    "rationale_sufficiency": "adequate | incomplete | missing",
    "risk_awareness": "addressed | partially_addressed | ignored",
    "procedural_correctness": "followed | partially_followed | violated"
  },
  "findings": ["string"],
  "recommended_actions": ["string"],
  "requires_human_review": true | false,
  "human_review_reason": "string | null"
}

## CONSTRAINTS
- Evaluate the decision against the policy rules that were active at the time, not current policy unless [CURRENT_POLICY_DELTA] is provided.
- If the case data is incomplete, set audit_outcome to "insufficient_evidence" and list what is missing in findings.
- Flag any decision where the rationale does not reference specific policy rules.
- If the decision involved a risk level of [HIGH_RISK_THRESHOLD] or above, requires_human_review must be true.
- Do not invent facts not present in the case data.
- If the decision was non_compliant, include the specific violated rule IDs in findings.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## CURRENT POLICY DELTA (if applicable)
[CURRENT_POLICY_DELTA]

To adapt this template, replace the square-bracket placeholders with your actual data and policy definitions. [CASE_DATA] should contain the full context of the original escalation event: user input, tool calls attempted, risk scores calculated, and any intermediate steps. [POLICY_RULES] must be the exact policy text that was in effect at the time of the decision, not a summary. [DECISION_TAKEN] is the action the system or human reviewer actually performed. [DECISION_RATIONALE] is the explanation recorded at the time. [FEW_SHOT_EXAMPLES] should include at least two examples: one compliant decision and one non-compliant decision, each with the expected audit output. [HIGH_RISK_THRESHOLD] should be set to your organization's defined risk level that mandates human review, such as "HIGH" or "CRITICAL". [CURRENT_POLICY_DELTA] is optional; include it only if you want the auditor to note whether the decision would be compliant under today's rules, which is useful for policy evolution tracking.

Before deploying this prompt into an automated audit pipeline, validate that the output JSON conforms to the schema every time. Run the prompt against a golden set of 20-30 historical decisions that your team has already manually audited, and measure inter-rater agreement between the model and your human auditors. Pay special attention to borderline cases: if the model and humans disagree on these more than 10% of the time, refine the policy rules or add more few-shot examples. For high-risk domains such as healthcare, finance, or safety-critical systems, always route non_compliant and borderline outcomes to a human review queue before the audit is finalized. Log every audit output with the model version, prompt version, and input hash so you can trace disagreements back to prompt changes or policy updates.

The Escalation Decision Audit Prompt is designed to be embedded in a governance review pipeline, not used as a one-off chat interaction. The prompt expects structured input—an escalation log entry containing the original decision, context, policy version, and outcome—and returns a structured audit assessment. The implementation harness must enforce input schema validation before the prompt is called, validate the output schema after the model responds, and route ambiguous or borderline assessments to a human reviewer. This is a high-stakes workflow: audit conclusions may be used in compliance reports, policy updates, or incident reviews, so the harness must treat every automated assessment as a draft until review gates are satisfied.

Start by defining a strict input schema for the [ESCALATION_LOG_ENTRY] placeholder. The input must include: decision_id, timestamp, escalation_policy_version, risk_level (enum: low, medium, high, critical), autonomous_action_proposed, escalation_decision (enum: escalated, not_escalated, deferred), decision_rationale, human_reviewer_id (nullable), and outcome_known (boolean with optional actual_outcome field). Validate this schema before the prompt is assembled. Reject malformed inputs with a structured error rather than passing garbage to the model. For the [POLICY_DOCUMENT] placeholder, inject the exact policy version that was active at the time of the decision—never use a live policy document that may have changed since the decision was made. Version-lock your policy references. The [AUDIT_CRITERIA] placeholder should contain the specific audit dimensions you care about: policy alignment, risk assessment accuracy, decision timeliness, documentation completeness, and outcome appropriateness. These criteria should be configurable per audit run, not hardcoded.

After the model returns its audit assessment, validate the output against an expected schema. The response should contain: audit_id, decision_id, overall_assessment (enum: compliant, non_compliant, needs_review), policy_alignment (object with aligned boolean and evidence array of policy clause references), risk_assessment_accuracy (object with accurate boolean and discrepancy_notes string), documentation_completeness (object with complete boolean and missing_fields array), improvement_recommendations (array of strings), and requires_human_review (boolean). If requires_human_review is true or overall_assessment is needs_review, route the audit to a human reviewer queue with the full input, output, and model confidence metadata. Log every audit assessment—both automated and human-reviewed—with the model version, prompt version, policy version, and timestamp. This audit trail is essential for demonstrating governance rigor to internal and external reviewers.

Choose a model with strong instruction-following and structured output capabilities. This prompt benefits from low-temperature settings (0.0–0.2) because audit consistency matters more than creative variation. If your governance workflow spans multiple model providers, test this prompt on each target model and calibrate the requires_human_review threshold per model. A model that is overly cautious will flood the human review queue; a model that is overly confident will miss real policy violations. Run a calibration batch with known outcomes—decisions you've already manually audited—and measure false-positive and false-negative rates for the non_compliant classification. Set your human-review routing threshold based on that calibration data, not on intuition.

Common failure modes in the harness layer include: input schema drift where new fields are added to escalation logs but not to the audit input schema, causing silent data loss; policy version mismatch where the audit references a newer policy than the one active at decision time, producing false non-compliance findings; and output parsing failures where the model returns valid JSON that doesn't match the expected enum values or field types. Mitigate these with schema validation on both sides of the model call, versioned policy injection, and a retry-with-correction loop for malformed outputs. If the model fails to produce valid output after two retries, escalate the entire audit to a human reviewer with the raw model response and error context. Never silently accept a malformed audit assessment.

Finally, treat this prompt as a governed artifact. Version it alongside your escalation policies. When you update the escalation policy, test this audit prompt against historical decisions to detect regressions in audit consistency. A policy change that causes previously compliant decisions to be flagged as non-compliant may be intentional, but it must be reviewed and documented, not discovered months later in an audit report. Wire the prompt version into your audit log metadata so every assessment is traceable to the exact instructions that produced it.