sots-re/verify/state-checksum/STATE_CHECKSUM.md

Per-turn state checksum

Status: validated on the real saves (verify/results/state-checksum/). The replay loop in §5 is designed but not run — it needs VM140, which lane R holds.

state_checksum.py computes a whole-state checksum of a .sav as a tree of per-subsystem and per-object digests that roll up to one root, and diffs two such trees to name the object that moved.

verify/state-checksum/
  state_checksum.py        the tool + library
  float_census.py          classifies every float leaf (evidence for §3)
  stability_check.py       identical bytes -> identical roots, coverage proved
  run_validation.sh        regenerates verify/results/state-checksum/
  test_state_checksum.py   62 tests

---

1. Why a whole-state checksum, next to the per-function harness

Every verification the project has today is per-function: hook a routine, compare the regions it declares, print a verdict. That verdict is bounded by the region declaration, and region declarations have been wrong in both directions:

• B4 found three hooks that printed "0 diverged" while their region set was empty.
• The harness audit (sots-engine/docs/harness-audit.md) found 23 undeclared side effects.
• B3's TechTree::ProcessResearch passed replace-mode by 40,300 items and was still wrong — by one unposted EVENT_RESEARCH_OVERBUDGET that no declared region covered (findings/subsystems/events.md).

Those are three different failures of the same kind: the verdict was green because the evidence was narrow, not because the state matched. Coverage is the evidence; the verdict is not.

A whole-state checksum is the complement. It never asks what a function declared. It asks whether the entire simulation state is still identical, using the strongest oracle this project has: End-Turn autosaves are byte-identical across runs and across processes (findings/subsystems/determinism-oracle.md).

The two are not redundant. The per-function harness says where in the code a divergence started; the state checksum says that one exists and which object it landed on, and no region-declaration mistake can hide from it.

1.1 What makes this evidence rather than a comforting number

Coverage is proved, not declared. After building the digest tree, the tool re-serialises the parse back into bytes and compares that with the inflated save, byte for byte (audit_coverage, on by default). When the reconstruction reproduces the stream, the whole file is a function of the digest's inputs — every tag, every value, every frame boundary — so no state change can be invisible to it. This is the one property that a hand-maintained region list can never have, and it is the direct answer to the empty-region-set failure: a state_checksum.py run that could not account for the file says coverage: FAILED at inflated offset 0x… and exits non-zero, instead of printing a clean root.

Observed on every save on this host:

coverage: PROVED (603360 bytes rebuilt == inflated); 35031 leaves, 190807 value bytes

It localises. The root is the fold of a tree, and objects carry names, so a divergence is reported as /Sim/players/Player[496 "Singularity"]/Status, not "the hash moved". This is the same principle that made the harness guards useful — name player+0x2b0, do not just say something changed.

---

2. The digest tree

2.1 Shape

The tree follows the save's own frame nesting (SAVE_FORMAT.md §3), with two foldings applied so that it reads as a subsystem tree rather than a flat item list:

fold	what it does	why
object tables	a run of (PlayerID, Player{}) sibling pairs becomes one players group whose children are Player[16 "re"], Player[32 "Fane Lao"], …	Sim has 259 flat children; without this there is no "players subsystem" to point at
inline id lists	PlayerIDs + n × . becomes one PlayerIDs[] node holding the values	one inserted id used to shift every following sibling and produce ~30 spurious "moves" per turn

Both foldings preserve order and byte span exactly; nothing is dropped, so the reconstruction audit still proves total coverage. The tables are PAIR_GROUPS, NAME_FIELDS, ELEM_KEYS and INLINE_ID_LISTS at the top of the module.

2.2 Naming

• Object frames get their id and their in-file name: Player[16 "re"], Sys[112 "Gamma Cephei"], Flt[1744 "Alpha Fleet"], Des[592 "Armor"]. The id is folded into the object's digest, so two objects with identical bodies and different ids do not collide. (The determinism-oracle byte diff could only say "1st of two Singularity records"; the tree says Player[496 …] and Player[512 …].) Ship frames carry no name field on disk, so a ship is labelled by id alone — Ship[1728].
• NULL-named (".") element frames are keyed by the first identifying child they carry: Events/.[EvTurn=3], ords/.[ordID=…].
• A uniquely-named field gets no index at all (/Sim/players/Player[16 "re"]/Status).
• Where an index is unavoidable it is the ordinal among same-named siblings, so an insertion elsewhere in the frame does not renumber everything after it.

