sots-re/findings/subsystems/ai-stepping-and-passes.md

The AI's stepping order and what the two passes are

Lane AI3, 2026-09-08. Program sots / "Sword of the Stars.exe", ImageBase 0x00400000, all addresses VAs. Static only; VM140 is held by lane W2. Nothing in this document has ever run under an instrument — every claim is read from the instruction stream, and §8 names the probe for each thing that needs one.

Continues ai-task-system.md (lane AI2) and ai-turn-logic.md (lane AI1). This lane closes AI2's open items 2, 3, 4, 5 and 6, and corrects two published claims.

Method. Same as AI1's and AI2's: objdump -b binary -m i386 -M intel over the raw image, every body swept to the next function start (rule 17), call targets from dumps/functions.json, jump tables and data read out of the image at real instruction boundaries, indirect-site census from tools/vtable_map.py. The decompiler was not used. The one new instrument is an unlimited-depth direct call-graph built from an E8/E9 scan of all 41,089 function bodies — AI2's reachability table was cut at depth 4 and that cut is the source of its wrong inference (§2).

Addresses: ghidra/addresses.d/lane-ai3.json (15 entries; tools/gen_addresses.py to a scratch path, 1,105 → 1,120, no duplicate names).

---

0. The two answers, up front

1. The AI players are stepped in ascending server-player-index order — i.e. save player order — and each player appears at most once per drain. The enqueue site AI2 could not find is StrategyApp::OnClientEvent 0x00838e10, and the thing that fills it is StrategyServer::ResumePlaying 0x007ddc90, which walks the player vector at StrategyServer+0x54 in index order. The order is therefore predictable from a save alone, with no live measurement.

AI2's search missed it for a specific and generalisable reason: 0x00b29f98 is not a pointer to the StrategyApp, it is the StrategyApp. MSVC folds the object base into the absolute address of the member, so the enqueue writes the absolute 0x00b29fb4 (= app+0x1c) and never materialises 0x00b29f98 at all. A scan for "functions that load the singleton" cannot see it. The address 0x00b29fb4 has exactly two references in the whole image, both in the enqueue.

Compounding it: 0x00838e10 has zero direct callers and no vtable slot. Its address is stored once, into StrategyServer+0x170, by CreateGame at 0x00889177. That is lane B6's third blind spot, and it is the second time this campaign has hit it.

2. Pass 0 and pass 1 are not "plan then execute". pass is a numeric tier, and the pass-1 sweep is a strict superset of the pass-0 sweep that additionally emits every order.

The single instruction that settles it is at 0x006abb2a, in FillCandidateToTierQuota 0x006abb00:

have = f(slot->+0x10) + g(slot) + slot->+0x20        ; force already assigned to this candidate
want = (tier == 0) ? cand->+0x10                     ; 0x006abb41
     : (tier == 1) ? cand->+0x14                     ; 0x006abb39
     : 0
if (have >= want) return                             ; quota already met

Each candidate carries two quota fields, and pass picks which one is in force. The hub above it runs for (i = 0; i <= pass; ++i) gather(..., i, ...), so pass 1 re-runs tier 0 and then tops up to the larger tier-1 quota.

And every order-emitting exit from that hub is gated pass == 1:

exit	gate	reaches
IssueRouteForFleets 0x006bbd50	if (pass != 1) return @0x006bbd78	0x006b76a0 → AI_IssueFleetTask → list 14
AssignFleetsAndIssueOrders 0x006c16c0	if (pass != 1) goto ret @0x006c177e	lists 14, 8, 10
RequestBuildForTask 0x006cea50	if (pass != 1) return @0x006ceaac	lists 3, 1

So the model is the classic two-phase allocation: pass 0 claims fleets against every task's minimum requirement, in priority order; pass 1 tops each task up to its desired requirement, again in priority order, and issues the orders. For ModCount that means only the pass-1 sweep produces TurnCommands elements (§2.4 states the one case I could not close).

---

1. The stepping order, instruction by instruction

1.1 StrategyApp is a static object at 0x00b29f98

Proved by mov ecx,0xb29f98; call <method> at 0x007842f6 and 0x007843a2 — an immediate, not a load — and cross-checked at 0x007843ac, where Update reads the absolutes ds:0xb29fa8 - ds:0xb29fa4 exactly where SyncLocalClients 0x00815fd0 reads this->+0x10 - this->+0xc.

