Skip to main content

Controls That Cannot See What They Guard

In one line: a control that exists, is correct, and audits the wrong property is more dangerous than a missing one — it is counted as coverage, and it can pass the very defect it was written to stop.

Evidence. One day, one repository: thirteen review findings — ten of them P1 — in the day's own new code, from an author whose commit prose was the best writing of the day. Nothing defective shipped; the review gate held. What failed was the rate of creation, and the shape was two mistakes repeated, not thirteen problems.

Then the harder measurement. The repository's four purpose-built reviewer agents were run, each with fresh context, against five of those defects. All four scored 0 of 5. Three of the five files would not have been dispatched to any of them. Their own diagnosis, reached independently by two of them:

every checklist audits whether a mechanism exists — provenance recorded, response_model declared, RLS forced — and never whether a determination is true.

Every defect had flawless machinery and said something false.

Worse than a gap, the compliance reviewer's line "System can ADD scrutiny but NEVER suppress risk signals" ticks green on a fabricated finding: rendering a false adverse result adds scrutiny. The invariant is bidirectional; the wording was not. The same one-directionality sat in the PR checklist, where the author ticked "no silent suppression" truthfully while a false clear was in the diff — nothing was suppressed, because the check never ran.

R165 — The reader roll-call. Adding a field, state or flag that qualifies an existing one is not finished until grep for the qualified thing has been run and every hit is either updated or named as deliberately unchanged. The grep output goes in the commit message. If it is not there, the change is a hypothesis about its consumers and is written as one. Two triggers, one instruction — grep the thing you are qualifying: a guard added beside a value, and a gate added in front of a capability (grep the resource, not the function).

R166 — The predicate roll-call. Before writing a boolean over a set of fields, grep the module for an existing predicate over those same fields. Name it in the diff, or state that none exists. The instance that produced this rule had its canonical predicate 140 lines up in the same file, exported, with the violated invariant written in its own docstring: "the ONE predicate every gap-consuming branch reads ... so the three cannot drift apart."

R167 — A compliance tick needs a reviewer, not an author. A compliance-facing diff does not take its checklist ticks from the person who wrote it. A reviewer with fresh context runs on the diff and its report is attached. A tick with no attached report is a self-assertion, and §7 already records that assertions are not evidence. Dispatch is decided from git diff --name-only, never from judgement about relevance — the failure being fixed is that dispatch depended on someone remembering.

Two corollaries carry as much weight as the rules:

  • A ticked box is a dispatch trigger, never a substitute. Nothing in a PR body may suppress a review.
  • Silence is not clearance. A reviewer ends by listing the changed files it did not cover, and why. An unreviewed surface currently looks identical to a reviewed one.

The camouflage clause (amends §2.3). The canon's own vocabulary is the most convincing camouflage available. Fail-closed, never-suppress, presence ≠ evidence can be written fluently about code that was never checked. §2.9 records that proximity to a real measurement is what makes an unmeasured claim feel measured; proximity to correct vocabulary does the same thing, more cheaply. Prose quality is not evidence of care and can be inversely correlated with it — when the commit messages get good and numerous, read the diff.

Why these are greps and reports rather than a call for care. §5.4 already says the controller "directs, reviews, and decides" and never implements, and calls long-session degradation "a structural property of context-window management, not speculation." That rule was not repealed on the day above; it was simply not run, by an author who could quote it. A control whose firing depends on the state of the person it constrains is not a control. Every rule here produces an artifact — grep output, a named predicate, a reviewer's report — that is either in the commit or is not.

Declared limits, so the numbers are not read as assurance.

  • Amended checklists took the reviewers from 0/5 to roughly 4.5/5 on the defect set they were written against — exactly the condition under which such a figure flatters. All five were found by a person reading a diff, not by any checklist.
  • R165 and R166 demand the author name what a grep returned. Nothing verifies the grep ran. They are the weakest members of this set.
  • The self-assertion problem is routed around, not solved. A checklist tick remains unfalsifiable; R167 only stops a tick from suppressing a review.
  • One repository, one day. Two of the five defects were found only because a reviewer was built and blind-tested that night; a fifth surfaced in the fix for another, after an external reviewer had already passed that fix.