2.3 Digest construction

blake2b-128, length-prefixed and domain-separated at every level:

leaf   = H("leaf",  tag, kind, value_key)
object = H("obj",   H("id", id_tag, id_bytes), frame_digest)
frame  = H("frame", tag, child_digest...)
group  = H("group", group_name, member_digest...)
list   = H("list",  tag, count_bytes, element_key...)
root   = H("save",  float_policy, mask_preset, top_level_digest...)

Order is part of the state, so children are folded in file order. The float policy and the mask preset are folded into the root so a strict root and a lenient root can never be compared by accident.

Note what is not hashed: the human labels of §2.2. Digests consume the on-disk tag and the id bytes; the "re" / "Gamma Cephei" part of a label is diagnostic metadata only. So improving the naming tables never invalidates a recorded root — verified in practice when Flt's name tag was corrected from a guess to the on-disk FtName and every root stayed the same.

2.4 The digest depends on the reader, not only on the bytes

Each leaf hashes its inferred kind alongside its bytes, and that kind comes from save_reader.py's schema and its int/float classifier (SAVE_FORMAT.md §2). The same four bytes typed int and typed float produce different digests. That is correct for comparing two saves parsed by one reader, and dangerous for a chain recorded months earlier, so every run prints and every chain records a readerFingerprint (blake2b-64 of save_reader.py), and verify_chain says so loudly when it does not match:

!! chain was recorded under save_reader 3f1e…, this is fe5a6f7cd4ae7910
   -- re-record before trusting a DIVERGE

It is deliberately not folded into the digest: a cosmetic reader edit should raise a warning, not invalidate every recorded root.

2.5 Masking is opt-in and audited

Default is no masking, so the one known non-idempotent field set (§4) is localised rather than absorbed. --mask resave applies the canonicalisation determinism-oracle.md prescribes. Each rule is scoped to a path prefix, not just a tag name, and the run always reports what it hit:

policy: floats=bits mask=resave reader=fe5a6f7cd4ae7910  [masked: Checksumx1, Statusx8]

A mask that matches nothing prints [mask matched NOTHING -- check the rule paths]. A mask nobody audits is a hiding place, and this project has already been bitten once by a comparison that quietly covered nothing.

2.6 --relabel-new-ids — comparing modulo the labelling of this turn's new ids

Added 2026-09-09 (lane BT) to the specification in findings/resolutions/2026-09-09-fleet-id-order-residue.md §3 item 1. Full write-up, with the acceptance output and the guard tests, in findings/subsystems/relabel-new-ids.md.

state_checksum.py POST-A.sav POST-B.sav --relabel-new-ids PRE-TURN.sav

Two processes with identical pinned AI seeds can still write different autosaves, because the order in which the AI visits the ship groups that need a new fleet is per-process. The ids are not the variable — they decode (id-allocation.md: id = (counter << 4) | node) to one client's own counters, minted in that order in every process. The same group gets a different id. This mode quotients that labelling out and nothing else.

Given the pre-turn save it computes the ids new in each post-turn save, matches the non-zero-node (client-minted) new fleets by a key that does not mention the id — (LocID or FPlan destination, sorted ship-id set) — builds the bijection π, exchanges the matched fleets' bodies between their slots, rewrites every fleet reference under π, compares the master id lists as sets, masks /Summary/Checksum with its reason on the line (§4.6: derived, and its inputs are unmodelled), and prints π:

relabel: pi = {1970<->1986}
IDENTICAL modulo pi = {1970<->1986}

Five guards, and every one refuses rather than degrades. Only ids absent from the pre-turn save (G1); only non-zero node nibbles (G2); π must permute one set, so the two saves must have minted the same ids (G3); the content keys must correspond one-to-one and be unique on each side (G4); and no leaf anywhere in either save may hold a permuted id at a site this tool does not model as a fleet reference (G5, matched on raw bytes so a reader typing slip cannot empty it). On a refusal nothing is rewritten and the ordinary comparison runs, so a real divergence still reports; the reason is printed on its own line.

