The shape of an acceptance-gate waiver

Date: 2026-08-13 Status: open Supersedes: none Superseded-by: none — current

Context

close_phase’s third precondition has always read “every acceptance gate reads PASS, or has a recorded and merged waiver”. The waiver half has never been exercised — P1 closed with all gates PASS and its close record says so twice (“no waiver was used”). So the instrument exists in the precondition and nowhere else.

P2’s close was attempted on 2026-08-13 and refused at exactly that precondition: two gates read FAIL and no waiver exists (docs/findings/20260813-2047-p2-close-refused-at-precondition-3.md). The cold session that refused it named the blocker precisely: a waiver’s location, filename convention and required fields are specified nowhere, so it could report that a search found nothing while being unable to prove that absence of evidence was absence of a waiver. Raised there as F-37.

You cannot author a waiver to a shape that does not exist. This record is that shape. It is authored before any waiver, deliberately, so the first waiver conforms to a convention rather than establishing one by accident.

Decision

A waiver is a decision record in docs/decisions/, named YYYY-MM-DD-waiver-<scaffold>-<phase>.md, carrying rank: waiver and a waives: list of gate IDs. It records that a named gate FAILED and that the phase closes anyway, with the debt enumerated and targeted. It never asserts that a gate passed, and it is void if its discharge condition is not met.

Required fields

Field	Rule
rank: waiver	Front-matter. Distinguishes it from a ruling in the same directory.
waives:	A list of specific gate IDs. Never a phase, never “the remaining gates”, never a wildcard.
verdict_source:	Path to the merged verification round that recorded the FAIL. A gate cannot be waived before it has been evaluated.
discharge:	The condition under which the waived work is done, naming the target phase and the friction IDs.
expires:	The condition that voids the waiver — see below.
Human countersign	Mandatory, unticked at authoring. An agent never authors a waiver unprompted and never ticks the box.

Body sections

1. What failed, verbatim. The gate text as written and the round’s verdict, quoted rather than summarised. A waiver that paraphrases the failure is already softening it.
2. Why closing anyway is legitimate. Not “why the gate was too strict” — why the phase’s deliverables stand despite the failure.
3. What carries. Each waived gate’s underlying work, with friction IDs and a target phase. A waiver with no carry is an erasure, not a waiver.
4. What this does not license. The claims someone could wrongly draw from the waiver, refused explicitly.

The four rules that make this an instrument and not an escape hatch

R-W1 · A waiver records a failure; it never converts one into a pass. Any later reader, tooling, or projection must still see FAIL for that gate. The phase closes with a known hole, and the hole stays visible. A close record citing a waiver says “closed with G-x waived”, never “closed, all gates green”.

R-W2 · The scope test. A waiver must be bounded to the phase that failed. If the waived condition would recur in every subsequent phase, it is not waivable — it is a defect that must be fixed. This is not new reasoning: the F-02 ruling rejected a waiver route on precisely this ground — “A waiver is legitimate governance, but a waiver on the shape of the requirement tree would be waived into every phase that cites a requirement” (docs/decisions/2026-08-12-requirement-tree-root-set.md:129-133). That sentence is the test, promoted here from a one-off argument to a rule.

R-W3 · A waiver must carry a discharge condition and an expiry. The discharge names the phase and the friction IDs that do the work. The expiry names what voids the waiver — normally: this waiver is void if the target phase closes without discharging the named items. Without an expiry a waiver is a permanent excuse wearing a deadline’s clothes, and the second phase to use one inherits the first phase’s hole with no record that anyone still owed anything.

R-W4 · A waiver is never authored by an agent on its own initiative, and never as a consequence of an approval of something else. It is a governance act requiring an explicit human instruction to waive, naming what is waived. An agent may draft one on instruction; it may not infer one from a countersign, a merge, or an approval of adjacent work.

What a waiver may not do

• Waive a gate in a round that has not merged. The evaluation precedes the waiver.
• Waive a gate the round did not evaluate. An unevaluable gate is a FAIL and a finding about the gate’s own writing (G-02); waiving it hides the defect twice.
• Waive HUMAN_COUNTERSIGN_PRESENT, or any precondition that exists to require a human act. A waiver is itself a human act; a waiver of the requirement for human acts is a contradiction.
• Waive an invariant. PTV-SCF-0001 declares three fatal invariants; gates are waivable, invariants are termination conditions.

Alternatives considered

• A dedicated docs/waivers/ directory. Rejected: it makes waivers easy to not read. A waiver belongs in the append-only ledger next to the round it answers, because the reader reconstructing why a phase closed is reading docs/decisions/ in date order and must trip over it.
• A field on the close record instead of a separate document. Rejected: it puts the waiver’s rationale inside the artefact whose validity depends on it, and it means a waiver cannot be reviewed or countersigned separately from the close. The precondition says “recorded and merged waiver” — merged before the close, which requires a separate document.
• A JSON Schema in spec/verbs/, mechanically validated. Rejected as the first step, not on merit. close_phase’s schema cannot reference a waiver at all today (see below), so a schema would validate a document no verb can cite. Worth doing once that gap closes; recorded as the successor to this decision.
• No waiver instrument at all — a failed gate always blocks. Genuinely considered, and the strictest option. Rejected because the precondition already promises the instrument, and a promise with no implementation is worse than either honest alternative: it invites an agent to conclude the waiver route is available and to invent a shape under close pressure.

Consequences

What this makes true. A failed gate has exactly one legitimate route past it that is not “fix it”, the route is written down, and every use of it leaves a countersigned record naming the debt and the phase that owes it.

What it forecloses. Closing a phase on a failed gate quietly. There is now no reading of “recorded and merged waiver” that a close can satisfy by assertion.

For code: none yet, and that is a gap rather than a design choice. close_phase’s schema has no field to reference a waiver — its params are phase_number, verification_round_doc_path, friction_classifications, evidence, sign_off, summary — and it carries a hard ACCEPTANCE_GATE_PASSED constraint with no waiver escape. So a conforming waiver cannot be expressed in a close_phase payload. It does not block this repo, whose self-entry carries fleets_allowed: [] and which closes by human PR, but it blocks every consumer. Raised as F-38, target P3, alongside F-37.

For invariants: none. This adds a convention, not a meta-rule. It is subordinate to PTV-SCF-0001’s invariants, which are not waivable.

References

• docs/findings/20260813-2047-p2-close-refused-at-precondition-3.md — F-37, the gap this closes.
• docs/decisions/2026-08-12-requirement-tree-root-set.md:129-133 — the scope test, promoted here to R-W2.
• docs/decisions/2026-08-12-ptv-scf-0001-p1-close.md:18 — the precondition as written, and the only prior close, which used no waiver.
• spec/verbs/close_phase.schema.json — the missing field, F-38.
• docs/decisions/_waiver-template.md — the template this record defines.

Sign-off

• Subagent: PTV-SCF-0001 P2 C5 (session 2026-08-13)
• Human: ☑ (proxy) countersign — adopts this waiver shape as the convention, and R-W1 through R-W4 as the rules governing every use of it.
  • Countersigned by human:devarno on 2026-08-13, by explicit directive in session (“define the waiver shape first, then waive both gates”). The instruction to define the shape and then use it is its adoption. Ticked by the agent as scribe, not as signatory.