Signed Rulings

1. The hole we’re closing. The ledger records rulings — “Robert ratified this.” Today, anything that can write to the repo can write that sentence, and our own fleet writes to the repo all day. So a ruling record currently proves nothing — the adversarial review of the coverage fence showed it could be forged by exactly the agents it is supposed to fence. You ruled the direction: the proof of who ratified must travel with the ruling itself, so any copy of the ledger — a clone, a fork, a laptop with no internet — can check it without trusting where it came from.
   ↘ go deeper — what the builder reads

   Implements Call 3 of the EXP-READER seal (signed rulings, not write-lock). A write-lock/ACL authenticates the channel; the threat includes writers already inside the channel, and a fork has no channel at all — so any channel-authenticating scheme is structurally out. The ruling record is a git-committed JSONL line carrying a detached signature over its canonical bytes (never a git commit/tag signature — those cover a whole tree and make the envelope ill-defined). Inside the signed body, mandatory: the ruling content, its class, the content-hash of the exact ledger state it ratifies, and the signing time. Authenticity and currency are separate checks: a valid-but-stale ruling reads STALE, never green.
2. The one rule that makes any of this real. The independent review caught the hole that would have made everything else theater: if the checker — the code that verifies signatures, the list of who may sign, and the switch that turns enforcement on — lives in the repo, the fleet can simply edit the checker. So the rule, non-negotiable: the checker that counts, the signer roster, and the on-switch live in your install, placed there by a human, never read from the repo being checked. CI runs a copy as an early-warning mirror, but its word is advisory until its own supply path is locked out of the fleet’s reach too. The verdict that counts renders on your machine.
   ↘ go deeper — the trust base & its gates

   Out-of-band home: ~/.config/quanta-authority/ — authoritative verifier (pinned version), pinned anchors (the signer roster or its content-hash; for keyless options also CA root + log key + genesis-roster hash), and the enforce flag. The in-repo copies are convenience mirrors, non-authoritative. The first roster’s fingerprint is pinned by hand at the ceremony — an attacker-authored “alternate genesis” in the repo is unreachable by construction, and an in-repo signed roster-change is NOT active until re-pinned by a human. Every gate ships born-red: forged ruling → INVALID · unlisted signer → INVALID · re-genesis attack → INVALID · in-repo verifier/flag edit → verdict unchanged · relabeled ruling-class → INVALID · stale state-hash → STALE · out-of-window/revoked signer → INVALID · tampered byte (incl. non-ASCII) → INVALID · gutted checker → caught by the plant-a-forgery harness · correctly-signed current ruling → VALID. Unknown is never green: the checker’s only passing output is VALID; CANNOT-VERIFY fails closed.
3. Your call — how the signature is made. The review also changed my recommendation: our signer roster is tiny (you, maybe Alie), and at that size the simplest tool beats the famous one.
   Option 1 — git’s own signing, keys we hold (my recommendation). You sign with a key you already have; the checker trusts a short pinned list of “these keys may ratify.” Costs nearly nothing, no services, works offline both ways, leaves no public trace. Honest weaknesses: a stolen key signs silently (no outside log to catch it — recovery is a roster edit plus re-ratifying, small at our size), and a thief could fake timestamps — bounded because every ruling names the exact ledger state it blesses, though false provenance about past states stays possible until the key is revoked.

   Option 2 — the public signing service (keyless). You log in with an identity account; a public service issues a one-time credential; every signature lands in a public log. Buys: no key to guard, a trusted clock, and a log we can watch to detect someone signing in your name. Costs: the service must be up when you sign, and your signing identity + each ruling’s fingerprint become publicly visible.

   Option 3 — run that service ourselves. Option 2’s properties, no public trace — but we operate the service and guard one root secret. Real ops, all on us.

   Recommendation: Option 1 now, Option 2 as the named upgrade — the recorded triggers: the roster grows past a handful, or a real compromise scare makes the public log’s detection worth its trace. Both paths share the one rule above; neither is safe without it.

   ↘ go deeper — why the recommendation flipped

   v1 recommended keyless (Option 2). The reviewer’s frame-fitness challenge: keyless exists to solve key management at scale — thousands of unknown signers. For 1–2 known humans, git-native keyed signing with a pinned allowed_signers roster delivers every promise on this page with far less machinery — and less trust machinery means less to gate and less to get wrong. What keyless genuinely buys (trusted time, log-based compromise detection) is recorded as the upgrade trigger, not the default. All 8 field citations in the underlying brief were verified against live sources before any claim here became load-bearing.
4. What you get once it ships (under the one rule, whichever option you pick):
   A forged ruling fails, everywhere. Including a forged roster — the first roster’s fingerprint is pinned in your install, so a substitute roster is rejected before any signature is even checked.

   A real signature on the wrong thing also fails. A ruling states what class of thing it ratifies and the exact ledger state it blesses — inside the signed portion. No replaying an old ruling onto new content; no relabeling; no blessing today with yesterday’s ruling.

   People can leave, keys can die. Roster entries carry validity windows — a removed signer’s past legitimate rulings stay valid; anything signed outside the window fails.

   Unverifiable is never green. Anything the checker can’t positively verify is treated as no ruling at all.
5. Still true after we ship (the honest residuals):
   An impersonated signer forges until revoked. No signature scheme survives its signer being impersonated. Option 1’s recovery is roster-edit + re-ratify; Options 2/3 add detection via the public log.

   The checker itself could have a bug. It is trust machinery and gets the full gate: forged-ruling, forged-roster, replay, relabel, and revoked-signer tests that must fail, plus a gutted-checker control the harness must catch.
6. On your word.
   1 — Report-only. The checker ships behind a flag; existing unsigned rulings read UNSIGNED; nothing breaks, counts get banked.

   2 — The ceremony. One sitting: you sign the standing rulings; the first roster gets pinned in your install.

   3 — Enforce. Coverage rulings first, widening class by class on evidence. The on-switch lives in your install — turning it off is yours, not the fleet’s.

The questions for your pen

Reference — the one rule & its gates · the three options · the four promises · residuals · rollout stages. Canonical source: docs/ai/SPEC-signing-primitive.md (v2, re-graded 8.5/10, independent adversarial review ×2). Nothing builds until your word.