The relabelled root is domain-separated (relabel-new-ids is folded into the root preimage), so a "modulo π" root can never be mistaken for a strict one, and every root recorded before this flag existed is bit-for-bit unchanged.

---

3. Float-parity policy

This is the subtle part, and it has to be settled now rather than at port time, because the policy decides what a future x64/SSE standalone is allowed to differ by.

3.1 What the engine actually does

From findings/subsystems/formula-gaps.md:

• State is stored in float32. Literals in the code are float32 values widened to double (0.05000000074505806), so the constants themselves are exactly representable as singles.
• fnstcw inside a hooked turn-pipeline call returns 0x127f: precision control = 53-bit (double), rounding = round-to-nearest-even. The FPU is not left in 24-bit single precision by the D3D9 device. So an x87 intermediate rounds to double and the caller then narrows to float32 — two roundings, not one.
• Integer rounding is fistp/fild, i.e. ties-to-even, not truncation and not C's round-half-away-from-zero.

3.2 The save is a narrowing boundary

Everything the checksum sees is a 4-byte IEEE-754 single. Whatever precision the FPU carried internally, the values that reach the save have already been narrowed to float32. That is a useful property: the checksum compares state at exactly the level where an x87-vs-SSE difference either survived the narrowing or vanished in it. It also means the checksum cannot see a precision difference that got rounded away — which is the right behaviour, because a difference that does not survive into state is not a state difference.

3.3 The policies

policy	float leaf hashes	separates	default
bits	the raw 4 bytes, unchanged	everything, including -0.0 vs +0.0 and distinct NaN payloads	yes
canonical	raw bytes, with -0.0 → +0.0 and every NaN → one quiet NaN (0x7fc00000)	everything except those two	no

canonical also normalises a bool byte to 0/1. Nothing else is ever normalised.

Why bits is the default. It is the only policy under which "the roots match" means "the state is identical". Everything else is a claim about which differences we have decided not to care about, and this project's whole lesson is that such claims must be earned, stated, and audited rather than assumed.

What bits catches: any state difference at all, down to one ULP of one float32 in one object, plus every non-float change. What it over-reports: exactly two cases where a value-equal result can carry different bits — signed zero and NaN payload. x87 FLD/FSTP quiets a signalling NaN where SSE may not; a zero result can pick up a sign from a different rounding path. canonical exists for precisely those two, and for nothing else.

Corpus evidence (verify/results/state-checksum/float-census.txt, 4 distinct saves, 4,474 float leaves):

     2337  ordinary
     1114  positive zero
      791  exact integer
      232  FLT_MAX (0x7f7fffff)

'canonical' would change 0 leaf/leaves across the corpus (a no-op today).
subnormals: 0  (each one is an x87/SSE parity risk)

No negative zero, no NaN, no infinity, no subnormals. So canonical is a no-op below the root on everything we have — verified by a test that fails the day that stops being true. The strict default therefore costs nothing today, and the lenient policy is available the moment a save contains a case that needs it.

The 232 FLT_MAX leaves (58 per save) are worth flagging: FLT_MAX is 0x7f7fffff, a finite normal value, not infinity. events.md corrected formula-gaps.md on exactly this point for the default EvPos. A checksum that treated "very large" as "infinite" would merge distinct states; bits cannot, and a test pins it.

3.4 Why there is no tolerant hashing policy

A tolerant hash is a contradiction, and it is worth writing down rather than rediscovering:

1. Quantisation moves the cliff, it does not remove it. Round to k bits and two values one ULP apart still hash differently whenever they straddle a bucket boundary, while two values 2^k ULPs apart inside one bucket hash the same. You get both false positives and false negatives, with the boundaries in arbitrary places.
2. It destroys the roll-up. The point of the tree is that a differing parent digest lets you descend to the object. Under quantisation a parent can differ while every child is "close enough", and you cannot tell from digests alone.
3. It makes the root uninterpretable. "Roots match" would mean "match to within a tolerance nobody recorded".

