sots-re/findings/control-flow/fleet-visit-order-mechanism.md

What orders the fleet-assignment visit? — the container hook on ad-turn27

• Owner / date: lane BU · 2026-09-09 · guest VM146 (sots-re-win10-146, re@192.168.10.146)
• Held: VM146, from the time this prediction was committed. VM140 (reference, exclusive), VM141 (lane AZ) and VM144 (lane BS) untouched; lane BT is on the host in verify/state-checksum/ and is not touched either.
• Trigger: findings/control-flow/ai-visit-order-probe.md §4.1 — lane BR's closing paragraph, which killed H2 by measurement and named this lane's work in one sentence: one bounded static read of AssignFleetsAndIssueOrders 0x006c16c0 and the gathering hub to place a hook, log (element address, systemId, minted fleetId) in visit order, two fresh processes. Frame: findings/resolutions/2026-09-09-fleet-id-order-residue.md §2.2 / §3 / §4.
• Build: bu-55408a9-20260909T071101Z, built in /srv/re-lab/build/sots-engine-bu after ssh spicy 'pct exec 111 -- rm -rf …' of the whole tree (rule 24), from a lane-private git worktree at ~/sots-engine-bu (branch wip/bu, commit 55408a9) with no local build* shipped (rule 21). binkw32.dll sha256 117c150a4dbd7f240ada7b8416917ad67eb9f239682dc7370a8a521e0c0956d5. Deployed to C:\SOTS\shimdist-bu.
• Input: C:\SOTS\SavedGames\ad-turn27-two-raiders.sav, sha256 1c8baa27680809d585ab1728391e82729642d32aaedffd5bf95b616f0a11a436, 100,809 B — re-verified on the guest before the deploy, equal to lane AD's, BP's and BR's published value.
• Route: load (ad-turn27-two-raiders.sav → one End Turn), held fixed, as in BP and BR, so this lane is unconfounded by lane BQ's per-history input (resolution §9.1).

---

0. Where the chain stands, in one paragraph

Two processes with identical pinned AI client seeds write autosaves differing in exactly 35 of 61,147 leaves, and all 35 are one transposition: two newly formed fleets exchange contents. The command blocks differ in exactly three words. The fleet-id counter is deterministic — 1970, 1986, 2002 are minted in that order in every process. What varies is the order in which the fleet-assignment pass visits the ship groups that need a new fleet. Lane BR then excluded RNG by measurement: across all three AI clients' OnResumePlaying brackets foreign_words=0, foreign_calls=0, residual=0, left_delta == observed (so not an inlined draw either), and the per-process global generator at 0x00af6e58 was drawn exactly three times in the whole process, from one return address, minting the three client seeds and doing nothing else. H2 is dead. What is left is H1 — an address-keyed container walked in heap order — or H1b — a comparator reading an uninitialised word, where the order is a function of nothing in particular. BR also measured that LFH randomisation is live here (four processes, four relative orders for one identical allocation sequence) and that the emitted command nodes' address order does not track the visit order, so the block cannot substitute for the hook. This lane places the hook.

---

1. The bounded static read, and what it bought

Read to place a hook, not to derive an answer (rule 18). Recorded here because the hook's validity rests on it, and because two of its three facts are new to the record.

1.1 Rule 17, discharged first

AssignFleetsAndIssueOrders was disassembled from dumps/sots.exe to the next function start, not to Ghidra's reported size. The real body is 0x006c16c0–0x006c247a ret; Ghidra's sizeInBytes (3504) and endAddress (0x006c247a) agree with the ret — but immediately after it sits a four-entry jump table at 0x006c247c, the target of jmp [eax*4+0x6c247c] at 0x006c22fb, followed by int3 padding to the next function start 0x006c2490. So a sweep clipped at fva + sizeInBytes loses the table, which is the same class of defect rule 17 names even though the ret itself was reported correctly this time.

1.2 The walk, and why the loop body is not the hook

param_4 is the std::vector<StarFleet*> that AcquireFleetsForTask filled (its [ebp-0x3c] result, per AI3). The function walks it three times:

loop	range	per element it calls	order
head	0x006c1730–0x006c1740, once at entry, before the pass gate	0x006a4290	vector index order
element	body at 0x006c17e0, cursor at [ebp-0x38]	the assignment work	vector index order
tail	0x006c1760–0x006c1770, entered at 0x006c1753 after the element loop is exhausted (jmp 0x6c1753 at 0x006c21c4)	0x0069da10	vector index order

The element loop's cursor is advanced by add eax,0x4 at 0x006c21b5 and compared against _Mylast refetched from [param_4+4] every iteration (0x006c21bb), with the back-edge jne 0x6c17e0 at 0x006c21be. So the visit order is the vector's index order and nothing inside the loop can reorder it — which relocates the question, correctly, to whatever filled the vector.

Patching the loop body would be a mid-function detour whose first instruction (0x006c17e6) is a branch target — from jne 0x6c17e6 at 0x006c174d, the first iteration's entry — so a 5-byte patch at the body head would corrupt the first pass through it. That is exactly the shape rule 19 exists for, and it is unnecessary:

0x006a4290 and 0x0069da10 each have EXACTLY ONE CALLER in the whole image, and that caller is AssignFleetsAndIssueOrders. (Ghidra cross-references: totalToCount = 1 for both.)

They are ordinary function entries, called once per element, in the same order the element loop will follow. Two entry detours therefore record the walk with no return-address filter, no mid-function patch, and no traffic from anywhere else in the game. A third detour on 0x006c16c0 itself brackets them, so each burst of element rows is attributed to (agent, task, pass, vector) rather than inferred from where the bursts fall — and pass matters, because the emitting body is pass-1-only while the head loop runs on both passes.

1.3 What the two callees are, and the layout they confirm

Both read the element's ships vector at [fleet+0xa8] − [fleet+0xa4] and each ship's id at [ship+0x4], which independently confirms StarFleet_off_Ships (+0xa4/+0xa8) and gives the ship id the same offset as StarFleet_off_Id. They are exact inverses over a std::vector<int> at agent+0x2d8 (_Myfirst +0x2d8, _Mylast +0x2dc, _Myend +0x2e0):

• 0x006a4290 = ClaimShipsOfFleet — for each ship, linear-scan the agent's id vector (0x006a42e0) and push_back the id if absent, with the MSVC grow path (capacity check against 0x3ffffffe, reallocate through 0x00483410);
• 0x0069da10 = ReleaseShipsOfFleet — find the id, memmove the tail down (import 0x009dd30c), [agent+0x2dc] -= 4. RET 4.

So the fleets acquired for a task have their ships' ids parked on the agent for the duration of the assignment walk and removed when it is done. New names, filed in ghidra/addresses.d/bu.json with the offset; AssignFleetsAndIssueOrders is not re-declared there (lane AI3 owns it, and gen_addresses.py rejects a same-address-different-name collision).

