# Workflow exception control kit

Use this kit when a workflow automation pilot starts touching real queues, deadlines, customers, or systems of record. The goal is to make exceptions explicit before automation expands.

## Exception classes

- Missing evidence: the case cannot be resolved because required source data is absent, stale, or inaccessible.
- Conflicting records: two or more systems disagree on status, owner, amount, entitlement, or deadline.
- Permission gap: the user, agent, or reviewer cannot access the evidence or tool required to proceed.
- Ambiguous owner: no team is clearly accountable for the next action or policy decision.
- Policy uncertainty: the workflow needs a judgment call that has not been encoded into approved operating policy.
- Downstream constraint: the next system cannot accept the action because of dependency, capacity, validation, or outage.

## Operating model

Each exception class should name a trigger, owner queue, evidence packet, user message, fallback route, service target, and remediation path. Review recurring exceptions weekly until the automation boundary is stable.

## Metrics

Separate clean containment from assisted containment, manual rescue, reopened work, and downstream rework. A workflow is ready to expand only when containment quality improves without hiding risk in another queue.