The green dashboard and the ageing red folder

A lending pilot celebrates a high straight-through rate. Most applications pass from intake to decision quickly. In a specialist queue, a much smaller set waits: customers with conflicting identity records, unusual income evidence, accessibility needs, a policy collision or a model abstention. They are older, more consequential and more expensive than the ordinary cases, yet the success slide treats them as residue.

One folder has waited long enough for a document to expire. A second has bounced between operations and risk because neither role can accept the relevant judgement. A third received a customer message before a timeout made the transaction state uncertain. The dashboard remains green because it counts automated completions and median handling time. It does not count reconstruction, tail age, repeated touches, customer effort, unknown effects or cases that moved to email.

Calling those files exceptions suggests that the real process happened elsewhere. Operationally, the opposite is true. They expose the evidence the process needs, the authority it lacks, the service capacity it consumes, the obligations it must protect and the repair it cannot avoid. The common route is only one region of the case population.

The real process is every route by which an eligible case reaches an accountable outcome, including the routes that fail, wait, diverge, recover or remain safely unresolved. Manage each divergence as an exception episode, then use recurrence and consequence to decide whether to recover automatically, involve a specialist, obtain evidence, redesign the process or suspend it.

Thought experiment: remove the word exception

Imagine the organisation is forbidden to label any case exceptional. It must name what actually happened: evidence absent, identity inconsistent, policy silent, dependency unavailable, decision discretionary, state unknown, capacity exhausted or customer route inaccessible. The queue immediately becomes more informative. Each condition suggests different evidence, authority, service time and recovery. The vague category had been hiding design work.

Now reverse the experiment and label every manual case a failure. A skilled clinician, credit officer or investigator exercising legitimate judgement becomes a defect to eliminate. The metric rewards automation even where context, dignity or legal authority belongs with a person. A useful exception system must therefore separate manual work from avoidable rework. Its question is not whether a human touched the case, but what evidence or authority that contribution added.

Part I · Exception episodesGive divergence an operating system

An exception episode begins at the first detectable departure from an admissible state and ends only when the case, its effects and its learning disposition are reconciled.

This article’s Exception Operating System has twelve services: divergence detection, exception identity, a type registry, a context capsule, triage, a resolution contract, specialist queues, recovery control, reconciliation, an exception ledger, a pattern-and-debt engine and a governance loop. It does not turn every anomaly into bureaucracy. It makes the smallest set of facts visible enough for a deliberate route.

The episode receives case, correlation, parent workflow, event, version and duplicate identifiers. It records the last admissible state, failed assertion, evidence present and missing, actions already attempted, side effects, affected parties, authority, deadline and closure proof. The case can then travel without forcing each receiver to reconstruct history from messages, model traces and several systems.

Workflow Exception Patterns provides a technology-independent classification of exception-handling strategies and distinguishes activity, case and recovery concerns.[4] BPMN 2.0.2 supplies modelling constructs for alternate flows, boundary events, errors, escalation, cancellation, termination and compensation.[3] Neither notation establishes whether the organisation can actually resolve a case, staff the route or learn from recurrence.

The Exception Type Registry is multi-dimensional

Types include expected alternate paths, evidence defects, identity or eligibility mismatch, rule collision, probabilistic insufficiency, dependency failure, state inconsistency, capacity failure, authority or discretion, affected-party challenge, novel conditions and systemic signals. Type and severity stay separate. A missing postcode in a marketing lead is unlike a missing identity field before payment, even if both appear as blank values.

Research across five organisations found that observed exception paths, particularly unexpected exceptions, were associated with longer throughput times in the studied processes.[5] That evidence is bounded to those settings. It supports looking beyond idealised models, not the stronger claim that every deviation is harmful. Passages-based conformance research provides methods for comparing observed behaviour with models while decomposing large problems.[6] Logs still omit conversation, judgement and off-system work unless those are captured separately.

Part II · Evidence and routingHand over the last admissible state, not a summary

A reviewer should begin with the unresolved decision, not spend the first half of the service time rediscovering what the workflow already knew.

The Exception Episode Contract travels with the case. It names the exception, severity and discovery time; parent workflow and versions; trigger; prior state; present, missing and conflicting evidence; attempted actions and effects; consequence; permitted actions; owner and skill; service time and expiry; retry and compensation; communication; closure proof; recurrence key; retention and reauthorisation.

The Exception Evidence Capsule is its operational payload. It preserves the intended outcome, last admissible state, exact divergence, source evidence, relevant model and tool results, decisions already taken, reservations and messages, open questions, affected party, deadline and permissible route. A recommended route may appear, but it carries no authority by itself. The reviewer keeps access to primary evidence because a summary can reproduce the error that created the exception.

Applied example: the missing covenant

