Enforcement Levels: Writing A Rule Is Not Fixing It

Four levels of enforcement, from a sentence in a prompt to a gate that fails the build, and how to choose.

Problem

Something goes wrong. A rule gets written. The same thing goes wrong again.

The usual response is to write the rule more clearly, move it higher in the file, or add emphasis. Sometimes that works. Often the count keeps rising, and the reason is that the rule was never the mechanism — it was a description of the desired mechanism, and nothing was built.

The system currently holds 237 written rules. The honest question is not how many exist but how many have anything behind them.

Design

Four enforcement levels, assigned explicitly when a rule reaches its third occurrence in the repeat ledger.

The distinction that matters is between read and run. L0 and L1 depend on something being read at the right moment, which depends on context, position and load. L2 and L3 do not depend on attention at all.

Choosing a level is a cost decision, not a severity one. L3 is expensive to build and expensive to be wrong about — a false positive that blocks work gets the gate disabled within a week, which is worse than never having built it. L0 is nearly free and nearly worthless for anything that recurs under pressure.

The working heuristic: anything that has recurred 3 times gets at least L2. Recurrence is evidence that reading is not sufficient.

Trade-offs

L3 gates have to be tuned before they are trusted. A gate that fires on the first run against real content and is wrong will be switched off. One check here reported 36 dead links on its first run, all of them fragments of inline JavaScript rather than real links. Fixing that before anyone else saw it was as important as writing the check.

L2 produces noise that decays into wallpaper. A check that reports a warning nobody acts on is L0 with extra steps. Either it escalates to L3 or its threshold is wrong.

Not everything can be checked. Tone, judgement, when to escalate — these live at L0 or L1 permanently, and pretending otherwise produces a gate that measures a proxy. A proxy gate is worse than a prompt rule because it creates false confidence.

Enforcement has a maintenance cost that outlives its author. A check bound to the format of a file it does not own comes silently unbound when that file is refactored. One parser here read a table by column position; two columns were inserted and it reported an empty queue for 21 days without erroring.

Choosing a level without over-building

The temptation with a ladder is to treat higher as better and build toward L3 everywhere. That produces a system with more gates than anyone can maintain, and unmaintained gates fail in the worst direction — they keep passing.

Four questions decide the level, and they are asked in order.

Can the rule be evaluated mechanically at all? If judgement is required — tone, whether to escalate, whether a claim is strategic — the ceiling is L1. Building an L2 check for something that cannot be measured produces a proxy, and a proxy gate creates false confidence, which is worse than the original problem.

How often does the situation occur? A rule that fires monthly does not justify a build step. A rule that fires on every artifact does, because at that frequency the cost is amortised in days.

What does a false positive cost? This is the question that decides between L2 and L3. A gate that blocks work incorrectly gets disabled or bypassed within a week, and once bypassed it appears in the system as though it were working. Where false positives are likely, L2 with a visible report is strictly better than L3 with a workaround.

Who maintains it when the thing it checks changes? Every check is coupled to a format, a path or a schema it does not own. That coupling is a standing liability, and the honest version of the question is whether anyone will notice when it silently unbinds.

In practice most rules settle at L1 or L2. L3 is reserved for a small set where the failure is irreversible — anonymity, external sends, deletions — and where a false positive costs an argument rather than a day of blocked work.

What broke

A rule at L0 with a rising count. The clearest possible signal, and it was visible in the ledger for weeks before anyone read the ledger as a whole rather than entry by entry. Fix: the triage pass now looks specifically for count ≥3 at L0, which is a one-line query and the highest-yield thing in the review.

A check that could not see the failure mode it was built for. A freshness monitor compared file dates, so a crashed job and a retired source were indistinguishable. It reported clean while the pipeline was failing. Fix: checks state their own scope in their output, so the caveat travels with the verdict.

A gate that was too strict and got bypassed. Not disabled — bypassed, which is worse, because the gate still appears in the system as though it were working. Any gate with a documented workaround is L0 wearing an L3 badge.

The measurement that is missing

The ladder describes how a rule can be enforced. It does not answer the question that would tell you whether the system works, which is what share of rules sit at each level.

That number is not measured here, and the omission is deliberate to state rather than quietly skip. The written rule set carries a level for the ones that escalated through the repeat ledger — but rules written directly, without a preceding incident, mostly carry nothing:

enforcement: L2 (build check) — present on ledger-escalated rules, absent on most others

Without the distribution, three questions cannot be answered. How many rules depend entirely on being read. Whether the ratio is improving or decaying as the set grows. And which of the rules currently at L0 have a recurrence history that should have escalated them and did not.

The instinct is to estimate. The reason not to is that an estimate of this particular number would be self-serving in a predictable direction — the rules that come to mind are the ones with visible enforcement, because those are the ones that fire. A count assembled from memory would overstate coverage, confidently.

So the honest statement is the one in the summary: 237 rules written, enforcement distribution unknown, measurement queued.

Files

The repeat ledger holds the count and the assigned level. Checks live beside the thing they check — build checks in the build, hooks in the repo, skill checklists in the skill file.

There is deliberately no central enforcement registry, which is a real gap: nothing currently answers what fraction of rules run rather than being read. That measurement is queued, and until it exists the count of 237 rules describes intent rather than behaviour.

[Enforcement Levels: Writing A Rule Is Not Fixing It](https://stillvalid.dev/architecture/enforcement-levels) — stillvalid, SV-6710 (deep-dive, verified 2026-08-14)