So the digest is always exact and tolerance lives in the differ. --ulps N classifies each leaf difference after it has been localised:

$ state_checksum.py A B --ulps 2
DIVERGED: 3 leaf difference(s)
  /Sim/players/Player[16 "re"]/IdealSuit: 11.106206893920898 -> 11.106207847595215  [1 ulp]  <= 2 ULP
  ...
floats: 3 differ, 3 within 2 ULP

The root stays strict; a human or a CI rule decides whether "three leaves, all ≤ 1 ULP" is an acceptable port artefact. That decision is then visible in the log, which is the whole point. This mirrors the existing harness vocabulary (verify/harness/compare/TRACE_FORMAT.md, per-hook ftol, default 0), rather than inventing a second one.

Real output, from the turn 2 → turn 3 transition (§4.3):

  /Sim/systems/Sys[112 "Gamma Cephei"]/RepCur: 336360.0 -> 336840.0  [15360 ulp]
  /Sim/systems/Sys[112 "Gamma Cephei"]/RepMax: 336360.0 -> 336840.0  [15360 ulp]
  /Sim/systems/Sys[288 "Ke'Dolarra"]/RepCur: 370000.0 -> 370520.0  [16640 ulp]
  /Sim/systems/Sys[288 "Ke'Dolarra"]/RepMax: 370000.0 -> 370520.0  [16640 ulp]
floats: 4 differ, 0 within 2 ULP

That is the mode working as intended: four float leaves moved, and the ULP column says at a glance that all four are genuine simulation changes (tens of thousands of ULPs — resource pools growing over a turn), not float-path noise. Had a port produced [1 ulp] on these instead, the same line would say so and the judgement call would be an explicit one.

3.5 The x64/SSE budget — MEASURED 2026-09-08, no budget needed

x87 with PC=53 rounds an intermediate to double and then to float32 — double rounding. SSE mulss/addss rounds once, directly to float32. For a minority of inputs those differ by one ULP, and one ULP in a float32 that feeds an fistp can cross a tie and change an integer. OpenRCT2 hit exactly this: "replays on x64 and x86 platforms will generate different sprite checksums" (guides/re-windows-2000s-howto.md §1.1).

Under the strict default, a port that changes the float path will be reported as diverged. That is deliberate: it is a real state difference. The port's job is either to reproduce the double rounding (compute in double, narrow explicitly at each store — which is what fpu_cw = 0x127f makes the original do) or to accept a documented --ulps budget on a named list of fields.

SETTLED on the VM, 2026-09-08 (lane F). It was not settleable from the host side — every save in the corpus was made at fpu_cw = 0x127f, one point rather than a curve — so lane F ran the End Turn seven times from ref-turn2.sav with the shim forcing the control word, and checksummed the results with this tool. Full write-up and the evidence chain that the setting actually held (38 independent in-pipeline samples per run): findings/subsystems/fpu-precision-sensitivity.md; artefacts in verify/results/fpu-cw/.

forced fpu_cw	precision / rounding	root vs baseline
stock, 0x027f, 0x127f, 0x137f	53-bit and 64-bit, nearest	identical, all 35,394 leaves
0x007f	24-bit, nearest	1 leaf + derived Summary/Checksum
0x1a7f	53-bit, round-up	2 leaves, 1 ULP each

The answer for §3, in one line: 53-bit and 64-bit x87 give the same state, so an SSE port computing in IEEE double has no double-rounding budget to preserve and floats=bits is free. What is not free is the two things the other two runs found:

0x007f (24-bit):  /Sim/systems/Sys[112 "Gamma Cephei"]/Pop2/PopG/PopC : 540000000 -> 540000002
0x1a7f (round-up):/Sim/fleets/Flt[34 "Beta Fleet"]/Pos/.[0] and /Pos/.[2] : 1 ulp each

So the port must (a) hold intermediates at 53 bits and narrow to float32 only where the original stores to a dword — never compute a chain in float — and (b) use round-to-nearest. Both are SSE defaults; they are now measured requirements rather than assumptions, each with a named regression witness on turn 2 of ref-turn2.sav.