1.4 What the read did not settle, stated so nobody reads more into it

• Where the new fleet id is minted is still not located. IDMap::AllocateOnLocalNode 0x008b8b70 has six callers and IDMap::AllocateLocalID 0x0080f710 twenty-four, none of them in the AI band 0x0068–0x006e on a direct edge from this function. So this lane logs the minted id by joining to the block, not by hooking the mint. That is a gap in the read and it is recorded as one.
• The gathering hub was not read. The resolution's §4 allows reading it; it is not needed to place this hook, and rule 18 says stop. If the answer is H1, the container that ordered the vector lives in AcquireFleetsForTask 0x006ceef0 / GatherFleetsForTier 0x006abf80 / 0x006b7c90 / 0x006cb310 and is stage 3, not this lane.
• Nothing here says the four list-10 groups are visited inside one call. They may be one vector in one task's call, or four bursts across four task calls. The instrument is agnostic: the bracket row records the call, and the element rows record the order within it, so both readings are visible in the same log. §2.3 predicts for both.

---

2. The predictions, committed before the run

Committed in their own commit, with no result in the file (rule 2).

P0 (the instrument, checked before any output file is opened). shim.log reads BUILD_ID bu-55408a9-20260909T071101Z; 28 of 28 registered hooks mode=off; zero ignoring unknown key; zero COVERAGE:; aiseed call=1/2/3 … pinned=1 with no pinned=0, no PIN MODE WITH NO PINS and no used=0xdeadbeef wildcard hit; and three aivisit: … create=MH_OK enable=MH_OK lines. Any miss and the run is void and nothing is read from it.

