Skip to main content

Exception Architecture

The designed protocol governing what happens when an agent encounters an operational state not present in its knowledge layer — specifying which states the agent resolves autonomously, which escalate to the Steward, under what conditions the escalation protocol invokes a human, and what record is written to the Operational Ledger when the exception is resolved.

Extended Definition​

Exception Architecture is not an edge case protocol. In a well-designed autonomous system, exceptions are the primary learning surface — the points at which the business's operational knowledge is tested against operational reality and updated. The quality of Exception Architecture determines the rate at which the Operational Ledger compounds, which determines the rate at which MTTI extends and the Escalation Rate falls.

The Steward who designs Exception Architecture is not the same Steward who handles individual exceptions as they arise. The design role requires precise specification made before the first execution cycle: which operational states are deterministic enough for the agent to resolve autonomously, which require escalation, under what conditions escalation invokes a human decision, and what record must be written to the Operational Ledger when each class of exception is resolved. The operational role requires responsiveness. Both belong to the same person in a lean autonomous business — but conflating them produces systems whose exception protocols are designed retrospectively, in response to failures, rather than prospectively, before the first execution cycle.

The most common failure in Exception Architecture is treating exceptions as problems to eliminate rather than as inputs to encode. A system designed to minimise exceptions produces a knowledge layer that grows slowly, because its exceptions are rare and therefore its learning cycles are rare. A system designed to classify, route, and encode exceptions produces a knowledge layer that grows with every resolved condition — because each resolution is a new entry in the Operational Ledger, a reduction in the future Escalation Rate for that class, and a refinement of the Intervention Threshold that governs when the agent can resolve the next similar condition autonomously.

  • Operational Ledger — The Operational Ledger is the knowledge asset that Exception Architecture feeds: every resolved exception, when properly encoded, becomes a new entry that compounds the system's ability to resolve future exceptions autonomously.
  • Intervention Threshold — Exception Architecture defines the Intervention Threshold for each class of exception: the boundary between what the agent resolves autonomously and what escalates to the Steward is the central design decision of Exception Architecture.
  • Stewardship Model — The Stewardship Model defines who designs and operates Exception Architecture: the Steward both specifies the protocol before the first execution cycle and handles the exceptions that arise during operation.
  • Escalation Rate — Exception Architecture determines the Escalation Rate: a well-designed protocol reduces the proportion of executions that require human intervention as the Operational Ledger compounds with resolved exceptions.
  • MTTI (Mean Time to Intervention) — Exception Architecture directly governs MTTI: the more precisely exceptions are classified and routed, the longer the system runs between required human interventions.
  • Full-System Design — Exception Architecture is a required component of Full-System Design: the protocol governing exception handling must be specified before the first transaction, not discovered through operational failure.
  • Knowledge Debt — Knowledge Debt accumulates when Exception Architecture fails to encode resolved exceptions: every cycle in which a Steward resolves an exception without it flowing back into the knowledge layer is a cycle of debt accumulation.
  • Deterministic Failure — Deterministic Failure is the standard Exception Architecture enforces: when an agent encounters an unresolvable state, the protocol defines how the workflow halts safely and surfaces the condition to the Steward.
  • Proof of Action — Proof of Action is the record Exception Architecture requires at resolution: every exception must be logged with its input, the routing decision, and the outcome so the ledger and governance record are both updated.
  • Context Architecture — Context Architecture is the infrastructure that Exception Architecture depends on: episodic memory stores resolved exceptions, semantic knowledge governs their classification, and procedural knowledge encodes the handling protocols.

Articles​

References​

  • Lexicon — canonical definition
  • Wiki — extended entry

Metadata​

First used: 2026-05-02
Pillar: What We've Learned

Part of the Arco Lexicon Ecosystem — maintained by Arco Venture Studio