Governance patterns — instruments that keep a rule enforced
The class of failure
A declared rule is not an enforced one.
A rule that is checked once, or checked by one broad review, leaves a gap that widens silently — a grant outlives its reason, an over-claim slips past a reviewer weighing everything at once. The class is policy that erodes between checks: release safety, compliance, access control.
What it is
Two patterns, one class — rules that are declared but not enforced, checks that run once and then drift silently. The first is ship-panel, an adversarial multi-judge review that gates what ships; the second is access-as-code, an access control paired with a standing reconciliation loop. Both convert a rule from declared to enforced by making the check a standing process rather than a one-time act.
/vetit) and runs over repositories, bundles, and single files. access-as-code is a pattern, applied across physical and system-access contexts rather than packaged as a single tool.Where it generalizes
The same panel shape runs over a repository, a bundle, or a single file; the same two halves apply to data access, system access, and credential issuance — anywhere a grant can outlive its justification. This is the governance / compliance layer — release review plus access reconciliation: IAM and change-control. The patterns travel because they are about an artifact's claims and an access set's drift, not a file type or a building.
The review panel
Six narrow questions beat one broad review.
A reusable, args-driven panel: six independent single-axis judges plus a synthesis step. It runs as the review stage of the ship-prep gate (/vetit) — an artifact does not ship until the report comes back CLEAR.
Why narrow seats
A reviewer asked to weigh everything at once lets a strength on one dimension paper over a weakness on another, and the failure that gets through is the one that fell between two concerns nobody owned. Six narrow seats remove the averaging: an artifact that reads well but over-claims fails the over-claim judge regardless of how clean it is elsewhere; an artifact that is accurate but pitched at the wrong reader fails the audience-fit judge on its own.
Single-axis by design
Each judge is given the artifact and one question — audience-fit, over-claim, sycophancy, defensibility — and told to answer that question and no other. The constraint buys decomposition; no dimension is owned by nobody.
Independent
No judge sees another's verdict before issuing its own, so there is no anchoring — none softens a call because a neighbor was lenient, none piles on because a neighbor was harsh. Six separate readings of the same artifact.
Adversarial by construction
Each judge is prompted to find the problem on its axis, not to confirm the artifact is acceptable. Because the default posture is suspicion, silence is a finding: no objection means the axis was examined and held, not skipped.
One synthesis sees the board
The seventh pass collects the six verdicts into a single report, sorting what blocks a ship from what merely advises. A block on any axis holds the artifact; the cost of six narrow reviews is paid by the machine, not the reader.
Args-driven, artifact-agnostic
The panel takes the artifact as an argument rather than being written against any one thing — the same shape vets a code repository, a written bundle, or a loose document. The axes travel because they concern claims and posture, not file type.
Repeatable by construction
A fixed, named set of axes makes the review re-runnable: the same artifact run twice is checked against the same six questions. CLEAR means a specific, re-runnable thing — not a reviewer's mood on a given day.
The reconciliation loop
The grant is the easy half to build.
Pair every access control with a standing reconciliation loop that checks the control is doing what it claims. The control grants or denies; the loop re-verifies, on a cadence, that the set actually holding access still matches the set intended to hold it — and surfaces any difference.
The control — one question, one instant
May this identity in, right now. It does not answer whether the set it currently admits is still the set that should be admitted — nothing in the grant-or-deny path is responsible for noticing the standing set has gone stale, so a control with no second half degrades silently.
The loop — reconcile on a cadence
A separate, scheduled process, independent of any single access event: compare the granted set against the intended set and emit the delta — entries present that should not be, entries absent that should be. It doesn't have to revoke automatically; surfacing the drift converts a silent divergence into a visible, actionable one.
How a standing set goes stale
Origin
The pattern came out of physical facility access: after-hours entry paired with a recurring reconciliation of who held access against who was supposed to. The mechanics were specific to a building; the shape is not. The same two halves apply to data access, system access, and credential issuance — and in each case the grant is the easy half to build and the reconciliation loop is the half routinely omitted, which is why the omission is the failure mode the pattern names.
What they share
The check becomes a standing process.
Both convert a rule from declared to enforced. The failure designed out is the same in each: a check that runs once, or that averages away the thing it should have caught, leaves a gap that widens silently.
| ship-panel | access-as-code | |
|---|---|---|
| Gates | Output — an artifact ships only on a CLEAR report | Access — the granted set against the intended set |
| The standing check | An explicit, repeatable, multi-axis review, run every time | A scheduled reconciliation, run on a cadence |
| Failure designed out | One broad review averaging away the finding | A grant that outlives its justification, unnoticed |
Running the instrument every time — and decomposing it so nothing falls between concerns — closes the gap.