The Law You Can't Feel: From "An Agent Checked Once" to "The Machine Enforces Every Time"

What you'll be able to do: explain the difference between a check that happened and a law that holds — and enact a real law change on a protected repo using nothing but a browser.

Choose your door

Builder — Builder Track: the one-line web edit that widened the law.
Architect — Architect Track: the three regimes of rule-keeping.
Translator — Bridge below.
Validator — Gates at the bottom.

The story this comes from

By July 2026, a tool I built had 45+ tests — but CI only ran nine of them (the tests/invariants/ folder). The rest had been run by an agent, once, on the day they were written. Passing yesterday is not a law; it's a memory.

The fix was option 4: change one line in the CI recipe — tests/invariants/ → tests/ — so the machine runs the whole test tree on every proposal, forever. I enacted it myself from the GitHub website: pencil icon, edit one line, commit. Main is protected, so GitHub forced the edit onto a branch and opened a PR; CI ran; I merged. Zero terminal. The law changed hands from agent-memory to machine-enforcement in one line.

Translator Bridge

A classroom rule that lives in the teacher's head works — while that teacher is in the room. Write it into the school handbook and wire it to the bell schedule, and it holds through substitutes, new students, and the teacher's sick days. "An agent checked once" is the teacher remembering. CI running tests/ is the handbook plus the bell: nobody has to remember, because the building itself enforces it.

Where the analogy ends: a handbook still needs humans to read and choose to obey it — enforcement is social. CI's enforcement is mechanical: the merge button physically refuses until checks pass. There is no "we'll let it slide today" in a locked branch. That's also the warning label: the machine enforces your law exactly as written, including its mistakes — which is why writing the law (Lesson 3) is the human's job and stays one.

Builder Track (DO FIRST)

Open any repo's .github/workflows/ folder on GitHub and find the verify/test workflow file. Read the last lines — find which paths the tests run on. That scope IS the law's reach.
Ask the option-4 question: "What exists in this repo that this file never runs?" The gap between written tests and enforced tests is where regressions live.
Walk the enactment (or dry-run it): pencil icon → edit the path → Commit changes → GitHub proposes a branch (main is locked — that refusal is the lock working) → Propose changes → Create pull request → watch checks → merge.
Note what you did NOT need: a terminal, a local copy, git commands. Law changes are one-line web edits when the chassis is right.

Architect Track (MODEL FIRST)

Three regimes of rule-keeping, in ascending strength:

Regime	Rule lives in	Fails when
1. Intention	someone's head	they forget, leave, or get busy
2. Inspection	a check someone ran once	the world changes after the check
3. Enforcement	the machine, on every change	only if the written law itself is wrong

The whole trick of the truth machine is pushing every rule from regime 1 and 2 into regime 3. Note the division of labor it creates: agents may propose laws (a PROPOSED_INVARIANTS.md file), but only the human enacts them — because regime 3 is absolute, the choice of what becomes absolute must stay with the human. You can't feel the law when it's working; you only feel it when it refuses you. That refusal is the product.

Validator Gates

Gate 1: In one sentence: why is "the tests passed when we wrote them" not a guarantee about today?
Gate 2: Name the three regimes and give a household example of each.
Gate 3: When GitHub refused to commit directly to main and forced a branch, was that an error? What was it?
Gate 4 (own words): Explain to a teammate why an agent may propose an invariant but must not enact one.

Lesson complete — you can now tell a memory from a law, and change a law with a pencil icon. Next: Lesson 5 — even a lawful machine can't grade its own homework.