Constraint Review Checklist¶
Procedure — instantiates Constraint Formulation
Prompts reviewers to check hard/soft classification, conflicts, scope, enforcement, exceptions, and stale assumptions.
A Constraint Review Checklist is a fixed sequence of prompts a reviewer runs over an already-existing constraint set to catch defects in the formulation itself — an unowned rule, a conflict with no tiebreak, a scope that has quietly drifted, an assumption that has gone stale. Its defining feature is that it is a meta-mechanism: it does not source, translate, or author any new constraint. It audits other people's constraints for governance quality and files findings. Where the rest of the archetype's mechanisms produce constraints, this one inspects them and asks whether each is owned, non-conflicting, in-scope, and still true.
Example¶
A model-risk team is responsible for the constraint set governing which machine-learning models are allowed to ship. Rather than re-reading everything from scratch each quarter, they run the constraint review checklist against the set. The prompts are deliberately generic: Does every constraint name an accountable owner? Do any two constraints conflict without a stated priority rule to break the tie? Does any constraint rest on an assumption that expires, and is a trigger set to revisit it when it does?
The pass surfaces three defects. Two constraints — a data-lineage rule and a rollback rule — have no named owner, so nobody is accountable when they need updating. A fairness-threshold constraint and a latency-budget constraint pull against each other with no rule saying which yields. And the "training data must be under twelve months old" constraint has no refresh trigger, so it will silently rot as the model ages. None of these are new constraints; they are holes in how the existing ones are governed. The checklist files them as remediation items with owners assigned, and the team fixes the formulation rather than the models.
How it works¶
The distinctive move is to work item-by-item against a set someone else built. Each prompt maps to a governance property a constraint ought to have — an owner, a conflict-resolution rule, a freshness trigger — and the reviewer records, for each constraint, whether the property is present. The output is not a decision about any option but a defect list with assignments. Because the same holes reappear as constraints accumulate, the checklist is run on a recurring cadence, which is what keeps a growing constraint set from decaying into orphaned, conflicting, stale rules.
Tuning parameters¶
- Audit depth — a fast presence-check versus a deep interrogation of each constraint's substance. Depth catches subtler rot but costs reviewer time and cannot run as often.
- Cadence — how frequently the sweep runs. Frequent review catches drift early but risks becoming rote; rare review lets defects compound.
- Reviewer independence — authored by the constraint owners themselves, or by an independent party. Independence catches blind spots; self-review is cheaper but forgiving.
- Pass bar — whether any open defect blocks sign-off or merely gets logged. A hard bar forces remediation but can stall work on trivial gaps.
When it helps, and when it misleads¶
Its strength is catching the quiet failure modes the archetype warns about — constraint theater, scope leakage, orphaned rules, stale lock-in — before they cause a bad decision. It is the mechanism that keeps a large, aging constraint set honest.
Its failure mode is becoming ritual: a checklist run for its own sake produces ticked boxes without judgment, certifying a set as reviewed while the substance rots underneath — presence confused for quality.[n1] The classic misuse is treating a completed checklist as evidence the constraints are good rather than merely examined. The guarding discipline is to rotate reviewers, sample-audit a few constraints in genuine depth rather than skimming all of them, and treat the checklist as a prompt for thinking, not a substitute for it.
How it implements the components¶
Constraint Review Checklist fills the governance-and-maintenance slice of the archetype — the part that keeps a constraint set well-formed over time:
constraint_owner— a core prompt verifies that every constraint names an accountable owner, and the review assigns one where it is missing.constraint_priority_rule— prompts surface unresolved conflicts and check whether a tiebreak exists to order the colliding constraints.update_trigger— prompts test whether each constraint's expiring assumptions carry a refresh trigger, and flag those that have already gone stale.
It does not itself source or translate any external hard_constraint, nor write the constraint_rationale behind one — turning laws and standards into binding, justified rules is the work of Legal Compliance Constraint; the checklist only audits whether that work was done well.
Related¶
- Instantiates: Constraint Formulation — the checklist is the governance procedure that keeps a formulated constraint set from decaying.
- Consumes: Requirements Constraint Specification — the authored constraint set it audits (any produced set will do).
- Sibling mechanisms: Acceptance Criteria · Budget / Time Limit · Design Constraint Document · Eligibility Rule · Legal Compliance Constraint · Optimization Constraint Model · Policy Rule Set · Requirements Constraint Specification · Safety Constraint
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Prompts reviewers to check hard/soft classification, conflicts, scope, enforcement, exceptions, and stale assumptions, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Constraint Review Checklist as 'Prompts reviewers to check hard/soft classification, conflicts, scope, enforcement, exceptions, and stale assumptions', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Requirements and systems-engineering review practice cohered checklist audits of constraint classification, conflicts, scope, enforcement, exceptions, and stale assumptions.
Related originating lineages:
- Law & Governance — Rule-governance practice contributes ownership, exception authority, conflict rules, and periodic validity review.
Review resolution: Requirements-review practice supplies the method, while governance contributes ownership and exception controls; the particular unified checklist is plausibly synthesized, so confidence remains moderate.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] Atul Gawande's The Checklist Manifesto argues that checklists catch predictable, avoidable omissions in complex work. Its own caution applies here: a checklist works only when it prompts genuine verification, and degrades into a box-ticking ritual the moment it is run to produce a completion record rather than to actually catch the omission. ↩