*Published July 14, 2026* --- A rule in your review checklist can be doing nothing, and you would never know. If a capable model would have caught the bug anyway, the rule sitting above it takes the credit. It looks load-bearing and is inert. Multiply that across a checklist nobody prunes and you are trusting a document that is half real, half decoration, with no way to separate the halves. So I started testing mine. Here is one line from the review procedure I run against my own agent skills: > (Reworded 2026-07-11 after the noun-hunt phrasing failed its transfer verify; the reworded commands-you-run form VERIFIED same day — Sonnet caught both fresh instances, including one the premium missed, Haiku caught one.) That is a rule carrying its own experimental status: encoded from a live defect, tested against cheaper models than the one that authored it, failed, reworded, retested, verified. Other rules in the file say "Transfer PENDING." It is a procedure and its own lab notebook at once. ## No defect, no rule The skill grew from 131 lines to 170 in five days, across 14 commits. Growth like that is usually bloat. What keeps it honest is the slot rule: no rule enters the file without a live defect that opened the slot, and the origin stays stamped in the text. The two-sided contract-reviewer requirement cites the sweep where a Blocker "lived *between* two skills," told in [The Bugs That Hide Between Your Agents](https://para.ngpcloud.org/the-bugs-that-hide-between-your-agents). The author-side fix phase exists because 3 of 4 second-pass Majors were defects introduced by the first pass's own fixes. The defect-class catalog grew from 4 classes to 12 the same way, each batch stamped with the sweep that produced it. The seed observation, from [Red-Teaming Your Own Agent Infrastructure Finds Live Defects](https://para.ngpcloud.org/red-teaming-your-own-agent-infrastructure-finds-live-defects): prose about infrastructure drifts from the infrastructure itself. ## Does the rule transfer? Origin-stamping is the first gate. The second: when a cheaper model runs the procedure, does the rule still fire? A rule that only works when a premium model applies it is not encoded procedure. It is latent behavior in the expensive model, and the file is taking credit for it. The cheap tier is the one I can afford to point at everything, so a rule that transfers gets applied constantly; one that does not gets applied only when I remember to pay. Pin a snapshot of the skill. Strip the answers out. Run five random skills plus clean controls through two cheap tiers told nothing. Ground truth comes from a premium pass. Reports grade findings Blocker down to Nit and end in a verdict; PROCEED means clean. Strip the ceremony and the floor is low: a pinned commit, one defect you already know about, a cheaper model told nothing. Every number here is pilot-strength, one run per tier per input. In the first round Sonnet recalled 7 of 8 ground-truth Majors; Haiku 6.5, a partial catch at half credit. The rounds double as live-defect hunts: round 5 caught `git diff HEAD` silently excluding new untracked files in a code-review skill. Both cheap tiers filed it as a Blocker. The premium pass had missed it, so new valid findings are a scored column: premium ground truth inherits premium blind spots. ## Failed, reworded, verified The best round is the one where a rule failed. Origin-case-residue: fragments of the founding example fossilized into what should be a general rule. It entered phrased as a noun-hunt: flag domain nouns carried over from the origin case. Round 2 falsified it, 0 for 2: in a domain-specific Rails skill, everything is domain nouns. Reviewers had no way to separate illustrative examples, which are fine, from executable commands hardcoding origin identifiers, which are the defect. The results file recorded the decision: "REWORDED, not reverted (the class caught a real live defect when premium applied it)." The class was real. The falsified hypothesis was the wording. Reworded to a commands-you-run form, it verified the same day: once the rule named something a reviewer could grip, the cheap tier caught both fresh instances, including one the premium missed, on the class the premium had originated. The asymmetry is real: the ratchet has only gone up so far, and every FAILED verdict has bought a rewording, not a removal. A class that fails its verify again would not have that defense. ## Scoring my own model of the models Each round opens with pre-registered predictions, scored at the end: 1 of 4 correct, then 4 of 5 once I stopped assuming capability rises monotonically with tier. In five rounds, no cold cheap-tier report has ever returned PROCEED, 0 for 52. A cold cheap tier can enumerate candidate findings. In 52 tries it has not certified one clean. The most repeated cheap-tier failure was not judgment: seven times, Haiku named a finding in its own analysis and dropped it from the findings list. That produced a scoring rule: score the whole report, not the findings block alone. ## The instrument catches itself Building round 5's answer-stripped snapshot exposed a defect in the skill under test: a stale "transfer unverified" parenthetical beside its own "VERIFIED same day" note. The internal-contradiction class the skill teaches was living in the skill itself. Fixed before the round ran. [Self Updating Spec as Living Document](https://para.ngpcloud.org/self-updating-spec-as-living-document) argues static specs become lies. I would push it further: even a self-updating spec lies between updates. The harness was positioned to catch it. ## Living instrument, immutable verifier [Evaluator Immutability Prevents Autonomous Agents From Grading Their Own Work](https://para.ngpcloud.org/evaluator-immutability-prevents-agents-grading-own-work) holds that any self-improving loop needs a verifier the loop cannot rewrite. A skill that went through a dozen versions in five days looks like a violation. It is the opposite. The skill is not the verifier; it is the subject. The verdicts come from outside: pinned snapshots it cannot edit, separate-pass ground truth, blind scoring, controls it does not know about. The discipline reduces to two gates per edit. A live defect opens the slot. A transfer verdict, VERIFIED, PENDING, or FAILED, decides what stays and in what words. I cannot tell you the loop reduced my defect rate; no before-and-after measurement exists. What I can tell you is which of my rules fire on cheap tiers, which are pending a real test case, and which one failed and why. A rule that has survived a real attempt to falsify it is a result. A rule that has never been tested is just a sentence you keep re-reading.