# L4 — what the live AI will emit, written before the module was built

Lane L4, 2026-09-08. Guest **VM145** (`sots-re-win10-145`, 192.168.10.145). Worktree `wip/l4` off
`main` `0117495`.

Rule 2: this file is committed **before** the shim module is written, and it names the falsifier for
every claim. Nothing below is a summary of a run; there has been no run.

The question this lane exists to answer: **does our emission model produce the same commands the
game does?** `src/game/ai` models the *shape* of a `TurnCommands` block and the *cost* of each
element, and decides nothing. Nobody has ever looked at a real AI block.

---

## 0. The instrument, and why it is one detour

`Game::StrategySim::ApplyTurnCommandBatch` **0x0088f9b0** receives `(blocks, n)` as two stack
arguments with `ecx = sim` — read straight off the prologue at `0x0088f9db`–`0x0088f9e7`, where
`n` is multiplied by `0x1b4` and added to `blocks` to make the end pointer. **At that instant every
player's submitted block is complete and in memory**, so one register-transparent entry stub dumps
the entire turn's command traffic: six gates and twenty-seven list lengths per player, plus the
element bytes.

That is a strictly better instrument than counting `ModCount` bumps, which is what every previous
lane has had. A bump count says *how many* commands; the block says *which lists, how many
elements, and what values*.

Second instrument: sixteen register-transparent entry counters (`probe_entry.cpp`'s pattern, its
own table so lane H's set is untouched), on the task bodies and the emission gates. One of them —
`StrategyAIAgent::RunTaskList` **0x006b3320** — additionally records its `pass` stack argument into
a global, so every later probe hit is **attributed to a pass**. That is what turns AI3's P2 from a
count into a measurement.

**Rule 20 is the whole design.** `AITRaid`'s list-16 emit is the named open item, and a zero at
`0x007635f0` means nothing unless `AITRaid::Execute 0x0068e670` is also probed: "never ran" and
"ran and emitted nothing" are opposite answers.

**Rule 19 control.** Both workloads have published oracle bytes. Every configuration is run against
them and any configuration that moves a byte has invalidated its own numbers.

---

## 1. Workload W1 — `turn1-state.sav`, one End Turn (the turn 1→2 transition)

Facts already in the corpus, from `turn1-state.sav` → `turn2-state.sav` (read this session with
`verify/save-reader`, not taken from a report):

| | |
|---|---|
| players | 8: ids 16, 32, 496, 512 (`Species` 0/2/0/2) and 528/544/560/576 (`Species == 4`) |
| player 32 | `HomeSys` **288** = Ke'Dolarra, `PlyrIdx` 1 |
| `ModCount` | 0 → 12 |
| `ResRate` | 0.25 → **0.8** on 32, 496, 512; unchanged (0.25) on 16 |
| `ResTNm` | `''` → `IND_Waldo` (32), `DRV_PlsFiss` (496), `BIO_GnMod` (512); `''` on 16 |
| `Status` | 0 → 4 on 16/32/496/512; **0 on all four `Species == 4`** |
| player 32 designs | 5 → 6; the new one is `DesID` **18**, `"Honor Lance"` |
| `designIds` | gains **18** *and* **1712** — the second belongs to player 528, whose design count also goes 18 → 19 |
| `NMnx` | 106 → 109 (ship **1728**, fleet **1744**, and one more) |
| new fleet | **1744** `"Alpha Fleet"` at system 288, holding ship 1728 of design 18 |

### P1 — the block set

**Prediction: `n == 4`, and the four `block+0x04` player ids are 16, 32, 496, 512 in that order.**

*Falsified if* `n == 8` — then the `Species == 4` factions **do** submit, they just submit empty
blocks, and AI4 §2's "no `StrategyClient` at all" is too strong (it would become "a client that
never sets the always-set gate", which is a different and stranger claim). *Falsified differently
if* the four ids are 0,1,2,3 — then `block+0x04` is a player **index**, not the save id, and every
published reading of that field needs the same correction.

### P2 — the four blocks, list by list

| block | gates set | lists non-empty |
|---|---|---|
| 16 (human) | rate only, value **0.25** | **none** |
| 32 (AI) | rate **0.8**, target (`IND_Waldo`) | **1, 3, 5 — one element each** |
| 496 (AI) | rate **0.8**, target (`DRV_PlsFiss`) | **none** |
| 512 (AI) | rate **0.8**, target (`BIO_GnMod`) | **none** |

Boost, group-4, the three-float Hiver gate and `CivilianRatios` **clear on all four**.

That sums to AI4's twelve: 4 rate + 3 target + 3 (player 32's lists) + 2 drivers.

*Falsified if:* any list outside {1, 3, 5} is non-empty on any block; or a list in {1, 3, 5} carries
more than one element; or the human's block carries a list at all; or 496/512 carry a list (they own
nothing, so a list element from them would mean a task fired against objects they do not have).

