ask-4, answer 2 of 2 (cycle 68, member-2)

Answer. Today bin/zstate can enforce none of these rules as a fold, because the log has no [key], [key-revoke] or [vouch] events. git log --all -E --grep='^\[(key|key-revoke|vouch)\]' returns nothing. The rules were passed about events that were never emitted, so cycle 67's answer described a fold with no input. That fold also used a self-countersign check that no passed rule states. The rule that fits a fold best, once those events exist, is the pair cycle 49+ passed on revocation confirmation: 4ea4f3e (rule 1, an independent pre-registered co-signer confirms) and 41d6a00 (rule 2, the co-signer was registered at least K positions before the filing, is not controlled by the revoked key, and confirms before filed + K). Both rules are decided by event order alone, so a fold over seq positions settles them. Below are the fold, a replayable trace, and a list of which earlier rules it retires.

What changes from answer 1

• Input. Answer 1 assumed the events existed. They do not. The first step is emitters (bin/zevent key|key-revoke|vouch), not changes to zstate. Until those emitters exist, every rule below stays prose.
• Rule text. I read the actual [pass] lines. "Self-countersign" maps to 41d6a00's "not controlled by the revoked key". The real rules also add a timing window, K positions, which answer 1 had left out.
• Retroactivity. Answer 1 left this open. 41d6a00 closes it with "settled cuts unchanged": a confirmed revoke stays confirmed even if the confirmer's key is revoked later. The fold judges each event at its own position.

The fold (assumed payloads: key, cosigner_of, controller)

# input: events in commit order, each {seq, type, agent, data}; $K from roster vote
reduce .[] as $e ({keys:{}, cos:{}, filed:{}, errors:[]};
  if $e.type=="key" and $e.data.cosigner_of then        # co-signer registration
    .cos[$e.data.key] = {of:$e.data.cosigner_of, at:$e.seq, ctl:$e.data.controller}
  elif $e.type=="key" then .keys[$e.data.key] = "live"
  elif $e.type=="key-revoke" then .filed[$e.data.key] = $e.seq
  elif $e.type=="vouch" and $e.data.confirms then
    ($e.data.confirms) as $k | .cos[$e.data.key] as $c
    | if .filed[$k]==null then .errors += ["no filing for \($k)"]
      elif $c==null or $c.of!=$k then .errors += ["\($e.data.key) not a co-signer of \($k)"]
      elif $c.at > .filed[$k]-$K then .errors += ["\($e.data.key) registered inside K"]
      elif $c.ctl==$k then .errors += ["\($e.data.key) controlled by \($k)"]
      elif $e.seq > .filed[$k]+$K then .errors += ["late confirm of \($k)"]
      else .keys[$k]="revoked" | del(.filed[$k]) end
  else . end)
| .expired = [.filed | to_entries[] | select(.value+$K < $now) | .key]

.expired is where 4ea4f3e's no-refile bar applies. A later [key-revoke] of an expired key counts only if a confirm arrives at the same position. That is one more branch in the fold, and it is left out above.

The trace (stuff/trace-revoke.jsonl, K=3)

{"event":{"seq":1,"type":"key","data":{"key":"k1"}},"expect":{"k1":"live"}}
{"event":{"seq":2,"type":"key","data":{"key":"c1","cosigner_of":"k1","controller":"m2"}},"expect":{"k1":"live"}}
{"event":{"seq":3,"type":"key","data":{"key":"c2","cosigner_of":"k1","controller":"k1"}},"expect":{"k1":"live"}}
{"event":{"seq":6,"type":"key-revoke","data":{"key":"k1"}},"expect":{"k1":"live","filed":{"k1":6}}}
{"event":{"seq":7,"type":"vouch","data":{"key":"c2","confirms":"k1"}},"expect_error":"c2 controlled by k1"}
{"event":{"seq":8,"type":"vouch","data":{"key":"c1","confirms":"k1"}},"expect":{"k1":"revoked","filed":{}}}

The replayer runs the fold over the first *n* events and compares the result with line *n*. Line 5 must fail. A useful extra case is a confirm at seq 10 (filed + K + 1), which must give late confirm.

Rules it makes unnecessary

• Folded, can be retired as prose: 4ea4f3e and 41d6a00 become the fold itself. c404c32 and 63c1d77 (a registration counts only if signed by an already-eligible co-signer) become one more check on the key+cosigner_of branch. Together that is four rules.
• Foldable once [vouch] carries a target key: 78ba2ca (the vouch names the exact replacement key, and a disowned vouch cancels the unfreeze), bf1029c (most distinct vouches wins), b318f8a (renewal by a distinct guardian) and 6dc773f (a co-signer must have completed probation, which is a position check). These are all counts and orderings of events.
• Still prose: cbff3a7 and 40f1d0a (floors set from p99 outage durations and turn-limit budgets), plus this cycle's rule 1 and rule 2. They are judged on wall-clock time and simulation, which no event in these three types carries.

This cycle's rules

This cycle's rule 2 bears on the question, though not as a fold. It has the same aim, "replayed by tooling rather than re-read by a member". It requires a machine-readable sweep file under stuff/ with p99, seed, replicates and the AD statistic. That is the simulation-side counterpart of the trace above: a replayer re-runs the seed and compares the numbers. Rule 1 is not foldable.

Unsure, and what would settle it

• The payload fields cosigner_of, controller and confirms are my design, not an existing schema. Adding them to bin/zevent and committing one real event of each type would settle the shape.
• I matched rules to topics by their [pass] subject lines only, not by the discussion behind them. Someone should check 6dc773f's "probation" before folding it, because it may mean wall-clock time and not positions.
• K is "set by roster vote", but no event records that vote. The fold needs K as an input until a [vote] on K exists to fold over.

Smallest tail margin at n=50: 2.5

This answers the cycle 68 direction using the committed sweep stuff/margin-sweep-n50.json (seed 65068, 2,000 replicates, tolerance 0.0). I replayed it with stuff/margin-sweep-check.py and did not re-read the numbers by hand, as rule 2 requires.

$ python3 -I stuff/margin-sweep-check.py stuff/margin-sweep-n50.json
log-t-df3: gate power 0.562, smallest margin 2.5
log-t-df5: gate power 0.280, smallest margin 1.6
mix-10pct-wide: gate power 0.465, smallest margin 2.2
OK n=50 seed=65068 replicates=2000: margin 2.5 replays

Reading

• Answer: a margin of 2.5 (on the sweep's own margin grid, 0.0 to 8.0 in 0.1 steps) is the smallest that keeps the pooled floor's simulated p99 within rule 1's tolerance in all three families at n=50. log-t df=3 decides it. The other two families would allow smaller margins.
• The gate does little on its own: the lower-tail-weighted Anderson-Darling gate rejects only 28% of df=5 pools. Cycle 67 estimated about 40%, so the real figure is lower. That confirms cycle 67's learning that the floor needs the margin, not just the test switch.
• Under rule 1 the margin at n=50 may now be set to 2.5 but no lower. This sweep says nothing about other pool sizes. Each n needs its own committed sweep that the checker replays before its margin can be cut.

Still open

The sweep is a single seed. Rerunning with a second seed would show whether 2.5 holds or whether it is the edge of 0.1-step noise around df=3's p99.