Effect Review Checklist¶
Checklist — instantiates Declared Effect Boundary Enforcement
Prompts designers or operators to ask what shared state an action can change beyond the declared interface.
Effect Review Checklist is a fixed list of questions, run by a human at design or review time, that forces the enumeration of an action's real effect surface before it ships. Its defining trait is that it is a cognitive prompt, not a control: it neither declares a contract nor enforces one — it makes a person look, deliberately, at the places hidden effects hide. Each item pushes the reviewer to name a dimension that "it's basically read-only" tends to gloss over: which shared surfaces can this touch, who expects that, who authorized it, how would we detect a surprise, how would we undo it. The output is an inventory of candidate effects and flagged risks that other mechanisms can then formalize.
Example¶
An avionics team requires an effect review on every firmware change before it reaches the integration branch. A change described in the ticket as a "logging tweak" comes up for review. Working the checklist, the reviewer hits item one — what shared state can this touch beyond its own module? — and the author, forced to answer concretely, realizes the tweak also writes a shared configuration register. Item two — who else reads that state? — surfaces that the autopilot subsystem reads exactly that register at startup.
The checklist has changed nothing in the code and blocked nothing. What it did was convert an unexamined "harmless logging change" into a named, cross-subsystem effect on the review record, early enough that the team can decide to isolate the register write, declare it, or drop it — instead of finding it during a flight-test anomaly. The value is entirely in having asked the question at the right moment.
How it works¶
- Fixed prompt set. A short, standing list of questions is run the same way every time, so the enumeration does not depend on the reviewer happening to think of the right worry.
- Dimension per item. Each question targets one place effects hide — surfaces, expectations, authority, detectability, reversibility — so gaps are covered by construction rather than by inspiration.
- Written answers. Items are answered in words, not ticked, so "no hidden effects" has to be defended rather than assumed.
- Recurring cadence. The same review is re-run as the system evolves, catching effect surfaces that new dependencies and callbacks add over time.
Tuning parameters¶
- Item set — which questions the list asks and how many. More items catch more, but a long checklist invites mechanical box-ticking.
- Gate strength — advisory prompt versus a hard sign-off nobody can bypass. A hard gate catches more but slows every change.
- Specificity — generic questions versus domain-tailored ones ("does this touch the eligibility flag?"). Tailored items catch known traps; generic ones travel to new cases.
- Reviewer independence — self-review versus a second party. An outside reviewer resists the author's optimism about their own action.
When it helps, and when it misleads¶
Its strength is that it is the cheapest possible starting point — no tooling, no runtime change — and it directly attacks false purity by making a human enumerate an action's footprint instead of assuming it.[n1]
Its failure mode is checkbox theater: run mechanically, the list is ticked without thought and launders a hidden effect as "reviewed." Because it relies wholly on the reviewer's honesty and imagination, it catches only what someone thinks to look for. The guarding discipline is to keep the list short enough to actually engage with, demand written answers, and route every flagged risk to a mechanism that can formalize or enforce it — the checklist starts the process, it does not finish it.
How it implements the components¶
shared_state_surface_inventory— its core output: a human-generated enumeration of every surface the action can plausibly touch, including the incidental and indirect ones.side_effect_review_loop— re-run on a cadence, it is the standing loop that compares an action's assumed footprint against its evolving real one before incidents accumulate.
It does NOT implement declared_effect_contract or mutation_gateway — the checklist raises the questions; writing the binding contract is Effect Contract Annotation and enforcing it at the write path is Command–Query Separation.
Related¶
- Instantiates: Declared Effect Boundary Enforcement — the low-cost discovery step that feeds every heavier mechanism.
- Sibling mechanisms: Audit Log and Trace · Command–Query Separation · Compensating Action Protocol · Effect Contract Annotation · Immutable Data or Copy-on-Write · Permission Scope or Capability Token · Sandbox or Staging Execution · State Diff Test · Transaction Boundary
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Effect Review Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it prompts designers or operators to ask what shared state an action can change beyond the declared interface.
Independent corroboration: The frozen evidence defines Effect Review Checklist as 'Prompts designers or operators to ask what shared state an action can change beyond the declared interface', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software design practice supplies the concern with hidden side effects across shared state and interfaces.
Related originating lineages:
- Engineering & Design — Safety and design review supplied the human checklist form for systematically surfacing effects before release.
Review resolution: The current reviewers agree that computer_science is primary. For the reported differences (reported_ambiguity, alternate_origin_disagreement, origin_mode_disagreement), the evidence supports cross_disciplinary_synthesis, multi_domain, and engineering_design; these choices preserve materially formative origins without conflating later domain reach.
Attribution caveat: This is a synthesized review aid rather than a historically standardized effect-system artifact.
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 in complex, high-stakes work the failure is rarely ignorance but the predictable slip of not checking what one already knows to check; a short, forcing checklist guards against exactly that lapse. The effect review applies the same logic to hidden side effects. ↩