CB: record the third pinned run

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
This commit is contained in:
alex 2026-09-08 19:26:33 -04:00
parent cd92076b39
commit cd17280f01

View file

@ -42,9 +42,11 @@ of size k > 1: three lanes ran it with `hooks=off` and got three different files
a 1/k coincidence — at lane L4's k = 6 that is a 17 % chance of a clean bill of health that means a 1/k coincidence — at lane L4's k = 6 that is a 17 % chance of a clean bill of health that means
nothing. Pinning removes the only per-process input and makes a control possible. nothing. Pinning removes the only per-process input and makes a control possible.
It worked. A process whose natural seeds were `0x227235b9 / 0x762d125e / 0x9d77d4e6`, pinned to an It worked, three times over. Three processes on that save, each drawing its own three natural seeds
earlier run's `0xe70a4703 / 0x0c63ca36 / 0x372be4df`, reproduced that run's **entire command block** (nine distinct words in all), two of them pinned to the first's, produced **one** autosave
— including the research pick that varies — and its autosave **byte for byte**. (`d59bb9f2fd0eb535…`) with identical gates — including player 512's research target `282`, the value
that varies — and identical element records. Two runs agreeing on a `k > 1` workload is a `1/k`
coincidence; three is `1/k²`.
## 3. What a replayer needs from this, in one place ## 3. What a replayer needs from this, in one place