Refinement Readiness Checklist¶
Decision checklist — instantiates Refinement Timing Guardrail
A fixed list of pass/fail criteria every proposed refinement must satisfy before it is allowed to proceed — the gate rendered as an explicit, repeatable checklist.
Judgment is inconsistent; a checklist is not. Refinement Readiness Checklist turns the guardrail's readiness gate into a fixed, itemized set of pass/fail criteria that every proposed refinement must clear before work starts — no meeting, no debate, just the same questions asked the same way each time. Its defining move is that it is a standing artifact rather than an occasion: the criteria are written down in advance and applied uniformly, so whether a refinement is ready doesn't depend on who's in the room or how persuasive the proposer is. Each item is phrased to be answerable yes or no with evidence — "is the requirement this serves stable?", "is the whole-system metric it targets defined?", "is the change reversible?" — and every item must pass. A single failed criterion holds the refinement, and the checklist names exactly which one, so the path to readiness is explicit.
Example¶
A database platform team maintains a checklist that any schema or storage optimization must pass before implementation. An engineer proposes denormalizing a heavily-joined set of tables and adding a materialized view to speed up the analytics dashboard. He runs it through the checklist:
(1) Is the query pattern stable? — No; the analytics team is still adding report types weekly, so the join shapes are moving. (2) Is there evidence this join is the actual bottleneck? — Partially; one slow dashboard, but no profiling under representative load. (3) Is the whole-system metric defined? — Yes: dashboard p95 load time. (4) Is the change reversible? — No; a materialized view plus denormalized columns hardens the schema, and downstream ETL jobs would start depending on the new shape, making rollback expensive. (5) Is the acceptable-roughness boundary respected — can the current schema stay correct and legible if we wait? — Yes.
The checklist stops the work on items 1, 2, and 4: the requirement isn't stable, the bottleneck isn't proven, and the lock-in is high. The refinement isn't rejected — it's not ready — and the failed items double as the to-do list that would make it ready: stabilize the query patterns, profile under real load, and design a reversible migration. Three months later, with those items now passing, the same proposal sails through the gate.
How it works¶
- Fix the criteria in advance. The checklist is authored once for a class of refinements and reused, so the bar doesn't move proposal to proposal.
- Make each item binary and evidenced. Every criterion is phrased to be answered yes/no against a fact, not an opinion — a stable requirement, a defined metric, a demonstrated reversibility.
- Require unanimous pass. The gate opens only when all items clear; any single failure holds the refinement and identifies precisely what is missing.
- Turn failures into a punch-list. A failed item is not a verdict but a prerequisite — the set of failed criteria is exactly the work needed to become ready.
Tuning parameters¶
- Criteria set — which questions the checklist asks and how many. More criteria catch more premature refinements but slow every proposal and risk box-ticking fatigue.
- Strictness of "pass" — how much evidence each yes demands (a stated intention vs. profiled proof). Stricter passes are more trustworthy but raise the cost of clearing the gate.
- Scope of applicability — which refinements must run the checklist at all; a low threshold gates everything including cheap reversible tweaks, a high one lets small work skip it.
- Revision cadence — how often the criteria themselves are updated as the team learns which questions actually predicted trouble.
When it helps, and when it misleads¶
Its strength is consistency and transparency. Like the surgical checklists Atul Gawande documented[1], it works by making the easy-to-skip-under-pressure step unskippable and identical every time, so a refinement's readiness stops being a matter of who argued hardest and starts being a matter of which facts are true. The failed items being self-documenting makes the checklist doubly useful: it both blocks premature work and prescribes the route to readiness.
Its failure mode is checklist theater: items get ticked mechanically, "yes" is asserted without evidence, and the gate becomes a formality that launches unready refinements with a clean paper trail. A checklist also can't weigh criteria against each other or handle the genuinely novel case its authors didn't foresee — it is blind to anything not on the list. The guarding discipline is to demand evidence behind each check rather than a checkmark, and to keep the criteria alive by revising them whenever a refinement passed the list yet still went wrong.
How it implements the components¶
refinement_readiness_gate— the checklist is the gate: a refinement proceeds only when its fixed criteria all pass.acceptable_roughness_boundary— one standing criterion tests whether the current rough state can remain correct and legible if the refinement waits, encoding the boundary explicitly.reversibility_and_lock_in_assessment— a criterion asks whether the change is reversible and what lock-in it creates, making lock-in a gating fact rather than an afterthought.
It does not implement complexity_budget — weighing a refinement against the team's shared appetite for complexity is done in live judgment by the Pre-Optimization Review Ritual; the checklist applies fixed criteria rather than a negotiated budget.
Related¶
- Instantiates: Refinement Timing Guardrail — the checklist is the readiness gate made explicit and repeatable.
- Sibling mechanisms: Pre-Optimization Review Ritual · Optimization Backlog with Trigger Conditions · Decision Record with Deferred Refinement · Representative Workload Profiling · Local–Global Metric Trace · Architecture Skeleton or Walking Skeleton · Reversibility Tag or Feature Flag · Timeboxed Optimization Spike
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Refinement Readiness Checklist operates by imposes a stable reusable binary evidence bar that every proposed refinement must satisfy. That concrete deployed or enacted form is Rule, Policy & Commitment under the frozen taxonomy.
Nearest alternative: Interface, Display & Cue — Although Interface, Display & Cue can support this mechanism, the frozen evidence makes its operative form the act that imposes a stable reusable binary evidence bar that every proposed refinement must satisfy; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Explicit pass/fail entrance criteria before advancing a refinement are systems-engineering lifecycle-gate practice; management supplies repeatable authorization governance.
Related originating lineages:
- Organizational & Management Science — Stage-gate governance materially supplies authorization and repeatable decision ownership.
Review resolution: The blind reviewers disagreed on primary lineage. Light authoritative research resolves the defining form in favor of engineering_design: Explicit pass/fail entrance criteria before advancing a refinement are systems-engineering lifecycle-gate practice; management supplies repeatable authorization governance. The rejected primary is retained only when it materially shaped the mechanism, and present-day breadth is recorded separately as domain_reach=multi_domain.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
References¶
[1] Gawande, A. The Checklist Manifesto: How to Get Things Right. Metropolitan Books (2009). Documents Atul Gawande's discussion of surgical checklist use, including the WHO surgical checklist. registry ↩