sots-re/findings/control-flow/raid-intercept-species-word.md

z — the raid interception word, and the species that pays it

• Type: control-flow (static decode of the gate + live measurement)
• Owner / date: lane AZ · 2026-09-09 · guest VM141 (sots-re-win10-b, 192.168.10.143)
• Status: static half verified, and it corrects two published sentences; the live z measurement was NOT taken — the workload was built to within one conjunct and then blocked (§6). A new corpus save is the deliverable, and §7 names the next workload from the failed conjunct
• Decides: the z term of lane AR's k + s + z tail model (findings/control-flow/raid-target-pick-verdict.md §4.2) — never observed through Slot13RngCalleeB by any lane, because every raid this campaign has run was Human
• Instrument: none was armed. hooks=off for the entire session; the probes=8 set the brief specifies was built and deployed to C:\SOTS\shimdist-az but never copied over C:\SOTS\shim.cfg. Nothing in this document is a measurement of the RNG.

---

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 not edited after the fact — only annotated with verdicts below the line.

1.0 What the brief said, and the two ways it is incomplete

My brief — inherited from lane AR's §4.2 and lane AG's §5.2 — states the gate as:

A Human or Zuul raider intercepts and draws nothing. Every other species draws a word.

That is wrong in two places, and both were found by reading FUN_00820af0 from the instruction stream on the host before any guest was touched (rule 18's corollary: static reading is for explaining, but here it is also for not wasting a workload). The function has three short-circuits and they are a disjunction; the campaign has only ever named the third.

FUN_00820af0(TradeManager* this, Vector3* out, TradeRoute* rt, StarFleet* fleet)   ; 0x00820af0

  ebx = registry_lookup(S+0x84, rt->tro)              ; the ROUTE OWNER (ServerPlayer)
  ...
  00820bc2  cmp  DWORD PTR [ebx+0x5c],0x1   ; ServerPlayer+0x5c is the serialised `Species` tag
  00820bc6  je   0x820bf6                   ; SC1 -- route owner is species 1
  00820bcf  call 0x81a2d0                   ; StarFleet_GetCrewSpeciesForIntercept(fleet)
  00820bd7  cmp  eax,0x1
  00820bda  je   0x820bf6                   ; SC2 -- RAIDER's crew species is 1
  00820bdd  call 0x81a2d0                   ; again, same value
  00820be3  call 0x545cc0                   ; SpeciesDef_Get(k)  ->  0x00b10a00 + k*0x184
  00820bed  call 0x53baf0                   ; SpeciesDef_HasInterceptFlag: [ecx+0x144] != 0
  00820bf4  je   0x820bf8                   ; SC3 -- flag clear: fall through to the draw
  00820bf6  mov  al,0x1
  00820bf8  fldz ; fstp [ebp+0xc]           ; frac = 0.0
  00820bfd  test al,al
  00820bff  jne  0x820c33                   ; short-circuited: NO DRAW
  00820c1b  call 0x47d830                   ; <<< NextFloat, ONE WORD -- this is `z`

Correction 1 — species 1 short-circuits too, and species 1 is Hiver. SC2 is a plain == 1 test on the raider's own crew species and has nothing to do with SpeciesDef+0x144. It is not mentioned in AR's §4.2 disjunct list as a species test at all (AR annotates it "raider is Species 0 -- no", which is true of AR's state and hides the rule).

Correction 2 — the route owner's species is a gate too. SC1 tests the route owner, not the raider. A route owned by a species-1 empire is intercepted with no draw whoever raids it. My brief does not mention this conjunct at all, and it is a way for this lane's run to come out zero for a reason that has nothing to do with the raider.

1.1 The species enum, named from the image

SpeciesDef_InitTable 0x005453a0 selects the Species/%s/... data-path prefix through jmp DWORD PTR [eax*4+0x545b60]. Reading the seven-entry jump table as bytes (not by the order the case bodies happen to be laid out in, which is a different order and would give the wrong answer):

index	jump-table target	string
0	0x005453f2	Human
1	0x005453f9	Hiver
2	0x00545400	Tarkas
3	0x00545407	Liir
4	0x0054541c	_NPC
5	0x0054540e	Zuul
6	0x00545415	Morrigi

SpeciesDef_Get 0x00545cc0 bounds-checks k <= 6, so there are exactly seven, and 0x00b10a00 + k*0x184 is the element. This independently confirms lane AR's "species 5 = Zuul" and "species 0 = Human", and it names 1, 2, 3, 4 and 6 for the first time in this campaign.

The +0x144 flag word is written only at 0x0054562f (or [ebx+0x144],2 when the element's index is 5) and 0x00545638 (or [ebx+0x144],1 when it is 0) — AR's read, reproduced.

1.2 The gate as a predicate, and the corpus counted against it (rule 28 practices 1 and 5)

0x00820c1b draws one word through Slot13RngCalleeB iff (a) the route's owner is not species 1 (Hiver), and (b) the raider fleet's crew species is not 1 (Hiver), and (c) the raider fleet's crew species is not 0 (Human) and not 5 (Zuul).

Equivalently: the raider's crew species is one of 2 Tarkas, 3 Liir, 4 _NPC, 6 Morrigi, and the route owner is not Hiver.

StarFleet_GetCrewSpeciesForIntercept 0x0081a2d0 returns the fleet owner's Species (FUN_0071e280(fleet)->+0x5c) on every path except one: when that species is 4 (_NPC) it scans the fleet's ships for a design->+0x14->+0xac..+0xb4 record and returns that record's +0x4. So for a player-owned fleet, crew species == owner species, full stop.

Corpus count, all 30 saves in verify/results/saves/, read with save_reader.py --json:

species present	saves
0 Human (player 0) + 2 Tarkas (the AI) + 4 _NPC	24
5 Zuul (both players) + 4 _NPC	6
1 Hiver, 3 Liir, 6 Morrigi	0

Corpus count against the predicate: 0 of 30. And the near miss is instructive: 24 saves already contain a Tarka empire, which is a drawing species — but it is the AI, and tscr is 253 in every one of them (bit 0 set = player 0 permitted, bit 1 clear = the AI has no Commerce Raiding). So the AI never rolls, A never fires for it, and no amount of patience on an existing save reaches z. The "an AI of another species already raids" option my brief asked me to consider is dead, and the corpus count is what killed it — the state has to be built.

And the tech data says which species can even be a raider. From verify/results/data-catalogs/tech_tree.json (MasterTechList.tech, per-race availability percentages as written):

edge	rp	Human	Zuul	Hiver	Tarkas	Liir	Morrigi
CCC_FTLBrdB -> CCC_FTLEcon	18,000	100	0	100	100	100	100
CCC_FTLBrdB -> CCC_ComRaid	5,000	0	100	0	0	0	0
CCC_FTLEcon -> CCC_ComRaid	12,000	100	0	0	100	100	100

So Hiver can never research Commerce Raiding at all (0% on both edges) — which makes SC2 unreachable for a Hiver player through vslot13, and leaves it as either a defensive test or the path for an _NPC-owned fleet with a Hiver-crewed design. And the species that can both raid and draw are exactly Tarkas, Liir and Morrigi.

This lane picks Tarkas (species 2). Liir is rejected on movement (their early game is a sublight crawl, and this workload lives or dies on parking a fleet on a distant node), Morrigi on their fleet-size-dependent drive. Tarkas is a plain node-drive empire with a 100% path to Commerce Raiding, and it is the species the AI already is in the lineage every other trade lane has used, so the route-owner side is a known quantity.

1.3 The workload

A new single-player game on VM141 with the species pool cut to Tarkas only — lane V's trick from the Zuul save, which makes both players Tarkas and so pins the route owner's species to 2 as well, satisfying SC1 by construction rather than by luck. Create-game parameters as close as I can get to lane AC's MyGamel3trade (NSys 28, MaxP 2, PCol 10, PSav 9,850,000, PTech 15, IncM 1.48, ResM 1.46), because that is the setup that put a human raider on a trade sector by turn 20 and gave the AI four trade routes by turn 22.

Then: research CCC_FTLBrdB -> CCC_FTLEcon -> CCC_ComRaid (34,000 RP on this branch), build several separate single-ship long-range fleets, and park them on a trade sector that sources a route. Separate fleets, not one fleet — the roll is per fleet (lane AD) at ODDS + 0.01·nShips, so m one-ship fleets roll m times and one m-ship fleet rolls once.

Cruisers if their range reaches, destroyers if not. Cruisers roll at (double)0.2f + (double)0.01f = 0.21 per fleet-turn against a destroyer's 0.06 — three and a half times the signal per fleet-turn — and a raider is displaced off the node by its own success (AR §4.3), so each fleet contributes at most one success per parking and the arm exhausts itself. That is the structural constraint on this workload and it is why hull choice matters more than turn count.

The route set moves between turns and this map is not AD's map. Lane AR's geometry table is for the MyGamel3trade lineage only. I will re-read trdmgr on the state I actually build and pick the target sector from that trfr set, preferring a sector that sources one or two routes: bound = n - 1, so n = 1 gives mask 0 and n = 2 gives mask 1, and in both cases RNG_NextInt cannot reject and 0x0088b613 costs exactly one word. At n >= 3 the rejection loop is live and s stops being one word per success.

1.4 The numbered predictions

#	prediction
P0	The species enum is 0 Human, 1 Hiver, 2 Tarkas, 3 Liir, 4 _NPC, 5 Zuul, 6 Morrigi, read from the jump table at 0x00545b60 as bytes. Falsifiable live: the save I build will carry Species 2 on both ServerPlayer records and the game will have been created with Tarkas selected in the UI
P1	FUN_00820af0 short-circuits on three conjuncts, not one. The campaign's published sentence ("Human or Zuul draws nothing, every other species draws") is incomplete: Hiver raiders draw nothing (SC2), and a Hiver-owned route is intercepted without a draw whoever raids it (SC1)
P2	The short-circuit sets frac = **0.0**, not 1.0 as both lane AG §5.2 and lane AR §4.2 write it. Traced through the x87 stack at 0x00820bf8–0x00820c33: fldz; fstp [ebp+0xc] on the short-circuit arm, and 0.0 + (1.0 - 0.0)*NextFloat() on the draw arm. The interception point is therefore at the route's source end for a Human or Zuul raider, not its destination. Word count unaffected; the published sentence is wrong (rule 28 practice 6 — read the polarity before the count)
P3	Corpus count against the predicate is 0 of 30, and the "an AI of another species already raids" option is dead: 24 saves hold a Tarka AI, but tscr = 253 in every one, so the AI lacks Commerce Raiding and never rolls
P4	OnAllCombatDone_Tail costs k + 2s words on this state, where k = permitted Tarka raiders parked with Pos bit-equal and s = successes on a route-sourcing sector. This is k + s + z with z = s, and it is the term no lane has ever observed
P5	draw_sites shows, on a turn with s successes: NextFloat 0x00820e18 calls == words == k; NextInt 0x0088b613 calls == words == s; and NextFloat 0x00820c1b calls == words == s. Bracket residual 0 on every turn
P6	The 0x00820c1b row is attributable to B and not to CreateRaidEncounter exactly when NextInt 0x008939ee reads calls = 0 on the same turn. Proof, and it is proof-carrying rather than a convention: FUN_00820af0 has exactly two E8 callers in the whole image — 0x0082cf65 and 0x0088b62c — verified by an image-wide relative-call scan; 0x0082cf65 sits in FUN_0082ce00, whose only caller is 0x00892700 inside FUN_00892640, which CreateRaidEncounter calls at 0x00893a25; and 0x008939ee is on the straight-line path from the empty-list gate to 0x00893a25 with no branch around it (0x008939c9 -> 0x008939ee -> 0x00893a25, decoded). So 0x008939ee at zero means the other caller never ran. If it is non-zero on a measured turn I will call that turn's attribution ambiguous and use another turn, not argue
P7	B's cost on a success is 2 words for a Tarka raider. Lane AG §5.2's "1 (NextInt) + 1 (NextFloat)" is right for a drawing species; lane AR's measured 1 is right for Human and Zuul; AG's committed §3.3 figure of "3 words on a succeeding turn" is right for k = 1 and a drawing species, and was wrong only because the lineage was Human
P8	The hooks=off control will agree with itself (two fresh processes, byte-identical autosaves) — I am predicting lane AR's outcome, not lane AD's, and I am not confident. AD's variation was confined to one AI player's decision sub-tree on a state ten turns earlier in a different game; a resolver is looking at the discrepancy now and neither outcome is safe to assume. If my control varies I will localise it by sub-tree with state_checksum.py --tree and state exactly which leaves my measurement depends on and whether those reproduce
P9	With k one-cruiser fleets at p = 0.21 per fleet-turn ((double)0.2f + (double)0.01f) I expect the first success within the first two or three instrumented turns. Any zero is reported as a binomial probability, never as "unremarkable" (rule 20), and an entry probe on B separates "did not fire" from "fired and found nothing"
P10	Not settled by this lane, predicted in advance (rule 15): the freighter doubling of the raid odds; the design+0x12c > 1 short-circuit; bestScale (0x009f8d48 = 0.33f when ship+0x18 & 0x100000); the rejection loop at 0x0088b613 for a candidate list of three or more; and whether SC2 is reachable at all for a player (the tech data says no)

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

If a Tarka raider parked on a route-sourcing sector succeeds, Slot13RngCalleeB is entered, NextInt 0x0088b613 fires — and there is still no NextFloat 0x00820c1b row — then the species flag is not the only thing gating that draw, and the two conjuncts ahead of it become the live suspects. In that case I will report, per rule 28, exactly which conjunct I satisfied and which I did not: SC1 is checkable in the save I built (the route owner's Species), SC2 is checkable the same way (the raider's owner's Species), and if both check out then SpeciesDef+0x144 is not what 0x0053baf0 is reading and the static decode is retired.

That is a real result and it is the more interesting one, because it would mean two lanes' static reads of the same twelve-byte function produced a confident wrong answer.

1.6 What could go wrong with the workload, and what each failure looks like

way it fails	symptom
the Tarka AI never builds a trade route in the turns I can afford	trdmgr holds zero rt records; no sector sources a route; A fires and B returns at G_B4 with 0 words — the exact zero lanes AC and AD measured, for AC's reason not mine
no Tarka hull reaches a route-sourcing sector	A never fires (G4 fails, Pos not bit-equal); probe 5 reads 0
I cannot get Commerce Raiding in the session	tscr stays 252; vslot13's G3b rejects; probe 2 fires and probe 5 reads 0
the target sector sources three or more routes	0x0088b613 words > calls and s stops being one word per success — reported, not hidden
the encounter query eats a scripted End Turn	detected from the Done pixel at (233,673) before every End Turn, per AR §10

---

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

---

2. The verdict, stated first

The static half is decided and it corrects the campaign's published sentence twice. The live z measurement was not taken — the workload was built to within one conjunct of it and then blocked, and §7 says exactly which conjunct.

FUN_00820af0 has three short-circuits, not one. 0x00820c1b draws its word only when the route owner is not Hiver, the raider's crew species is not Hiver, and the raider's species does not set SpeciesDef+0x144 (Human and Zuul). The campaign's sentence — "a Human or Zuul raider draws nothing; every other species draws a word" — is wrong for Hiver on both sides of the relation, and my own brief inherited it.

And the short-circuit sets frac = 0.0, not 1.0. Both lane AG §5.2 and lane AR §4.2 write 1.0. Traced through the x87 stack, the short-circuit arm stores a zero and the interception happens at the raided route's source end. The word count is unaffected; the sentence is wrong, and rule 28 practice 6 is exactly about not reading a count before the polarity.

The species enum is named from the image and it agrees, independently, with lane AP's decode of the save's own ISsp list: 0 Human, 1 Hiver, 2 Tarkas, 3 Liir, 4 _NPC, 5 Zuul, 6 Morrigi. Two derivations from different artefacts, one from SpeciesDef_InitTable's jump table and one from the wire format, agreeing on all seven.

A new corpus state exists and it is the first of its kind: verify/results/saves/az-turn23-tarka-comraid.sav — a Tarka empire (species 2) with Commerce Raiding researched, three AI-owned trade routes, tscr = 127, and five AI Tarka fleets parked on trade-sector nodes with Pos bit-equal, two of which clear G0–G4. It is the first non-Human, non-Zuul playable-species save in the corpus and the first save in which a drawing species is standing on a route-sourcing sector.

---

3. What was run

Guest VM141, hooks=off for the entire session — no instrument was ever installed, and no measurement is claimed. C:\SOTS\shim.cfg was shim.cfg.hoff from this lane's own dist (C:\SOTS\shimdist-az, BUILD_ID az-989c692-dirty-20260909T0453Z) throughout. The shim was built on CT111 in /srv/re-lab/build/sots-engine-az, rm -rf'd before the build (rule 24), from a lane-private git worktree at ~/sots-engine-az (branch wip/az) with no local build* shipped (rule 21); exports 66 names identical to the real binkw32.dll. The dirty in the build id is the regenerated include/generated/sots_addresses.h (1,283 entries, rule 14 — regenerated, never hand-resolved), and the generator's duplicate-name check fired and was obeyed: my first draft of ghidra/addresses.d/az.json named 0x00820af0, which lane AG already carries as TradeManager_ComputeRaidInterceptPoint. My entry was withdrawn rather than renamed. That is rule 14 working exactly as designed, on the first fragment I wrote.

3.0 The species choice, and why it is Tarkas and not Morrigi

Tarkas was picked and committed in §1.2 on movement and tech-availability grounds, before the game was created. After the empire existed and Commerce Raiding was already researched, the coordinator relayed lane AP's finding that Morrigi (6) would have been strictly better: it is equally a drawing species for z, and it is the only species that reaches SpyManager::Slot13RngCallee's cmp [spyOwner+0x5c], 6 branch — Chance(0.75f) at 0x00840929 and a NextInt at 0x008409c7 — so a Morrigi save would unblock a stuck spy target as well. The instruction was explicitly not to restart, and I did not. Recorded here because the next lane to build a non-Human raider should pick Morrigi unless it has a reason not to: the z question does not care which of Tarkas, Liir or Morrigi it is, and one of the three is worth twice as much.

3.1 The game that was built

A fresh single-player custom game on VM141, species pool cut to Tarkas only (lane V's trick from the Zuul save), so both empires are species 2 and SC1 is satisfied by construction rather than by luck. Create parameters: 28 stars, 5 ly spacing, 2 players, 10 initial colonies, 9,850,000 treasury, Initial Technologies 15 (max), Economic Efficiency 148%, Research Efficiency 150% (max), Alliances on, Random Encounters 100%. Saved on the guest as MyGameazTarka.

turn	what happened
1	Tarkas confirmed in the lobby's species dropdown — the dropdown offered only Tarkas and Random, which is the UI-side confirmation that the pool was cut correctly. CCC_FTLEcon set as the research target: 4 turns, so CCC_FTLBrdB was among the 15 initial techs
1–6	16 stock Extended Range destroyers queued and built at Kea'Donum (Tarka hull: Range 20.0, Speed 2.0, cost 2,690 — not the Human 27.0/2,252 lane AR used)
6	CCC_FTLEcon completed. CCC_ComRaid appeared as a new node and was set: 3 turns
~10	CCC_ComRaid completed. tscr reads 127 on all five sectors
16	first two AI trade routes appear (trfr 4 and 27, tro 32)
16	16-destroyer Alpha Fleet ordered to Ku'Valt (a sector-752 member system), ETA 7
23	the fleet arrived into a defended system and was destroyed — 16 DE lost, 15 DE + 3 CR killed. Player 0 has zero fleets
23	state saved as az-turn23-tarka-comraid.sav; three AI routes; five AI fleets parked on sector nodes

Two ceasefire offers from Fane Kona were declined on sight. Diplomacy confirms War, so G_B3's relation test passes for any route of the AI's raided by me.

3.2 The state, read from the save (rule 28 — field values, not a summary)

az-turn23-tarka-comraid.sav, save_reader.py --strict: 0 error, 0 warn, resyncs 0, hint-failures 0, 58,892 items, 6,397 frames, 2,503 raw bytes.

Players — and this is the corpus's first playable non-Human, non-Zuul empire:

PID	PlyrIdx	Species	name	AL/NA/CF
16	0	2 = Tarkas	re (this lane)	0 / 0 / 0
32	1	2 = Tarkas	Fane Kona (the AI)	0 / 0 / 0
496	2	2 = Tarkas	Chandra (no home, no colonies)	4 / 0 / 0
512–560	3–6	4 = _NPC	Alien Menace, Peacekeeper Enforcer, Von Neumann, Independent Colony	—

Trade sectors:

TradeID	grid	tsct	tscr	tsnumflt	Pos
736	1	0	127	0	[0.1028, 8.0082, 0.1116]
752	2	2	127	2	[0, 0, 8.0]
768	3	0	127	1	[-0.4027, -0.8793, 1.7497]
784	4	0	127	0	[-8.0, 8.0, 0]
800	5	2	127	2	[-8.0, -8.0, 0]

Routes (trdmgr, three rt records, tro = 32 on all three, trfrs = trtos = 0): trfr = 4 → trto 9, trfr = 27 → trto 15, trfr = 27 → trto 1. With index = id/16 − 3 (pinned from Sim.systemIds and cross-checked against the Idx tag on every system, which reproduces the name list exactly), system 4 = Ke'Sothram lies in sector 752 and system 27 = Keo'Va lies in sector 800. So sector 752 sources one route and sector 800 sources two at turn 23; sectors 736, 768 and 784 source none.

tscr = 127 is a new value and it matters (rule 28 practice 3). Every earlier corpus save reads 252 (0b11111100) or 253; lane AC watched bit 0 flip 252→253 the turn Commerce Raiding completed, and lane AG read the mask as "the NPC slots default set, your bit is the tech". This game has seven players rather than eight, and the mask reads 0b1111111 — bit 1, the AI's, is set too. Either the Tarka AI has researched Commerce Raiding in this game, or the mask's default for a non-human empire differs from what the AC lineage showed. I did not find the writer and I am not guessing: this is recorded as a falsification of the corpus-wide constant, which is what practice 3 asks for, and the writer of TradeSector+0x90 is now a named open item.

3.3 Five AI Tarka fleets are parked on sector nodes, and two of them clear G0–G4

Read straight out of the save — Flt.Pos against Trade[id].Pos, all three floats:

fleet	id	ships	LocID	FtFlg	Pos vs sector Pos	G3c armed (tsct bit 1)?	clears G0–G4?
Rho Fleet	274	6	768	0x80c	bit-equal	no (tsct 0)	yes
Freighters	3248	3	752	0x400	bit-equal	yes	no — no 0x800
Escorts	3344	6	752	0xc00	bit-equal	yes	yes — carries 0x800
Freighters	4160	9	800	0x400	bit-equal	yes	no — no 0x800
Nu Fleet IV	1490	1	800	0xd	bit-equal	yes	no — no 0x800

So k = 2 on this save with the player owning no fleets at all, and both raiders are Tarka. ServerTradeManagerImpl::vslot13 should enter TradeManager::Slot13RngCalleeA exactly twice per turn here, and 0x00820e18 should read calls == words == 2. That is a committed, cheap, falsifiable prediction about a save that is now in the repo, and it needs one probes=8 run to settle.

It also confirms lane AG's reading of G3c from the other side: Freighters at 752 and 800 are rejected because tsct bit 1 is set (the AI trades in its own sector) and they do not carry FtFlg & 0x800, while Escorts in the same sector, on the same node, does carry it. Two fleets, same sector, same position, opposite outcomes, and the only field that differs is the one AG's decode names.

---

4. Verdicts on the committed predictions

#	prediction	verdict
P0	species enum 0 Human, 1 Hiver, 2 Tarkas, 3 Liir, 4 _NPC, 5 Zuul, 6 Morrigi from the jump table at 0x00545b60	CONFIRMED, twice over. The game was created with Tarkas selected in the lobby and both ServerPlayer records in the resulting save carry Species = 2. Independently, lane AP decoded the same seven values from the save's own ISsp list. Two artefacts, two methods, no disagreement
P1	three short-circuits, not one; Hiver raiders draw nothing; a Hiver-owned route is intercepted without a draw	CONFIRMED statically (0x00820bc2, 0x00820bd7, 0x00820bed, decoded to the next function start). Not testable live and, for the raider side, not testable at all through vslot13: CCC_ComRaid is 0% for Hiver on both of its edges, so a Hiver player can never raid. SC2 is therefore either defensive or the _NPC-crew path — see §6
P2	the short-circuit sets frac = 0.0, not 1.0	CONFIRMED statically, and it corrects lane AG §5.2 and lane AR §4.2 in place (rule 11). 0x00820bf8 is fldz; fstp [ebp+0xc]; the draw arm at 0x00820c20–0x00820c30 computes 0.0 + (1.0 − 0.0)·NextFloat(). A Human, Zuul or Hiver interception lands at the route's source system, not its destination
P3	corpus count 0 of 30; the "an AI of another species already raids" option is dead	CONFIRMED for the corpus as it stood — and the reason I gave was wrong in an interesting way. I said the Tarka AI never rolls because tscr bit 1 is clear. That is true of all 24 AC-lineage saves. It is false on the map I built, where tscr = 127 and two AI Tarka fleets clear G0–G4 (§3.3). The option was dead for the corpus, not for the mechanism
P4	tail costs k + 2s	NOT TESTED. No instrumented run was made
P5	draw_sites rows at 0x00820e18, 0x0088b613, 0x00820c1b	NOT TESTED
P6	0x008939ee == 0 proves a 0x00820c1b row belongs to B	CONFIRMED as a static argument, and it is proof-carrying rather than a convention: an image-wide E8 rel32 scan finds exactly two callers of FUN_00820af0 — 0x0082cf65 and 0x0088b62c. 0x0082cf65 sits in FUN_0082ce00, whose only caller is 0x00892700 inside FUN_00892640, which CreateRaidEncounter calls at 0x00893a25; and 0x008939ee is on the straight-line path from the empty-list gate to that call (0x008939c9 → 0x008939ee → 0x00893a25, decoded, no branch around it). Not exercised, because there was no run
P7	B costs 2 words for a Tarka raider	NOT TESTED
P8	the hooks=off control will agree with itself	NOT TESTED — see §5 for the predicate-based prediction I owe under rule 26 corollary (c), committed but unrun
P9	first success within two or three instrumented turns at p = 0.21	NOT TESTED, and the hull assumption was wrong before the run started: no cruiser design is available to a Tarka empire at game start (the Cruiser category in the Build screen is empty), so the arm would have been destroyers at p = 0.06, not cruisers at 0.21
P10	freighter doubling, design+0x12c, bestScale, the rejection loop — not settled	HELD. None of them was settled

The prediction that was wrong is the useful one, again. P3's count was right and its reason was wrong, and the way it was wrong is the whole finding of §3.3: I asserted that a Tarka AI never rolls because its tscr bit is clear, having checked that on 24 saves from one lineage. The first map I generated has tscr = 127, the AI's bit set, and two AI Tarka fleets standing on trade-sector nodes with Pos bit-equal. A field constant across the whole corpus is a coincidence until its writer is found — practice 3 predicted its own violation here, and I still wrote the sentence.

---

5. The control I owe and did not run (rule 26 corollary (c))

The resolver's predicate arrived mid-run and it changes what a control on this state is worth. I am recording the prediction here, unrun, so that whoever takes the state is testing a written number rather than describing an outcome. Read from az-turn23-tarka-comraid.sav:

AI player	ResTNm at turn start	exposed decision predicted?
Fane Kona (PID 32, PlyrIdx 1)	''	YES — a research-pick turn
Chandra (PID 496, PlyrIdx 2)	XNC_TrnsHum2	held

Committed: two hooks=off processes loading az-turn23-tarka-comraid.sav and taking one End Turn will NOT agree. Fane Kona enters the turn with ResTNm == '', which is the resolver's named pick-turn predicate and lane AS's signature exactly. I expect the variation to be confined to Player[32]'s TechTree leaves, and I expect /Sim/trdmgr and the five Trade records to be bit-identical across processes — which would still leave k = 2 and the raid arm reproducible even though the whole-save hash is not.

That prediction is cheap to falsify and it is the first test of the resolver's predicate on a map outside the AD/AR and AS lineages.

---

6. What blocked the measurement, precisely (rule 28)

Which conjuncts the built state satisfies, and which it does not. For the AI's two qualifying Tarka raiders on az-turn23-tarka-comraid.sav:

conjunct	satisfied?	evidence
G0–G2 fleet at a trade-sector node	yes	Rho Fleet LocID 768, Escorts LocID 752
G3b owner's bit in tscr	yes	tscr = 127, bit 1 set
G3c FtFlg & 0x800 where armed	yes for both	0x80c and 0xc00
G4 Pos bit-equal	yes for both	§3.3, all three floats
SC1 route owner not Hiver	yes	tro = 32, species 2
SC2 raider crew species not Hiver	yes	owner species 2, and 0x0081a2d0 returns the owner's species for any non-_NPC owner
SC3 SpeciesDef[2]+0x144 == 0	yes	the flag word is written only for species 0 and 5
G_B3 relation to the route owner is 0 (war)	NO	every route in the save has tro = 32, and the qualifying raiders are owned by 32. PlayerAlliances_Relation returns 3 for self, B rejects on > 0, the candidate list empties and B returns at G_B4 with 0 words

The failed conjunct is G_B3, and it is failed by self-relation, not by the species gate. Everything the species half of this lane exists to test is satisfied on this save; the raider is simply parked next to routes it owns. That is a different sentence from "the species word did not fire" and it must not be written as one.

Why my own raider never got there — two causes, both worth recording because both are cheap to avoid:

1. The fleet was destroyed. I ordered the 16-destroyer Alpha Fleet to Ku'Valt, a sector-752 member system, intending to use it as a staging post. Ku'Valt is an AI colony; the arrival produced a real tactical battle and the whole fleet died (Ranking screen: DE built 16, lost 16, enemy killed 15 DE + 3 CR). Never stage a raider through a member system — order it to the node directly. My blind "resolve the encounter peacefully" click sequence also does not work for a real battle: the four icons are fight / auto-resolve / retreat / peaceful, and the peaceful option is not offered when both sides have ships.
2. The sector node could not be aimed at from the default camera, and this is a genuine map property rather than a mistake. Lane AR reports that a node is a legal move target whose hover readout names it (Sector 5 / Range / ETA). On this map the two route-sourcing nodes lie 2.4 ly from Ke'Sothram (sector 752) and 2.6 ly from Ka'Sogroth (sector 800), and the Move-mode hover snaps to the nearest system over a radius of well over 100 screen pixels. Every probe I placed — twelve of them, on a grid — named a system. Fitting screen = f(world) from hover-confirmed reference points reproduces the systems to ~10 px but places the node within ~30 px of Ke'Sothram, because the offset from the star to the node points nearly along the camera axis and is foreshortened to almost nothing.

The fix for the next lane, and it is one gesture. rdrag on the star map rotates the camera (verified — the whole field re-projects and the rotation is reversible). Rotating ~90° takes the star-to-node offset out of the camera axis and separates them by the full 40-plus pixels per light year the zoom provides. Left-drag does not pan, the arrow keys do nothing, and the camera does not follow the selection — so rotation is the only tool, and it is sufficient.

---

7. The cheapest next workload, named from the failed conjunct (rule 28 practice 2)

Not "park a raider" — that is the nearest container and it is what cost this lane its session. The failed conjunct is G_B3, and the state that satisfies it is:

A trade route whose owner is at war with a raider that is already parked.

On az-turn23-tarka-comraid.sav that is one route sourced at a system inside sector 768, because Rho Fleet (PID 32, Tarka, 6 ships) is already parked on 768's node with Pos bit-equal and clears G0–G4. Sector 768's member systems include Ku'Paaka (index 17) and Ka'Palum (index 26), both owned by player 0. So:

1. Give player 0 a trade route sourced at Ku'Paaka or Ka'Palum. The empire already has CCC_FTLEcon; what it does not have is freighters, and lane L3's row 374 records that a trade station is a bonus rather than a prerequisite (NumTradeRoutesSupported has a floor of one per owned system).
2. Then, on any turn A succeeds for Rho Fleet, B's candidate list contains a route owned by player 0, PlayerAlliances_Relation is 0 = war, G_B3 passes, 0x0088b613 fires, and FUN_00820af0 runs with a Tarka raider and a Tarka route owner — all three short-circuits fail and z draws its word.
3. No fleet of the player's needs to move at all, which removes both of the failures in §6.

The alternative — the player's own raider on 752 or 800 — is still open and now costs only the camera rotation of §6 plus about seven turns of travel, with the ship built at Ku'Paaka (10.0 ly from 752's node) rather than the homeworld (13.2 ly).

Two numbers the next lane should carry in: on this map a Tarka Extended Range destroyer has Range 20.0, Speed 2.0, cost 2,690 (the Human hull lane AR used is 27.0 and 2,252), and no cruiser design exists at game start for a Tarka empire, so the raid odds are the destroyer's 0.05 + 0.01·nShips, not the cruiser's 0.2 + 0.01·nShips. Send many one-ship fleets.

---

8. Corrections to earlier findings (rule 11)

1. Lane AG gate-indexed-rng-audit.md §5.2 and lane AR raid-target-pick-verdict.md §4.2 — both render FUN_00820af0's short-circuit as frac = 1.0. It is 0.0 (fldz; fstp at 0x00820bf8). Word counts unaffected; the interception geometry claim is inverted.
2. Lane AR §4.2 and its board row — "A Human or Zuul raider intercepts at frac = 1.0 and draws nothing; every other species draws a NextFloat." Incomplete on both sides: a Hiver raider also draws nothing (0x00820bd7, an ordinary == 1 test that has nothing to do with SpeciesDef+0x144), and a route owned by a Hiver empire is intercepted without a draw whoever raids it (0x00820bc2, on the route owner). The species that both can raid and do draw are Tarkas, Liir and Morrigi.
3. ghidra/addresses.d/ag.json, TradeManager_ComputeRaidInterceptPoint — its prototype text carries the same frac = 1.0. Corrected in place, with the two extra conjuncts named.
4. The tscr reading — raid-gate-multiplicity.md §4 and gate-indexed-rng-audit.md §3.3 both describe the mask as 252/253 with the NPC slots set and the human's bit as the tech flag. That is a fact about the AC lineage. This lane's map reads 127, with the AI's bit set as well. The mask's writer is unfound and the value is not a corpus constant.

---

9. Coverage, and what was not done (rule 15)

• No instrumented run, no control pair, no word count. hooks=off for the whole session; no shim.cfg.hp8 was ever copied over C:\SOTS\shim.cfg. Nothing in this document is a measurement of the RNG.
• z remains unobserved through B. It is still the cheapest unexercised state in the trade half, and it is now one trade route away rather than one save away.
• SC2 (Hiver) is unreachable through vslot13 for a player and was not tested at all. Whether an _NPC-owned fleet with a Hiver-crewed design can reach it is untested and is the only route to that conjunct I can see.
• The tscr = 127 reading is one save. I did not capture a pre-Commerce-Raiding save of this game, so I cannot say which bit the tech set here, or whether the AI has the tech.
• The freighter doubling, design+0x12c, bestScale and the 0x0088b613 rejection loop are all exactly where lane AR left them.
• Chandra (PID 496) is a Tarka empire with no homeworld, no colonies, no designs and AL = 4. I did not chase what it is; it holds no routes and no fleets, so it is inert for this question.
• One --strict-clean save was added and one game state was lost. The 16-destroyer fleet is gone; the save is the turn-23 autosave and is the state as it stands.

---

10. Artefacts

what	where
this document	findings/control-flow/raid-intercept-species-word.md
new corpus save — first Tarka empire, Commerce Raiding, AI raiders parked	verify/results/saves/az-turn23-tarka-comraid.sav (sha256 3d5eb826c149d1fd0278c746f32e6148ca9883a1bc5b522c0d5e6e13fac9788a, 73,385 B, turn 23, --strict clean: 0 error 0 warn, resyncs 0, hint-failures 0)
new address (1 entry, no name collides)	ghidra/addresses.d/az.json
shim build (unused for measurement)	az-989c692-dirty-20260909T0453Z, /srv/re-lab/shim/dist-az → C:\SOTS\shimdist-az
build tree	lane worktree ~/sots-engine-az (branch wip/az) → CT111 /srv/re-lab/build/sots-engine-az, rm -rf'd first

New content for the coverage ratchet (rule 27): this save carries a TradeSector with tscr = 127 (every earlier save reads 252 or 253), seven ServerPlayer records rather than eight, two Species = 2 player-controlled empires, and five StarFleets whose LocID is a TradeSector id with Pos bit-equal to the node. Nothing here is a new kind of item, so the ratchet should hold; the --strict run above is the check.

---

11. VM141 as left

Guest restored, hold released. Game stopped; C:\SOTS\shim.cfg is shim.cfg.hoff; C:\SOTS\binkw32.dll is this lane's build (az-989c692-dirty-20260909T0453Z), original still at binkw32_real.dll. Left in place, all additive: C:\SOTS\shimdist-az (4 files) and C:\SOTS\ui\az-{go,ui}.ps1. click_helper.ps1 is unmodified.

C:\SOTS\SavedGames has grown by one game. Lane AR's 12-row set plus MyGameazTarka.sav and MyGameazTarkat11cr.sav, and the three autosaves now belong to the Tarka game. Screenshot the Load dialog and re-derive the rows — they have moved again.

Five things that cost this lane time, for the next holder.

• rdrag on the star map ROTATES the camera. Left-drag does not pan, the arrow keys do nothing, and the camera does not follow the selection — it moves only when the game moves it (a combat, a fleet order). Rotation is the only camera tool and it is enough: it is what separates a trade sector node from a member star when the offset between them lies along the camera axis.
• The Move-mode hover snaps to the nearest system over a radius of >100 px, so a sector node within ~3 ly of a member star cannot be hovered from a camera angle that foreshortens the offset. Do not conclude the node is unreachable — rotate first. This is the caveat lane AR's "fit two points and land first try" needs on a crowded map.
• wheel DOES zoom both the star map and the research tree, and it zooms toward the screen centre. Board row 374's "wheel-zoom does nothing useful" is true of panning the tech tree, not of zooming: wheel x y -120 3 on the Research screen is what made the top-row CCC nodes clickable when the Research title bar and the Savings panel were sitting on top of them.
• A research node hidden under a HUD panel is not clickable — the panel eats the click silently and no preview appears. Zoom out until the node clears the chrome.
• A blind "auto-resolve peacefully" click sequence does not resolve a real battle. The four encounter icons are fight / auto-resolve / retreat / peaceful, and peaceful is not offered when both sides have ships. My turn loop clicked them blind and put a 16-destroyer fleet into a tactical battle it lost. Sample the Done pixel at (233,673) first, and screenshot the query before choosing — the icon set is not constant.

---

Proposed board rows

New rows:

| CORRECTION: the raid-intercept species gate has THREE short-circuits, and HIVER is in two of them | control-flow | verified | high | 100% | 2026-09-09 | **Lane AZ**, static, `findings/control-flow/raid-intercept-species-word.md`. The campaign's published sentence - lane AR section 4.2, lane AG section 5.2, and my own brief - is *"a Human or Zuul raider draws nothing; every other species draws a word"*. **Incomplete on both sides of the relation.** `FUN_00820af0` short-circuits on THREE disjuncts, decoded to the next function start: **SC1 `cmp [routeOwner+0x5c],1` at 0x00820bc2** - the ROUTE OWNER's `Species`, so a HIVER-owned route is intercepted with no draw WHOEVER raids it; **SC2 `cmp eax,1` at 0x00820bd7** on `StarFleet_GetCrewSpeciesForIntercept(raider)` - a HIVER raider draws nothing, and this is an ordinary `== 1` test with nothing to do with `SpeciesDef+0x144`; **SC3 `SpeciesDef_HasInterceptFlag` at 0x00820bed** - Human (0) and Zuul (5) only, which is the one the campaign had. So `0x00820c1b` draws only for a raider of species **2 Tarkas, 3 Liir, 6 Morrigi** (or 4 `_NPC`) against a route owned by a **non-Hiver**. **AND THE POLARITY IS INVERTED IN BOTH PUBLISHED RENDERINGS**: the short-circuit arm sets **frac = 0.0**, not 1.0 (`fldz; fstp [ebp+0xc]` at 0x00820bf8; the draw arm computes `0.0 + (1.0-0.0)*NextFloat()`), so a Human/Zuul/Hiver interception happens at the raided route's SOURCE end. Word counts unaffected; the sentence is wrong (rule 28 practice 6 - read the polarity before the count). **Species enum named from the image**: `SpeciesDef_InitTable 0x005453a0` dispatches through the jump table at **0x00545b60**, whose seven entries READ AS BYTES give `0 Human, 1 HIVER, 2 TARKAS, 3 LIIR, 4 _NPC, 5 Zuul, 6 MORRIGI` - the case bodies are NOT laid out in case order, so reading the disassembly top-to-bottom gives the wrong enum. This agrees with lane AP's independent decode of the save's `ISsp` list on all seven. **And the tech data closes SC2 for players**: `CCC_ComRaid` is **0% for Hiver** on both of its edges (`CCC_FTLBrdB->CCC_ComRaid` and `CCC_FTLEcon->CCC_ComRaid`), so a Hiver empire can never raid and SC2 is unreachable through `vslot13` for any player |

| FIRST TARKA SAVE IN THE CORPUS - and two AI raiders are already parked on sector nodes | verify | verified | high | 100% | 2026-09-09 | Lane AZ, VM141, `verify/results/saves/az-turn23-tarka-comraid.sav` (`3d5eb826...`, 73,385 B, turn 23, `--strict` 0 error 0 warn, resyncs 0, hint-failures 0). A fresh 2-player custom game with the species pool cut to **Tarkas only** (lane V's Zuul trick), so **both empires are species 2** - the first playable non-Human, non-Zuul empire the campaign has. `CCC_FTLBrdB` came free in the 15 starting techs, `CCC_FTLEcon` took 4 turns and `CCC_ComRaid` 3 more at Research Efficiency 150%, so **Commerce Raiding by turn 10**. Three AI trade routes (`tro 32`, `trfr` 4, 27, 27). **FIVE AI TARKA FLEETS ARE PARKED ON TRADE-SECTOR NODES WITH `Pos` BIT-EQUAL**, and two of them clear G0-G4: `Rho Fleet` (274, 6 ships, `LocID 768`, `FtFlg 0x80c`) and `Escorts` (3344, 6 ships, `LocID 752`, `FtFlg 0xc00`). The other three are rejected at **G3c** exactly as lane AG's decode says - `tsct` bit 1 is set on 752 and 800 (the AI trades in its own sectors) and they lack `FtFlg & 0x800`; `Escorts` sits on the SAME NODE as `Freighters` 3248 and differs only in that bit. **COMMITTED PREDICTION, one `probes=8` run to settle: `k = 2` on this save with the player owning NO fleets, so `Slot13RngCalleeA` is entered exactly twice per turn and `0x00820e18` reads calls == words == 2.** `B` will still cost 0 - every route is `tro 32` and the qualifying raiders are owned by 32, so `PlayerAlliances_Relation` returns 3 for self and `G_B3` empties the candidate list |

| `tscr` IS NOT A CORPUS CONSTANT - it reads 127 on a fresh map, with the AI's bit SET | control-flow | verified | high | 100% | 2026-09-09 | Lane AZ. Every one of the 30 earlier corpus saves reads `Trade[].tscr` = **252** or **253**, and lane AC watched bit 0 flip 252->253 the turn Commerce Raiding completed; lane AG's section 3.3 reads the mask as "the NPC slots default set, your bit is the tech". On the first map this lane generated, **all five sectors read 127** - seven players instead of eight, and **bit 1, the AI's, is SET as well as bit 0**. Either the Tarka AI researched Commerce Raiding, or the default for a non-human empire differs from what the AC lineage showed; **the writer of `TradeSector+0x90` is still unfound and no guess is offered**. This is rule 28 practice 3 landing on the lane that quoted it: my own committed prediction P3 said a Tarka AI never rolls because its `tscr` bit is clear, which is true of 24 saves from one lineage and false on the first new map. The COUNT was right and the REASON was wrong |

| WORKLOAD BLOCKED, and the failed conjunct is G_B3 not the species gate | control-flow | in-progress | — | 60% | 2026-09-09 | Lane AZ. `z` - the `NextFloat` at `0x00820c1b` charged to `Slot13RngCalleeB` - is **still unobserved**, and this lane did not run an instrument at all (`hooks=off` throughout, no `shim.cfg.hp8` ever copied). What it built is a state that satisfies **SC1, SC2, SC3 and G0-G4** and fails only **G_B3**: the qualifying raiders are the AI's and every route is the AI's own, so `PlayerAlliances_Relation` returns **3 for self**, `B` rejects on `> 0` and returns at `G_B4` with 0 words. **THE CHEAPEST NEXT WORKLOAD IS NAMED FROM THAT CONJUNCT AND NEEDS NO FLEET MOVEMENT AT ALL**: give **player 0** a trade route sourced at `Ku'Paaka` (index 17) or `Ka'Palum` (index 26), both player-0 colonies and both members of **sector 768**, where the AI's `Rho Fleet` is already parked and already clears G0-G4. Then a success for `Rho Fleet` puts a player-0 route in `B`'s candidate list at relation **0 = war**, `0x0088b613` fires, and `FUN_00820af0` runs with a Tarka raider against a Tarka owner - all three short-circuits fail and **`z` draws**. Two failures worth not repeating: the 16-destroyer raider fleet was **destroyed** staging through `Ku'Valt`, a sector-752 MEMBER SYSTEM that is an AI colony (order to the NODE, never through a member), and a blind "auto-resolve peacefully" click sequence **does not resolve a real battle** - peaceful is not offered when both sides have ships |

| GUEST GOTCHA: `rdrag` ROTATES the star map, and that is how you aim at a crowded sector node | meta | verified | high | 100% | 2026-09-09 | Lane AZ, VM141. Lane AR's recipe - fit `screen = (A*wx+B*wz+C, D*wx+E*wz+F)` from two known points and land on any node first try - **does not generalise to a crowded map**. On lane AZ's map the two route-sourcing sector nodes lie **2.4 ly from `Ke'Sothram`** and **2.6 ly from `Ka'Sogroth`**, the Move-mode hover snaps to the nearest **system** over a radius of well over 100 screen pixels, and twelve grid probes all named a system. The offset from star to node points nearly **along the camera axis** and foreshortens to ~30 px however far you zoom in. **THE FIX IS ONE GESTURE: `rdrag` on the star map ROTATES the camera** (verified, reversible, the whole field re-projects). Left-drag does NOT pan, the arrow keys do nothing, and **the camera does not follow the selection** - it moves only when the game moves it (a combat, a fleet order). Also: **`wheel` DOES zoom, on the star map AND the research tree**, toward the screen centre - board row 374's "wheel-zoom does nothing useful" is true of PANNING the tech tree, not of zooming, and `wheel x y -120 3` is what made the top-row `CCC` nodes clickable when the `Research` title bar and `Savings` panel were sitting on top of them. **A research node under a HUD panel is not clickable and the click is eaten silently** - no preview appears and nothing tells you why |

Edits to existing rows:

• Row 62 (guest holders) — VM141 = FREE (lane AZ released 2026-09-09; guest restored, shim.cfg.hoff, this lane's binkw32.dll). **SavedGames has grown by a whole new game**: lane AR's 12-row set PLUS MyGameazTarka.savandMyGameazTarkat11cr.sav, and the three autosaves now belong to the Tarka game - **screenshot the Load dialog and re-derive the rows**. Left C:\SOTS\shimdist-az+ui\az-{go,ui}.ps1; click_helper.ps1unmodified. GOTCHAS:rdragrotates the star map (left-drag does NOT pan, arrow keys do nothing, the camera does not follow the selection); the Move-mode hover snaps to the nearest SYSTEM over >100 px so a node within ~3 ly of a member star needs a camera rotation first;wheel zooms both the star map and the research tree; a research node under a HUD panel is silently unclickable; and a blind auto-resolve-peacefully click sequence DOES NOT resolve a real battle - it cost this lane a 16-ship fleet.
• Row 186 / the k + s + z row — append: Lane AZ 2026-09-09: the zterm's gate is THREE conjuncts, not one - the route owner must not be HIVER (0x00820bc2), the raider's crew species must not be HIVER (0x00820bd7), and only then doesSpeciesDef+0x144(Human, Zuul) decide. And the short-circuit sets frac = **0.0**, not 1.0.z is still unobserved; the cheapest state for it is now a player-owned route sourced in a sector where an AI raider is already parked, which needs no fleet movement at all.
• Lane AR's B costs ONE word row — append: SCOPE CORRECTED (lane AZ 2026-09-09): "every other species draws a word" is wrong for HIVER raiders and for HIVER-owned routes, and Hiver can never research Commerce Raiding anyway (CCC_ComRaidpct 0 on both edges), so SC2 is unreachable throughvslot13 for a player. The drawing raiders are Tarkas, Liir and Morrigi.