A commercial-credit case lacks one covenant document. The episode records the facility, policy and evidence versions, calculation already completed, exact document required and expiry date. It sends a specific request rather than a generic rejection. The case waits without losing its last valid state. When evidence arrives, freshness and identity checks run again. Only a complete pack may enter credit judgement. The exception route protects both decision quality and customer time.

Applied example: the fraud abstention

A fraud model abstains because device and identity signals conflict. The investigator receives primary events, model output, rules already applied, holds already placed and the deadline for protective action. The packet does not say merely “low confidence”. The specialist can distinguish compromised credentials, legitimate travel or a data-linkage fault and has the authority to keep, change or release the hold. Their decision becomes a receipt that later outcomes can test.

Part III · Time and economicsA queue is a consequence engine

First-in-first-out is not neutral when evidence expires, harm grows or only one role can exercise the necessary authority.

The Queue Geometry and Ageing Model tracks arrivals by type, segment and source; service demand by skill and authority; priority by consequence, deadline, vulnerability, recoverability and evidence expiry; transfers and rework; oldest and tail age; abandonment and off-system work; specialist capacity; surge; ownership gaps; and thresholds for alternate routes, customer protection or suspension. Volume and median age remain useful, but they are never the whole picture.

Suppose the median case closes in one day while a small tail of sanctions cases approaches a statutory or evidence deadline. Optimising the median may allocate scarce expertise to easy work and let consequence accumulate. A visible priority rule can protect deadlines and vulnerable customers while being tested for unfair effects. Paper 157 owns the fuller mathematics of human-agent queue capacity; here, queue measures serve the semantic duty to resolve each exception safely.

The exception economics ledger

Exception cost includes detection delay, queue and service time, transfers, specialist effort, evidence reacquisition, model and tool cost, retry and compensation, customer delay and abandonment, working-capital effects, conduct or safety exposure, avoided loss from correct resolution, redesign cost and residual tail. Compare each type with the real manual baseline. It is false to charge automation with every exception while assuming the old process had none.

The exception rate needs a denominator and a clock

An exception count without its eligible population is almost meaningless. The denominator should identify process version, product, channel, supplier, jurisdiction and customer segment where those distinctions affect exposure. A fall from 400 episodes to 200 is not improvement if eligible volume fell by three quarters, or if a new channel displaced the same burden into unobserved calls. Report the rate beside absolute volume and prevented harm, then preserve the denominator definition when comparing periods. When eligibility changes, show the old and new populations separately before presenting an aggregate.

The clock should begin at the first observable divergence, not when an exception finally enters a specialist queue. Otherwise detection delay disappears from the record and a badly instrumented process can look fast. Separate time to detect, time awaiting evidence, time awaiting authority, active resolution time and time to reconcile downstream effects. Median duration describes the ordinary case; percentiles and the age of the oldest open cases expose the tail. The ledger can then distinguish quick containment from genuine closure and value averted loss without pretending that every avoided incident is cash saved.

Thought experiment: the disappearing backlog

A release appears to eliminate recurrent exceptions. The queue shrinks to zero. One interpretation is that the defect is fixed. Another is that staff now complete the missing step in email because the new interface removed their formal route. Event logs support the first story; customer callbacks and observation support the second. The only reliable closure test reconciles end outcomes, off-system work and residual burden. Queue disappearance is not process improvement by itself.

Case closure and population closure need different receipts

A case closes when its authoritative outcome is known, the affected party has received the promised decision or remedy, and every material side effect has been reconciled. That receipt belongs to the episode. It does not prove that the condition which produced the episode has disappeared. Closing the defect requires a population receipt: recurrence measured against a stable eligible population, the residual tail described rather than averaged away, displaced work checked across channels, and the new control verified under realistic operating pressure.

The two receipts prevent opposite errors. Without case closure, a redesign programme can celebrate while customers still wait for money, correction or explanation. Without population closure, one skilful recovery can be mistaken for proof that the process is sound. Owners should therefore retain linked but separate fields for episode outcome, local containment, root-cause status, redesign evidence and residual exposure. Reopening one does not automatically erase the others; it creates a traceable reason to reconsider them.

Part IV · Learning and limitsRepair the case without closing the defect

An exception can be noise, legitimate variation, a workaround, a local defect, emerging risk or evidence that the formal process is wrong.

The Exception Debt Register records recurrence, affected segments and versions, ordinary and tail volume, operational and customer burden, workaround dependencies, suspected root cause, disconfirming evidence, containment, redesign candidate, decision owner and residual tail. Exception debt is not a count of unusual cases. It is the obligation accumulated when a known divergence continues to consume people or expose customers because the underlying condition remains unrepaired.

Workaround research treats local deviations as goal-directed responses whose underlying problem should be understood before adoption.[7] Qualitative research across six case organisations reports motives connected to misalignment among organisational, unit and personal goals.[8] A 2026 open-access method distinguishes recurrent workaround patterns from transient fixes for process improvement.[9] Case evidence also shows that coordinated workarounds can become routines when mandated systems misfit local realities.[10] None of this means a workaround is safe.

