Review Trigger Register¶
Reopening register — instantiates Regress Termination Rule
A living list of the events, thresholds, and failures that would reopen a closed decision — each with an owner who must act — so closure stays provisional and revisitable rather than permanent.
Terminating a regress means acting on an accepted base — but if that base can never be reopened, closure hardens into false certainty. A Review Trigger Register is the artifact that keeps closure provisional: a standing, living list of the specific events, thresholds, and failures that would invalidate the accepted base and force a fresh look, each paired with the owner who must respond and the residual doubts being watched. What makes it THIS mechanism is that it faces forward — it does not set the original stopping point or record why the base was accepted; it governs what would unstick it. It is how a decision gets to be both closed enough to act on and reopenable when the world moves.
Example¶
A bank deploys a machine-learning model to set credit limits. At approval, the decision is deliberately closed — but a review trigger register is opened alongside it. It enumerates what would reopen the model: the population-stability index drifts past a set bound, a fairness metric crosses its threshold, the appeal rate spikes, a relevant regulation changes, or twelve months elapse regardless. Each trigger names an owner — the model-risk lead — and the required response: re-validate within thirty days. The register also carries the residual uncertainties being watched, such as "validated on pre-downturn data; behavior in a recession is unverified." Ongoing monitoring of this kind is exactly what model-risk supervisory guidance expects.[1] The approval can now stand and the model can run, without anyone pretending the question is settled forever — the moment a trigger fires, a named person owes a review.
How it works¶
- Enumerate the invalidators. At closure, list the concrete conditions — new evidence, drift past a threshold, an observed failure, a legal change, an affected-party challenge, a calendar date — that would reopen the decision.
- Assign an owner and a response to each. A trigger with no owner is decoration; every entry names who must act and what acting means.
- Track the residue as watch-items. Carry the doubts left unresolved at closure as things to monitor, so a soft spot is watched rather than forgotten.
- Keep it living. Revisit the register itself as conditions change, retiring stale triggers and adding new ones.
Tuning parameters¶
- Trigger thresholds — how easily each condition fires. Tight thresholds catch problems early but risk constant reopening; loose ones keep stability but can let a base rot past usefulness.
- Coverage breadth — how many kinds of trigger are tracked. Broad coverage misses less; narrow coverage is maintainable but blind outside its list.
- Owner specificity — a named individual versus a diffuse team. Named owners get acted on; diffuse ones let triggers fire into the void.
- Cadence mix — event-driven triggers, periodic reviews, or both. Event-driven catches shocks; periodic catches slow drift the thresholds miss.
When it helps, and when it misleads¶
Its strength is holding the honest middle between two failures: a decision frozen forever and a decision relitigated daily. By pre-naming triggers and owners, it lets a closure be genuinely acted on while remaining genuinely reopenable, and it keeps residual uncertainty in view instead of quietly discarding it at the moment of closure.
Its characteristic decay is alarm fatigue and neglect: triggers that fire into an inbox no one reads, or a register that goes stale because nobody owns the register itself. Set thresholds too loose and closure becomes permanent while looking reviewable — the register run backwards, its triggers deliberately calibrated never to fire. Too tight, and it reopens everything and closes nothing. The discipline that keeps it alive is to assign named owners, periodically test that a trigger actually produces a review, and audit the register as a live object rather than a filing-cabinet formality.
How it implements the components¶
reopening_condition— the register is the enumerated set of conditions that would reopen the closed decision.burden_of_reopening— each entry fixes who must act and what they must do when a trigger fires, so reopening is owned rather than optional.uncertainty_residue— it carries the doubts left after closure as monitored watch-items, keeping them visible instead of discarded.
It does not set the original bar for closing (stopping_criterion → Decision Closure Criteria), decide who holds authority to reopen at the top of an escalation (authority_boundary → Governance Authority Chain), or record why the base was accepted in the first place (assumption_record → Assumption Log).
Related¶
- Instantiates: Regress Termination Rule — it is the mechanism that keeps a terminated regress reopenable.
- Sibling mechanisms: Decision Closure Criteria · Five Whys with Stop Rule · Assumption Log · Burden-of-Proof Rule · Evidence Sufficiency Rubric · Axiom Set · First-Principles Statement · Governance Authority Chain · Research Stopping Rule · Timeboxed Inquiry Record
Notes¶
A Review Trigger Register pairs naturally with Assumption Log but faces the opposite direction: the log records what base was accepted and why, while the register records what would unmake it. Kept together they form a complete accountability loop; kept apart, a team can know its assumptions without ever noticing when one has quietly stopped holding.
References¶
[1] Ongoing monitoring and periodic revalidation of deployed models — reopening a model when performance drifts or conditions change — is a core expectation of model-risk management guidance (e.g., the U.S. supervisory guidance SR 11-7). It is a real institutional instance of pre-naming what would reopen a closed decision. ↩