Correction to the experiment as it was written here. The three values proposed above span only two FPU modes. 0x027f is 53-bit — it differs from 0x127f only in bit 12 (infinity control), which every x87 since the 387 ignores — and 0x137f is 64-bit extended, not a rounding change. Precision control is bits 8–9 (00=24, 10=53, 11=64) and rounding control is bits 10–11. The genuine single-precision word is 0x007f and a genuine rounding change is 0x1a7f; run as originally specified, all three settings come back identical and the tempting conclusion — "nothing depends on the control word" — would have been wrong on both of the axes that actually matter.

Until that runs, "the checksum is exact and the port must match bit-for-bit" is a policy, not a measured requirement. It is the right default either way — it fails loudly rather than quietly — but it should not be described as validated.

---

4. What was validated, on which saves

Regenerate with verify/state-checksum/run_validation.sh; outputs land in verify/results/state-checksum/. Saves are read from $SOTS_SAVES_DIR plus the in-repo verify/results/saves/, and the script skips cleanly when neither has anything. No .sav is copied into either repo.

The corpus on this host is 10 files with 4 distinct contents (the four the determinism work produced): a3f9dc4b turn-1 pre-turn, ab4ac2d7 turn-2 post-turn, bb4fd9ac turn-2 pre-turn/manual (the loaded-and-re-saved form of ab4ac2d7), 978041ac turn-3 post-turn.

4.1 Identical saves produce identical checksums, and every save is covered

reader fingerprint: fe5a6f7cd4ae7910
10 file(s), 4 distinct content(s)

sha256:978041acd168b56e  2 file(s)  STABLE + COVERED
    root 5ac4a24197e82de49f3077cd8dd25fad  Autosave - turn3.sav, turn3-state.sav
sha256:a3f9dc4b49fc669c  2 file(s)  STABLE + COVERED
    root 9bbcbd4945cd8319b65d7d7958772ee0  Autosave EndTurn - turn2.sav, turn1-state.sav
sha256:ab4ac2d7e2977260  3 file(s)  STABLE + COVERED
    root aa85fe76d412cdb3a0e7e52c8f0ca9e2  Autosave - turn2.sav, Autosave Backup - turn2.sav, turn2-state.sav
sha256:bb4fd9ac89f41e3b  3 file(s)  STABLE + COVERED
    root a1448e6c1867fc53708810b3a2f9ec77  Autosave EndTurn - turn3.sav, MyGameverify1verify1.sav, verify1.sav

VERDICT: all stable and fully covered

"COVERED" is the byte-for-byte reconstruction (§1.1), so this is a stronger statement than sha256 equality: the parse is deterministic and total, not just the bytes.

4.2 The known re-save difference is localised, not reported as a whole-state mismatch

This is the deliverable that matters. determinism-oracle.md established that loading a post-turn autosave and re-saving it changes exactly five things. The tree names all five and nothing else:

$ state_checksum.py turn2-state.sav "Autosave EndTurn - turn3.sav"
A  aa85fe76d412cdb3a0e7e52c8f0ca9e2  verify/results/saves/turn2-state.sav
B  a1448e6c1867fc53708810b3a2f9ec77  $SOTS_SAVES_DIR/Autosave EndTurn - turn3.sav
policy: floats=bits mask=none reader=fe5a6f7cd4ae7910
DIVERGED: 5 leaf difference(s)
  /Summary/Checksum: -1205790620 -> -1205790636
  /Sim/players/Player[16 "re"]/Status: 4 -> 0
  /Sim/players/Player[32 "Fane Lao"]/Status: 4 -> 0
  /Sim/players/Player[496 "Singularity"]/Status: 4 -> 0
  /Sim/players/Player[512 "Singularity"]/Status: 4 -> 0

$ state_checksum.py turn2-state.sav "Autosave EndTurn - turn3.sav" --mask resave
A  a55e433687fff0e380de2caabf964a31
B  a55e433687fff0e380de2caabf964a31
policy: floats=bits mask=resave reader=fe5a6f7cd4ae7910  [masked: Checksumx1, Statusx8]
IDENTICAL

