Handoff Prompt with Audit Trail and Decision Log

Use this prompt when an AI system must transfer control to a human operator and the handoff itself is a regulated, auditable event. This is not for simple triage or context-passing. The primary job-to-be-done is producing a decision audit artifact—a structured, machine-readable record that captures what the AI decided, why it decided it, which guardrails were evaluated, and what evidence supports each step. The ideal user is a governance team, a compliance engineer, or a platform engineer embedding AI into a workflow where post-hoc review by risk and compliance officers is a hard requirement. The output must serve two masters simultaneously: a logging system that indexes structured fields for search and alerting, and a human reviewer who needs a clear, evidence-backed narrative to adjudicate the handoff.

This prompt is appropriate when the cost of an unexplained decision is high. Concrete triggers include: an AI agent reaching a safe operating limit and refusing to proceed; a guardrail violation where a policy boundary was crossed; a regulatory gate failure in a finance or healthcare workflow; or a human override of an AI recommendation that must be justified for audit. In these cases, the handoff must include the decision tree path, confidence scores, the specific rule or policy evaluated, and the raw evidence that informed the decision. The prompt requires several inputs to function correctly: [CONVERSATION_HISTORY] or [EVENT_LOG], [DECISION_CONTEXT] including the specific limit or violation reached, [GUARDRAIL_POLICIES] that were evaluated, [EVIDENCE_SOURCES] with citations, and an [OUTPUT_SCHEMA] defining the required audit fields.

Do not use this prompt for standard operational handoffs where a simple summary and state transfer are sufficient. If you only need to pass a conversation transcript and a list of pending tasks to a support agent, use the Structured Handoff Payload Prompt Template or the Conversation Summary Handoff Prompt Template instead. This prompt adds material latency and token cost because it forces the model to generate a full decision log, justification chain, and evidence map. Reserve it for workflows where the handoff itself is a compliance record. Before implementing, confirm that your logging infrastructure can parse and store the structured output, and that your human review queue can render the audit fields without overwhelming the operator. The next step is to wire the prompt into an application harness that validates the output against the required schema before the handoff is accepted.

This prompt template is designed for governance teams and engineering leads who need an explainable AI-to-human transition. It instructs the model to produce a structured handoff that includes the full decision log, override justifications, approval statuses, guardrail evaluations, and evidence citations. The output is intended to be machine-readable for downstream compliance systems and human-readable for operators and auditors. Use this when the cost of an unexplained handoff is high—such as in finance, healthcare, or regulated product workflows—and when you need to demonstrate to an auditor exactly why the system escalated.

textCopy
You are a governance handoff agent. Your task is to produce a structured handoff payload when the AI system reaches its safe operating limit, requires human approval, or escalates due to a policy or guardrail violation.

Generate a JSON object with the following structure:
{
  "handoff_id": "string",
  "timestamp": "ISO 8601",
  "escalation_reason_code": "string from [CONFIDENCE_THRESHOLD, GUARDRAIL_VIOLATION, TOOL_FAILURE, PERMISSION_DENIED, REGULATORY_BOUNDARY, AMBIGUOUS_INTENT, EDGE_CASE, APPROVAL_TIMEOUT, HUMAN_OVERRIDE, OTHER]",
  "severity": "LOW | MEDIUM | HIGH | CRITICAL",
  "decision_log": [
    {
      "step": "string",
      "decision": "string",
      "rationale": "string",
      "evidence_citations": ["string"],
      "timestamp": "ISO 8601",
      "confidence_score": 0.0-1.0
    }
  ],
  "guardrail_evaluations": [
    {
      "guardrail_name": "string",
      "rule_reference": "string",
      "outcome": "PASS | FAIL | WARN",
      "triggering_content": "string or null",
      "evaluation_timestamp": "ISO 8601"
    }
  ],
  "override_justifications": [
    {
      "override_id": "string",
      "overridden_decision": "string",
      "justification": "string",
      "approver": "string or null",
      "approval_status": "PENDING | APPROVED | DENIED",
      "timestamp": "ISO 8601"
    }
  ],
  "pending_approvals": [
    {
      "approval_id": "string",
      "action_description": "string",
      "required_role": "string",
      "stakeholders": ["string"],
      "timeout": "ISO 8601 or null",
      "status": "PENDING | EXPIRED"
    }
  ],
  "context_summary": {
    "user_intent": "string",
    "actions_taken": ["string"],
    "unresolved_state": "string",
    "conversation_transcript_id": "string or null"
  },
  "recommended_operator_actions": ["string"],
  "audit_evidence_package": {
    "model_version": "string",
    "prompt_version": "string",
    "tool_call_log": ["string"],
    "retry_attempts": 0,
    "pii_redaction_notes": "string or null"
  },
  "governance_review_readiness": {
    "all_decisions_logged": true,
    "all_guardrails_evaluated": true,
    "all_overrides_justified": true,
    "evidence_citations_complete": true,
    "human_review_required": true
  }
}

