Default and Delegation Protocol¶
Protocol — instantiates Bounded-Rationality Decision Design
Routes routine choices to vetted defaults, automation, or qualified owners with override and exception logging.
A Default and Delegation Protocol disposes of the ordinary case before anyone deliberates about it. It is a standing rule that pre-commits, for a defined class of routine low-stakes decisions, what the answer is (a vetted safe default), or who is allowed to make it (a named qualified owner or an automation), so that the common case is closed without spending fresh attention on it. The idea that makes it this mechanism and not a sibling is pre-disposition of the routine: it settles the many uninteresting choices in advance, and its safeguards — an override anyone can invoke, and a logged trail of every exception — exist so that "closed in advance" never quietly becomes "closed to challenge."
Example¶
A mid-size company processes thousands of employee purchase requests a year. Left ungoverned, every laptop dock and software renewal would land on a manager's desk for a signature. The Default and Delegation Protocol replaces that with a standing rule: any purchase under $500 from an approved-vendor catalog is auto-approved and charged to the team's budget; purchases from $500 to $5,000 are delegated to the requester's direct manager under a written delegation-of-authority schedule; anything above $5,000, or from an unlisted vendor, falls out of the protocol entirely and must go to finance. Crucially, the rule ships with two safeguards. Any auto-approval can be overridden — a manager can pull a small purchase back for a look — and every override and every out-of-catalog exception is written to a log. The result is that the overwhelming majority of spend clears with zero deliberation, managers spend their attention only on the band that needs judgment, and the exception log is where anyone later asks whether the $500 line is drawn in the right place.
How it works¶
The protocol works by (1) defining the decision class it governs and, just as importantly, the conditions that put a case outside its scope; (2) assigning each in-scope case a disposition — a default value, an automated action, or a delegated owner with the authority to decide; (3) attaching an override path so the pre-committed disposition is a strong default, never a locked door; and (4) requiring that overrides and exceptions be recorded, so the rule stays inspectable and its boundary stays reviewable. Its distinctive move is that it removes deliberation from the common case on purpose — the saving comes precisely from not re-deciding what has already been decided well enough for this class.
Tuning parameters¶
- Default aggressiveness — how wide a band auto-resolves versus routes to a human. Wider defaults save more attention but enlarge the blast radius of a wrong default.
- Delegation depth — how far down authority is pushed and to whom; deeper delegation is faster and closer to the work but demands more trust and clearer competence boundaries.
- Override friction — how easy it is to pull a case back from its default; frictionless override protects agency but can erode the time savings if overused.
- Exception-logging granularity — how much of each override and out-of-scope case is captured; richer logs make the boundary auditable but add overhead.
- Default expiry / review cadence — how often the default and delegation schedule is revisited; without a cadence, a once-safe default silently outlives its context.
When it helps, and when it misleads¶
Its strength is that it converts a stream of repetitive choices into a governed, low-attention flow while keeping a paper trail — the routine gets cheap without going dark.
Its characteristic failure is default lock-in: a default that was safe when set persists unquestioned after the environment shifts, and because nobody re-decides it, nobody notices it has gone wrong. Defaults are sticky for a documented reason — status-quo bias makes the pre-set option the one people keep even when a better one is available[1] — which is exactly why a delegation protocol needs an expiry date and a live exception log rather than a "set it and forget it" posture. The classic misuse is delegation that moves the work without the authority or accountability, leaving an owner responsible for a decision they cannot actually make or a default no one owns. The guarding discipline is to review the exception log on a cadence and treat a rising override rate as the signal that the default's boundary has moved.
How it implements the components¶
default_and_delegation_rule— this is the protocol's core: the explicit assignment of each routine case to a default value, automation, or delegated owner.decision_context_boundary— the protocol states the class it governs and the conditions that eject a case from its scope, so "routine" is defined rather than assumed.accountability_and_transparency_contract— the override path and the exception log are the contract that keeps a pre-committed disposition inspectable and challengeable.
It does NOT watch a running method for anomaly signals and force a case upward via escalation_threshold — that is Algorithmic Escalation Gate. This protocol pre-disposes the ordinary case downward to a default or owner; the gate detects the extraordinary case and escalates it.
Related¶
- Instantiates: Bounded-Rationality Decision Design — the protocol is the archetype's default-and-delegation layer, the thing that keeps routine choices from consuming scarce judgment.
- Sibling mechanisms: Algorithmic Escalation Gate · Satisficing Threshold Rule · Timeboxed Search · Progressive Option Screening · Cognitive Offloading Aid · Two-Stage Review · Choice Architecture Simplification · Post-Decision Calibration Review · Decision Method Triage Matrix
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Default and Delegation Protocol operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it routes routine choices to vetted defaults, automation, or qualified owners with override and exception logging.
Independent corroboration: The frozen evidence defines Default and Delegation Protocol as 'Routes routine choices to vetted defaults, automation, or qualified owners with override and exception logging', so its operative form is Decision, Gate & Allocation.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Organization design cohered predelegation of routine low-stakes decisions to qualified roles or standing rules, with bounded authority, escalation, and exception logging.
Related originating lineages:
- Behavioral Economics — Bounded-rationality and default research supplied the attention-saving rationale and warning that preselected choices persist through status-quo bias.
Review resolution: Organization design cohered predelegation of routine low-stakes decisions to qualified roles or standing rules, with bounded authority, escalation, and exception logging.
Attribution caveat: Delegation is managerial, while combining it with vetted defaults and universal override produces a synthesis.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Samuelson, W., & Zeckhauser, R. "Status Quo Bias in Decision Making". Journal of Risk and Uncertainty 1(1), 7–59 (1988). Documents status-quo bias: decision makers disproportionately retain a preexisting or default option. registry ↩