offset	absolute	what	evidence
+0x0	0x00b29f98	flag byte; bit 2 = "a StrategyServer exists"	test byte [esi],4 @0x00815fd6, or al,4 @0x008891a6
+0x4	0x00b29f9c	StrategyServer*	mov [esi+4],eax @0x0088916c after 0x007d78d0
+0xc/+0x10/+0x14	0x00b29fa4/a8/ac	vector<StrategyClient*>	walked by RunPendingAITurns and SyncLocalClients
+0x1c/+0x20/+0x24	0x00b29fb4/b8/bc	vector<int> pendingAITurns	§1.3
+0x2c	0x00b29fc4	AIProcessMinTime (seconds, float)	AI2 §7

1.2 StrategyServer::ResumePlaying 0x007ddc90 — the order

if (0x0080f4d0(&this->+0x4)) return
if (++this->+0x168 == 1 && this->+0x1b4) { obs->vt[4](2,0); obs->vt[7](); }
0x007dd230(&this->+0x174, 0)                 ; clear
0x007dd230(&this->+0x174, playerCount)       ; resize
for (i = 0; i < playerCount; ++i)            ; players[] at this->+0x54..+0x58, INDEX ORDER
    if (players[i]->Elim == 0) players[i]->Status = 0        ; +0xf8, +0x164
for (i = 0; i < playerCount; ++i)            ; SECOND walk, INDEX ORDER
    p = players[i]
    if (p->Status != 0) continue
    ev = { vptr = 0x00a23bb8 }                                ; on the stack
    cb = this->+0x170
    if (!cb) Log("...") else cb(p->+0x4 /*netId*/, 0x26, &ev)

+0xf8 is Elim and +0x164 is Status — both save-visible ServerPlayer fields (findings/objects/struct-recovery.md, rows 0xf8 | -0x2a8 | bool | Elim and 0x164 | -0x23c | int | Status). So:

• every non-eliminated player has Status reset to 0 and then receives SEResumePlaying, in player-array order;
• an eliminated player receives it only if its Status already happened to be 0.