Two things to note. The tree distinguishes the two Singularity players by id (496 and 512) where the raw byte diff could only say "1st of two Singularity records". And the masked run reports Statusx8 — it replaced all eight Player.Status fields, of which four were already 0; that number is printed so the mask's reach is visible rather than assumed.

4.3 A real turn transition is fully attributed

One real End Turn (verify/results/state-checksum/turn2-to-turn3.txt), 108 leaf differences, every one carrying a path:

  /Summary/Turn: 2 -> 3
  /Sim/FleetIDs[]: removed [1744], added [34, 1776]  (7 -> 8 entries)
  /Sim/ShipIDs[]: removed [], added [1760]  (16 -> 17 entries)
  /Sim/RNG/.: '<raw 2503 B ef4d678696ed4c53>' -> '<raw 2503 B a80459bfd63a006b>'
  /Sim/players/Player[16 "re"]/Sav: 289688 -> 532369
  /Sim/players/Player[16 "re"]/Events/EvNxID: 2 -> 3
  /Sim/players/Player[16 "re"]/Events/Events/.[EvTurn=3]: only-in-B
  /Sim/players/Player[32 "Fane Lao"]/TechTree/TResDone[106]: 2879 -> 5768
  /Sim/players/Player[32 "Fane Lao"]/Maint: 500 -> 1000
  /Sim/players/Player[496 "Singularity"]/dipstats/.[1]/lastally: 2 -> 3
  ...

That reads as a turn report: economy, research, the new fleet and ship ids, the advanced RNG state, and the new event bucket at EvTurn=3 — which is the turn-bucketed layout events.md established, walked correctly by the tree.

Of the 108 differences, 93 are scalar value changes, 13 are structural (12 nodes only in the turn-3 save, 1 only in turn 2), and 2 are id lists. Only 4 are floats, and all four are far outside any plausible tolerance:

  /Sim/systems/Sys[112 "Gamma Cephei"]/RepCur: 336360.0 -> 336840.0  [15360 ulp]
  /Sim/systems/Sys[288 "Ke'Dolarra"]/RepMax:   370000.0 -> 370520.0  [16640 ulp]
floats: 4 differ, 0 within 2 ULP

Worth knowing before budgeting float-parity work: on a two-player 28-system turn the float state barely moves, and what moves, moves a long way. Nothing in this corpus sits near a rounding boundary, so §3's question is about paths this corpus does not yet exercise.

4.4 Chain record and verify

recorded 3 turns -> chain-turn1-3.json
  turn 1  9bbcbd4945cd8319  cov-ok  turn1-state.sav
  turn 2  aa85fe76d412cdb3  cov-ok  turn2-state.sav
  turn 3  5ac4a24197e82de4  cov-ok  turn3-state.sav

$ state_checksum.py --chain chain-turn1-3.json turn1 turn2 turn3
turn 1  MATCH   9bbcbd4945cd8319  turn1-state.sav
turn 2  MATCH   aa85fe76d412cdb3  turn2-state.sav
turn 3  MATCH   5ac4a24197e82de4  turn3-state.sav

and, substituting a wrong save at turn 2, the desync-log behaviour — stop at the first divergent turn, name the subsystems:

turn 1  MATCH   9bbcbd4945cd8319  turn1-state.sav
turn 2  DIVERGE a1448e6c1867fc53 != aa85fe76d412cdb3  MyGameverify1verify1.sav
    subsystem /Summary: 42b2094efe6e285a -> 8c7e33a33dc76b3d
    subsystem /Sim/players: fa7f5ad40afed208 -> 3416ca2128671b1e

The saves in this chain are the ones the game actually wrote across two End Turns, so the chain mechanics are validated on real turn data. What is not validated is generating a fresh chain from the VM — see §5.

4.5 Tests

62 tests, uv run python3 -m unittest discover -s verify/state-checksum -t verify/state-checksum. All pass. With only the in-repo saves, two real-save tests skip (the bb4fd9ac re-save form is not in the repo); with SOTS_SAVES_DIR pointed at the full corpus, 62 pass, 0 skipped. 24 of them cover --relabel-new-ids (§2.6), and 7 of those 24 assert a refusal — the guards are the part worth testing.

