Lecture 2.4
Exceptions are where most policy failures live. This lecture treats the exception as a first-class object with its own conditions, authority, and expiry.
Learning objectives
After this lesson, the reader should understand:
Concept framework
Exception anatomy
Case study
An exemption granted for an emergency is still in force four years later. Why?
Take a real instance. A procurement policy caps any single vendor at 30% of category spend, to limit concentration risk. When the primary vendor's plant burns down and only one alternate can deliver in time, the procurement committee grants an emergency exception: rule displaced, the 30% concentration cap; trigger, the vendor's confirmed inability to fulfil contracted volume; granting authority, the procurement committee; duration, 'for the duration of the supply emergency'; justification, recorded in the committee minutes at the time. That duration clause is the failure. 'For the duration of the emergency' is a condition, not a date, and nobody was assigned to re-evaluate whether the condition still held. The emergency passed within months. The exception, expressed with no notion of time a runtime could check, stayed in force. Two years later, a second exception is granted against the same rule, for an unrelated reason: a new preferred-vendor agreement that also pushes one supplier over the cap. Nobody granting the second exception checks whether one already exists, because the first was never expressed as a queryable object — it was a line in a document nobody thought to search. The concentration limit is now suspended twice, for two different reasons, and no single review catches that either justification alone no longer applies without also checking the other. As an artifact, an exception is not just a document. It displaces a specific rule, under specific trigger conditions, granted by a named authority, for a stated duration, with a recorded justification — one queryable object among however many others touch the same rule. A runtime can ask, of any rule, how many live exceptions currently displace it, and what each one's own conditions require; a question no prose document was ever structured to answer. Tracking which default holds until something displaces it, and what displaces it, is what the field calls defeasible reasoning[1]. The strongest objection is that hard expiry dates create their own harm. Emergencies do not end on schedule; an exception that lapses automatically on the date written into it can cut off supply on the day the alternate vendor is still the only one able to deliver. The objection is right, and it changes the design rather than defeating it. Expiry should not mean silent lapse any more than it should mean silent persistence. It should mean a dated review: on the stated date the exception escalates to its granting authority, which renews it with a fresh justification or lets it go. What the artifact refuses is the third option the prose allowed — nobody deciding at all. The second exception exposes a harder limit. Once two live exceptions displace the same rule, something must say which prevails when their conditions overlap and their consequences differ. Formal work on defeasible reasoning treats the priority between rules as itself something to be argued and recorded, not assumed[2]. An artifact can make the overlap visible; it cannot decide the priority on the institution's behalf. Choosing between two exceptions is an act of authority, and it belongs to whoever granted them.
Discussion questions
Discussion (0)
No responses yet. Be the first to answer one of the questions above.
Start the course to join the discussion.
Exercise
Model one exception completely.