sots-re/findings/control-flow/raid-target-pick-verdict.md

The raid target pick — a verdict on TradeManager+0x0c

• Type: control-flow (static decode of the writer + live measurement)
• Owner / date: lane AR · 2026-09-08 · guest VM141 (sots-re-win10-b, 192.168.10.143) — held from the time this file was committed
• Decides: lane AG's gate-indexed-rng-audit.md §3.3 final paragraph — per-system containing-sector table versus sector-indexed vector of six — which lane AD (raid-gate-multiplicity.md §4) measured and correctly reported it could not separate on sector TradeID 832
• Instrument: lane Z's return-address ledger (draw_sites) + lane H's entry probes at probes=8, the byte-neutral set. Not probes=11 (lane H bisected index 8 as not byte-neutral)

---

1. Predictions, committed before the build (rule 2)

Everything in §1 was written and committed before the shim was built, before the workload was played and before any counter was read. It is reproduced verbatim below when the results are added; nothing in it is edited after the fact, only annotated with verdicts.

1.0 The static result this lane found first, stated as a falsifiable prediction

Lane AG's §7 lists "ServerTradeManager+0x0c's writer was not found" as the one load-bearing inference in its document. This lane found the writer on the host before touching the guest, and it decides the question on its own. It is written here as a prediction, because a live run can falsify it, and because rule 3 says static reading and behavioural comparison are different instruments and neither is trusted alone.

FUN_00841700 (this in ecx → ebx; 214 bytes, 0x00841700–0x008417d5, decoded to the next function start per rule 17) does exactly three things:

;  1. CLEAR the +0x0c vector
0084170b  lea  ecx,[ebx+0xc]                    ; &this->vec0c
0084170e  call 0x459f70                         ; vector<T*>::resize(0)  -- arg pushed at 0x841709

;  2. RESIZE it to the length of the vector at [this+4]+0x40 .. +0x44
00841713  mov  ecx,[ebx+0x4]
00841716  mov  eax,[ecx+0x44]
00841719  sub  eax,[ecx+0x40]
0084171c  mov  edx,[ebx+0x10]                   ; vec0c._Mylast
0084171f  mov  edi,[ebx+0xc]                    ; vec0c._Myfirst
00841726  sar  eax,0x2                          ; N = count([this+4]+0x40..+0x44)
00841729  sar  ecx,0x2                          ; cur = count(vec0c)
0084172c  mov  DWORD PTR [ebp-0x4],0x0          ; fill value = NULL
00841733  cmp  eax,ecx
00841735  jbe  0x841749
0084173f  lea  ecx,[ebx+0xc]                    ; grow:  _Insert_n(_Mylast, N-cur, NULL)
00841742  call 0x50e6a0
00841754  lea  ecx,[ebx+0xc]                    ; shrink: erase(_Myfirst+N, _Mylast)
00841757  call 0x4ddfc0

;  3. FILL it by walking sectors x their member systems
0084175c  ecx = this->+0x1c ; eax = (this->+0x20 - ecx)/4       ; the SECTOR vector
00841778    sect = sectors[i]
0084177f    inner count = (sect->+0x7c - sect->+0x78)/4          ; the sector's MEMBER vector
00841798    m   = sect->members[j]
008417a2    idx = m->+0x5c                                       ; the member's OWN INDEX field
008417a5    edi = this->+0x0c
008417a8    mov DWORD PTR [edi + idx*4], ecx                     ; table[idx] = sect

Three things follow, and each is checkable by a reader who disagrees:

1. The table's length is, by construction, the length of the container that trfr indexes. FUN_00841cd0 — the function that settles what trfr means, and the one AG cites for exactly that — resolves a route's source endpoint at 0x00841d36 as mov eax,[edi+0x4]; mov ecx,[eax+0x40]; mov edx,[esi+0xc]; mov eax,[ecx+edx*4], i.e. ([this+4]+0x40)[rt->trfr]. Step 2 above resizes the +0x0c vector to the length of that same vector on that same object. So G_B1a (0 <= rt->trfr < count(this->+0x0c..+0x10)) is satisfied by every route with a valid trfr, by construction, in the same way that AG showed vslot15's G1 is satisfied by every rt in every save by construction.
2. The slot index is a system's own index field, and the slot value is a TradeSector*. Step 3 writes table[m->+0x5c] = sect where sect came out of the sector vector and m came out of that sector's member list. That is the definition of a per-system containing-trade-sector table. FUN_00841c70 reads it back the same way (arg->+0x5c → bounds check against the same count → table[idx], then table[idx] + 0x78 — the member vector — is handed to FUN_0059ec00), which is the independent confirmation that +0x5c on the indexing object and +0x78 on the table element are the two halves of one relation.
3. The table is rebuilt on load. FUN_00841700 has five callers; one of them is FUN_00858a10, which is full of ReadInt/ReadFloat calls and invokes FUN_00841700 at 0x00858f07 as its last real act. So a loaded save has a populated table, and this is not a galaxy-generation-only structure.