Three of the tests earn their keep by having caught real defects during development: the sibling-index cascade in §2.1, a string value's length prefix missing from the reconstruction (which made the coverage audit fail loudly at offset 0x1c instead of silently under-covering — the audit working exactly as intended, on its author), and the raw-byte completeness scan of §2.6, which caught the reader typing a fleet reference as a float where a value-based scan saw nothing.

2026-09-09 correction, not a defect in the tool. test_known_resave_delta_localises_to_five_ named_leaves enumerates candidate pairs over sorted filenames, and asserted the re-save direction as 4 -> 0. Adding cb-turn2to3-endturn.sav to the corpus produced a pair whose re-saved member sorts first, so the observed direction was 0 -> 4 and the test failed on a corpus fact. The claim is symmetric; the assertion now is too (and still requires all four Status leaves to move the same way, with Checksum following by ∓16).

4.6 A negative result on Summary.Checksum

determinism-oracle.md observed that the top-level Checksum moves by exactly −16 when four Player.Status ints go 4 → 0, and concluded it is additive and derived. Two candidate derivations were tried here and both are ruled out: it is not a byte sum over the inflated stream, and it is not a sum over the int leaves. Both are consistent with the −16 on the re-save pair (both change by −16 there), but neither leaves a constant residual across turns 1/2/3, so neither is the function.

Most likely it is an additive sum over some traversal of the in-memory state — a desync check of the same family as this tool — which would explain why it tracks the four Status ints and not the file. Unresolved, and it does not need resolving: it is derived, so it is masked or localised, never trusted as evidence. Recorded here so nobody re-runs the same two experiments.

---

5. The replay loop — designed, NOT run

VM140 is held by one lane at a time under the lab exclusivity rule (campaign/board.md; holder was R-recapture, is M-movefleet as of 2026-09-08). Nothing in this section has been executed by this lane. It is written to be handed to whoever holds the VM.

5.1 The loop

  record:                                   verify:
  seed.sav ──┐                              seed.sav ──┐
             │  load                                   │  load
             ▼                                         ▼
      [game: End Turn] ──> (Autosave).sav        [game: End Turn] ──> (Autosave).sav
             │                  │                      │                  │
             │                  ▼                      │                  ▼
             │        state_checksum root_N            │        state_checksum root_N'
             │                  │                      │                  │
             └── feed back ─────┘                      └── feed back ─────┘
                                │                                         │
                                ▼                                         ▼
                        chain.json (turn, root,              compare: first N where
                        per-subsystem digests)               root_N' != root_N is the
                                                             divergent turn; diff the
                                                             two saves to name the object

Per turn, on the host:

1. Push the current save to C:\SOTS\SavedGames\ (scp to re@192.168.10.139).
2. Drive the UI: Load Game → Single Player → OK → pick row → OK → Launch → wait for the strategy map → End Turn → wait for the new turn → Quit to Main Menu.
3. Pull (Autosave).sav and (Autosave EndTurn).sav back.
4. state_checksum.py the post-turn autosave; append {turn, root, subsystems} to the chain.
5. The post-turn autosave becomes the next iteration's input.

Comparison against a recorded chain is state_checksum.py --chain chain.json S1 S2 …, already implemented and validated on the three real saves (§4.4). It stops at the first divergent turn — the OpenRCT2 desync-log discipline: only the first divergence is diagnostic, everything after it is downstream noise.

5.2 The one canonicalisation the loop needs

Step 5 feeds a loaded post-turn autosave back in. That is precisely the case determinism-oracle.md flagged: Player.Status 4 → 0 and the derived Summary.Checksum move on the round trip. So:

• compare post-turn autosave against post-turn autosave with --mask none (they are byte-identical run to run; no canonicalisation is needed and none should be applied);
• use --mask resave only when comparing across a load boundary — a re-implementation's output against a loaded autosave, or a pre-turn save against a post-turn one of the same turn.

The chain records which mask it was built under and verify_chain refuses to compare across policies, so this cannot be got wrong silently.

