Human-in-the-Loop Approval Timeout Handoff Prompt

This prompt is designed for workflow automation engineers who are building AI-driven systems that require explicit human approval before executing a high-risk action. Its specific job is to handle the expiry of an approval window. When a time-boxed approval request is sent to one or more stakeholders and no response is received before the deadline, the AI must not proceed autonomously. Instead, it must generate a structured handoff package that revokes its own conditional authority, captures the full state of the pending action, and provides a clear escalation path for a human operator to resolve the deadlock. This is not a general-purpose handoff prompt; it is a safety-critical component for systems where inaction has operational consequences.

Use this prompt when your application logic has already detected a timeout condition on a pending_approval state. The required inputs include the original action request payload, the list of stakeholders who were notified, the time-box parameters, and the current system state. Do not use this prompt for real-time handoffs during live chat sessions, for tool execution failures, or for guardrail violations—those scenarios have their own dedicated handoff templates. This prompt is also inappropriate when the AI can safely retry the approval request or when the action is low-risk enough that a default fallback (like discarding the request) is acceptable. Its primary value is in regulated or high-stakes environments—such as finance, healthcare, or infrastructure automation—where an unexecuted action and an expired approval window represent a risk that must be formally documented and escalated.

The output is a structured handoff payload, ideally in JSON, that includes the pending action, the expiry reason, a record of non-responsive stakeholders, and a revocation of the AI's authority to proceed. The prompt forces the model to be explicit about what did not happen and why. Before integrating this into a production harness, you must define validation checks for the output schema, ensure the escalation path is mapped to a real human queue, and log the handoff event for audit purposes. The next step after reading this section is to review the prompt template and adapt the placeholders to your specific approval schema and escalation routing rules.

This prompt template is designed to be invoked when a human-in-the-loop approval workflow has exceeded its configured time-box. It instructs the model to synthesize the state of the expired request into a structured handoff object, rather than allowing the workflow to hang indefinitely or fail silently. The template uses square-bracket placeholders for all dynamic inputs, ensuring it can be adapted to different approval schemas, risk levels, and organizational routing rules without modifying the core instruction set.

codeCopy
SYSTEM: You are an Approval Timeout Handoff Generator. Your task is to produce a structured JSON handoff payload when a human approval request has expired. Do not take any action on the pending task. Your only job is to package the state for a human operator.

USER: An approval request has timed out. Generate the handoff payload.

PENDING ACTION:
[PENDING_ACTION_DESCRIPTION]

APPROVAL REQUEST DETAILS:
- Request ID: [REQUEST_ID]
- Requested By: [REQUESTOR_IDENTITY]
- Requested At: [REQUEST_TIMESTAMP]
- Timeout Window: [TIMEOUT_DURATION]
- Expired At: [EXPIRY_TIMESTAMP]

STAKEHOLDER STATUS:
[STAKEHOLDER_STATUS_LIST]

CONDITIONAL AUTHORITY:
- Pre-approval Authority Granted: [PRE_APPROVAL_STATUS]
- Revocation Status: [REVOCATION_STATUS]

RISK AND CONTEXT:
- Risk Level: [RISK_LEVEL]
- Business Context: [BUSINESS_CONTEXT]

OUTPUT_SCHEMA:
{
  "handoff_type": "APPROVAL_TIMEOUT",
  "request_id": "string",
  "status": "EXPIRED",
  "pending_action": {
    "summary": "string",
    "action_type": "string",
    "target_resource": "string"
  },
  "approval_window": {
    "requested_at": "ISO8601",
    "timeout_duration": "string",
    "expired_at": "ISO8601"
  },
  "stakeholders": [
    {
      "role": "string",
      "identity": "string",
      "response_status": "NO_RESPONSE | APPROVED | REJECTED",
      "last_updated": "ISO8601 | null"
    }
  ],
  "authority_status": {
    "pre_approval_granted": "boolean",
    "revoked_due_to_timeout": "boolean",
    "current_effective_authority": "string"
  },
  "escalation": {
    "recommended_path": "string",
    "urgency": "HIGH | MEDIUM | LOW",
    "sla_breach_risk": "boolean"
  },
  "operator_instructions": "A concise, prioritized checklist for the human operator to resolve this timeout.",
  "audit_log": "Summary of key events leading to timeout."
}

CONSTRAINTS:
- Do not fabricate stakeholder responses. Use only the provided statuses.
- If no escalation path is provided, infer a reasonable default based on the risk level and business context.
- The operator_instructions field must contain actionable steps, not a generic apology.

To adapt this template, replace each bracketed placeholder with data from your workflow engine. The STAKEHOLDER_STATUS_LIST should be a structured block, such as a markdown table or a list of JSON objects, detailing each required approver and their response state. The OUTPUT_SCHEMA is provided inline as a JSON Schema-like structure to constrain the model's generation; for stricter enforcement, this schema should be passed via your model's dedicated JSON mode or tool-calling interface. After generating the handoff, the calling application must validate the output against the expected schema before routing it to a human review queue or incident management system.

The approval timeout handoff prompt is designed to sit at the end of a stateful approval workflow. When a human-in-the-loop approval request reaches its expiry window without a response, the application should call this prompt to generate a structured handoff payload. The prompt expects a rich context object containing the original action request, the list of stakeholders who were notified, their response statuses, the time-box parameters, and any conditional authority revocation rules that were in effect. Do not call this prompt for active approvals that are still within their window—it is specifically for expired, abandoned, or timed-out approval states where the system must escalate to a human operator with full context.

Wire the prompt into your application as a post-timeout handler. When a scheduled approval timer fires or a polling loop detects an expired window, assemble the [PENDING_ACTION], [APPROVAL_REQUEST_DETAILS], [TIME_BOX_EXPIRY], [STAKEHOLDER_RESPONSE_LOG], and [AUTHORITY_REVOCATION_STATUS] fields from your workflow state store. Pass them into the prompt template and call your model with a low temperature (0.0–0.2) to maximize structural consistency. Parse the output against a strict JSON schema that validates the presence of escalation_reason_code, pending_action_summary, stakeholder_status, revocation_notes, and recommended_escalation_path. If parsing fails, retry once with the validation error appended to the prompt as a correction hint. If the second attempt also fails, log the raw output and fall back to a pre-defined static handoff template that a human operator can interpret.

Log every handoff generation event with the model version, prompt version, input context hash, output payload, and validation result. For high-risk actions such as financial commitments, configuration changes, or data deletion, require a second human reviewer to acknowledge the handoff before any further automated steps proceed. Do not allow the system to silently discard expired approvals—every timeout must produce an auditable handoff record. Test this harness with simulated timeout scenarios that include partial stakeholder responses, fully unresponsive stakeholders, and cases where conditional authority was revoked mid-window. The most common production failure mode is incomplete stakeholder response logs, so add a pre-prompt check that verifies all required stakeholder fields are populated before calling the model.