ADR VERIFICATION GATE

adr-verification-gate.md

Fixture Bindability discipline. Every ADR's verification gate must include 'Can the gate FAIL under this fixture?' Refactor-correctness is not fix-correctness.

Stark

WHAT THIS PATTERN TEACHES

Why a 'bit-identical' refactor proof is not the same as a fix-correctness proof. How to construct fixtures that can bind (would detect regression if the fix were incorrect). The decision tree for verification gates.

WHEN TO USE THIS

Every ADR that ships with a verification gate. Pairs with /docs/methods/SYSTEMS_ARCHITECT.md §4.6 schema-vs-ADR cross-check and §4.7 implementation rehearsal.

AT A GLANCE

## Verification Gate

**Fixture:** <data set or scenario>
**Can the gate FAIL under this fixture?** <yes/no + algebraic rationale>
**Fixture-bindability proof:** <one sentence>
**Rehearsed at:** <commit-sha or "not yet">

FRAMEWORK IMPLEMENTATIONS

Markdown

## Verification Gate (paste into every ADR)

**Fixture:** <data set / scenario / runtime state used to exercise the gate>

**Can the gate FAIL under this fixture?** <yes | no + algebraic/empirical rationale>
  - If **no**: this is a refactor-correctness test, not a fix-correctness test.
    Add a fixture where the fix CAN bind, OR downgrade the verification claim
    to "preserves prior behavior" (a refactor proof, not a fix proof).

**Fixture-bindability proof:** <one sentence showing the fixture would detect
  regression if the fix were incorrect>

**Rehearsed at:** <commit-sha or "not yet" — see SYSTEMS_ARCHITECT.md §4.7>

**Implementation Scope (reality anchor):**
  - Status: Proposed | Accepted | Deferred
  - Deliverables exist at HEAD?
    - <path/1> — <existence-check command + result>
    - <path/2> — <existence-check command + result>
  - If any deliverable is missing: status MUST be "Proposed," not "Accepted."

← All Patterns