5.3 What it needs from lane R's recipe

Everything below already exists in findings/subsystems/running-the-game.md and findings/subsystems/determinism-oracle.md; this is the list of what the loop consumes, so the VM holder can say which parts are still true.

need	where it is today	note
launch the game non-interactively	schtasks /Run /TN SOTS (task created /IT /RL HIGHEST, runs C:\SOTS\launch.cmd)	nominally ~30 s to the main menu, but the board records it taking >60 s; screenshot and verify before the first click or the path lands in Credits. 3× qm sendkey 140 esc skips the Bink intros
click driver	task SOTSUI running recipe/click_helper.ps1, reading C:\SOTS\ui\cmd.txt (click X Y | move | key | type | sleep ms | fg)	QEMU mouse_move/mouse_button do not register (no USB tablet); this is the only working path
the End-Turn click path	determinism-oracle.md: Load Game (512,536) → Single Player (512,290) → OK (551,523) → row → OK (682,624) → Launch (511,663) → ~30 s → End Turn (100,714) → ~5 s → menu (1000,714) → Quit to Main Menu (938,699) → OK (537,377)	1024×768 windowed at 0,0; display.cfg must pin windowed 1 / 1024 / 768
where saves live	C:\SOTS\SavedGames\; End Turn writes (Autosave EndTurn).sav (pre-turn), (Autosave).sav (post-turn), rotates (Autosave Backup).sav	nothing is written on Load or on Launch
a clean Load dialog	move pre-existing autosaves aside, as determinism-oracle.md did with pre-existing\	the dialog lists by filename; a stale row shifts the row click
file transport	scp over re@192.168.10.139	the earlier work also used a Z:\saves share
failure triage	ssh spicy 'echo "screendump /tmp/x.ppm" | qm monitor 140' + convert	the loop should screenshot on any step that times out, since a mis-click looks like a divergence
shim state	binkw32.dll proxy with shim.cfg hooks=trace was loaded during the determinism runs and did not perturb the bytes	the chain must record the shim build id; a hooks=replace run is a different chain, not a continuation

Two hazards worth stating before anyone runs it:

• Text fields ignore Backspace and Esc (running-the-game.md), which is why the existing save names are concatenated. The loop should never need to type, but if it does, it cannot correct a typo.
• A mis-click is indistinguishable from a divergence at the checksum layer. The loop must assert the expected turn number from the parsed save (Summary.Turn) before recording a root, and screenshot when it does not match. Without that, the harness can report a confident DIVERGE that is really a missed button — which would be exactly the same class of error this whole tool exists to prevent. The board's >60 s main-menu gotcha is this hazard already happening once; a blind click landed in Credits. Every wait in the loop must be a wait-for-condition, never a fixed sleep.

5.4 What the loop would buy

The three-turn chain in §4.4 is real but tiny. A 50-turn chain from a fixed seed would be the project's first end-to-end regression: any change to the shim, to a replaced function, or to the standalone engine either reproduces 50 roots or names the turn and the object where it stopped. That is the OpenRCT2 replay test, with a stronger oracle than they had (byte-identical saves rather than reconstructed command streams) and a finer diagnostic (a named object rather than a sprite-checksum delta).

---

6. Costs and limits

• ~6 s per save on this host, dominated by save_reader.py (37k items). --no-audit saves roughly a fifth of that and gives up the coverage proof; do not use it in a gate.
• The digest is only as good as the parse. The reconstruction audit closes the gap between "the reader read something" and "the reader read everything", but a reader that mis-types a field still produces a self-consistent, total, deterministic digest. That is why §2.4 records the reader fingerprint.
• Opaque frames (TechTree body, spy2, civr, comms, Ojvs, Attrib, sprjs, SvSctOb, trdmgr, spymgr, CD) are covered byte-for-byte but not named internally, so a divergence inside one localises to the frame, not to a field. Improving that is schema work in save_reader.py, not checksum work.
• The corpus is one game: 2 real players, 28 systems, 3 turns. Every claim in §3 and §4 is bounded by that. In particular §4.3's "zero float leaves differ across a turn" is a fact about this game, not about the engine.