**The sharpest falsifier is list 8/10/14 non-empty.** Player 32 gets a brand-new fleet (1744) this
turn, and a fleet is exactly the thing lists 8/10/14 order. If the AI issues a fleet order on the
same turn it creates the fleet, AI4's P2 attribution is wrong by exactly the fleet-order group and
the twelve has to be re-derived.

### P3 — the element values

* **list 3** (`{i32 ordinal, i32 designId, i32 systemId, i32 w}`): `designId == 18`,
  `systemId == 288`. The `w` word has never been observed and is not predicted.
* **list 5** (`{i32 systemId, OutputRates}`): `systemId == 288`, i.e. **the same system the build
  order names**.
* **list 1** (`ShipDesignDef` frame + `i32`): the element carries the id **18** somewhere in its
  first 48 bytes.

*Why 18 matters.* 18 is not a multiple of 16 and does not come from the master `NMnx` counter — the
*other* new design that turn, player 528's, got **1712** from that counter, and 528 submits no
block. So there are two id spaces, and the prediction is that **a client-issued design carries a
small client-local id in the command itself**, while a server-created object gets a master id.
*Falsified if* the list-1 element's ids are all ≥ 512 / multiples of 16 — then 18 was assigned
server-side when the command was applied and the design command carries no id at all, which is a
materially different thing for a reimplementation to emit.

### P4 — the probes on W1

| probe | prediction | what a miss means |
|---|---|---|
| `RunTaskList 0x006b3320` | **6** = 3 AI players × 2 passes | 2 ⇒ only one player's task list runs and 496/512 reach `ResTNm` by some other path; 0 ⇒ the instrument is broken, not the game |
| `BuildTurnCommands 0x00783780` | **4**, one per submitting block | ≠ 4 ⇒ P1 is wrong from the other side |
| `RequestBuildForTask 0x006cea50` | **> 0 and even-ish** — entered on both passes, emits only on pass 1 | entries only in pass 1 ⇒ the caller gates before it, and AI3 §2.3's "the hub returns an empty list on pass 0" is not the whole mechanism |
| `AssignFleetsAndIssueOrders 0x006c16c0`, `IssueRouteForFleets 0x006bbd50` | **entered, both passes, zero list-8/10/14 elements** | entered + elements ⇒ P2 falsified |
| `AITRaid::Execute 0x0068e670` | **0** | — |
| `ClientOrder 0x007635f0` (list 16) | **0** | — |
| the six shared planner bodies (`AITColonize` 0x0068b400, `AITEscortGateInvade` 0x0068c7c0, `AITInvade` 0x0068d7a0, `AITNodeBore` 0x0068e590, `AITBuildPoliceShips` 0x00690380, `AITBuildDeepScanShips` 0x006901a0) | **at least one build-shaped body entered in both passes; at most one produces the single list-3 element** | none entered ⇒ the list-3 element comes from a task nobody has named, and AI3 §5's path table is not the emission path |
| `AITAdvanceIdleShips::Execute 0x0068f230` | entered (priority 0, always last) | — |
| `IsClaimedByAnotherTask 0x006a8d20` | **> 0** | — |

**Stated in advance so it cannot be claimed afterwards: W1 almost certainly cannot settle AI3 §2.4.**
A turn-1 AI with one colony and no fleet of its own has nothing to raid, so `AITRaid` is predicted
not to run at all, and a zero at `0x007635f0` will then be a *non-answer* about pass 0 — exactly the
"did not fire" vs "fired and found nothing" distinction rule 20 is about. The AITRaid question needs
`AITRaid::Execute` to be entered, and W2 is the better chance.

**Also stated in advance: this probe set cannot settle AI3's P3.** An entry counter on
`IsClaimedByAnotherTask` measures the "called often" half only; the steal branch at `0x006a8ded` is
*inside* the function and an entry probe cannot see it. P3 stays open.

---

## 2. Workload W2 — `ref-turn2.sav`, one End Turn (the turn 2→3 transition)

`ref-turn2.sav` **is** `turn2-state.sav` (same sha256). Corpus facts for 2→3:

* `ModCount` 12 → 24; `NMnx` 109 → 111 (ship **1760**, fleet **1776** `"Gamma Fleet"`);
* fleet **1744** `"Alpha Fleet"` is **gone**, replaced by fleet **34** `"Beta Fleet"`, in transit
  (`FtTrans 1`), flight plan one waypoint `Wpt 272`, `pnd 288`, ETA 3, origin = Ke'Dolarra's
  position;
* no `ResTNm` change on any player; `ResRate` already 0.8.

AI4 §2.1 attributes the twelve as 4 rate + list 5 + list 3 + list 10 + **2 × list 14** + list 8 + 2
drivers.

### P5 — the block

**Prediction:** `n == 4`; blocks 16, 496, 512 carry the rate gate and **nothing else** (no target
gate this turn); block 32 carries the rate gate and lists **3 = 1, 5 = 1, 8 = 1, 10 = 1, 14 = 2**,
everything else empty.

