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.
Describe the unresolved condition as data
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
}
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.
Make the next human action specific
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.
Design recovery as part of the state machine
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.
Connect exceptions to observability carefully
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.
A practical review checklist is:
- Can missing, conflicting, and unauthorized states be distinguished?
- Does each open item request a specific next action?
- Is ownership explicit when escalation occurs?
- Can retries avoid duplicate unresolved work?
- Does resolution retain its reason and source context?
- Can operators see when coverage or audit information is incomplete?
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?
Top comments (1)
Separating an infrastructure retry from a business authority pause is where the economics of these pipelines usually break down. When an orchestration layer treats a missing approval the same as a transient connector timeout, it defaults to exponential backoff. That burns inference budget on retries that cannot succeed until a human intervenes. Making the unresolved policy condition an explicit terminal state stops the token burn and prices the delay where it belongs.