Inputs:
- Conversation or session context: [CONTEXT]
- Decision log entries: [DECISION_LOG]
- Guardrail evaluation results: [GUARDRAIL_EVALUATIONS]
- Override records: [OVERRIDE_JUSTIFICATIONS]
- Pending approval state: [PENDING_APPROVALS]
- Escalation reason code: [ESCALATION_REASON_CODE]
- Severity classification: [SEVERITY]
- Model and prompt version identifiers: [AUDIT_METADATA]

Rules:
1. Every decision in the log must have a rationale and at least one evidence citation. If no citation exists, use "NO_EVIDENCE" and set governance_review_readiness.evidence_citations_complete to false.
2. If any guardrail evaluation outcome is FAIL, severity must be at least HIGH.
3. If an override justification has approval_status PENDING, include it in pending_approvals as well.
4. Never include raw PII in the payload. If PII was present in the original context, note it in pii_redaction_notes and reference redacted segments by ID.
5. The governance_review_readiness object must accurately reflect the completeness of the payload. Set any field to false if the corresponding section is missing or incomplete.

To adapt this template, replace the square-bracket placeholders with live data from your application's decision logger, guardrail evaluator, and session store. The governance_review_readiness object acts as a self-audit mechanism: if your system cannot populate a section completely, the corresponding boolean must be set to false so the human reviewer and any downstream compliance system know the handoff is incomplete. Before deploying, run this prompt against a set of known escalation scenarios and validate the JSON output against your schema. For high-risk domains, add a human review step before the handoff payload is delivered to the operator to confirm the severity classification and recommended actions are appropriate.

This prompt is designed to be the final step in an AI agent's execution pipeline before control transfers to a human operator. It should be invoked only after the agent has exhausted its autonomous capabilities, reached a defined safe operating limit, or encountered a guardrail violation. The implementation harness must ensure that the prompt receives a complete, structured context object—not raw conversation logs—so the model can synthesize a coherent handoff payload. Pre-processing should assemble the decision log, tool call history, guardrail evaluations, and evidence citations into the [CONTEXT] placeholder. If any required field (e.g., decision_log, guardrail_evaluations) is missing or malformed, the harness must abort the handoff and log a structured error before the prompt is ever called.

Post-processing is where the real governance work happens. The model's output must be validated against a strict JSON schema that enforces the presence of audit_trail, decision_log, override_justifications, approval_statuses, guardrail_evaluations, and evidence_citations. Use a schema validator (e.g., jsonschema in Python, zod in TypeScript) to reject any output that omits required fields or contains malformed timestamps. If validation fails, implement a single retry with the validation error message injected into the [CONSTRAINTS] block, instructing the model to repair the specific failure. If the retry also fails, log the raw output, the validation errors, and the full request context to an audit log, then escalate to a human via a fallback channel (e.g., a PagerDuty incident or a high-priority ticket with the raw context attached). Never silently discard a failed handoff—governance teams need the failure record for compliance reviews.

Logging is the backbone of audit readiness. Every handoff invocation must produce an immutable log entry containing: the prompt version, model identifier, full request payload (with PII redacted if necessary), the validated output, the validation result, and a timestamp. Store these logs in a write-once, append-only system (e.g., an S3 bucket with object lock, a blockchain-anchored log, or a compliance-grade database like AWS QLDB). For high-risk domains such as healthcare or finance, require a human operator to acknowledge receipt of the handoff and record that acknowledgment alongside the log entry. This closes the loop and proves that the transition of control was completed, not just attempted. Wire the acknowledgment into the application as a callback or webhook that updates the log entry's status from pending_review to acknowledged.

Model choice matters for reliability. Use a model with strong instruction-following and JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) because the output must conform to a complex schema under pressure. Set temperature=0 to minimize variance in the structured output. If your governance requirements demand explainability, consider routing the handoff through a model that supports citation or chain-of-thought reasoning, then extract the reasoning into the decision_log field. Do not use a lightweight or local model for this prompt unless you have extensively tested its schema adherence on edge cases—failed handoffs in production are a governance risk, not just a UX inconvenience.

Finally, integrate this prompt into your existing escalation infrastructure. The validated JSON output should be programmatically routed to the correct human queue based on the escalation_reason_code and severity fields. Use the recommended_next_steps field to pre-populate the operator's interface, reducing ramp-up time. Avoid the temptation to add conversational niceties or markdown formatting to the prompt output—the receiving system is a machine, and the human operator will see the structured data rendered in a dashboard, not raw text. Test the full harness end-to-end with simulated guardrail violations, tool failures, and missing context to ensure that every failure mode produces a logged, reviewable artifact rather than a silent drop.