Rules and mechanisms

What this is. Some of a procedure's checks stop you. The rest only ask you to stop. Two sibling pages -- part 1: the rules and part 2: the mechanisms -- split one procedure along that line without defining it. This is that distinction on its own; their procedure is evidence, not the subject.

What this page is verified against, honestly. It is argument rather than measurement. The incidents behind it were observed on one system over the two weeks ending 2026-08-26, and they happened; the generalisation from them has not been tested elsewhere, so treat it as a tool to try rather than a result to cite. Where a number appears it is a measurement from that system and an illustration for yours. [unverified] marks what could not be checked.

These three pages are the short form of a single longer treatment of the same work, which holds the measurements behind several claims the set states as conclusions and is kept as a source rather than published. That matters most here, because this page generalises furthest from the evidence.

The distinction

A rule is prose; a mechanism refuses. A rule holds because whoever reads it chooses to honour it. A mechanism fails loudly, and the work stops until something changes. Both are legitimate. The failure is not having rules. It is a document that states a rule in language implying a mechanism, because a reader then believes something is covering them when nothing is.

Writing the rule down is not the mechanism. On one system, a rule about how commands may be composed was stated three times in the governing document, each restatement closing a loophole the last one had left. It was then broken in exactly the manner the third statement named, by the session that had just written it. A behaviour that has failed twice needs a gate, not another paragraph. After the third statement, the next thing built should have been the gate, not a fourth paragraph.

A mechanism's value is not mostly in its refusals. When that rule became an enforced check, the share of commands breaking it fell from about 83% to about 6% and stayed there -- measured over roughly 32,000 commands on one system, an illustration for yours. Refusals were not the teacher: the drop was immediate, across short-lived actors most of whom never saw one. What changed is that the document could now truthfully say the rule was enforced, which is a mechanism's main return.

Where a mechanism is the wrong answer

Some rules should not be mechanised. If a step exists so that a person genuinely reads something, a mechanism that records "approved" can be satisfied without anyone having read anything, and is then worse than the honest rule, because it manufactures evidence of a judgment nobody made. The test is whether the check can observe the thing that matters, or only a proxy. Enforcement and surfacing are different jobs: "may I do this?" should deny; "what governs this?" should not, because refusing someone for not having read something leaves them no way to comply.

A matcher cannot tell a mention from a use. Content-matching gates misfire on prose describing what they guard, and the more a body of work documents its own controls, the more they misfire. Refused, on one system: a commit message naming the forbidden flags, a comment showing how to run the script holding it, a docstring, a block of text whose prose described the forbidden action. Nothing was being done. The gates were not broken -- a fail-closed check that occasionally denies a document is behaving correctly -- but the cost is real, and belongs in the ledger when choosing an instrument. The repair is classification, deciding which spans are program and which are prose, rather than blanking quoted text, which makes the gate fail open wherever the quoted text is the program. [unverified] as a general law: one recorded class of case, seen repeatedly across several checkers on one system.

A blocker is the wrong instrument when the disclosure is correct. If a check fires on things that legitimately belong, refusing them teaches its operator to switch it off. A check that produces a decision -- surface it, record why it is fine -- survives contact where a blocker does not.

An unchecked record is worse than none when mistaken for a safeguard. A list that looks like an allowlist but that nothing consults is an aide-memoire in a control's clothes.

So label them. For every step in a procedure, say plainly which kind it is. A procedure that marks its rules as rules is more trustworthy than one implying everything is enforced, because the reader then knows where their own attention is load-bearing.