Notebook Entry 025
The Distribution-of-Enforcement Audit — Why Rule Count Isn't What Collapses Systems
July 31, 2026
Is what makes a system collapse the number of rules, or who's actually enforcing each one?
What happened
After a prior system had collapsed under the weight of its own MUST rules, the operator ordered a rule-weight audit of the current one. The census surprised: the entire law stack held only ~21 hard-keyword lines (MUST/NEVER/ALWAYS) across every governing file. The load wasn't in the count — it was in the distribution: roughly 40% of rules enforced by structure (closed schemas, pointer architecture — walls that cannot decay), ~35% by automated nightly/weekly watchers (zero in-session attention cost), ~20% by the agent's in-session habits, ~5% by the human, batched to protect her attention.
Root cause (of the earlier collapse, now diagnosable)
the old system's rules all drew on a single scarce resource — runtime attention. Every MUST competed with every other MUST and with the actual work. Compliance decayed exactly as predicted, not because there were too many rules, but because they all had the same fragile enforcer.
What changed
A standing governor: every new MUST must name its enforcer — structure, watcher, habit, or human — before it's born, and habit-only rules get challenged first. One genuine pile-up spot (a warnings line mixing live hazards with restatements of law enforced elsewhere) was dieted to hazards-only.
The lesson
A client-ready governance diagnostic in one question per rule: "who enforces this?" Count the answers. A stack where every MUST is enforced by someone-remembers will collapse at twenty rules; a stack where most rules are walls and watchers stays healthy at a hundred. Audit the distribution, not the count.
One implementation insight every other Tuesday.
What actually works when you ship AI in real organizations. Nothing you could get from a press release.