Scale automation without flattening the process: govern exceptions

An enterprise scales automation when every exception arrives with a common code, evidence, and owner even though each process retains a different happy path. The thesis is testable: when two teams use “error” for incompatible events and apply the same retry, scale is already producing duplicates, silent queues, or incorrect actions.

The happy path is not the shared contract

A purchase order, a shipment, and a supplier onboarding do not share identical rules, data, or consequences. Forcing them into one template removes useful context and creates hidden special cases. Yet all of them must answer comparable questions when data is missing, a dependency expires, policy blocks an action, or a decision is ambiguous.

Useful standardization begins where normal flow stops. Operations needs to know what happened, whether retry is safe, which object is affected, who can resolve it, and when it escalates. That common envelope enables measurement and improvement without turning different processes into copies.

A six-family exception taxonomy

The OMG BPMN 2.0 specification provides a common notation and distinguishes events such as error, escalation, timer, and compensation. It does not prescribe this business taxonomy, but it demonstrates why “failed” is insufficient: different events require different continuations.

Use six mutually exclusive top-level families:

1. DATA_INVALID. A field is absent, a format is invalid, a source is stale, or valid sources conflict.
2. POLICY_BLOCK. A rule, threshold, permission, or approval prevents continuation. Retrying without policy change is wrong.
3. DEPENDENCY_TRANSIENT. A network, service, or temporary resource is unavailable and may allow bounded retry.
4. BUSINESS_NOT_FOUND. An expected object or relationship—order, contract, account, or counterparty—does not exist.
5. AMBIGUOUS_DECISION. Evidence is valid but insufficient to choose an action within the agreed confidence boundary.
6. INTEGRITY_OR_SECURITY. A potentially harmful duplicate, manipulation, unauthorized access, or inconsistency requires containment.

Domain codes live underneath: DATA_INVALID.VENDOR_TAX_ID or BUSINESS_NOT_FOUND.PURCHASE_ORDER, for example. The prefix permits portfolio comparison; the suffix preserves local meaning.

The minimum exception envelope

An exception should be an operational object, not free text buried in a log.

Field	Purpose
exception_id	Prevents double closure and enables stable references
occurred_at and detected_at	Separates origin time from detection latency
business_object_type/id	Identifies the invoice, order, shipment, or request
automation_id/version	Locates the exact workflow and artifact
reason_code/subcode	Activates comparable policy and analysis
retryable and attempt	Prevents infinite or unsafe retries
evidence_refs	Links permitted inputs, outputs, and events
owner_queue and due_at	Establishes accountability and clock
resolution_code	Records how the case ended without erasing it

Do not copy personal data or full documents into the envelope. Use references with defined permissions and retention.

Routing matrix: the code must change behavior

Family	Default response	Resolver	Acceptable closure
DATA_INVALID	stop object; request or reconcile data	data custodian	corrected, source changed, or discarded
POLICY_BLOCK	do not retry	policy owner/approver	authorized, rule updated, or rejected
DEPENDENCY_TRANSIENT	bounded delayed retry	technical team after exhaustion	recovered or degraded
BUSINESS_NOT_FOUND	find relationship or create case	process operations	linked, created, or cancelled
AMBIGUOUS_DECISION	deliver evidence to reviewer	domain expert	human decision and reason
INTEGRITY_OR_SECURITY	pause and contain	security/control	released, blocked, or investigated

The AWS Step Functions error-handling documentation distinguishes retriable errors, terminal conditions, timeouts, and Catch paths. The portable lesson is that Retry is not treatment. It belongs to explicit codes, with a maximum and an alternative exit.

Operating loop: detect, contain, resolve, learn

A taxonomy creates value only when it drives a loop. Detect and preserve the affected object first. Then contain the consequence: pause that instance rather than the whole portfolio unless risk is shared. Route sufficient evidence. Finally, close with a resolution code and review recurrence.

NIST published SP 800-61 Rev. 3 in 2025, integrating preparation, detection, response, recovery, and improvement into cybersecurity risk management. A business exception is not automatically a cybersecurity incident, but the disciplined cycle transfers: prepare before the event, limit impact, and learn afterward.

Review families weekly and subcodes monthly. A rise in DEPENDENCY_TRANSIENT may require engineering; recurring DATA_INVALID points to source controls; AMBIGUOUS_DECISION may call for better rules or evidence. Do not reward fast closure when teams merely reclassify or discard cases.

Instrumenting the contract in Quantum

In Quantum Automation Center, an exception can link to the business object, execution, and timeline. State shows whether it remains open; artifacts and logs provide evidence; the queue and permissions assign resolution authority; and analytics expose family, age, and recurrence. The Quantum ontology helps preserve object identity across agents and automations.

Do not turn the catalog into another store of free-text messages. Require family, subcode, object, owner, and resolution so different engines report against one contract.

Counterargument: real exceptions are too domain-specific

They are specific in detail. A customs rejection and a missing bank account should not share a runbook. The mistake is to conclude they cannot share a family, clock, evidence envelope, or state. Without that common level, leaders cannot distinguish poor data from technical instability, and operations cannot decide where to invest.

Allow local subcodes and versioned context fields. Create a new family only when default response, owner, and closure criterion are genuinely different. If only the user-facing message changes, it is probably still the same type.

When not to use an enterprise taxonomy

A complex taxonomy is unnecessary for one low-volume workflow with one owner. A small register with mutually exclusive types, ownership, and a clear route may be enough. Do not introduce categories when the team cannot identify the affected object; create stable identity first.

Do not use taxonomy to disguise a broken process. If most cases become exceptions, the assumed happy path is wrong. Redesign the rule or source before optimizing the queue.

First exercise: reclassify last week

Take one week of failures and, without looking at workflow names, classify every case into one of the six families. Mark where object, evidence, owner, or resolution is missing. Cases that two people classify differently reveal ambiguous definitions; cases that fit nowhere expose a real gap. Publish the resulting dictionary, assign routes, and make each code determine an action—not merely a dashboard color.

Sources

• OMG Business Process Model and Notation (BPMN) 2.0 — omg.org
• AWS Step Functions — Handling errors in workflows — aws.amazon.com
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations — nist.gov