Pending Approval Tracking Prompt Template

This prompt is designed for AI assistants operating inside approval-gated workflows where progress stalls until a human or system stakeholder explicitly approves a pending item. The core job-to-be-done is maintaining a structured, auditable inventory of items blocked on approval, surfacing them at the right time, and preventing silent workflow failures caused by forgotten approvals. The ideal user is an engineering lead or product developer building a copilot for procurement, contract review, change management, content publishing, or any multi-step business process that requires explicit sign-off before the next stage can proceed.

Use this prompt when your assistant must track multiple concurrent approval requests across long-running sessions, detect when an approval is overdue, and re-prompt the user without being annoying or losing context. It is appropriate when approvals have clear identifiers, requestors, approvers, and deadlines that can be extracted or inferred from conversation context. The prompt expects structured input including the current pending approval inventory, conversation history, and a defined escalation policy. Do not use this prompt for simple yes/no confirmations within a single turn, for workflows where approval is implicit (e.g., the user's continued engagement counts as approval), or for systems where the approval decision is made by the model itself rather than an external human or system actor. In high-stakes domains such as healthcare, legal, or financial compliance, always pair this prompt with human review of the generated approval status and escalation triggers before any action is taken.

Before implementing, define your approval state machine: what states an item can be in (e.g., pending, approved, rejected, expired, cancelled), what transitions are valid, and what timeout thresholds trigger escalation. The prompt works best when fed a structured [PENDING_APPROVALS] array with fields for item_id, description, requestor, approver, requested_at, deadline, and status. If your application cannot provide this structured input reliably, invest in upstream extraction before relying on this prompt. The output should be consumed programmatically—parsed into your state management layer—rather than displayed raw to users. Start by running the prompt against a golden dataset of conversations with known approval events and verify that no approval is dropped, duplicate reminders are not generated for the same item within a cooldown window, and escalation triggers fire at the correct thresholds.

This section provides the core prompt template for detecting, tracking, and surfacing approval-blocked items across conversation turns. The template is designed to be dropped into an AI harness that maintains session state, feeding it the current conversation context and a structured inventory of previously identified pending approvals. It expects the model to return a machine-readable JSON object that your application can parse, validate, and use to drive reminder logic, escalation workflows, or user-facing status displays.

textCopy
You are an approval tracking assistant operating inside a multi-turn conversation system. Your job is to maintain an accurate inventory of items that are blocked waiting for user or stakeholder approval. You must detect new approval needs, update existing items when their status changes, and flag items that are overdue or at risk of timeout.

## Current Conversation Context
[CONVERSATION_HISTORY]

## Existing Pending Approvals Inventory
[EXISTING_APPROVALS_STATE]

## Current Date and Time
[CURRENT_DATETIME]

## Instructions
1. Scan the conversation for any new items that require approval. An item requires approval when a decision, sign-off, or explicit confirmation is needed before work can proceed. Look for phrases like "needs your approval," "please confirm," "waiting on sign-off," "blocked until you decide," or explicit decision points presented to the user.
2. For each existing item in the inventory, determine if its status has changed based on the conversation. An item is resolved when the user provides explicit approval or rejection. Do not infer resolution from silence or topic changes.
3. For each item (new or existing), compute or update the following fields:
   - `item_id`: A stable identifier. Use existing IDs for known items; generate new unique IDs for new items.
   - `description`: A concise description of what requires approval.
   - `requested_by`: Who or what system requested the approval.
   - `approver`: The person or role whose approval is needed.
   - `status`: One of `pending`, `approved`, `rejected`, `cancelled`, or `expired`.
   - `requested_at_turn`: The conversation turn number when the approval was first requested.
   - `last_mentioned_turn`: The most recent turn where this item was discussed.
   - `timeout_timestamp`: If a deadline or SLA was mentioned, the ISO 8601 timestamp when the item becomes overdue. Otherwise null.
   - `dependency_of`: An array of item_ids that are blocked by this approval. Empty array if none.
   - `blocked_by`: An array of item_ids that block this approval. Empty array if none.
   - `escalation_triggered`: Boolean. Set to true if the item is past its timeout_timestamp and has not been resolved.
   - `urgency_rationale`: A brief explanation of why this item is urgent or can wait, based on conversation signals.
4. If an item has been resolved (approved or rejected), keep it in the inventory but mark its status accordingly. Do not delete resolved items.
5. If an item's timeout has passed and it remains unresolved, set `escalation_triggered` to true and include a brief escalation note in the output.
6. If the user explicitly cancels an approval request, set status to `cancelled`.
7. Do not invent approvals that were not mentioned in the conversation. Do not mark items as resolved without explicit user confirmation.

## Output Schema
Return a single JSON object with the following structure:
{
  "approvals": [
    {
      "item_id": "string",
      "description": "string",
      "requested_by": "string",
      "approver": "string",
      "status": "pending|approved|rejected|cancelled|expired",
      "requested_at_turn": integer,
      "last_mentioned_turn": integer,
      "timeout_timestamp": "ISO 8601 string or null",
      "dependency_of": ["item_id strings"],
      "blocked_by": ["item_id strings"],
      "escalation_triggered": boolean,
      "urgency_rationale": "string"
    }
  ],
  "summary": {
    "total_pending": integer,
    "total_overdue": integer,
    "new_items_detected": integer,
    "items_resolved_this_turn": integer
  },
  "escalation_alerts": [
    {
      "item_id": "string",
      "alert_message": "string",
      "recommended_action": "string"
    }
  ]
}

## Constraints
- Do not include conversational filler or explanations outside the JSON object.
- Ensure all item_ids are unique and stable across turns.
- If no approvals exist, return an empty approvals array with appropriate summary counts.
- If the conversation contains no new information about approvals, return the existing inventory unchanged with `new_items_detected` and `items_resolved_this_turn` set to 0.

To adapt this template, start by defining how your application serializes [CONVERSATION_HISTORY]. A common approach is to pass the last N turns as structured messages with turn numbers, speaker roles, and timestamps. The [EXISTING_APPROVALS_STATE] placeholder should receive the JSON output from the previous invocation of this prompt, allowing the model to maintain continuity. If this is the first turn, pass an empty approvals array. The [CURRENT_DATETIME] field should be injected by your application server to prevent timezone drift. Before deploying, test the template against conversations with overlapping approval requests, implicit rejections, and multi-party approval chains to ensure the dependency mapping logic holds. Wire the output into a validation layer that checks for duplicate item_ids, invalid status transitions, and missing required fields before persisting the state update.

This prompt is designed to be called within a stateful application loop, not as a standalone chat interaction. The application must maintain a structured pending_approvals data store (a database table, a key-value store, or a serialized JSON object in session state) that the prompt reads from and writes to. The prompt's output should be parsed as a strict JSON list of approval items, each with an approval_id, status, age, dependencies, and escalation_triggered boolean. The application layer is responsible for merging this output back into the canonical state store, not the model. This separation ensures that the model's reasoning about timeouts and dependencies is advisory, while the actual state transitions and escalation actions (sending emails, pinging Slack, opening tickets) are executed deterministically by your code.

To wire this into a production workflow, implement a state reconciliation loop that runs on every user turn and on a scheduled tick for timeout detection. First, serialize the current pending_approvals list and the recent conversation turns into the prompt's [APPROVAL_STATE] and [CONVERSATION_CONTEXT] placeholders. After receiving the model's output, validate each item against a JSON schema that enforces required fields (approval_id, status, last_updated_timestamp) and allowed enum values for status (e.g., pending, approved, rejected, expired). Reject any item that references a non-existent approval_id or introduces a dependency cycle. For high-stakes workflows, add a human review gate before executing any escalation action: if the model sets escalation_triggered: true, queue the item for a human reviewer rather than automatically firing a notification. Log every state change with the previous state, new state, model's raw output, and the reviewer's decision for auditability.

Model choice matters here. Use a model with strong JSON mode and long-context handling (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) because the prompt must process a potentially large list of approval items alongside conversation history. If your approval list exceeds ~50 items, implement pagination or chunking in the application layer: split the list into batches, process each batch through the prompt, and merge results. For retry logic, if validation fails (malformed JSON, missing fields, invalid state transitions), retry once with the validation error message injected into the prompt as additional [CONSTRAINTS]. If the retry also fails, log the failure, preserve the previous valid state, and alert the on-call channel. Do not let a model output error corrupt your canonical approval state. Finally, avoid using this prompt for real-time safety-critical approvals (medical device sign-offs, financial transaction authorization) where deterministic rule engines are required; this prompt is appropriate for business workflow approvals where the cost of a missed escalation is a delayed decision, not a safety incident.