Your AI Workflow Needs an Exception Contract

An operational brief can look complete while the information needed to act is still missing.

A production item may have a deadline but no approved artwork. Two systems may disagree about its stage. A suggested next action may require an authority the current operator does not hold.

In the anonymized ecommerce operating-layer case in my portfolio, exceptions and human decisions are part of the architecture. A related observability case describes a shared trace contract. Neither public page establishes a quantified benefit from exception handling. This note proposes a concrete contract for making unresolved work visible.

A free-text warning can alert a person, but it is difficult to route, reconcile, or close consistently. A useful exception needs a type, source context, affected work, owner, and resolution state.

It should also distinguish an observation from an interpretation. “Approval field unavailable” is different from “approval denied.” Missing data cannot safely become a negative business fact.

Here is a wholly invented exception record:

{ "type": "approval_context_missing", "observed_state": "required approval could not be established", "proposed_action": "hold for review", "owner_role": "production_coordinator", "resolution_state": "open", "execution_allowed": false } Enter fullscreen mode Exit fullscreen mode This example is an illustrative contract, not an operational export. An implementation would need authorized source references and stable identity, without exposing private payloads in public logs.

A queue entry saying “AI uncertainty” asks the operator to investigate everything. A more useful entry asks them to confirm the applicable approval, resolve a source conflict, or assign an owner.

The daily brief can then show what is known, which dependency is unresolved, and why a suggested action remains blocked. Human prioritization stays explicit.

The same principle applies to a process change. An agent can structure a proposed SOP update, but the proposal remains a draft until the responsible owner and required approver act. A missing review is an exception state, not permission to publish the draft.

These distinctions keep the system's narrative from outrunning its authority.

Exceptions change over time. A missing field may arrive, a conflict may be resolved, or a decision may become stale after the source changes again.

The workflow needs to recognize those transitions. A retry should update or reconcile the existing unresolved item where appropriate, rather than multiplying notifications. Closing an exception should preserve the reason and the evidence used to close it.

Some failures belong to infrastructure; others belong to the business process. A temporarily unavailable connector can support a technical retry. An unresolved policy decision needs a person. Treating both as “retry later” hides the organizational work.

This is a proposed implementation detail, not a claim that all transition paths in the case have already been verified.

A trace should identify the workflow, decision, outcome, risk, and review state without dumping customer messages or credentials. Sanitized references can connect the trace to authorized evidence.

The observability pattern also keeps logging failures from becoming an uncontrolled failure of the operational workflow. That does not mean the system should conceal missing audit coverage. The appropriate degraded behavior depends on the action's requirements and must be defined explicitly.

Measurements to collect include unresolved age, repeated transfers, missing ownership, and exceptions reopened after source changes. They should accompany review effort and error analysis.

The ecommerce operating-layer case and observability contract describe the surrounding design. Which unresolved state would make today's brief unsafe to treat as an execution plan?