P1 (the outcome set, rule 19's own check). (Autosave).sav ∈ {e913ff41188211c02d536da616337544e64133996cd7cc7a6521a8df1960226f, 724528ffde9a7514b69ab9e82ed3b8c8ade63d622c0720de30503a73a92df11e} in both runs, and the pre-turn (Autosave EndTurn).sav = 16f63adbf383946db17c381998957172bca803406b7df78f3b03805fef0bbcb8 in both. A third file is ambiguous between k ≥ 3 and the three aivisit detours perturbing the run and does not immediately mean either; §2.4 names the disambiguation and this lane will run it rather than pick a story.

P2 (rule 26 (d), the pin's own control). At least one of the two runs is byte-identical to lane BP's unpinned run L (e913ff41…), which is the natural run whose observed seeds this lane's pin uses. Until that holds, nothing is read from a pinned pair. If both runs land on 724528ff… the control is unmet and this lane says so and takes a third process rather than reading the pair anyway.

P3 — THE HEADLINE, AND IT IS THE COMMITTED PREDICTION THE BRIEF ASKS FOR. The visit order is ascending element address. Concretely, in each run and for the burst that covers the groups list 10 records:

• elem in the aivisit claim rows is strictly increasing with idx;
• the aivisit slots row (the vector's storage read straight out of param_4) is the same sequence, so the two independent readings agree;
• the aivisit rel rows are the same order as the claim rows for the same call, i.e. the vector was not permuted during the walk;
• and across the two processes, the element order differs exactly where the visit order differs. If run 1 lands on e913ff41… (list 10 = (384,1970) (80,1986) (384,2002) (816,7072), system 384 first) and run 2 on 724528ff… ((80,1970) (384,1986) …, system 80 first), then the system-384 group's element address is below the system-80 group's in run 1 and above it in run 2. If both runs land on the same file, both must show the same relative address order, which is the weaker but still falsifiable form.

P4 (the join). Every aivisit claim row's ships=[…] id set contains the ship id list of exactly one list-10 element of the same block, and that mapping is injective. This is what makes the pairing of element address to (systemId, fleetId) a measurement rather than an assumption about position.

P5 (the block, inherited unchanged from BP and BR). The aiorders dump has 9 blocks and 81 elements, the same (pid, list, idx) key set and the same per-list counts (player 32 emitting {1:3, 3:19, 5:15, 7:2, 8:3, 10:4, 12:12, 14:8, 23:15}), and differs from BP's runs A and B only inside the proven noise mask plus, at most, the three transposition words.

2.1 How each of these could be wrong, and the symptom

way	symptom	what it would mean
H1 is right	P3 holds: elem ascending with idx, and the two processes' address orders differ exactly where their visit orders do	The container is address-keyed. The engine's deliverable 2 (a canonical order that is a function of the save alone) is confirmed as the right fix, and stage 3 is naming the container inside the gathering hub.
H1b is right	P3 falsified: elem is not monotone in idx, and the order tracks neither address nor id	An uninitialised-word comparator, or some third key. The next separation is named in §2.4 and it is cheap.
a third possibility this lane must not hide	elem ascending in both runs and both runs land on the same file, so nothing distinguishes	P3 holds only in its weak form. It is consistent with H1 and does not test it. Reported as a weak result, not a confirmation, and the fix is a third process.
the walk is one burst per task, not one vector	the bracket rows show four calls with one element each	Then the varying order is the task order, not a within-vector order, and the address to test is the task pointer, which the bracket row also carries (task=). The instrument survives; the H1 test moves to that column and this file will say so.
a wrong offset	fid=0, nships=0 or an empty ships=[] on rows whose fleets plainly have ships	The reads are probed, so this shows as a logged zero, never a fault. The join (P4) fails visibly rather than silently, and the run is reported as an instrument failure.
the hook perturbs the turn (rule 19)	a third autosave file	Not separable from k ≥ 3 by these runs alone. §2.4.
the pin is half-applied	any pinned=0, a PIN MODE WITH NO PINS line, or a used=deadbeef hit	The run is void. Checked in shim.log before any output file is opened.
a stale or wrong binary (rule 24)	BUILD_ID ≠ bu-55408a9-20260909T071101Z	Void. The CT111 tree was rm -rf'd before the rsync and the build was re-run from the lane commit.
the config carries an inherited defect	a live line inside what was meant to be a comment; an unnamed registered hook silently installed under hooks=trace	Defended twice: tools/check_shim_configs.py passes with shim.cfg.bupin marked # exhaustive, and the non-comment diff against the file it was copied from is quoted in §2.2.

2.2 The config, and the two diffs (BP's check, and it has caught a real defect)

shim.cfg.bupin is shim.cfg.bppin with exactly three non-comment lines added. Taken against the real shim.cfg.bppin pulled off the guest, not against a local copy of it:

$ diff <(grep -v '^\s*#' shim.cfg.bppin | grep -v '^\s*$') \
       <(grep -v '^\s*#' shim.cfg.bupin | grep -v '^\s*$')
7a8,10
> aivisit=on
> aivisit.out=C:\SOTS\shim.aivisit.txt
> aivisit.ships=8

bppin has 43 live lines, bupin 46. And against shim.cfg.brprobe, the file this lane actually copied (BR's, which is bppin plus the three airng lines), the diff is six lines and shows the airng bracket being taken back out:

$ diff <(grep -v '^\s*#' shim.cfg.brprobe | grep -v '^\s*$') \
       <(grep -v '^\s*#' shim.cfg.bupin | grep -v '^\s*$')
6,8c6
< airng=on
< airng.pin_seed=off
< airng.out=C:\SOTS\shim.airng.txt
---
> airng=off
9a8,10
> aivisit=on
> aivisit.out=C:\SOTS\shim.aivisit.txt
> aivisit.ships=8

airng is off deliberately: BR already took the per-client ledger on this exact state and it came back clean, so re-installing that bracket would be three more detours for an answer already in hand. Everything else is byte-for-byte BP's: hooks=trace, all 28 registered hooks off by name, aiorders=on with deep=off and words=12, aiprobes=off, airesearch=off, aiseed=pin with 32=156ebbbd,496=fe7b2826,512=0ed341d1,*=deadbeef.

And the structural check the resolution asked for is now enforced, not remembered. shim.cfg.bupin carries a line reading exactly # exhaustive, so tools/check_shim_configs.py requires it to name every registered hook:

$ tools/check_shim_configs.py
check_shim_configs: OK (27 registered hooks, 2 template(s) declared exhaustive)

(27 is the count excluding the self-test hooks the checker exempts; the file carries 28 hook.* lines, the 28th being Shim::SelfTest::Fill.)

2.3 The instrument, stated in full (rule 19 wants the list, not the adjective)

Installed, and nothing else: the Mars::Application::Initialize detour; the seven draw-site detours (unconditional whenever hooks != off); one aiorders detour on StrategySim::ApplyTurnCommandBatch; one aiseed detour on StrategyApp::RunAI; and three new aivisit detours. That is BP's instrument plus three. All three new targets are function entries; two of the three are called from exactly one place in the image and that place is the third. No airng bracket, no facades, no entry probes, no watchpoints, no research hooks.

2.4 The disambiguations, named before the run so they cannot be chosen after it

• A third autosave file → one plain run of shim.cfg.bppin (this lane's aivisit lines removed, everything else identical). Under the k ≥ 3 reading that run cannot land on a third distinct file with probability better than 1/3; under the perturbation reading it lands on one of BP's two. This is BR's own procedure and it is adopted verbatim.
• P3 falsified (H1b) → the next separation is whether the order tracks the ids: the element rows already carry fid and the ship id set, so "ascending fleet id" and "ascending minimum ship id" are testable from the same log with no further run. If the order tracks neither address nor id, the key is a word nothing in the save determines, and the follow-up is a watchpoint on the comparator inside the gathering hub — a different lane and a different instrument.
• P2 unmet (both runs on 724528ff…) → a third process, and no reading of the pair until one of them reproduces run L.

2.5 What this lane cannot decide, whatever it says

One save, one procedure, one build, one route (load), one turn. It can say what the visit order is a function of on this turn; it cannot name the container that produced it (that is stage 3, in the gathering hub), it cannot speak about a turn that acquires fleets by a different gather block, and it says nothing about lane BQ's per-history residue, which is a different input in the same layer. The 3–40-turn fuse at 0x0069dbb0 cannot fire inside one turn of a load and is untested here, exactly as in BP and BR.

---

3. The result

---

2.6 A second prediction, committed after run 1 and before run 2's autosave existed

Run 1 is in and it did two things at once: it falsified P3 as written and it named a sharper key than P3 had. Rule 2 says a prediction exists to be disagreed with, and the honest move when a measurement hands you a better model mid-lane is to commit the new model as a prediction before the next run, not to present it afterwards as what was meant all along. So:

What run 1 measured (details and the full log in §3). The walk order over the acquired-fleet vector is not ascending element address — 0 of 5 multi-element sequences. It is lexicographically ascending in (fleet->Location*, fleet*) — 5 of 5, with the fleet pointer breaking the tie in the one sequence where two fleets share a Location. Both keys are heap addresses. And the newly minted fleet ids are already on the fleet objects at claim time, so the id↔group pairing is decided upstream of this function and this walk inherits it.

The committed prediction for run 2, written at 07:26 UTC while run 2 was still loading:

Q1. Run 2's aivisit log is again (loc, elem)-lexicographically ascending in every multi-element sequence, and again not ascending in elem alone.

Q2 — the cross-process test, and it is the one that matters. Identify the two groups by their ships, which are process-independent: the system-384 group is the fleet holding ship 6976, the system-80 group is the fleet holding ship 5264. In run 1, loc(384-group) = 0x3205b040 < loc(80-group) = 0x3205eb90, and the autosave was e913ff41… — the branch on which 384 is visited first and takes id 1970. Therefore:

• if run 2's autosave is 724528ff… (the 80-first branch, (80,1970) (384,1986) in list 10), then in run 2 loc(80-group) < loc(384-group) — the two Location objects land in the opposite relative order;
• if run 2's autosave is e913ff41… again, then loc(384-group) < loc(80-group) again.

Falsifier: the ordering relation between the two Location addresses failing to agree with the branch. That would say the Location pointer is a correlate on one process and not the key, and would push the mechanism back toward H1b or toward some third key.

Q3. The fleet ids carried on the elements at claim time follow the same relation: on the e913ff41… branch the fleet holding 6976 carries fid=1970; on the 724528ff… branch it carries fid=1986.

3.0 Lead

H1 is confirmed and P3 is falsified in the same measurement, which is the best outcome this lane could have had. The walk is not ordered by the element address — 0 of 4 multi-element sequences, in either process. It is ordered by the element's Location* — 4 of 4, in both processes, strictly ascending, with the fleet pointer breaking the one tie. Both keys are heap addresses, and the container is therefore address-keyed: H1, with a sharper key than the hypothesis was stated with.

The proof that it is the address and not some correlate of it is inside this lane and does not depend on the branch changing: two processes that wrote byte-identical autosaves visited the same six fleets in two different orders, and the two orders are exactly what ascending Location* predicts in each process. Two transpositions moved; both moved with the addresses.

And the hook found something the static read had missed: the newly minted fleet ids are already on the fleet objects when this walk first touches them. So AssignFleetsAndIssueOrders does not decide the id↔group pairing — it inherits it, from a walk in the gathering hub that is ordered the same way. That relocates the engine's canonicalisation point by one function and is stated in §4.2.

3.1 P0 / P1 / P2 — the instrument and the controls, checked before anything was read

Verified identically in both runs, from shim.log, before any output file was opened:

check	run 1	run 2
BUILD_ID	bu-55408a9-20260909T071101Z	same
exe base	0x005e0000 (ASLR delta +1966080), pid 9408	same base, pid 5752
registered hooks mode=off	27 + selftest: … mode=off = 28 of 28	same
ignoring unknown key	0	0
COVERAGE:	0	0
aiseed call=1/2/3 … pinned=1	3 of 3, no pinned=0, no PIN MODE WITH NO PINS, no deadbeef	3 of 3, same
natural seeds observed (then overwritten)	4e82d22a / c6e8cff1 / 278fc9d2	a777d022 / 79bf6acf / b08b77ae
aivisit: … create=MH_OK enable=MH_OK	3 of 3 (rva 0x002c16c0, 0x002a4290, 0x0029da10 → va 0x008a16c0, 0x00884290, 0x0087da10)	same

Six more natural seeds, sharing no value with each other or with any of the twelve already on the record — lane L1's per-process seeding reproduced a sixth and seventh time. And exe base is 0x005e0000 for the eighth process on this guest, so "pointer order" here still means heap order and nothing else.

P1 holds. Both runs: pre-turn (Autosave EndTurn).sav = 16f63adbf383946db17c381998957172bca803406b7df78f3b03805fef0bbcb8 (100,758 B), post-turn (Autosave).sav = e913ff41188211c02d536da616337544e64133996cd7cc7a6521a8df1960226f (101,375 B). No third file. The rule-19 ambiguity the brief warned about did not fire, so this lane is in neither the k ≥ 3 case nor the instrument-perturbation case and the disambiguation run was not needed on that account.

P2 holds, and it is the strongest single fact about the instrument. cmp — not just the hash — says both runs' post-turn autosaves are byte-identical to verify/results/saves/bp-pinA-turn28.sav, which is byte-identical to lane BP's unpinned run L. So a process carrying a seed pin plus three new detours inside the AI's fleet-assignment path reproduced a natural, unpinned run of this turn byte for byte, twice. That is rule 26 (d)'s control met, and it is also rule 19's control for aivisit, taken rather than assumed. The pre-turn file is byte-identical to bp-turn28-pre.sav as well.

Against BP's other branch, state_checksum.py --floats bits --mask none reports the familiar DIVERGED: 35 leaf difference(s), and the leaves are BP's transposition — including Flt[1986]/ships/Ship[5264]: only-in-A, which is exactly what this lane's aivisit rows say (fid=1986 ships=[5264]). Hook → command block → save, end to end.

3.2 P5 — the command block, under BP's proven noise mask

Comparator: lane BR's cmp_aiorders.py, unmodified, with BP's L/A-proven mask.

• run 1 vs BP's run A — 9 blocks, 81 elements, identical (pid, list, idx) key sets, identical per-list sizes, identical SET gates, and NONE. Every differing word is inside the proven noise set.
• run 1 vs BP's run B — same structure, and exactly the three transposition words (list 8 idx1 word0 1970/1986, list 10 idx0 word0 80/384, list 10 idx1 word0 384/80).
• run 1 vs run 2 — NONE outside the noise set, and the same list-10 order (384,1970) (80,1986) (384,2002) (816,7072).

P5 holds in its strong form, and P4 (the join) holds too: every aivisit claim row's ship-id set matches exactly one list-10 element's group, and the mapping is injective — 1970 ← [6976], 1986 ← [5264], 2002 ← [6992], 7072 ← [11 ships].

3.3 P3 — FALSIFIED as written, and replaced by a sharper key

The aivisit claim rows are the head loop's walk of the acquired-fleet vector as AcquireFleetsForTask delivered it. Both runs, both multi-element calls:

Run 1 (e913ff41…)

call=4 n=6   loc ascending: YES   elem ascending: NO   fid ascending: NO
   elem=0x3254ba70  loc=0x3205b040  fid=1970  ships=[6976]
   elem=0x3254ac90  loc=0x3205cba0  fid=1602  ships=[6080 5920 5936]
   elem=0x3254c600  loc=0x3205eb90  fid=1986  ships=[5264]
   elem=0x325497c0  loc=0x33ae5278  fid=354   ships=[2176 2352]
   elem=0x3254cbc8  loc=0x33ae7020  fid=1570  ships=[5840 6144]
   elem=0x3254a100  loc=0x33ae8938  fid=1346  ships=[5024]
call=7 n=2   loc ascending: YES   elem ascending: NO   fid ascending: NO
   elem=0x3254b4a8  loc=0x0d7a5dc8  fid=7072  ships=[2720 2992 3456 …]
   elem=0x32549698  loc=0x33ae6028  fid=258   ships=[1728]

Run 2 (e913ff41…, byte-identical output)

call=4 n=6   loc ascending: YES   elem ascending: NO   fid ascending: NO
   elem=0x326b4c98  loc=0x321c5708  fid=1602  ships=[6080 5920 5936]
   elem=0x326b5010  loc=0x321c74b0  fid=1970  ships=[6976]
   elem=0x326b5828  loc=0x321c7940  fid=1986  ships=[5264]
   elem=0x326b3450  loc=0x338ab288  fid=354   ships=[2176 2352]
   elem=0x326b2e88  loc=0x338ac4c8  fid=1346  ships=[5024]
   elem=0x326b64e0  loc=0x338ae270  fid=1570  ships=[5840 6144]
call=7 n=2   loc ascending: YES   elem ascending: NO   fid ascending: NO
   elem=0x326b6bd0  loc=0x0d85a3c0  fid=7072  ships=[2720 2992 3456 …]
   elem=0x326b3578  loc=0x338ad278  fid=258   ships=[1728]

Score, over the four multi-element claim sequences of the two processes:

candidate key	sequences ordered by it
fleet->Location (ascending)	4 / 4
fleet (the element address — P3's key)	0 / 4
fleet->Id	0 / 4
systemId	0 / 4 (run 1 visits system 384 before system 80)
minimum ship id in the group	0 / 4 (run 1 visits ship 6976's group before ship 5264's)

So P3 as written is falsified, and so is every save-derived ascending key anybody has proposed: the order is not ascending system id, not ascending minimum ship id, not ascending fleet id. What it is ordered by is a heap address.

The one tie, and what it says about the comparator. In run 1 two fleets share a Location (1970 and 2002 are both at system 384, loc=0x3205b040 for both — the Location object is interned per system, not per fleet). The sequence that contains both is ordered 2002 (elem 0x3254b948) then 1970 (elem 0x3254ba70) — ascending element address within the tie. So the observed order is lexicographic in (Location*, StarFleet*): a primary key that is a heap address and a tie-break that is another one. That is the signature of a std::map/set keyed on the location with the object as the disambiguator, or of a sort with that comparator.

A caveat on which rows to read, recorded because it nearly cost a wrong number. The rel (tail loop) sequences are not all sorted, and they should not be: the tail loop runs after the element loop, and the element loop can extend the vector — in call=5 the vector arrives with one element and the tail loop walks seven. Those sequences read [the newly added element] + [the delivered order], which is not the container's order and is not evidence about it. The claim rows are the head loop, which runs before anything is added, and those are the four sequences scored above. The tail rows are still worth their place: on every call whose vector did not grow they reproduce the claim order exactly, which is the self-check that the vector is not permuted during the walk.

3.4 The cross-process test, and it is decided without needing the branch to flip

Runs 1 and 2 wrote byte-identical autosaves. They nevertheless visited the same six fleets in two different orders:

run 1 : 1970  1602  1986  354  1570  1346
run 2 : 1602  1970  1986  354  1346  1570

Two transpositions — (1970, 1602) and (1570, 1346) — and both are exactly the pairs whose Location addresses exchanged relative order between the two processes:

group	run 1 loc	run 2 loc	relative order
fleet 1970 (ship 6976, system 384)	0x3205b040	0x321c74b0	before 1602 in run 1, after it in run 2
fleet 1602 (ships 6080/5920/5936)	0x3205cba0	0x321c5708	—
fleet 1570 (ships 5840/6144)	0x33ae7020	0x338ae270	before 1346 in run 1, after it in run 2
fleet 1346 (ship 5024)	0x33ae8938	0x338ac4c8	—

Nothing in the save changed. Nothing in the seed changed. Two heap addresses exchanged order, and the visit order followed them, twice, in the same process pair. That is the measurement the resolution's §2.2 called a precondition, now observed as the cause on the actual walk.

It also explains, for free, why the two runs' autosaves are identical anyway: 1602, 1346 and 1570 are pre-existing fleets, and reordering them changes no id assignment. The transposition reaches the save only when the pair that swaps is a pair of groups that need a new id — which on this turn is the {6976 @ 384, 5264 @ 80} pair, and that pair kept its order in both of these processes (loc(6976-group) < loc(5264-group) in run 1 and in run 2), which is why both landed on e913ff41…. Q2's second clause therefore holds as predicted, and Q3 with it (the fleet holding 6976 carries fid=1970 in both).

3.5 Run 3 — the branch flipped, and the Location addresses flipped with it

Runs 1 and 2 both landed on e913ff41…, so the cross-branch form of Q2 had no sample. A third fresh process was taken for exactly that, with the identical instrument and the identical config — this is the sample the two-process design could not guarantee, not a change of procedure.

Run 3's (Autosave).sav = 724528ffde9a7514b69ab9e82ed3b8c8ade63d622c0720de30503a73a92df11e, byte-identical (cmp) to verify/results/saves/bp-pinB-turn28.sav — BP's run B, the other branch. Pre-turn 16f63adb… as always. Instrument identical and verified the same way: build bu-55408a9, exe base=0x005e0000 (pid 480), 28 of 28 hooks off, zero unknown keys, zero COVERAGE:, three of three pinned=1 (three more fresh natural seeds: 39037bfa / 2a58e189 / 00640d2c), three aivisit detours MH_OK. Its block against BP's run B: NONE outside the noise set, list 10 (80,1970) (384,1986) (384,2002) (816,7072), list 8 idx0=2002 idx1=1970 idx2=1538 — identical.

And the walk:

call=4 n=6   loc ascending: YES   elem ascending: NO   fid ascending: NO
   elem=0x338cff48  loc=0x333ed4c8  fid=1970  ships=[5264]          <- the SYSTEM-80 group, FIRST
   elem=0x338d0510  loc=0x333ed710  fid=1986  ships=[6976]          <- the SYSTEM-384 group, SECOND
   elem=0x338cf4e0  loc=0x333eede0  fid=1602  ships=[6080 5920 5936]
   elem=0x338d5e18  loc=0x34cc4958  fid=354   ships=[2176 2352]
   elem=0x338cf168  loc=0x34cc6948  fid=1570  ships=[5840 6144]
   elem=0x338d69a8  loc=0x34cc7268  fid=1346  ships=[5024]

This is the prediction, hit exactly:

process	loc of the 384-group (ship 6976)	loc of the 80-group (ship 5264)	relation	visited first	(Autosave).sav
run 1	0x3205b040	0x3205eb90	384 < 80	384	e913ff41…
run 2	0x321c74b0	0x321c7940	384 < 80	384	e913ff41…
run 3	0x333ed710	0x333ed4c8	80 < 384	80	724528ff…

The branch of the outcome set is the relative order of two heap addresses. Q2's first clause was committed before run 3 existed and it is met. Q3 with it: on this branch the fleet holding ship 6976 carries fid=1986 and the one holding 5264 carries fid=1970, which is the transposition, and state_checksum finds the same 35 leaves against run 1 that BP found between A and B.

Three processes, three distinct visit orders of the same six fleets, all ascending by Location*:

run 1 : 1970  1602  1986  354  1570  1346
run 2 : 1602  1970  1986  354  1346  1570
run 3 : 1970  1986  1602  354  1570  1346

Final score over the six multi-element claim sequences of the three processes: ordered by fleet->Location 6 / 6; by the element address 1 / 6 (a two-element coincidence in run 3); by fleet id 0 / 6; by system id 0 / 6; by minimum ship id 0 / 6.

3.6 The thing the static read missed, and it moves the engine's fix

The fleets carry their new ids before this walk ever touches them. fid=1970 is already on the element at idx=0 of the very first burst of claim rows — the head loop, which runs at function entry before the pass gate and before any emission. So AssignFleetsAndIssueOrders does not mint, and does not decide which group gets which id. It receives a vector that is already ordered by Location* and already carries the pairing, walks it in that order, and writes the order into list 10.

Two things follow, and both matter more than the hook did:

1. The mint is upstream, in whatever produced the vector — AcquireFleetsForTask 0x006ceef0 and its three gather blocks (0x006abf80, 0x006b7c90, 0x006cb310). Since the delivered vector is Location-ordered in six of six samples and the ids follow that order, the natural reading is that the same address-keyed container orders the gather, and the mint happens as it is walked. That is an inference, not a measurement — this lane did not hook the gather — and §4.3 says what would settle it.
2. The Location object is interned per system, not per fleet. Run 1's two fleets at system 384 (1970 and 2002) share loc=0x3205b040. So the key is one address per location, and on this turn the two competing groups are at two different systems, which is why the whole residue is a single binary choice.

3.7 What the hook cost, and the timings

aivisit writes 40 lines on this turn — ten AssignFleetsAndIssueOrders calls, of which three are pass 0 with empty vectors, and 18 element rows. aivisit: calls=10 claim_rows=… rel_rows=… closes every log. End Turn with this hook set was ~10 s in run 1 (End Turn 03:21:07, autosave 03:21:13) and comparable in runs 2 and 3 — BP's "~35 s" is generous, BR's "~4 s" was with one fewer module.

---

4. Verdict

4.1 H1 vs H1b

H1 IS CONFIRMED. The fleet-assignment pass walks an address-keyed order, and the key is named: the element's Location*, with the element pointer breaking ties.

Six of six multi-element sequences across three fresh processes are ordered by fleet->Location ascending. Zero of six are ordered by the element address alone (so P3, the committed prediction, is falsified as written), zero by fleet id, zero by system id, zero by minimum ship id. Three processes produced three different orders of the same six fleets, and every difference is a pair whose Location addresses exchanged relative order. And the two branches of the campaign's outcome set are the two relative orders of one pair of Location objects: loc(384-group) < loc(80-group) → e913ff41… (twice), loc(80-group) < loc(384-group) → 724528ff… (once), with the autosaves byte-identical to lane BP's A and B.

H1b — an uninitialised-word comparator — is excluded on this path, and not by preference: an uninitialised key would not reproduce a strict total order by a specific live pointer field in six of six sequences, and it would not track that field across a branch flip. It remains a live hypothesis for other paths; it is dead for this one.

The residue is therefore not noise and not an unbounded scramble. It is a deterministic function of the process's heap layout: the outcome set of visit orders is the set of orderings of the relevant Location pointers, which on ad-turn27 is two, because two groups compete and their Location objects can land either way round.

4.2 What it implies for the engine

The resolver's deliverable 2 — game/ai visits groups in a canonical order that is a function of the save alone, ascending systemId then ascending minimum ship id — is confirmed as the right shape, and this lane can now say what it is and is not.

• It is right that a canonical order is needed and that the original's order cannot be reproduced. The original's key is a heap address. Nothing in the save determines it, and nothing in our engine can or should reproduce it. Canonicalisation is not a convenience here; it is the only option.
• It is right that our order will be one member of the original's outcome set. The outcome set is exactly the set of orderings of the competing groups, with no other constraint — measured, not assumed — so any total order over the groups is a member. Ascending systemId then minimum ship id is a member.
• The one place the deliverable should change, and it is a change of level, not of order. Deliverable 2 places the canonical visit at "the point where a task forms a fleet from a ship group", inside AssignFleetsAndIssueOrders. The measurement says the pairing is already fixed when that function is entered. So the canonical order has to be imposed where the group set is gathered and the ids are minted — the engine's analogue of AcquireFleetsForTask — and AssignFleets must then preserve it. If the engine canonicalises only at the assignment step it will canonicalise the emission order while leaving the minting order to whatever its own container does, which is the same bug one level up.
• Should the canonical order be a different one? On the evidence, no — and this lane has evidence rather than convention, which is what the brief asked for. The original's typical behaviour is not ascending systemId (run 1 and run 2 visit system 384 before system 80) and not ascending minimum ship id (they visit ship 6976's group before ship 5264's). It is not any save-derived order, in either direction, in any of the three processes. There is no order for us to match, so the criterion collapses to "pick a total order that is cheap, stable and obviously a function of the save" — and (systemId, min ship id) is exactly that. The one refinement worth writing into id-allocation.md: the tie-break matters, because the original's own tie-break is the second pointer, so two groups at the same location must still be totally ordered by us; minimum ship id does that.
• Deliverable 3 (the captured-order override) is unaffected and is still the exactness knob. List 10 records the original's order on every captured run, and this lane confirmed the chain block → save end to end in both branches.

4.3 What this lane did NOT establish

• It did not hook the mint. That the gather is ordered by the same key is an inference from six ordered samples plus the ids already being present; it is not measured. The measurement that would settle it is one more detour on AcquireFleetsForTask 0x006ceef0 (or on the client-side fleet-create the mint sits behind) logging (group, minted id) at the moment of minting. That is stage 3 and it is small.
• It did not identify the container. "Ordered by Location*" is a property of the delivered vector, not a name. Whether it is a std::map<Location*, …>, a std::set<StarFleet*> with a location comparator, or an explicit sort is a bounded static read of the three gather blocks — worth taking now that the read has a key to look for, which it did not before.
• One turn, one save, one route (load), one build. The claim "the visit order is address-keyed" is a claim about this walk on this turn. Nothing here speaks to a turn whose fleets are acquired through a different gather block.
• Nothing about lane BQ's per-history residue, which is a different input in the same layer.
• The 3–40-turn fuse at 0x0069dbb0 cannot fire inside one turn of a load and is untested here.
• aivisit's neutrality is measured on this state and nowhere else — three processes, two of them byte-identical to an unpinned natural run and the third byte-identical to BP's other branch. That is the strongest form of rule 19's control available for a hook that cannot be removed from a pinned run, and it is still a statement about one workload.

---

5. Guest notes for the next lane (VM146)

• Released restored and hash-verified — see §6.
• The direct QEMU screendump is the right instrument and this lane confirms BR's note: ssh spicy "echo 'screendump /tmp/x.png -f png' | qm monitor 146" then scp. Twenty-odd screenshots, zero ambiguous frames, zero wasted clicks. tools/vmshot.py still cannot be used from this WSL host (no PIL), so the one-liner is the path.
• PowerShell script execution is disabled on the guest for files, but -ExecutionPolicy Bypass -File works and inline ssh re@… '<powershell>' works. C:\SOTS\ui\bphash.ps1 fails if you run it as a bare .ps1; run helpers as powershell -NoProfile -ExecutionPolicy Bypass -File <path>.
• scp cannot fetch two remote files in one command with quoted parenthesised names — it returns protocol error: filename does not match request. Copy (Autosave).sav to a plain name on the guest first, then scp that.
• Load-dialog geometry re-verified from a screenshot in all three runs, unchanged: 7 rows from y=260 at 29 px pitch, ad-turn27-two-raiders is row 1 at (400,260). Path: Load Game (512,536) → Single Player (512,290) → OK (551,523) → row (400,260) → OK (682,624) → Launch (511,663) → End Turn (100,714). One click per helper call, screenshot between.
• Timings, three runs. Main menu ~2 min 45 s from schtasks /Run /TN SOTS (fg + key {ESC} ×3 spaced 2.5 s, screenshot-verified, never slept-and-clicked); click path ~1 min at one click per call; turn-27 load 1 min 35 s / 1 min 30 s / 1 min 25 s — much faster than BP's 3.5–4 min once the guest is warm, so budget the first load long and the rest short; End Turn ~6–10 s with this hook set. Three complete runs in 19 minutes of guest time.
• The AI client seeds are minted on the LOAD path, not at End Turn. aiseed call=1/2/3 appears in shim.log about 40 s before the map is drawn. It is a useful "the load is nearly done" signal and it is worth knowing before somebody reads a seed line as evidence that the turn ran.
• Left in place: C:\SOTS\shimdist-bu (binkw32.dll, BUILD_ID, shim.cfg.bupin), C:\SOTS\ui\budeploy.ps1, C:\SOTS\ui\preBU\ (the pre-BU autosave pair), and C:\SOTS\ui\bu{1,2,3}-turn28*.sav. BR's shim.cfg.{brprobe,brdeep} and files untouched; click_helper.ps1 and BP's helpers untouched.

---

6. Release

VM146 released restored and hash-verified, exactly as found:

• C:\SOTS\SavedGames back to the 9-file pre-BU set, both autosaves byte-identical to C:\SOTS\ui\preBU\ and to BR's published values — (Autosave EndTurn).sav a3f9dc4b…, (Autosave).sav d59bb9f2…;
• ad-turn27-two-raiders.sav still on disk at 1c8baa27… (so the Load-dialog geometry above still holds);
• C:\SOTS\shim.cfg = hooks=off;
• C:\SOTS\binkw32.dll = 07c962946d93c2cfef336803ac041150bda2640c05980b266902b1aa1a618359, the pre-BP file, restored from C:\SOTS\ui\preBP\binkw32.dll. Note for the next lane: the file to restore is that one, not binkw32_real.dll (603d0a96…) — I restored the real DLL first and had to correct it, which is worth one line so nobody repeats it;
• C:\SOTS\shim.trace.jsonl removed; game process not running.

Artefacts: verify/results/shim/bu/ — BU{1,2,3}-shim.log, BU{1,2,3}-aivisit.txt, BU{1,2,3}-aiorders.txt, claimcheck.py (the ordering test), claim-order.txt (its output over all three runs), shim.cfg.bupin. The three output saves are byte-identical to verify/results/saves/bp-pinA-turn28.sav (runs 1 and 2) and bp-pinB-turn28.sav (run 3) and are deliberately not duplicated in the repo — verified with cmp, not with a hash alone.

Engine: sots-engine branch wip/bu, commit 55408a9 — src/shim/hooks/ai_visit.{h,cpp}, the main.cpp and CMakeLists.txt wiring, src/shim/shim.cfg.bupin (marked # exhaustive), and the regenerated include/generated/sots_addresses.h. tools/clean_room_check.sh: OK. tools/check_shim_configs.py: OK. Address fragment: ghidra/addresses.d/bu.json.

---

Proposed board rows

New row:

| THE AI'S FLEET-VISIT ORDER IS AN ADDRESS-KEYED CONTAINER AND THE KEY IS THE FLEET'S `Location*` - H1 CONFIRMED, H1b DEAD, and the campaign's two-file outcome set IS the two orderings of two heap pointers | control-flow | verified | high | 100% | 2026-09-09 | Lane BU, VM146, stage 2 of the chain lane BR unblocked (`findings/control-flow/fleet-visit-order-mechanism.md`). Build `bu-55408a9-20260909T071101Z`, fresh CT111 tree (rule 24), lane worktree (rule 21), `shim.cfg.bupin` = `shim.cfg.bppin` with EXACTLY THREE non-comment lines added (`aivisit=on/.out/.ships`), diffed against the real bppin PULLED OFF THE GUEST and quoted in the finding, marked `# exhaustive` so `tools/check_shim_configs.py` ENFORCES that all 27 registered hooks are named. THREE fresh processes, route LOAD, seeds pinned to lane L's observed values; 28 of 28 hooks off, zero unknown keys, zero COVERAGE, 3/3 `pinned=1` in every run, three `aivisit ... MH_OK` in every run, `exe base=0x005e0000` for the 8th process on this guest. THE HOOK: `AssignFleetsAndIssueOrders 0x006c16c0` walks a `std::vector<StarFleet*>` by index (cursor `[ebp-0x38]`, `_Mylast` REFETCHED every iteration, back-edge `jne 0x6c17e0` at 0x006c21be), and that walk is BRACKETED BY TWO LOOPS OVER THE SAME VECTOR that call one function each - **`StrategyAIAgent::ClaimShipsOfFleet 0x006a4290` and `ReleaseShipsOfFleet 0x0069da10`, which have EXACTLY ONE CALLER EACH IN THE WHOLE IMAGE and it is that function**. So the instrument is two ordinary function-entry detours plus a bracket on 0x006c16c0, with NO return-address filter and NO mid-function patch - the loop body could not be patched anyway, its first instruction 0x006c17e6 IS a branch target. **RESULT: the visit order is NOT ascending element address (0 of 6 multi-element sequences over three processes), NOT ascending fleet id (0/6), NOT ascending systemId (0/6), NOT ascending minimum ship id (0/6). It is ASCENDING `fleet->Location` (StarFleet+0xa0): 6 OF 6**, with the fleet pointer breaking the one tie (two fleets at system 384 share one interned Location object and are ordered by element address within it). So the container is address-keyed and the comparator is lexicographic in (Location*, StarFleet*), BOTH heap addresses. **P3 - the committed prediction, "the visit order is ascending element address" - IS FALSIFIED, and the hypothesis class it tested is CONFIRMED with a sharper key.** THE CROSS-PROCESS PROOF, and it does not rest on one sample: three processes visited THE SAME SIX FLEETS IN THREE DIFFERENT ORDERS (run1 1970/1602/1986/354/1570/1346; run2 1602/1970/1986/354/1346/1570; run3 1970/1986/1602/354/1570/1346) and EVERY difference is a pair whose Location addresses exchanged relative order. Runs 1 and 2 wrote BYTE-IDENTICAL autosaves and still visited in different orders - the reordered pairs were pre-existing fleets, which is why the save did not move. **AND THE BRANCH FLIP IS MEASURED: run 3's `loc(system-80 group) = 0x333ed4c8 < loc(system-384 group) = 0x333ed710`, the OPPOSITE of runs 1 and 2, it visited system 80 first, and its autosave is `724528ff...` BYTE-IDENTICAL (cmp) to lane BP's run B - while runs 1 and 2 have `loc(384) < loc(80)`, visit 384 first, and are BYTE-IDENTICAL to BP's runs A and L.** So the campaign's two-file outcome set on `ad-turn27` IS the two orderings of two heap pointers. **H1b (an uninitialised-word comparator) is EXCLUDED for this path**: an uninitialised key cannot reproduce a strict total order by a specific live pointer field in 6 of 6 sequences and cannot track that field across a branch flip. **A SECOND FINDING THE STATIC READ HAD MISSED: the newly minted fleet ids are ALREADY ON THE FLEET OBJECTS when the head loop first touches them** (`fid=1970` on the element at idx=0 of the first burst, before the pass gate and before any emission), so `AssignFleetsAndIssueOrders` INHERITS the id-to-group pairing rather than deciding it; the mint is upstream in the gather (`AcquireFleetsForTask 0x006ceef0` + 0x006abf80/0x006b7c90/0x006cb310), and since the delivered vector is Location-ordered and the ids follow that order, the natural reading is that the SAME container orders the mint (INFERENCE - the gather was not hooked). ENGINE CONSEQUENCE, and it MOVES deliverable 2 by one level: the canonical order must be imposed WHERE THE GROUP SET IS GATHERED AND THE IDS ARE MINTED, not at the assignment step, or the engine canonicalises the emission order while leaving the minting order to its own container. On the choice of canonical order this lane has evidence rather than convention: the original's order is NOT ascending systemId and NOT ascending minimum ship id in ANY of the three processes, so THERE IS NO ORIGINAL ORDER TO MATCH and `(systemId, min ship id)` is as good as any - keep it, and keep the tie-break, because the original's own tie-break is a second pointer. RULE 26(d) AND RULE 19, BOTH MET BY MEASUREMENT: runs 1 and 2 are BYTE-IDENTICAL to lane BP's UNPINNED run L, so a process carrying a seed pin PLUS three new detours inside the AI's fleet-assignment path reproduced a natural run byte for byte, twice; run 3 reproduced BP's other branch byte for byte. `aivisit` is behaviourally neutral on this state, measured, not argued. P1/P2/P4/P5 all hold; under BP's noise mask every run's block differs from BP's same-branch run in NOTHING outside the noise set and from the other branch in EXACTLY the three transposition words. Rule 17 discharged: 0x006c16c0's body is 0x006c16c0-0x006c247a `ret` with a FOUR-ENTRY JUMP TABLE living PAST the ret at 0x006c247c (target of `jmp [eax*4+0x6c247c]` at 0x006c22fb). Six more per-process AI seeds, none shared - L1 reproduced a 6th and 7th time. Artefacts: `verify/results/shim/bu/`; the three output saves are byte-identical to `bp-pinA-turn28.sav` x2 and `bp-pinB-turn28.sav` x1 and are deliberately not duplicated |

Edits to existing rows:

• Row 62 — VM146: lane BU held it 2026-09-09 03:15–03:40 local for the container hook (three runs) and released it restored and hash-verified: SavedGames back to the 9-file pre-BU set with both autosaves byte-identical to C:\SOTS\ui\preBU\ (a3f9dc4b…, d59bb9f2…), shim.cfg hooks=off, binkw32.dll 07c96294…, shim.trace.jsonl removed, game process not running, exactly as found. Load-dialog geometry re-verified by screenshot in all three runs and unchanged: 7 rows from y=260 at 29 px pitch, row 1 at (400,260). Left C:\SOTS\shimdist-bu, C:\SOTS\ui\budeploy.ps1, C:\SOTS\ui\preBU\ and C:\SOTS\ui\bu{1,2,3}-turn28*.sav; BR's and BP's files untouched. THREE NEW GUEST GOTCHAS. (1) The file to restore over C:\SOTS\binkw32.dll is C:\SOTS\ui\preBP\binkw32.dll (07c96294…), NOT binkw32_real.dll (603d0a96…) — I restored the real DLL first and had to correct it. (2) PowerShell script execution is disabled for .ps1 files: C:\SOTS\ui\bphash.ps1 fails as a bare path; run helpers as powershell -NoProfile -ExecutionPolicy Bypass -File <path>, or send inline PowerShell over ssh. (3) scp refuses two remote files in one command when the names carry parentheses (protocol error: filename does not match request) — copy (Autosave).sav to a plain name on the guest first. TIMINGS, THREE RUNS, and they revise BP's: main menu ~2 min 45 s; click path ~1 min at one click per helper call; the turn-27 load was 1 min 35 s / 1 min 30 s / 1 min 25 s — BP's "3.5–4 min and not compressible" is the cold figure, and a warm guest is less than half that; End Turn ~6–10 s. Three complete runs in 19 minutes of guest time. And: the three AI client seeds are minted on the LOAD path — aiseed call=1/2/3 lands in shim.log about 40 s before the map is drawn, which is a useful "load nearly done" signal and must not be read as evidence that the turn ran.
• Row 360 — append: MECHANISM NAMED 2026-09-09 (lane BU, VM146): the residual visit order is an ADDRESS-KEYED CONTAINER walked in ascending fleet->Location (StarFleet+0xa0), with the fleet pointer as tie-break - 6 of 6 multi-element sequences over three processes, versus 0 of 6 for element address, fleet id, systemId or minimum ship id. Three processes gave three different orders of the same six fleets and every difference is a pair whose Location addresses exchanged order. The two-file outcome set IS the two orderings of two heap pointers: loc(384-group) < loc(80-group) -> e913ff41 (x2), the reverse -> 724528ff (x1), each byte-identical to lane BP's A/L and B.
• Row 415 — append: And the 35 leaves are now explained end to end: the visit order is ascending Location pointer, so which of the two new fleets gets 1970 is decided by which of two heap objects has the lower address in that process (lane BU, 2026-09-09).
• Row 333 / the Rung C row — append: MECHANISM SETTLED 2026-09-09 (lane BU): the residual input is a heap address ordering, so it is not reproducible by construction and canonicalisation is the ONLY option, not a convenience. The engine's canonical order must be imposed WHERE THE GROUPS ARE GATHERED AND THE IDS MINTED, not at the assignment step - lane BU measured that the fleets already carry their new ids when AssignFleetsAndIssueOrders first touches them.
• Row 326 — append: Lane BU reproduced per-process seeding a 6th and 7th time (six more distinct natural words across three processes on ad-turn27, none shared).
• The resolver's H1/H1b row (2026-09-09 fleet-id-order-residue) — append: RESOLVED 2026-09-09 (lane BU): H1 CONFIRMED with the key named (fleet->Location, tie-break the fleet pointer); H1b excluded on this path. The resolution's section 2.2 precondition is now observed AS THE CAUSE on the actual walk.

Docs to correct in place (rule 11), proposed, not done by this lane:

• findings/resolutions/2026-09-09-fleet-id-order-residue.md §3 deliverable 2 — the canonical visit belongs at the gather / mint, not at AssignFleetsAndIssueOrders; the fleets already carry their ids at that function's entry. §4's H1 row can be marked confirmed with the key.
• findings/subsystems/id-allocation.md §5 — add: the client-side fleet id is minted in the order an address-keyed container delivers the groups (ascending Location*), so the mapping id→group is per-process in the original; the engine mints in a canonical order and must do so at the gather.
• findings/subsystems/ai-stepping-and-passes.md — AssignFleetsAndIssueOrders gains the two new per-element callees and the note that its walked vector arrives Location-ordered.
• guides/lab-screen-wall.md — add the two guest gotchas above (-ExecutionPolicy Bypass -File, and scp with parenthesised names).