Cross-lane note (rule 18's open list). method-rules.md names "the Player.Status writer between tail phase 31 and the autosave" as an open watchpoint question. 0x007ddd3f is a Player.Status writer — players[i]->Status = 0 for every live player. It fires at the resume boundary, which per AI1 is after the End-Turn autosave, so it is probably not the writer that item is chasing; recording it so the next lane to take that watchpoint knows which hit is this one.

1.3 StrategyApp::OnClientEvent 0x00838e10 — the enqueue

if (*(void**)0x00b29f9c == 0) return                  ; no StrategyServer
if (netId == 0) return
find client in [0x00b29fa4 .. 0x00b29fa8) with client->+0x148 == netId ; else return
p = client->+0x150
if (eventId == 0x26 && p->+0xf9 != 0 && p->+0xfa == 0) {
    if (!0x00438fe0(&pending /*0x00b29fb4*/, &netId))  ; already queued?
        0x0059f1a0(&pending, &netId)                   ; vector<int>::push_back
    return
}
StrategyClient::RaiseEvent(client, eventId, ev)        ; 0x00783ee0, synchronous

Three consequences that matter:

1. SEResumePlaying for an AI player is the only deferred event in the game. Every other event, and the same event for a human player, is delivered inline from the server's own call.
2. The queue is deduplicated. 0x00438fe0 returns true when the id is already present and the push is skipped, so a player can appear at most once per drain.
3. The AI test is two bytes on the player, +0xf9 != 0 && +0xfa == 0.

1.4 The AI-player predicate is on two bytes the save does not carry

struct-recovery.md's ServerPlayer table runs 0xf8 Elim, then jumps to 0xfb NPC, 0xfc RebAI, 0xfd ReqCL, 0xfe AIBn, 0xff CnTrd, 0x100 CnRad … — a packed run of bools. +0xf9 and +0xfa are the two holes in that run: in-memory bytes with no serialised counterpart.

That is a real gap for Rung B. Whether a given player's turn is run by the AI is decided on state that is not in the save, so it must be set at load or game-setup time from something that is (AIBn, NPC, RebAI, or a GameOptions player-type list). I did not find the writer. An image-wide scan for the +0xf9/+0xfa displacements returns 83 and 82 sites across many unrelated classes, and I did not filter it to ServerPlayer receivers. This is the one thing in §1 I would hand to a watchpoint first (§8).

1.5 RunPendingAITurns re-reads its bounds every iteration

AI2 read the drain correctly. One detail worth adding, because a reimplementation will get it wrong: 0x00838d16–0x00838d2a re-loads both +0x1c and +0x20 on every iteration, so the vector may legally grow (and reallocate) while it is being walked, and any player enqueued by an AI turn is picked up in the same drain. Whether that ever happens is unmeasured.

1.6 What this means for ModCount

The stepping order is save player order, filtered to live players, filtered to AI players, each once. Combined with §2, the per-turn sequence of TurnCommands writes is:

for each live AI player in save order: pass 0 (claims only, no writes) then pass 1 (writes), with tasks visited in AI2's stable descending priority order within each pass.

That is a complete, offline-computable ordering claim. It is the piece that was missing.

---

2. The two passes

2.1 The dispatch, re-verified

RunTaskList 0x006b3320(agent, &list, pass, &claims) — __cdecl, four stack args. At 0x006b3478:

eax = [ebp+0x10]                 ; pass
[edi+0x130] += 4                 ; push the task onto the call stack at agent->+0x12c
edx = task->vt[5]                ; [*task + 0x14]
push eax ; push agent ; ecx = task
call edx                         ; Execute(agent, pass), __thiscall, ret 8
if (back(agent->+0x12c) == task) pop

So pass is the second stack argument of Execute, at [ebp+0xc] in a standard frame. All 30 distinct Execute bodies read it. (31 classes, 30 bodies: AITColonize/AITColonizeGoal, AITInvade/AITInvadeGoal, AITEscortGateInvade/AITEscortGateInvadeGoal and AITRespondAttackSystem/AITRespondDefendSystem share bodies.)

2.2 pass is a tier index, and the tier selects a quota

AcquireFleetsForTask 0x006ceef0 is the hub every fleet-shaped task reaches. Its real span is 992 bytes to the next function start; Ghidra's size is short again (rule 17, now seven functions across seven lanes). It has three blocks, and each is the same shape:

for (i = 0; i <= pass; ++i)          ; 0x006cef6a / 0x006cf039 / 0x006cf0fe -- `jl` guard then `jle` back-edge
    gather(agent, threshold, target, candidates, i, &gathered)
if (0x00698960(candidates, ..., &gathered))   ; is the requirement met?
    commit(...)

Block A gathers via GatherFleetsForTier 0x006abf80, which walks the 0x20-stride candidate vector and calls FillCandidateToTierQuota 0x006abb00 per candidate with the tier. That function's prologue is the definition quoted in §0: tier 0 ⇒ the quota at cand->+0x10, tier 1 ⇒ the quota at cand->+0x14, anything else ⇒ 0. It is a compiler-generated switch (sub ecx,0 / je / dec / jne), not an if.

So the two passes are two force requirements per candidate, a minimum and a desired, filled in two priority-ordered sweeps of the whole task list.

2.3 Pass 0 writes nothing

Three independent readings agree:

1. The two emitters are pass-1 gated. IssueRouteForFleets 0x006bbd50 and AssignFleetsAndIssueOrders 0x006c16c0 both open with the MSVC sub eax,0 / je L / dec eax / jne L shape on pass, taking the working arm only when pass == 1. RequestBuildForTask 0x006cea50 does the same.
2. The hub returns an empty fleet list on pass 0. The result vector lives at [ebp-0x3c]; I enumerated every lea of that slot in the 992-byte body — five sites — and only two of them pass it to a function that can write it, namely 0x006bbd50 (twice) and 0x006c16c0 (once). Both are pass-1 only. So on pass 0 the copy-out at 0x006cf24d copies an empty vector, and every caller's "for each fleet returned, issue the order" loop runs zero times.
3. No gather or commit helper reaches an order method. Unlimited-depth direct closures: 0x006c3e50 (commit) reaches 16 functions and no order method; 0x006cb310 268 and none; 0x006b7c90 139 and none; 0x006abf80 40 and none; 0x00698960 1 and none. Only 0x006c16c0, 0x006cea50 and 0x006bbd50 — the three pass-1 gates — carry an order edge.

The two task-level bodies that gate on pass themselves corroborate:

• AITAdvanceIdleShips::Execute 0x0068f230 is if (pass != 1) return; at 0x0068f25a — its entire body is pass-1 only. It has priority 0, so it is always the very last task in the list. The AI sweeps up whatever is still idle only after every other task has taken both its minimum and its desired force. That is exactly what the two-tier model predicts.
• AITNodeBore::Execute 0x0068e590 does its setup (0x00685810) and its finaliser (0x0068e090) only when pass == 0, and forwards pass to 0x0068a520 in both.

2.4 The one exception I could not close

AITRaid::Execute 0x0068e670 reaches list 16 at depth 1: at 0x0068e89e it calls 0x006b76a0 and then, at 0x0068e8b8, loops ClientOrder 0x007635f0(client, fleetId, 1) over the returned fleets. Neither the call nor the loop has a pass guard of its own. It fires iff the fleet vector at [ebp-0x28] is non-empty, and that vector is downstream of the same hub — so §2.3's argument says it is empty on pass 0, but I did not trace [ebp-0x28] to closure. Treat "AITRaid emits nothing on pass 0" as inferred, not verified. It is one entry probe on 0x007635f0 (§8).

---

3. The .data invade tunables have no loader — they are constants (AI2 §10.6, closed)

0x00a1795c and 0x00a17960 each have exactly one 4-byte reference in the entire image, and both are the mov eax, ds:[imm32] inside their own GetPriority override. There is no writer anywhere. Their values are in the PE image:

address	value	override	table priority	effect
0x00a1795c	650	AITInvade::GetPriority 0x00683670	500	flag raises it to 650
0x00a17960	750	AITEscortGateInvade::GetPriority 0x006835e0	400	flag raises it to 750

They sit inside a run of unrelated statics (floats 0.5/0.75/0.9 and pointer tables into the weapon-name block at 0x00a17618), i.e. one translation unit's .data, packed by the linker. There is no CSV path and nothing to find. Lane N's pop-type table and lane E1's difficulty table were built in code from .rdata literals; this is the simpler shape one step further down — no construction at all.

3.1 Correction to ai-task-system.md §3: the flag polarity is inverted

AI2 published if (!(this->+0x4 & 1)) return *(int*)0x00a1795c. The instruction stream is:

00683670  movzx eax, byte [ecx+4]
00683674  not   al
00683676  test  al, 1
00683678  je    0x0068367f          ; ZF set  <=>  bit0 of ~b == 0  <=>  bit0 of b == 1
0068367a  jmp   0x00694220          ; bit0 CLEAR -> the default table lookup
0068367f  mov   eax, ds:0xa1795c    ; bit0 SET   -> the tunable

So the tunable applies when bit 0 of this->+0x4 is SET, the opposite of the published claim. This matters because it flips the meaning of the flag — AI2 called it "not yet committed", and on the instruction stream the tuned, higher priority is the flag-set state, not the flag-clear state. I have not identified what bit 0 of +0x4 is; note that AITInvade::Execute maintains two different bytes at +0x38 and +0x39 that look far more like "committed" than +0x4 does, so "committed" should be treated as an unsupported name, not just an inverted one.

Also: the default arm is not the table directly. 0x00694220 is a shared 17-byte thunk, return AITask_PriorityForType(this->vt[1]()), which then calls AI2's 33-arm table at 0x00691f00. The table itself stands unchanged.

---

4. Slots 11, 12 and 13 (AI2 §10.2)

4.1 Slot 12 — named: preemption permission

IsClaimedByAnotherTask 0x006a8d20(agent; void* obj) is the only consumer, and it is called from the per-fleet filter inside FillCandidateToTierQuota at 0x006abc71 with test al,al; jne <skip candidate> — so true means "reject this candidate".

key = obj ? obj->+4 : 0
owner = lookup(key) in agent->+0x2e8..+0x2ec        ; 8-byte pairs {IAITask* owner, int objectId}
if (not found here and not in the 4-byte set agent->+0x2d8..+0x2dc) return false   ; free
cur = back(agent->+0x12c)                           ; the task call stack RunTaskList maintains
if (stack empty || !cur) return true
if (!cur->vt[12]()) return true                                        ; 0x006a8db3
if (!owner) return false
if (cur->GetTypeId() == owner->GetTypeId()) return true
return !(cur->GetPriority() > owner->GetPriority())

Slot 12 is "this task may take an object already claimed by a strictly lower-priority task of a different type". Default false (26 classes ⇒ any claimed object is off limits); five classes set it. Because the list is processed in descending priority, the owner is normally the higher-priority task, so the steal branch should almost never fire — which is a falsifiable prediction (§7, P3).

This also names agent->+0x2e8 positively: it is the claim registry, a vector of {IAITask*, objectId} pairs. RunTaskList erases the task's entries from it before calling Execute, which is consistent.

4.2 Slot 13 — consumer found, semantics partially read

RangePenaltyForTask 0x00696620 is the only slot-13 dispatch I found (call [eax+0x34] at 0x00696630, on the this receiver):

budget = this ? this->vt[13]() : 15
n = max(1, agent->+0x10->+0x8 - 0x0080da80(player) + 1)
if (n < budget) return 0
switch (player->Species)                     ; byte index @0x006966a8 = [0,0,0,0,2,1,0]
                                             ; jump table @0x0069669c = [0x69668a, 0x696693, 0x69668a]
    species 5 (Zuul)                -> return 0
    species 0,1,2,3,4,6 and >6      -> return 1000000

So slot 13 is a range/hop budget, compared against a count, with a prohibitive 1,000,000 penalty past it. Its default is 15; AITDefendColonyIncoming and AITDefendGateIncoming return INT_MAX, so they never take the penalty — an incoming attack is answered at any distance.

And the Zuul are exempt. That is a fourth independent cross-check on AI2's species reading, after Hiver-only gates in arm 1, Zuul-only node-bore in arm 5, and NPC building nothing in arm 4. Four coincidences is not a coincidence.

I have not identified agent->+0x10->+0x8 or 0x0080da80, so I am not naming the units. n is a small count that grows with something; "hops" and "turns" both fit and I cannot separate them statically.

4.3 Slot 11 — consumer found, semantics not read

Dispatched at 0x006cf10e, inside AcquireFleetsForTask's third block: `eax = task ? task->vt11

1, and eaxis then pushed as an argument to0x006cb310, the block-C gatherer. Its default is trueand onlyAITInvade/AITInvadeGoaloverride it, returningthis->+0x39`.

AITInvade::Execute 0x0068d7a0 computes that byte at 0x0068d80f–0x0068d82a:

this->+0x39 = (0x006a6380(agent, this->+0xc) < 2 * 0x006a6260(agent, this->+0xc))

i.e. a comparison of two per-target quantities with a factor of two — a "do I have less than twice X?" ratio test. So slot 11 gates how block C gathers, and for an invade it is a strength ratio against the target. Not named. 0x006a6260 and 0x006a6380 were not read.

---

5. The nine "no order method" tasks are not planners — AI2 §4.2 corrected

AI2 wrote that nine task classes have no order method within depth 4 and inferred, explicitly flagged as unverified, that they are "goal tasks whose job is to spawn sub-tasks onto the list, not to emit orders".

That is wrong, and the cause is the depth-4 cut. All nine reach an order method by direct calls only, at depths 4 to 9. Unlimited-depth direct closure, one concrete path each:

task	order	path
AITColonize / AITColonizeGoal	list 7 (colonize) @4	0068b400 → 0068b280 → 006930f0 → 00578ff0 → 00769640
AITEscortGateInvade / …Goal	list 7 @4	0068c7c0 → 0068c5d0 → 00693080 → 005790b0 → 00769640
AITInvade / AITInvadeGoal	list 14 @5	0068d7a0 → 0068d460 → 006ceb80 → 006c16c0 → 006987e0 → 007634d0
AITNodeBore	list 14 @5	0068e590 → 0068a520 → 006ceef0 → 006c16c0 → 006987e0 → 007634d0
AITBuildPoliceShips	list 3 (build) @6	00690380 → 006ce460 → 006ce360 → 006ce190 → 006bd790 → 006b3bc0 → 00762fd0
AITBuildDeepScanShips	list 3 @6	006901a0 → … (identical)

AITColonize emitting the colonize order and AITBuildPoliceShips emitting a build order is exactly what those names promise. There is no planner tier.

What the six shared/thin bodies actually are is forwarders into shared parameterised workers:

body	forwards to	shape
0x0068b400 (Colonize, ColonizeGoal)	0x0068b280	48 B; worker(ecx = agent, this, pass, this->+0x8, &this->+0x20, &this->+0x10), plus edi = this->+0xc as an implicit register argument
0x0068c7c0 (EscortGateInvade, …Goal)	0x0068c5d0	80 B; __fastcall(ecx = this->+0xc, edx = agent) + 8 stack args
0x0068d7a0 (Invade, InvadeGoal)	0x0068d460	160 B; 11 args, then maintains this->+0x38/+0x39

The +0xc-in-edi convention in the first of those is worth flagging on its own: it is a whole-program-optimised custom calling convention, invisible to a decompiler prototype, and a reimplementation that only ports the stack arguments will silently pass garbage.

What the "Goal" suffix actually distinguishes is not behaviour — the paired classes share an identical Execute — it is the two GetTarget slots. AI2's slot 2/3 body census already showed the variants return different members (+0x8/+0xc vs +0xc/+0x10). So a Goal task is the same task pointed at a different pair of fields, not a different kind of thing.

---

6. The reachability bound, honestly (AI2 §10.1)

AI2's table was a depth-4 direct closure. Mine is an unlimited-depth direct closure over an E8/E9 scan of all 41,089 bodies. It is still a lower bound, and here is the size of the gap.

The union of the unlimited direct closures of all 31 Execute bodies is 1,534 functions, 358 of them in the AI band. Inside that set, tools/vtable_map.py finds 940 indirect call sites:

kind	count	reachability risk
call-abs (import / CRT thunks)	598	none
virtual, slot resolved	156	low — 133 of them are slots 0–13, i.e. IAITask itself
call-reg-unresolved	88	unknown
vptr-unresolved	72	unknown
call-reg-nonmem / not-vptr	26	low

So the honest statement is: 160 indirect call sites inside the AI closure cannot be resolved by the current tool, and any of them could reach an order method. Rule 16 stands.

Where it matters most, though, the closure is tight. The two functions that carry every order emission have almost no indirect surface at all:

• AcquireFleetsForTask 0x006ceef0: 7 indirect sites — 4 import thunks, IAITask slot 1 (GetTypeId, returns a constant) twice, and slot 11 (returns a bool). None can reach code.
• AssignFleetsAndIssueOrders 0x006c16c0: 4 indirect sites, all import thunks.

One thing the census turned up that deserves a follow-up: slot 5 (Execute) is dispatched at 14 sites inside the AI closure, not just from RunTaskList 0x006b348d. 0x006c8fd0 alone has twelve. Tasks running other tasks is real; I did not read those sites and cannot say whether they are sub-task execution or an unrelated class that shares slot 5.

---

7. Predictions (rule 2) — written before any run

P1 — the AI turn sequence is fully determined by the save

Stepping order = live players in save-array order, filtered to AI; within each player, tasks in AI2's stable descending priority order; two passes, the first writing nothing.

Prediction: hook 0x006b348d and log (playerNetId, task->GetTypeName(), task->GetPriority(), pass) for one turn. The log is a concatenation of per-player blocks in ascending save-player order; within each block the priorities are non-increasing within pass 0, then non-increasing again within pass 1, over the same multiset. Falsified if: the player blocks are in any other order (then ResumePlaying is not the only filler of the pending vector, or the callback is not the only enqueue), or the two passes visit different sets.

P2 — pass 0 writes no TurnCommands at all

Prediction: hook the 26 order methods and record pass from a hook on 0x006b348d. Zero order calls occur between the pass-0 entry and the pass-0 exit of RunTaskList for every player. Falsified if: any order method fires during pass 0. The most likely falsifier is AITRaid's list-16 emit at 0x0068e8b8 (§2.4), which has no pass guard of its own — so instrument 0x007635f0's entry, not its cost (rule 20). Why it matters: this halves the ModCount arithmetic. AI2's P1 says an AI fleet order costs two list-14 elements; if pass 0 also emitted, it would cost four.

P3 — task-to-task preemption never fires on a normal turn

Slot 12 permits stealing only from a strictly lower-priority owner, and the list is processed in descending priority, so by the time a task runs, every existing owner outranks it.

Prediction: an entry probe on 0x006a8d20 shows it is called often and the steal branch (0x006a8ded via 0x006a8de9) is never taken. Note this is a rule-20 shape: a count of zero at the call site cannot distinguish "never called" from "called and always rejected" — probe the branch. Falsified if: the branch fires. That would mean the claim registry outlives the sort, i.e. claims from a previous task list survive into this turn, which would make the AI's state path-dependent across turns and is a much bigger deal for Rung B than the preemption itself.

P4 — the two AI-player bytes are derived, not loaded

ServerPlayer+0xf9/+0xfa have no save field (§1.4).

Prediction: a write watchpoint on player+0xf9 fires exactly once per player during game setup / load, from a function that reads AIBn, NPC or RebAI, and never again during a turn. Falsified if: it is written mid-turn — then whether a player is AI-controlled can change during a game and the stepping-order model needs a per-turn input the save does not supply.

---

8. What this lane did not do

1. Nothing ran under an instrument. Every claim above is static. §7 is the measurement plan; §2.4, §4.2, §4.3 and §1.4 are the four places where I would spend the probes first.
2. ServerPlayer+0xf9/+0xfa have no located writer (§1.4). This is the biggest remaining hole, because it is an input to the stepping order that the save does not contain. Probe: a hardware write watchpoint on player+0xf9 across load and one turn.
3. AITRaid's pass-0 behaviour is inferred, not verified (§2.4). Probe: entry hook on 0x007635f0.
4. Slot 11 is not named (§4.3), and 0x006a6260/0x006a6380 were not read.
5. Slot 13's units are not named (§4.2); agent->+0x10->+0x8 and 0x0080da80 were not read.
6. Bit 0 of IAITask+0x4 is not identified (§3.1). I corrected the polarity and withdrew the name.
7. 160 indirect call sites inside the AI closure are unresolved (§6), so the reachability result is still a lower bound — just a much larger one than AI2's.
8. The 14 non-RunTaskList slot-5 dispatch sites were not read (§6).
9. 0x006cb310, 0x006b7c90 and 0x006c3e50 were read only for their order-method reachability, not for what they do. The claim "pass 0 claims fleets" is the shape the quota code implies; I did not verify that 0x006c3e50 actually records a claim.

---

9. Corrections to earlier findings

• ai-task-system.md §4.2 — "the nine with no order method are goal/planner tasks". They are not. All nine emit orders; the depth-4 cut hid it (§5). AI2 flagged the inference as unverified and it was the right thing to flag.
• ai-task-system.md §3 — the two priority overrides' flag polarity. The tunable applies when bit 0 of +0x4 is set, not clear, and "committed" is not a supported name for that bit (§3.1).
• ai-task-system.md §10.6 — "the .data priority tunables were not traced to a loader". There is no loader; they are image constants, 650 and 750, with one reader each and no writer (§3).
• ai-task-system.md §10.4 — "the two-pass meaning is inference". Settled (§2): pass is a tier index selecting between two per-candidate quota fields, and pass 0 emits nothing.
• ai-task-system.md §6.1 / §10.5 — "the StrategyApp+0x1c fill site was not found". Found (§1). AI2's method was sound; it was defeated by the object being static rather than heap-allocated.
• ai-turn-logic.md / ai-task-system.md — IAITask slot 12. Named: a preemption permission (§4.1).

---

10. Ranked plan for sots-engine/src/game/ai

AI2's items 5 and 7 are done. The revision:

#	deliverable	why	testable how	blocked on
1	game/ai/tasks tuned priorities DONE this lane — the two tunables are now constants (650/750) with the corrected flag polarity, and the misleading committed name is withdrawn	§3 makes them facts, not inputs	host: golden values + polarity test	—
2	game/ai/turn_order DONE this lane — the stepping order and the two-pass model as pure functions	§1 and §2. Zero game state; it is the ModCount sequence	host: order + dedup + pass-emission cases	—
3	game/ai/tables — the nine AI CSV tables (AI1's item 1, AI2's item 2)	unchanged: zero AI understanding needed, mars/text already exists	oracle diff vs the shipped CSVs	nothing
4	measure P1 and P2 on VM140	P2 halves the ModCount arithmetic; P1 is the whole ordering claim	hook 0x006b348d + entry probes on the order methods	VM140 (lane W2)
5	find the ServerPlayer+0xf9 writer (§8.2)	an input to the stepping order that the save does not carry	write watchpoint (rule 18: this is a watchpoint, not a week of reading)	VM140
6	read 0x006c3e50 and the claim registry	closes "pass 0 claims fleets" from shape to fact	—	a lane
7	game/ai/agent — the spine as named stubs	now has real semantics for phase 20 and the two passes	host: phase-order test	#6