Override and Exception Log¶
Document — instantiates Heuristic vs. Algorithm Tradeoff and Selection
Records when users depart from the default method, why, and whether exceptions reveal a boundary failure.
An Override and Exception Log is a running record — an event stream — that captures each time a human departs from the default method, the reason they gave, and how the case turned out. Its purpose is not to police individuals but to turn scattered departures into a signal: when overrides cluster on a particular kind of case, that cluster is evidence the method's boundary is drawn in the wrong place. The one idea that makes it this mechanism is that it is a live, per-event record of what people did against the default — one row per departure, growing continuously — rather than a static description of any method. It listens to the exceptions the system's designers didn't anticipate.
Example¶
A disability-benefits agency uses an automated eligibility rule to make first-pass determinations. Caseworkers may override the rule — granting where it would deny, or denying where it would grant — but every override must be logged with the case, the direction, a structured reason code, and, later, the appeal outcome once one exists. On its own, any single override is just one caseworker's judgment. Read in aggregate over a quarter, though, a pattern jumps out: overrides pile up on applicants with one particular impairment, the caseworkers almost all override in the same direction, and those overrides are overwhelmingly upheld on appeal. That cluster is not noise — it is the rule telling on itself. The log routes the finding to recalibration: the eligibility rule scores that impairment wrong, and its boundary needs redrawing. Exceptions became a repair signal instead of a nuisance.
How it works¶
The log works by (1) capturing every departure from the default as a structured event — case, direction of override, reason code, and decider; (2) linking each event to its eventual outcome or appeal result; (3) aggregating across events to find where overrides concentrate; and (4) reading a cluster of upheld overrides on a case type as evidence of a boundary defect worth escalating to recalibration. Its distinctive feature is the event-stream shape: it accretes one row at a time from real operations, so the signal it carries is empirical and continuous, not a periodic snapshot.
Tuning parameters¶
- Reason-code structure — how much structure the "why" field carries; free text is easy to enter but hard to aggregate, coded reasons aggregate cleanly but can force real reasons into wrong boxes.
- Pre-authorization vs. log-only — whether an override needs sign-off first or just needs recording; pre-authorization controls risk but slows the case and suppresses honest departures.
- Cluster threshold — how many concentrated overrides trigger a boundary review; a low threshold catches defects early but chases noise.
- Retention and visibility — how long records live and who sees them; longer retention strengthens the signal, but the more punitive the visibility, the weaker the signal becomes.
When it helps, and when it misleads¶
Its strength is dual: it surfaces where the default method is wrong (clustered upheld overrides) and, read the other way, where automation bias[n1] is suppressing overrides that should be happening (a method that is never overridden even where it errs). It converts the friction of exceptions into the raw material for improving the boundary.
Its characteristic failure is that the moment logging is used punitively, the signal dies — people stop overriding when they should, or stop logging honestly, and the log fills with defensive non-reasons. A classic misuse is treating every override as deviance to be minimized, which optimizes for a quiet log rather than a correct method. The guarding discipline is to keep logging strictly non-punitive and to review clusters rather than individuals, so caseworkers experience the log as a channel for fixing the rule, not as surveillance.
How it implements the components¶
human_override_pathway— the log is the sanctioned channel and record for departing from the default; it makes overriding a first-class, captured action rather than an off-book workaround.heuristic_validity_boundary— clustered, upheld overrides are read as direct evidence that a method's validity boundary is mis-set, feeding a specific boundary revision.calibration_feedback_loop— the accumulating stream of departures and their outcomes is a continuous input to recalibration of thresholds and rules.
It does NOT statically document a method's intended use, constraints, and review owner — that per-method spec sheet is the Model or Rule Card, which implements method_portfolio_registry. The card describes the method; this log records what people did against it, one departure at a time.
Related¶
- Instantiates: Heuristic vs. Algorithm Tradeoff and Selection — the log realizes the archetype's "accountable override" invariant, keeping departures recorded and turning them into feedback.
- Consumes: Decision Method Triage Matrix — the log records departures from the default lane the matrix assigned, so the matrix defines the "default" a departure is measured against.
- Sibling mechanisms: Decision Method Triage Matrix · Stakes–Latency–Error Scorecard · Heuristic Boundary Checklist · Algorithmic Escalation Protocol · Shadow-Mode Method Comparison · Retrospective Error Calibration Review · Model or Rule Card
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Override and Exception Log operates as a persistent ledger, log, register, or case record that preserves history and traceability because it records when users depart from the default method, why, and whether exceptions reveal a boundary failure.
Independent corroboration: The frozen evidence defines Override and Exception Log as 'Records when users depart from the default method, why, and whether exceptions reveal a boundary failure', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Override and Exception Log is most directly rooted in organizational and management science's practice of coordinating people, authority, strategy, knowledge, and work. The lineage fits its defining practice: Records when users depart from the default method, why, and whether exceptions reveal a boundary failure.
Related originating lineages:
- Law & Governance — Override and Exception Log also draws materially on law and governance's development of rights, duties, procedures, oversight, and legitimate authority, which shaped this mechanism rather than merely adopting it as an application.
- Ethics of Technology & AI Governance — Human override, automation bias, and algorithmic accountability materially shape the log when defaults are automated.
Review resolution: Both independent reviews agree on primary origin organizational_management; reconciliation resolves alternate_origin_disagreement. Formative alternate lineages retained: law_governance, tech_ethics_ai_governance. The broader reach of later applications is kept separate as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records how the formative lineages relate. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=false preserves the reviewers' boundary judgment.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Automation bias — the tendency to over-trust automated recommendations and under-use human judgment to correct them, so wrong machine outputs get rubber-stamped. A method that generates errors yet is almost never overridden is a warning sign of automation bias, which the log is positioned to detect. ↩