← Module 2 · Policy Engineering

Lecture 2.4

Exceptions

Exceptions are where most policy failures live. This lecture treats the exception as a first-class object with its own conditions, authority, and expiry.

Lesson 10 / 40Start the course to keep your place and get the rest by email.

Learning objectives

After this lesson, the reader should understand:

  • 01Distinguish an exception from a condition and from a waiver.
  • 02Express precedence between a rule and its exceptions.
  • 03Handle exceptions granted by a different authority.

Concept framework

Exception anatomy

  1. 01Rule displaced
  2. 02Trigger conditions
  3. 03Granting authority
  4. 04Duration or expiry
  5. 05Recorded justification

Case study

The standing emergency exemption

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

  • Should exceptions ever be permanent?
  • Who audits the population of live exceptions?
  • How do overlapping exceptions resolve?
  • Should an expired exception lapse automatically, persist until revoked, or escalate for review — and does the answer depend on the harm of each failure?

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.

  1. 01Name the rule it displaces.
  2. 02State its trigger conditions precisely.
  3. 03Name the granting authority and the expiry.
  4. 04Describe what happens on expiry.
  5. 05List every other live exception against the same rule, and state which prevails where they overlap.

Footnotes

  1. ^1Ray Reiter, "A Logic for Default Reasoning," Artificial Intelligence 13 (1980): 81–132.
  2. ^2Henry Prakken & Giovanni Sartor, "Argument-Based Extended Logic Programming with Defeasible Priorities," Journal of Applied Non-Classical Logics 7, no. 1–2 (1997): 25–75 — priorities between defeasible rules as themselves derivable and contestable.

Further reading

  • Administrative law on waivers and derogations.
  • Exception handling in safety-critical specification.
  • NOMOS-SPEC-003 (Temporal Validity) — a concrete answer: a rule schema extension adding valid_from/valid_until as a half-open interval. A rule outside its bounds is marked 'expired' in the audit trace and simply excluded from the verdict, rather than the whole artifact needing to be re-issued for a transition that is structurally just a date range.