Blocker Register¶
Document — instantiates Necessary-Condition Closure Design
Records missing, weak, unknown, stale, or waived conditions and their decision path.
A Blocker Register is a running, shared document that records only the problem members of the condition set — the prerequisites that are missing, weak, unverified, stale, or waived — together with each one's disposition and the person accountable for moving it. Where a checklist asks "are all items satisfied?", the register answers a narrower question about the ones that are not: what exactly is the plan, who owns it, and when does that plan expire? Its identity is the disposition ledger. Nothing on it may sit in the ambiguous state of "known-bad but unaddressed," and a waiver on it is a dated, owned exception — never a quiet re-coloring to green.
Example¶
A private-equity firm is closing the acquisition of a regional logistics company. The purchase agreement lists conditions to closing — clean title on the fleet, antitrust clearance, a financing commitment, a key-customer consent, and a Phase I environmental report. Most are done. The deal team keeps a Blocker Register for the rest. Antitrust clearance is pending (owner: outside counsel; disposition: wait, expected date logged). The key-customer consent is at risk (owner: the deal lead; disposition: escalate to the seller's CEO). The environmental report flags a stale survey from a prior owner (disposition: commission a fresh Phase I, or negotiate an escrow holdback as a compensating control). Each row states the condition, its status, the chosen move, the owner, and the review date. When counsel proposes simply waiving the customer-consent condition to hit the closing date, the register makes that visible as an explicit, signed risk-acceptance with an expiry — not a silent deletion — so the partners decide it with eyes open.
How it works¶
One row per unsatisfied or exception condition. Each row carries a status (missing, weak, unknown, stale, or waived), a disposition drawn from a fixed menu (repair, delay, compensating control, explicit risk-acceptance, redesign), an accountable owner, and a review or expiry date. Waivers are first-class entries with expiries so they cannot become permanent by neglect. Closed rows are retained rather than deleted, so the register doubles as the memory of which exceptions were ever taken and why.
Tuning parameters¶
- Status taxonomy — coarse (blocked / clear) versus fine (missing / weak / unknown / stale / waived). Finer status drives better dispositions but demands honest classification.
- Waiver expiry policy — whether every waiver must carry an expiry and re-review, or some run open-ended. Mandatory expiries fight drift; open-ended ones reduce churn but rot.
- Escalation trigger — how long a row may sit unmoved before it auto-escalates. Tight triggers keep momentum; loose ones tolerate slow external dependencies.
- Visibility — a private working doc versus a broadcast to all stakeholders. Broadcasting raises accountability and social pressure but can politicize dispositions.
When it helps, and when it misleads¶
Its strength is that it converts a fog of "some stuff isn't ready" into a finite, owned, dated list of exceptions, and it is where accountability for the unmet conditions actually lives. Its signature failure mode is waiver drift sliding into normalization of deviance[n1] — each individual waiver looks reasonable, but the accumulation quietly redefines a missing prerequisite as an acceptable normal. A related misuse is the register that grows without ever closing — a graveyard of stale rows nobody prunes. The guarding discipline is mandatory expiries on waivers, periodic re-review that forces each open row to move or escalate, and treating a lengthening waiver list as itself a red flag about the gate's integrity.
How it implements the components¶
condition_evidence_record— each row captures why a condition is currently unsatisfied: unknown, stale, or weak evidence, with its recency and validator noted.blocker_decision_rule— the disposition field enforces that every problem condition takes a valid closure move (repair / delay / compensate / accept-risk / redesign) rather than a silent assumption.exception_or_waiver_record— waivers are logged as dated, owned, expiring exceptions, the register's most load-bearing feature.
It does not enumerate the full standing set of hard conditions (necessary_condition_set) under a stated outcome (success_predicate) — that complete forward list is All-Conditions Checklist — and it does not rank which unmet condition is the current bottleneck (weakest_condition_margin); that is Limiting-Factor Board.
Related¶
- Instantiates: Necessary-Condition Closure Design — the register holds the exception state of the closure gate.
- Consumes: All-Conditions Checklist — the checklist surfaces the unmet items; the register logs and dispositions them.
- Sibling mechanisms: All-Conditions Checklist · Condition Coverage Test Suite · Dependency Closure Map · Go/No-Go Condition Review · Limiting-Factor Board · Preflight Review · Readiness Gate Scorecard without Averaging · Red-Team Precondition Challenge · Weakest-Link Postmortem
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Records missing, weak, unknown, stale, or waived conditions and their decision path, making its operative form a durable account of actual events, decisions, or transitions whose value depends on history or provenance.
Independent corroboration: The frozen evidence defines Blocker Register as 'Records missing, weak, unknown, stale, or waived conditions and their decision path', 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: Project and risk governance keep a shared exception ledger of unmet prerequisites, dispositions, accountable owners, and expiring waivers.
Related originating lineages:
- Accounting & Auditing — Accounting and audit practice contributes the ledger, reconciliation, control, or financial-record discipline used here.
- Law & Governance — Law and governance contribute the charter, contract, adjudication, rights, disclosure, or procedural-accountability form used here.
Review resolution: Project and risk governance supply the primary register practice. Accounting and audit contribute exception-ledger retention, while governance contributes explicit, authorized, expiring waivers; those ingredients justify cross-disciplinary synthesis, but the artifact has multi-domain rather than literally universal reach.
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.
Notes¶
[n1] Normalization of deviance — Diane Vaughan's term, from her analysis of the Challenger disaster, for the process by which a repeatedly tolerated out-of-spec condition gradually comes to be treated as normal and acceptable. ↩