P0 — the verdict, predicted. TradeManager+0x0c is a std::vector<TradeSector*> of length numSystems, indexed by system index. AG's per-system reading is right; the sector-indexed-vector-of-six reading is false, and 0x0088b613 is therefore reachable in principle. ad-turn27-two-raiders.sav has systemIds of length 28, so the table has 28 slots and trfr ∈ {14,16,18,20} clears G_B1a with room to spare.

How P0 could be wrong, and the symptom of each way (rule 2 requires this):

way it could be wrong	symptom in the run
[this+4]+0x40 is not the systems vector — some other container of a coincidentally similar length	B is entered on a success and still costs 0 words
m->+0x5c is not a system index (e.g. the member list holds something else)	same symptom; table[trfr] would then be null or a wrong sector, and G_B1b rejects
the members of sector 816 do not include the systems the routes are sourced at	B entered, 0 words; and the save's tssys list would contradict the route's trfr
FUN_00841700 is not called on this path after all (my caller read is wrong)	B entered, 0 words, table all-null

In every one of those cases the observable is the same: B entered, 0 words. That single number is the whole experiment, and it is why the run is worth taking even though the static read looks closed.

1.1 The state, read fresh from the save (rule: do not inherit a number)

Read from verify/results/saves/ad-turn27-two-raiders.sav with verify/save-reader/save_reader.py --dump, before touching the guest.

trdmgr holds FIVE rt records at turn 27, not three. Lane AD's §4 reports "three route records, trfr = 18, 14, 14"; the save has five, trfr = 18, 16, 14, 20, 14, tro = 32 (the AI) on all five, trfrs = trtos = 0 on all five. This is a correction to raid-gate-multiplicity.md §4 and to its board row (rule 11), recorded before the run rather than after.

System index ↔ system id is index = id/16 − 3, pinned from Sim.systemIds [48, 64, 80, …, 480] (28 entries, stride 16, first = 48). Applying it to each sector's tssys list reproduces lane AG's index sets for all six sectors exactly, which is the check that the mapping is right:

sector TradeID	grid	tsct	tscr	member system indices	fleets present
752	1	2	253	1, 10, 20, 24, 17	6864
768	2	2	253	2, 7, 14, 21, 22, 27	6880
784	3	0	253	4, 8, 12, 25	—
800	4	0	253	6, 11, 5	—
816	5	2	253	9, 15, 16, 18, 19, 26	7072 Freighters (PID 32, 11 ships), 7088 Escorts
832	6	0	253	13, 23, 0, 3	3744 Alpha, 6544 Beta — AD's two raiders

So on the turn-27 route set:

• sector 816 sources TWO routes (trfr 18 and 16) → candidate list n = 2, bound = 1;
• sector 768 sources two (trfr 14 twice) → n = 2;
• sector 752 sources one (trfr 20) → n = 1, bound = 0;
• sectors 784, 800, 832 source none. 832 is still the one sector no route is sourced in.

Geometry, recomputed rather than inherited (node positions from trdmgr, colony positions from Sim.systems[].Sys.Pos; player 0 = PlyrIdx 0 = PID 16, HomeSys 48, CnRad true):

sector	from Epsilon Eridani (idx 0)	from Downbelow (idx 12)	sources a route?
752	12.85	8.43	yes (1)
768	11.53	10.14	yes (2)
784	9.36	3.49	no
800	9.37	11.77	no
816	15.66	12.12	yes (2)
832	4.99	4.56	no

Reproduces lane AD's table to the last digit. Player-0 fleets at turn 27: 3744 Alpha Fleet and 6544 Beta Fleet on 832 (both DesID 17, one CR Repair and Salvage each, Range consumed to 4.0125), and 6672 Gamma Fleet at LocID 48 (home, Range 9.0).

