what it did while somebody was working.

which day, and in which mode

The ledger is 32 days old. That is not how long these verdicts took, and the difference is the whole reason this column is here. Recorded verdicts land on 15 of those days and outright refusals on 19, because the gate spent almost all of that time in watch mode and was only armed at the end. A single total beside an age is a rate the reader will compute and that never existed.

which law, how many times

Every count is a verdict the ledger recorded, grouped by the rule that produced it. The laws with baseline- in front of them are compiled into the binary and hold in a repository with no configuration at all; the rest come from a guard file a project owns.

and the refusals that were wrong

A refusal count on its own measures nothing. It measures something beside the count of refusals that should not have happened, and that second number can only be read off a ledger that holds both, which is why it is here and not in a footnote. rabadon wrong <rule> <why> writes it onto the same hash-chained ledger as the refusal itself, so it is covered by rabadon audit and cannot be quietly edited down.

Every one of these was found by being on the receiving end of the gate rather than by reading its source. The rule that matched an in-place editor example also refused the report saying so, because the example was in the report as quoted text. None of the three was answered by switching the rule off.

which law did the refusing, once it was armed

The table further up counts recorded verdicts, which is watch mode. This one counts commands that did not run.

when it was switched on, and when it was not

Supervision lives in one file for the whole machine and the absence of that file means unguarded. A session switched it off at 02:25 on 3 August, it stayed off while four other sessions kept working underneath it, and no event recorded that anywhere. A mode change is a line on the ledger now. The count below starts the day that line started being written, which is why it is small.

and how many of the laws can fire at all

A rule that reads correctly to a person, passes rabadon lint, and is structurally incapable of ever refusing anything is the same failure this page is about, one layer in. So every guard rule on this machine was put through the real gate binary with a command it was written to refuse. Not a reading of the pattern, a run of the engine, 430 times.

20 of these rules were written by the engine itself after a real incident, and 0 of those cannot fire. Each one names something that had already gone wrong once and was free to go wrong again.

and the other direction

Rules that refuse work they were never written about. Found by driving 172 allow twins through the gate, an allow twin being a command the rule's own author wrote down as one that must pass. 21 more were withheld: a git push twin at a guard carrying a push gate is not a judgement, because the gate forks a shell and runs the project's own suite before deciding, and driving one would both execute that suite and move the state the two binaries were being compared under.

Measured at commit 74404c19431f. The first census was run at b384d6a714f1, before the repairs, and it is not enough to compare this number against that one: two figures taken at two moments differ by the clock as much as by the code. So both binaries were built and every rule was driven through each of them back to back, in one pass, between 2026-08-03T17:25:17Z and 2026-08-03T17:25:24Z. The old binary answered 411 can fire and 16 cannot, reproducing the published figure exactly; the repaired one answered 425 and 0.

The whole census: rule_census.json, 328 rules, each with the probe it was driven with and the verdict the gate returned.

the laws it wrote for itself, after the thing had already happened

When a check goes red the engine proposes a fix, and where the failure was a way of working rather than a line of code it writes a rule so the same class cannot happen twice. Each one below was authored after a real incident, in the repository the incident happened in. The sentence on the right is the rule's own, read out of the guard file it lives in rather than retyped here.

Three numbers where a page would normally print one, because the ledger records an authoring EVENT and neither of the other two facts follows from it. 15 events, 14 distinct laws, because one law was written twice after two separate incidents in two repositories. And 3 of those laws is on the ledger and in no guard file anywhere, which means it cannot fire in any repository ever. Counting events and calling them rules was the first version of this section and it would have published a law that does not exist. The check runs in make test.

the push it would not let through

The gate does not take the session's word for whether the suite passes. It runs the project's own test command itself, reads the verdict, and holds the push until the tree is green. What follows is how often that happened during real work, not in a rehearsal.

the records, as they were written

Nothing above has to be taken on trust. Every published record is here, project by project, in the file the page is built from. Home paths are rewritten and the extractor refuses to write at all if an account name survives redaction, whole or truncated. Runs made to exercise the engine are excluded by name and the excluded count is printed, because a filter that hides its own size is the same problem one layer down.

The whole file: field.jsonl, 778 records, one JSON object per line.