The learning loop preserves episodes, distinguishes declared variation from deviations, clusters recurrence without losing consequence, interviews resolvers and affected people where appropriate, tests process goals and constraints, compares codification with policy or service redesign, runs a bounded change, monitors displacement and retires the workaround only when the replacement works. Observation focuses on cases and process state, not screens, keystrokes or individual pace.

Protected alternate routes reveal service truth

Not every departure from the dominant route is a defect. Telephone assistance, accessible evidence formats, translation, proxy support or professional discretion may be the legitimate process for a protected need. Labelling these episodes as failure can turn inclusion into an apparent source of cost and invite harmful optimisation. The registry should mark declared alternate routes, record why they exist and compare their outcomes with the service promise. Review should test timeliness, dignity, access and quality, not merely pressure those routes to match the speed of a digital majority. A recurring request may still reveal that the main route needs redesign, but the evidence must not be used to eliminate the accommodation that exposed the truth.

The strongest rival: most anomalies deserve very little architecture

The claim that exceptions are the real process can encourage overengineering. Rare random cases may be cheaper for competent people to handle. Enumerating every imaginable edge can make software rigid. Workarounds can be local innovation. Variation may preserve dignity or professional discretion. Instrumentation can become surveillance, and aggressive elimination targets can teach workers to hide hard cases.

The answer is observability for choice, not formalisation for its own sake. Retain a simple named manual route when volume and consequence do not justify automation. Protect challenge and reporting. Codify only stable, safe and useful routes. A low-volume small-business operation may need a generalist, a shared case record and an explicit reconciliation check, not a platform. That negative control keeps the Exception Operating System proportional.

Bainbridge’s analysis warned that automation can leave people with abnormal and recovery work while weakening the conditions needed to perform it.[11] A meta-analysis of 18 experiments examined routine and failure performance, workload and situation awareness across automation levels.[12] Those findings do not settle every AI allocation, but they make it unsafe to assume a person can recover merely because the workflow routes to them. High-reliability organisation research is likewise a bounded body of organisational evidence, not a universal checklist.[13]

Explicit failure boundary

Suspend the affected workflow or population when exception identity is lost, side effects cannot be reconciled, cases lack an accountable owner, evidence expires before decision, a common-mode fault overwhelms safe capacity, compensation fails without a repair route, workers must bypass controls to complete legitimate work, affected-party protection is absent, or the dashboard cannot see abandoned and off-system cases. A case-level may solve one file; it cannot legitimise continued unsafe entry.

Google’s SRE guidance explains retry amplification, overload, backoff, jitter and load shedding.[14] Microsoft’s compensating-transaction pattern stresses recorded progress, application-specific repair and possible manual intervention.[15] Compensation is forward work under current conditions. It cannot retract what a recipient has already seen or guarantee restoration of the original world.

Fourteen diagnostic casesTest what the exception means before choosing the route

These compact scenarios are design examples rather than reported deployments. Each begins from the last admissible state and ends with a case and population disposition.

Executable decision instrumentException Resolution and Redesign Navigator

Load a named case or vary the controls. The Navigator selects one of five routes while keeping evidence, authority, ageing, effects and recurrence visible.

What the Navigator can establish

The instrument checks whether a case has a declared route, sufficient evidence, a compatible authority, protected service time and a population disposition. It cannot prove a model is accurate, a workaround is legitimate, a person is effective, a queue is fair or a change is lawful. Teams must test those questions on representative cases, review affected-party outcomes and apply the relevant legal and organisational framework.

ConclusionDesign the moment when ordinary stops

The common path matters, but it tells leaders little about how a process behaves when evidence is incomplete, systems disagree, people challenge, automation abstains or the world changes mid-case. Those moments reveal the real requirement. They show whether the organisation knows its state, can assemble primary evidence, has the necessary skill and authority, protects the affected person and can establish a valid outcome after partial action.

NIST AI RMF 1.0, a voluntary framework currently under revision, calls for deployment-context evaluation, monitoring, human roles, appeal, incident response, recovery and change management.[1] Its Generative AI Profile adds provenance, pre-deployment testing and risks that emerge through use.[2] The UK Government AI Playbook provides public-sector guidance on meaningful human control, intervention, feedback and lifecycle management.[16] The EU AI Act adds scoped, phased obligations for covered systems,[17] while ISO/IEC 42001:2023 frames organisational operation, nonconformity and improvement.[18]

The changed management rule is direct: measure the full case population, package every divergence, route by evidence and consequence, reconcile the world state, and let recurrence challenge the formal process. Do not automate every anomaly. Do not celebrate its disappearance without finding where the work went. Keep a competent manual route when it is the sound design, redesign when debt becomes structural, and suspend when the exception reveals an unsafe premise. The process becomes real where the happy path ends.