1.2 The workload

Build several separate single-ship Extended Range destroyer fleets (stock hull, Range 27.0, cost 2,252, node speed 4.0 — no research required) and park them on sector 816's node, Pos bit-equal, for as many End Turns as the session allows. Sector 768 is a secondary target if the map allows it: it is closer (10.14 ly from Downbelow) and also sources two routes, so a fleet there is a second independent instance of the same test at no extra build cost.

Separate fleets, not one big fleet, and this is arithmetic not taste. A is per fleet (lane AD) and its odds are ODDS_DE + PER_SHIP·nShips for a destroyer fleet. One 5-destroyer fleet rolls once at 0.05 + 0.05 = 0.10; five 1-destroyer fleets roll five times at 0.06 each — expected successes 0.10/turn against 0.30/turn. Three times the signal for the same ships.

1.3 The numbered predictions

#	prediction
P0	(above) +0x0c is the per-system containing-sector table; AG's reading is right and the sector-indexed reading is dead
P1	TradeManager::Slot13RngCalleeA is entered once per parked permitted fleet per turn and costs 1 word each — lane AD's per-fleet result, re-confirmed on a different sector and a different hull
P2	On a turn A succeeds for a fleet on 816, Slot13RngCalleeB is entered and reaches 0x0088b613, costing ≥ 1 word — the number lane AC and lane AD both measured as 0
P3	B's full cost on such a success is 2 words: NextInt at 0x0088b613 (exactly 1 — RNG_NextInt has no zero-bound early-out, and with bound = 1 the mask is 1 so no rejection is possible either) plus NextFloat at 0x00820c1b inside FUN_00820af0, unless that function's species short-circuit fires (owner->+0x5c == 1, or either of the two SpeciesDef tests)
P4	Therefore OnAllCombatDone_Tail costs k + 2s words on a turn, where k = parked permitted fleets and s = successes among them. With one raider that is 1 on a failing turn and 3 on a succeeding turn — AG's committed number in §3.3, tested
P5	draw_sites shows a strategic row at call 0x0088b613 (NextInt) with calls == words == s, and one at 0x00820c1b (NextFloat) with calls == s, words == s − (species short-circuits). Both are sites no lane has ever fired; 0x00820c1b is one of the six lane AG added to the inventory
P6	0x00820e18 (A's NextFloat) shows calls == words == k, reproducing AD's per-fleet pricing on a hull and a sector AD did not use
P7	The hooks=off control will not agree with itself — I expect AD's failure to repeat, because it is the per-process client-AI seed and the AI is larger by turn 33 than at 27, not smaller. I predict the variation is again confined to Player[32]'s designs / build queues / fleet ids, and that /Sim/RNG and /Sim/trdmgr are bit-identical across all runs. If a /Sim/trdmgr leaf, a trade-sector leaf or a player-0 fleet leaf moves, my numbers are not off a reproducible sub-tree and I will say exactly that instead of reporting them
P8	If A is entered k times but B is never entered across the run, that is not a negative — it is a run of failed Bernoulli trials, and I will report the exact binomial probability rather than the word "unremarkable" (rule 20)

1.4 The falsifier, stated as the sentence I will have to write

If a raider is parked on sector 816 with Pos bit-equal, A succeeds for it, B is entered, and B still costs 0 words — then P0 is false, TradeManager+0x0c is not the per-system table, lane AG's §3.3 decode is retired, and the campaign loses a finding it is currently leaning on.

That is a real result and it is the one I am most interested in, because it would mean a careful static read of the writer produced a confident wrong answer — which is rule 3's warning pointing the other way from its usual direction.

1.5 What this lane will not be able to settle, predicted in advance (rule 15)

• The freighter doubling. Sector 816 holds the AI's Freighters fleet, so param_2 is finally testable in principle — but separating p = 0.06 from p = 0.12 needs on the order of a hundred fleet-rolls. At the sample size a session affords, the success count is consistent with both and I will report it as consistency, not validation.
• The design+0x12c > 1 short-circuit. Still unpriced; the Dreadnought category was empty for lane AD and nothing in this workload changes that.
• bestScale. 0x009f8d48 = 0.33f applies when ship+0x18 & 0x100000. I will read the destroyer's flag from the save rather than assume it is clear.
• A rung-A calibration pair. P7 predicts there is none to be had on this lineage.

---

Results, and the verdict, follow below. Nothing above this line is edited after the run.