### P6 — list 14 is two elements against one fleet, and the second field is the discriminator

Lane Q read the element as `{i32, i32, bool}`; `human-turn2-orders.sav` (a UI fleet move) carries
exactly one, `{1456, 0, true}`. AI2's P1 says the AI's bridge calls the adder twice with mode 0 and
mode 1 and the adder keys on `(fleet, mode)`.

**Prediction: the two list-14 elements are `{F, 0, b}` and `{F, 1, b}` with the same `F`, and `F` is
also the fleet id list 8's element names.** That converts AI2's P1 from an inference about bump
counts into a read of the values.

*Falsified if:* both elements carry the same second word (then the adder does not key on mode and
the doubling has another cause); or the two fleet ids differ (then it is two orders against two
fleets and the "one order costs two elements" rule is wrong); or list 14 has one element (then
AI4's two list-14 bumps came from two different fleets and the reference turn moved two).

### P7 — which fleet id the order names

**Prediction: `F == 1744`** — the fleet that exists at submit time — and **34 does not appear
anywhere in the block.** 34 is created when the order is applied, from the same small-id space as
design 18.

*Falsified if* `F == 34`: then the client creates the fleet object *before* submitting and ships the
new id in the command, which would make the small-id space **client-allocated and part of the wire
protocol** — a much bigger constraint on a reimplementation than the alternative, because our engine
would have to reproduce that counter exactly to get byte-identical saves.

This is the one prediction I would most like to be wrong, because the falsifier is the more
interesting world.

### P8 — list 10's first word

Lane AI4 §4.5 refused to name list 10 (`{i32, i32, counted i32}`) on positional evidence alone.

**Prediction: its first `i32` is `F`, and its counted vector holds ship ids** — on W2 that means the
single ship **1728**. If so, "assign these ships to this fleet" is supported by values rather than
by adjacency, and the list can be named.

*Falsified if* the counted vector is empty or holds system ids (W2's route is a single hop to 272,
so a `{…, 272}` tail would make it a route-shaped command instead).

### P9 — AITRaid, the second attempt

Player 32 now owns a fleet, so `AITRaid` has a candidate. **Prediction: `AITRaid::Execute` is
entered on both passes and `ClientOrder 0x007635f0` is entered zero times**, i.e. list 16 stays
empty and AI3 §2.4's inference holds — but *for the reason the probe can see*, which is the point.

*Falsified if* `0x007635f0` is entered with `pass == 0` recorded: then pass 0 **does** emit, AI3's P2
is falsified, and every `ModCount` arithmetic in `ai-order-emission.md` that assumes one emitting
sweep is off by a factor.

---

## 3. Rule 19 — the controls, and what they are compared against

Published oracle bytes (sha256 prefixes, `findings/subsystems/running-the-game.md`):

| workload | `(Autosave EndTurn).sav` | `(Autosave).sav` |
|---|---|---|
| W1 from `turn1-state.sav` | `a3f9dc4b…` | `ab4ac2d7…` |
| W2 from `ref-turn2.sav` | `bb4fd9ac…` | `978041ac…` |

Three configurations per workload, each a separate launch:

| run | `shim.cfg` | purpose |
|---|---|---|
| **C** | `hooks=off` | proves **this clone** reproduces the oracle at all. VM145 is a ZFS clone; nothing has ever checked that it is byte-faithful. If C fails, the lane reports that and stops — every later number would be measured against an unknown baseline. |
| **A** | `aiorders=on`, `aiprobes=off` | the block dump alone: one detour |
| **B** | `aiorders=on`, `aiprobes=all` | the dump plus sixteen entry probes |

**Prediction:** C, A and B all reproduce both oracle hashes. **Falsified if** A or B moves a byte —
in which case that configuration's numbers are reported as unmeasured, not as results, and the
sixteen-probe set is bisected with `aiprobes=N`. Lane H's precedent is explicit that a MinHook
detour has changed this game's behaviour once already, and that the probe module is the one it
happened to.

---

## 4. What this lane will not do, said now

1. **It does not close AI3's P3** (§1, P4). An entry probe cannot see a branch inside the callee.
2. **It does not test the eleven "free" lists** (AI4 P1's untested half) unless one of them turns up
   populated, which P2/P5 predict will not happen. If one does, that is the result.
3. **It does not settle the Hiver gate** (AI4 P3). The corpus has no Hiver player and this lane is
   not manufacturing one.
4. **It reads element bytes, not element types.** The dump emits a fixed 48-byte window per element
   plus the same bytes as ints and floats; decoding to lane Q's records happens offline, in the
   report, where a wrong record is visible as a wrong value rather than being baked into the
   instrument. Where a list's in-memory element is larger than 48 bytes the dump says so rather than
   silently truncating.
5. **The dump's own coverage check**: for every list it walks the node chain *and* reads `_Mysize`,
   and logs a `MISMATCH` line if they disagree. A wrong list layout would otherwise print a
   confident, wrong zero (rule 1).