# PL — decomposing the `/Sim/players` residual Every lane so far attacked a named subsystem and reported which leaves fell out. This one runs the other way: start from the residual the metric reports, group it by **mechanism**, and say what the remaining leaves actually are. Closing leaves is secondary to the decomposition. Binary re-measured, not inherited. `sots_turn` built from `main` (`aabd8a3`) in this worktree, `tools/standalone_report.py --binary …`: | pair | baseline | after | closed | regressed | `/Sim/players` share | |---|---:|---:|---:|---:|---:| | `turn1-state -> turn2-state` | 209 | **128** | 81 | 0 | **54** | | `turn2-state -> turn3-state` | 108 | **69** | 39 | 0 | **24** | | pair 1, `--commit-blocked=T31 --ai-player 1` | 209 | 126 | 83 | 0 | 52 | | pair 2, same | 108 | 67 | 41 | 0 | 22 | The stale `status.json` breakdown said `/Sim/players` 55. It is **54** on pair 1 and **24** on pair 2. --- ## 1. The decomposition The first fact, and the one that reframes the rest: **53 of the 54 leaves on pair 1 and 23 of the 24 on pair 2 are values our turn writes back unchanged from the input save.** Only one leaf in the whole block — player 32's `Sav` — is a number we computed and got wrong. The residual is almost entirely *unmodelled*, not *mismodelled*. | # | mechanism | pair 1 | pair 2 | rung | blocked on | |---|---|---:|---:|---|---| | M1 | **AI research orders** — `ResRate`, `ResTNm`, `ResErrRoll`, and the tech-tree state they move (`St[n]`, `TResDone[n]`, `Tbd[n]`) | 12 | 2 | **B** | `game/ai`: the AI picks a target *during* the turn | | M2 | **AI ship construction** — `ShipRecs/*`, `Maint`, `FNG/FNGNum`, `NumDes` + the new `Des[…]` frame, `lboid`, and player 32's `Sav`/`PvSav` | 17 | 8 | **B** | lane B6: no build order exists at load | | M3 | **Observation records refreshed by the AI's own new design** — `odes`, `owep`, `otch/*/otnL` (phase T34 `RecordObservedDesigns`, stub) | 9 | 1 | **B** | downstream of M2 — the observed design *is* the design the AI just made | | M4 | **Events** — `Events/EvNxID` + the bucket frames | 8 | 6 | A (4/3) + B (4/3) | half is the human's `EVENT_NO_RESEARCH`, implemented in P11 and gated only on a **game-data root**; half is the AI's `EVENT_SHIPS_BUILT`/`EVENT_RESEARCH_OVERBUDGET` (M2/M1) | | M5 | **Bankruptcy limits** — `BnkEl`, `BnkPr` | 4 | 4 | **A** | `BnkEl`: T31 is implemented and blocked on an operator flag. `BnkPr`: needs one tuning constant from the data files | | M6 | **`Status`** — 0 → 4 on four of eight players | 4 | 0 | A? | the **predicate** is not identifiable from this corpus (§4) | | M7 | **`PvSav`** — the S00 snapshot, for players M2 does not touch | 0 | 2 | **A** | nothing — closed here | | M8 | **A monster faction's one-off design** — player 528 `NumDes` 18→19 + `Des[1712 "Refugee Trade Ship"]` | 2 | 0 | B? | unexplained; a non-empire faction creates a design on turn 1→2 and never again | | | **total** | **54** | **24** | | | Per-mechanism evidence is in §2–§5. ### Rung split of the block | | pair 1 | pair 2 | |---|---:|---:| | Rung B (needs the AI's own orders) | 42 | 14 | | Rung A, implemented, gated on a **game-data root** (`--data`) | 6 | 5 | | Rung A, closable, no blocker | 2 | 5 | | not identifiable from the corpus (`Status`) | 4 | 0 | **Three quarters of the `/Sim/players` residual is Rung B**, and it all hangs off two AI decisions on one player: pick a research target, and queue one destroyer. The Rung-A part is small, and most of it is *already written* — it needs the harness to be handed the game's data directory, not more reverse engineering. --- ## 2. M1 / M2 / M3 — the three faces of one AI turn (Rung B) Player 32 "Fane Lao" is the only AI empire that owns colonies, and it does two things in the turn that our engine cannot: it assigns research, and it builds a ship. Everything in M1, M2 and M3 is a consequence. Measured, from the state-checksum tree over the three saves: * `ResTNm` `''` → `IND_Waldo` and `ResRate` `0.25` → `0.800000011920929` — the AI's own order. The two "Singularity" shadow empires do the same (`DRV_PlsFiss`, `BIO_GnMod`), and their `ResErrRoll` flips `False` → `True`. `St[106]` 2 → 3 and `TResDone[106]` 0 → 2879 → 5768 then follow from the allocation. * `PvSav` 50,000 → 38,100 and again 92,651 → 80,751: **11,900 leaves the treasury before the first spine phase on both turns.** That is lane B6's queue-time deduction of a build order the input file does not contain, and it is why player 32's `PvSav` does not close in §5. * The new design is `Des[18 "Honor Lance"]`, and the observation records name it exactly: `odes/.[1]` holds `odid=18, opid=32` — **the AI observes its own new design**. `owep/.[1]` is `bal_gauss`, that design's weapon, and the three `otch` entries whose `otnL` moves from 1 to 2 are `DRV_Fissn`, `WEP_GsDrvr`, `DRV_Hyper` — that design's technologies. So T34 `RecordObservedDesigns` is not an intel pass over enemy fleets at all on this workload; it is a self-registration triggered by design creation. * On pair 2 the same design is built again (`srb[0]` 1→2, another `EVENT_SHIPS_BUILT`), and this time `odes/.[1]/otnL` moves 2→3 while the `otch` entries stay at 2. **`odes` is re-stamped on build; `otch` is re-stamped on design creation.** One workload, two different refresh rules — worth recording before anyone models T34 from the pair-1 numbers alone. None of this is closable without `game/ai`. It is listed here so the next lane does not re-derive it: **42 of the 54 leaves on pair 1 are one AI player's research pick and one destroyer.** ## 3. M4 — events The corpus posts exactly two events on pair 1 and three on pair 2, and the split is clean: | player | event | rung | |---|---|---| | 0 (human) | `EVENT_NO_RESEARCH`, every turn | **A** — P11 implements it; blocked on the string table | | 1 (AI) | `EVENT_SHIPS_BUILT` (both turns), `EVENT_RESEARCH_OVERBUDGET` (turn 3) | B — M2 and M1 | P11's own note is precise about it: *"4 event(s) NOT posted: no string table."* Lane EV measured `--commit-blocked=P11 --data ROOT --ai-player 1 --ai-player 2 --ai-player 3` at **4 closed on pair 1, 3 on pair 2, 0 regressed**. Those leaves are in today's residual only because `tools/standalone_report.py` invokes the binary with no `--data` root. ## 4. M6 — `Status`, and why it is not identifiable here `Status` goes 0 → 4 on turn 1→2 for players 16, 32, 496 and 512, and stays 0 for 528, 544, 560 and 576. It then stays 4 on turn 2→3, which is why the leaf does not appear in pair 2's residual at all. The trouble is that the two sets are **perfectly correlated with species**: the four that take the 4 are species 0 and 2, the four that do not are all species 4. Sweeping every scalar field of the player record on `turn1-state`, **fourteen** of them split the roster exactly the same way — `ReqCL`, `AMine`, `CnTrd`, `CnVItl`, `cdp`, `hadvs`, `harcc`, `hgs`, `PvMA`, `CstE`, `CstR`, `CstT`, `MinRate`, `MaxOH`, `NPTrk`, `PrGtTrf`, `TerraMod`, `pddm` — eighteen of them. Any one of them "fits". Only two corpus saves carry a non-zero `Status` at all, so there is one observation of one transition on one roster: **any predicate chosen here is a one-bit fit on eight correlated players, which is exactly the shape rule 23 was written for.** `ReqCL` is the most plausible on name and on meaning — `Status = 4` is written by `MarkPlayerTurnEnded` from the End-Turn submission paths (W2), and `ReqCL` reads as "a client must submit for this player" — but it is a hypothesis with a workload attached, not a finding. **The probe that settles it** (rule 18, rule 20): an entry probe on the writer W2 located at `OnMessage+0xa15`, capturing the player index on every call for one turn. It names the set directly and costs one VM session. Instrument the *entry*, not the count. ## 5. What this lane changed See the prediction block below; measured results follow it. --- ## 6. Predictions, written before the build (rule 2) ### PL-1 — `PvSav` is S00's snapshot of `Sav` `PvSav(turn N+1) == Sav(turn N)` holds exactly for players 16 and 576 across all three saves (50,000 → 50,000 → 289,688 against `Sav` 50,000 → 289,688 → 532,369; and 0 → 0 → 98,871 against `Sav` 0 → 98,871 → 198,730). For player 32 it is `Sav(turn N) − 11,900`, the M2 deduction. **Predicted:** pair 1 — 0 closed, 0 regressed (every player's `Sav` already equals its `PvSav` in `turn1-state`, so the snapshot is a no-op there). Pair 2 — **2 closed** (`Player[16]/PvSav`, `Player[576]/PvSav`), **0 regressed**; player 32 stays open, short by exactly 11,900. **Falsification.** If the snapshot were taken later than S00 — say after P02 writes savings — player 16's `turn3` `PvSav` would be its *turn 3* `Sav` (532,369), not its turn 2 `Sav` (289,688). It is 289,688. If the snapshot were per-player conditional, some player other than 32 would show an offset; none does. If it regresses anything, the symptom is a player whose `PvSav` and `Sav` differ in the input for a reason that is not M2 — there is none in the corpus, so a regression here means the field is not a snapshot at all. ### PL-2 — T31's difficulty column is recoverable from the input save T31 is blocked on `ServerPlayer+0xf9`, the per-player "is AI" flag, which the save does not carry and which is worth ×1.1 on that player's max income. The operator supplies it with `--ai-player N`. But the input save **already carries the answer**: its `BnkEl` was written by the original at the end of the previous turn from the colony state the save holds. Computing `BnkEl` from that state under both columns and comparing against the stored value identifies the column — for every player whose max income is non-zero, since the two columns differ by 10%, far more than one truncation. **Predicted:** on `turn1-state`, the column resolves to non-AI for player 0 and AI for player 1; it is *ambiguous* (both columns give `BnkEl = 0`) for the five players that own nothing, where the value is 0 either way. Player 7's column is unknown before measuring. With the column identified from the save and `BnkEl` committed, the phase closes **2 leaves per pair, 0 regressed** — the same as `--commit-blocked=T31 --ai-player 1` measures today, but with no operator input. **Falsification.** (a) If the AI flag does more than select a ×1.1 income column, the identified column will still reproduce the *stored* value while the *post-turn* value diverges; symptom — `BnkEl` closes on pair 1 and regresses on pair 2, or the other way round. (b) Player 576's `BnkEl` is **constant** at −665,806 across all three saves although its `Sav` grows; if its column is identified and its post-turn max income has moved, committing regresses that leaf. Symptom — 2 closed and 1 regressed. (c) If the pre-turn computation reproduces *neither* column's value for a player, the phase must abstain for that player, and the leaf stays pass-through — no regression, but no close either. ### PL-3 — the protection factor is a widened float (rule 23, read the four bytes) `ComputeBankruptcyLimits` multiplies `BANKRUPTCY_PROTECTION_LIMIT_FACTOR` in as a `double`. The image does not. In `ServerPlayer::UpdateBankruptcyLimits` the two constants are loaded by **different opcodes**, and that is the whole point: ``` DB 45 FC fild dword [ebp-4] ; maxIncome, still on the stack afterwards DD 05 30 EC A2 00 fld qword [0x00a2ec30] ; DD /0 = m64fp -- a DOUBLE in .rdata D8 F9 fdivr st(0), st(1) ; maxIncome / that double E8 … call ftol ; -> BnkEl, then the -2e9 clamp 8B 0D DC DF AE 00 mov ecx, [0x00aedfdc] ; the tuning pointer slot D8 09 fmul dword [ecx] ; D8 /1 = m32fp -- a FLOAT32 E8 … call ftol F7 D8 neg eax ; -> BnkPr ``` The `.rdata` double at `0x00a2ec30` reads `00 00 00 40 33 33 C3 BF` = **−0.15000000596046448**, i.e. `(double)(float)-0.15` — already handled. The protection factor is the other case: it is read `dword ptr`, so whatever decimal the data file carries is **narrowed to float32 before the multiply**, and our `double` multiply is wrong at every boundary. **Predicted:** 0 leaves move on this corpus — all seven non-zero `BnkPr` records invert to a max income where `3.3` and `(double)3.3f` truncate to the same integer. Three hand-written test expectations move by one or twenty (`-3300 → -3299`, `-330 → -329`, `-1320000000 → -1319999980`). The two constants disagree on roughly **1.1% of max-income values at the corpus's empire size**, rising with empire size, so this is a fix the corpus cannot see — report it as thin coverage, not as verified. **Falsification.** If the factor were a `double` in the image the opcode would be `DC /1`, not `D8 /1`. If some *other* call site multiplies the same global as a qword, the storage is a double and this is wrong; the check is a cross-reference sweep on `0x00aedfdc`.