Purpose and fit

Use this when a workflow has a normal path but unresolved items accumulate in inboxes, get retried or wait indefinitely for help. Design the operational handling of exceptions after the task’s permissions and human handoffs have been agreed.

The result is a proposed exception register and a clear reviewer routine for receiving, reviewing and closing blocked work. Focus on observable triggers and work status rather than a model’s self-reported confidence. Actual queue implementation and stop/restart controls require separate operational verification.

Before you start

Provide the existing workflow outline, known stop conditions and any real exception notes you may safely share. A few descriptions are sufficient; you do not need to generate a queue dataset. Supply approved reviewer roles, available tracking location and known fallback, leaving unconfirmed controls or access explicitly unresolved.

Expect a draft exception-register structure and reviewer routine with rehearsal cases, not an implemented queue or verified stop/restart controls. Each exception needs an observable trigger, last-known state and proposed authorised decision route.

Required inputs

  • The approved workflow, existing stop conditions and people authorised to decide what happens next.
  • Examples of missing inputs, conflicting sources, failed checks, unavailable reviewers and tool interruptions.
  • The consequences of delay, duplicate execution or an incorrect restart.
  • A suitable tracking location, reviewer availability and an agreed manual fallback.

Practical workflow

  1. Define the triggers that create an exception, such as a missing required source, a conflicting instruction or an interrupted change with an unknown result. Give each trigger an observable description.
  2. Specify a safe holding state. Preserve the work reference and known status, prevent automatic continuation and record whether any action may already have occurred. An uncertain result must not trigger a blind retry.
  3. Create a minimal review packet: the task, trigger, verified facts, sources, checks performed and decision required. Include references rather than unnecessary copies of sensitive content.
  4. Assign an owner and backup for each exception type. Agree response targets based on the consequence of waiting, and define what happens when neither person is available. Silence must not become approval.
  5. Define closure outcomes: corrected input, approved bounded restart, manual completion, cancellation or further investigation. For restarts, confirm the last completed step, check for duplicates and record the authorising decision.
  6. Rehearse a routine exception, an unavailable reviewer and an interrupted action. Check that every item remains visible, then review queue age and repeated triggers to identify upstream fixes.

Expected output

An exception register and a one-page reviewer routine. Copy this record:

Work reference: [non-sensitive identifier] Trigger and observed time: [what/when] Last verified state: [completed and unknown steps] Holding state: [how continuation is prevented] Evidence references: [approved sources] Decision needed: [specific question] Reviewer/backup: [roles] Response target: [agreed interval] Escalation if overdue: [route] Outcome and rationale: [decision] Restart/duplicate check: [result] Closed by/time: [record]

Hypothetical example: a request update times out after submission. The item is held while an authorised operator checks the destination record. The team avoids resubmitting until it knows whether the first update succeeded.

Human checks

Reviewers confirm their authority for the requested decision; queue ownership alone does not grant permission to change records. The operations owner checks whether response targets are realistic and whether the backup can access the evidence. System owners verify the actual stop and restart controls separately.

Limitations

A register cannot enforce a stop or guarantee timely review. Some interrupted actions require specialist investigation. Growing exception volume can indicate a poorly scoped workflow; adding reviewers should not be the automatic response.

Starter prompt

Design exception handling for this approved workflow using these sanitised notes: [workflow, triggers, roles and controls]. Existing permissions and stop conditions are [boundaries]. Propose a holding state, review packet, owner, backup and closure route for each exception type.

Create a register with these fields: work reference; trigger and observed time; last verified state; holding state; evidence references; decision needed; reviewer and backup; response target; overdue escalation route; outcome and rationale; restart and duplicate-check result; closure owner and time. Leave future results blank. Add three rehearsal scenarios, including an unknown action result. Flag blind retries, missing reviewers and restarts needing explicit authorisation. Use observed triggers rather than model confidence scores. Do not grant permissions, approve restarts, send escalations or execute workflow actions.

Adapt the requested fields to the authorised inputs actually supplied. If the result of an action is unknown, preserve that uncertainty and propose a hold pending destination verification, never a blind retry. Treat missing reviewer availability or permissions as unresolved; do not invent completion times, authorisation or successful closure. State the expected output and acceptance criteria before drafting. Ask for essential missing information; where a useful partial draft is possible, label its limits and assumptions. Do not invent facts, evidence, results or approvals.

Data, model variability and your responsibility

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.