Names the six regions (four result, two guard) that are the classifier's whole
output surface, and then names every predicate the decision consumes next to
which side computed it -- because the module takes those predicates as given, so
reading them off the live objects is its interface rather than a shortcut. Also
records that the node-graph indirect edge path-solver.md could not resolve
statically is resolved DYNAMICALLY here, by making the same call from the hook.
The observed-design list is a MOVE-TO-BACK vector capped at 20 records per
DESIGN OWNER, and that is why lane CV's 55 odes leaves looked unrelated: a turn's
output is a permutation of its input, not an append.
rich turn ad-turn27 + BR's deep tcb vs bp-pinB-turn28 1092 -> 1058
36 closed / 2 regressed vs CV's run; 116 / 8 vs the 1166 baseline
canonical turn2-state + CB's tcb vs turn3-state 62 -> 61
1 closed / 0 regressed, set-differenced by leaf PATH
All five committed predictions held; P5 held in direction and was wrong in
magnitude (9 leaves, not 4 -- I predicted spurious records, not leaves).
CV's "no upstream dependency" is right for the design half and wrong for the
other 24 leaves of the 79, two separate ways, and both are named rather than
attempted: the otch/owep arms need three undecoded design->tech/weapon set
builders (the wire's own DOpts list covers 13 of the 18 tech names the turn
moves), and the design half is itself capped by SHIP CONSTRUCTION -- two designs
get their first ships that turn. Fed the true post-turn ship list the same code
leaves 1 leaf of 55 instead of 21, so the mechanism is not the residual.
Control, run: with the NPC-owner guard compiled out the canonical pair goes
61 -> 70 and the rich turn stays at 1058. The guard is load-bearing on one pair
and inert on the other, which is why both were run.
Coverage, stated as loudly as the divergence: 8 players swept, TWO produce any
record; the canonical pair offers 16 (player, ship) pairs of which the guard
drops 15, leaving one record call on one design. No foreign observation moves on
either pair, so the visibility gate -- a two-bit-per-player word at Ship+0x54
that is not on the wire, stood in for with ownership -- is entirely unexercised
and is labelled a hypothesis.
ghidra/addresses.d/dt.json: 10 entries (the sweep 0x007c2350, the recorder
0x007be340, RecordObservedWeapon, the vector helpers, sizeof(ObservedDesign) =
0x10, the vftable, and ServerPlayer +0x254 / +0xfb). gen_addresses.py merges it
clean at 1320 entries, no duplicate name or address.
The classifier is a real callable unit (StarFleet::ClassifyLeg 0x00703730, thiscall,
ret 0x14, two direct callers), so the hook goes on the classifier and not on a proxy
for it. Nine predictions with their falsification symptoms, the workload that reaches
both route classes, and the three input gaps that are counted per call rather than
argued away. addresses.d/dn.json carries the eleven offsets the hook needs plus the
vtable slot that resolves path-solver.md's node-graph indirect edge.
Track 0 items 0a and 0b. The finding has the full account; the two things
that matter for anyone reading the gate afterwards:
gate.sh was taking TAIL's exit code from `ctest ... | tail -15`, so it printed
"GATE ok host-ctest" directly above "2 tests failed out of 59". The same
masking was on the host build and on the shim cross-build. All three now
capture the real status and trim the output afterwards.
The corpus-skip check counted every "unset, skipped" line, two of which are not
corpus tests, so it could never reach zero. It is now scoped to the tests gated
on the corpus, SOTS_DATA_DIR is set so game_design_census actually runs against
it (43 saves, 2728 designs, 0 mismatched -- a test that had been skipping), and
every remaining skip is printed by name so none can be invisible again.
Replace mode was tried live on a turn that actually completes a tech, with a
two-process hooks=off oracle established first on that exact (save, procedure,
route). Verdict: game/sim/research stays compared.
What displaced: all 13 tech-tree leaves the turn moves -- 2 from the pass itself
and 11 from the SetResearched cascade -- produced by our code in live game memory,
with the original's ProcessResearch never executing.
What did not: 16 leaves, every one written by ServerPlayer::OnTechResearched.
Five player tech-effect fields (OutMod, ConMod[0..2], ResTNm), one ObservedTech
element, two event records plus EvNxID, and five derived leaves behind them.
Also: ref-turn2 + one End Turn does NOT complete a tech, so every research oracle
before this one was taken on a quiet turn; and a config that names all 27 registered
hooks off and passes check_shim_configs.py still installs six detours, because the
M0 stub and the FPU module's four sampling detours have no hook. key.
The phase is FUN_007c2350 (tail phase 34): for every player, over every ship of
every fleet, gated on a two-bit-per-player field at Ship+0x54 that is NOT on the
wire, call RecordObservedDesign(player, ship.design). That function dedups on
odid alone, and on a hit it ERASES and PUSH_BACKS rather than updating in place --
so the list is ordered by last observation and otnF survives the move -- then caps
the list at 20 entries per DESIGN-OWNER, counted from the back, after every single
record call. sizeof(ObservedDesign) = 0x10.
Predictions, computed from a Python simulation of that mechanism over the corpus,
committed before any engine code is written:
P1 rich turn odes: 55 -> 21, i.e. 34 closed / 0 regressed
P2 otch+owep (24 leaves): 0 closed / 0 regressed, blocked (see the finding)
P3 rich-turn total 1092 -> 1058
P4 canonical pair: 1 closed / 0 regressed
P5 the NPC-owner guard is worth 4 leaves of regression on the canonical pair
The canonical pair on the same binary puts ModCount on 12 -> 24 exactly (zero
residual), so the cost table is right on the lists that pair exercises and the
rich turn's residual of 2 must sit in lists 1, 7 or 12. The only uniform
per-element explanation is list 7 (colonisation) at 2 bumps -- fitted to one
observation, recorded as a prediction with its falsifier.
Also records the regression check on tools/aiorders_to_tcb.py: 8 shallow logs
byte-identical, 4 lane-CB logs corrected (they were deep dumps whose payloads
the converter had been discarding), and the canonical pair's replay unchanged.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
Replays lane BR's deep command block for ad-turn27-two-raiders.sav through
sots_turn --turn-commands and compares with bp-pinB-turn28.sav (724528ff).
Verdict: outcome 3. DIVERGED: 1092 leaf difference(s) against a 1166-leaf
do-nothing baseline; 80 closed, 6 regressed; the stream's whole contribution to
the state is /Sim/ModCount (1430 -> 1500, target 1502, residual 2).
Two blockers upstream of the turn: the typed writer drops one usp item in
Game::SpecialProjectNameGen (12 of 43 corpus saves, exactly 12 bytes each), and
--relabel-new-ids refuses by guard G3 because the engine mints no client fleet
ids. The tail's tscr gate is TRUE on this save (253, not 252).
tools/aiorders_to_tcb.py now reads the deep dump's aivec/aistr rows, only at a
word the field map already types as a vector, with the followed count
cross-checked against the begin/end pair.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
Implements the 2026-09-09 fleet-id-order resolution, section 3 item 1. Given the
pre-turn save, compute the ids new in each post-turn save, match the client-minted
(node nibble != 0) new fleets by a key that does not mention the id -- (LocID or
FPlan destination, sorted ship-id set) -- build the bijection pi, rewrite every
fleet reference, compare the master id lists as sets, mask /Summary/Checksum with
its reason on the line, and print pi.
Acceptance, both halves:
bp-pinA vs bp-pinB IDENTICAL modulo pi = {1970<->1986} (35 leaves -> 0)
ad-oracle-A vs -B REFUSED, then DIVERGED: 94 leaves (unchanged)
Five guards, every one refusing rather than degrading: only ids absent from the
pre-turn save; only non-zero node nibbles; pi must permute one set; content keys
must correspond one-to-one and be unique per side; and no leaf anywhere may hold a
permuted id at an unmodelled site (matched on raw bytes, not the reader's typed
value). A refusal rewrites nothing and falls back to the ordinary comparison.
Three corrections to the specification from contact with the data, in
findings/subsystems/relabel-new-ids.md section 4: FtName is an id-attached label
and needs the same treatment as the id; relabelling the Flt[] keys is the wrong
operation (exchange the bodies -- the fleet table is id-ordered and identical in
both saves); a node's new-id set spans object kinds.
Default path proven unchanged: pre- and post-change modules agree on the root
digest, coverage, mask hits and every (path, digest) in the tree over all 43 saves
under two policies, and on 5,602 lines of CLI stdout across every mode.
Also fixes a pre-existing, unrelated test failure: the re-save localisation test
enumerated pairs over sorted filenames and hard-coded the direction 4 -> 0, which
a later corpus addition reversed. Suite 38 -> 62 tests, all passing.
From as-turn15-spydeployed.sav, 11 End Turns under probes=8. Detection at Frame
22, P at Frame 25: 0x00840a3c 1 call / 1 word, the first firing of any of P's
sites. 0x00840929 and 0x008409c7 are the MORRIGI branch and cannot be reached in
a Human game - correcting every inventory that lists them as three sites behind
one gate. The counter-mission roll 0x0088dc43 fires from Frame 19 (corpus was 0
of 22) and the deploy NextFloat 0x0078c97f is measured with cbh reproducing lane
AS's value bit for bit. Species table decoded, which also names AS's 0.75f as
Zuul and 0.5f as Morrigi. Two corrections to lane AG 3.2 (CnTrd is the target's;
ncp is a scalar counter). PB4 was wrong and is named: the trade-raid roll entered
the tail at Frame 20, re-confirming lane AD's per-fleet model. Control pair
disagrees (three outcomes in six processes) - not a calibration pair - and
probes=8 is byte-identical to a control over 44,438 leaves. Exposure fields
recorded per turn: saturated on this map.
P's three sites are two mutually exclusive branches on the spy owner's Species;
only 0x00840a3c is reachable from a Human empire. Species table decoded from the
corpus. Predicted trajectory for the 20-turn wait, including the counter-mission
roll 0x0088dc43 firing at Frame 19, and the deploy NextFloat 0x0078c97f.
Mars::RNG::Chance at 0x00887c8a, in the BODY of ServerSpyManager::vslot13 (tail
phase 23 call 9), measured at 1 call / 1 word / no_draw_calls=0 / strategic=true
on VM144 at probes=8, with OnAllCombatDone_Tail going 363 -> 364 against 0 on
every turn any lane has measured. The entry probe on SpyManager::Slot13RngCallee
read 0 on the same turn -- that zero was never about the subtree.
Predicate, decoded to save fields: spy.deat != 0 && spy.sdet == -1 &&
sys(deat).ARes2 > 0 && (sys(deat).TerrFl & 1). Corpus count 0 of 22; the failed
conjunct is deat != 0, not the belt -- all 22 corpus saves already had one.
Also: ServerSystem::AddSpy 0x007514c0 writes deat and pushes the spy id into
ServerSystem+0x1cc in the same two instructions, so spies2 is the per-system
DEPLOYED-spy vector; measured non-empty for the first time in the corpus.
And 0x0078c97f, a strategic NextFloat in the SHIPACTION_DEPLOYSPY handler, is in
no existing inventory -- decoded, not measured.
Lane PAR localised the AI's RNG variance to this function and stopped. This
reads it from the instruction stream (0x006ad700..0x006ae61a, swept to the next
function start; the padding confirms Ghidra's size is right on this one) and
measures it live with a sub-bracket on VM145.
THE MODEL. Nine live draw sites plus two provably dead. Only three of the nine
can cost more than one word, and only through NextInt's rejection loop; the four
cl_Chance probabilities are all strictly inside (0,1), so neither zero-word
early-out is reachable anywhere in the function. The loop-carried draw fires
once per SMALL STANDARD WEAPON BANK selected by
f = 1.00 / 0.75 / 0.50 by request flags, hull size and one 0.3 coin
M = (int)(N * f); D' = max(1, (N+1)/M)
L = #{ bank j : PointDefence section, or j mod D' == 0 }
which is not monotone in N -- at f=0.75, N=4 costs 4 words and N=5 costs 3.
VERIFIED. Client 32's seven turn-1 words decompose as TWO composer calls: a
costOnly=1 price query (3 words) and a costOnly=0 build (4). That was predicted
from two push literals at 0x006cda9a/0x006cdb17 and committed before the probe
existed. Two pinned runs in fresh processes agree row for row. The probe's bank
counts 3/1/2 match the Tarkas section catalog's bank counts exactly -- a hooked
pointer walk and a parsed data file agreeing from opposite directions. The
detour is behaviour-neutral: unpinned it reproduces the published
d59bb9f2fd0eb535.
NOT VERIFIED, and this is the part worth reading. The loop-carried draw has
NEVER FIRED -- six composer calls across four runs, zero. On turn 1 the weapon
lookups gate it; on turn 15 every composer call is a price query that returns
nine steps earlier. Five of the nine sites have never fired and two of nine
exits have ever been taken. The formulas for those are read, not measured, and
section 6 says so.
CORRECTS roll-parity.md: its site table omits a live draw site (0x00691e9b,
which the same lane measured live at 0x00691ea0), so the AI turn has 22 live
sites and not 21; and 'six of seven turn-1 words come from the composer' is
five from its body plus two from a helper it calls -- all seven are in its
subtree.
NEW: on turn 15 the composer is 10 of 16 words, not 16 of 16. The task
system's coin at 0x0069086a fires four times and never fired on turn 1.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
Diffing the four master id lists in the Sim block accounts for every object created on
turn 2->3: ship 1760 (server counter 110), fleet 1776 (111), fleet 34 (client node 2,
counter 2), and DesignIDs unchanged at 43 -- so no design was created that turn and
1776 is a fleet, not a design. Sharpens the correction to turn-command-replay.md row 2.
Also works out what explanation (B) implies for CB's reloaded run: the client re-issues
18, collides in its own map, and the autosave still matches because only the server's
state is serialized.
The client-side allocator is not a second allocator. StrategyServer and StrategyClient
are both StrategySim, which owns an IDMap at +0x80; each sim allocates from its own map
on its own local node index. StrategyServer::InitGameForPlayer sets that index to
PlyrIdx + 1 (node 0 is the server's) and seeds the client from the server's counter for
that node. IDMap::Initialize names the save's NM* tags: NMSz nodes, NMLc local node,
NMnx that node's counter -- confirming B5's labelled hypothesis and adding the other two.
Cross-checked on 20 saves: nodes 1, 2 and 3 all occur, counters run from 1 per node, and
2,600 ids collide zero times. Corrects turn-command-replay.md row 2: design 18 IS in
turn2-state.sav, so the canonical pair needs one minted id, not two. One open item, with
the one-hook probe named: a reloaded save produced fleet 34 rather than 18, and nothing I
read restores a client counter.
techId is the 0-based index into the master tech list sorted by _stricmp -- read out of
MasterTechTree's ctor, which sorts a copy of the parse-order list and then writes
def->techId = i. 282 is XNC_TrnsHum2, which lane L4 had already observed live and nobody
connected. tools/techid_table.py derives all 293 offline and refuses to print unless the
four observed points agree.
Three lanes could not build this workload. VM144 built both halves from a cold main
menu on a stock, unmodified install -- no data file touched, no save edited -- and the
answer to the question they were built to ask is no.
TRADE. The premise everyone carried, that trade needs station construction plus its
tech, is wrong about the station: StrategyVars.txt makes a trade station a +2-routes,
+25%-income bonus, and NumTradeRoutesSupported has a floor of 1 per owned system, so
the population thresholds scale the count and do not gate it. The gate is one tech,
CCC_FTLEcon, and Zuul cannot research it at all. 20 routes and 6 trade sectors by
turn 4; 21 by turn 13.
SPY. Lane W3: "no lane has identified which UI produces a spy-program entry." It is
the fleet panel's Special menu, and the reason nobody found it is that the ship a spy
docks with is the Cruiser REPAIR AND SALVAGE mission section -- nothing in the UI
calls it a tender or mentions spies. Prediction S1 holds: the container grows at Build
Spy while the craft is still docked (tdep=-1, atto=<tender>), so no enemy colony and no
asteroid belt are on the critical path, which is what every earlier cost model assumed.
THE MEASUREMENT. With 21 routes, 6 sectors and 1 spy craft live, lane H's eleven entry
probes report the four outer tail callees entered exactly once per turn, as always, and
SpyManager::Slot13RngCallee, TradeManager::Slot13RngCalleeA and CalleeB entered ZERO
times -- this turn and across all seven instrumented turns, every probe installed=true.
The RNG ledger and the standalone's generator model do NOT need extending on account of
either container being non-empty. The next condition is active contents, not present
contents: tsnumflt=0 on every sector and spyon=0 on the spy.
WHAT ELSE FELL OUT. The trade-route vector is torn down and rebuilt every turn inside
ServerTradeManagerImpl::vslot9 (lane V2's phase-23 call 5 of 8, previously "draw-free"
and unexplained) -- an agreement, dropped rather than re-minted, as is the AI2 growth
helper. Two addresses are minted, both trapped live and both `mapped` not `verified`
because ReVa was unreachable: ShipAction_BuildSpy 0x00789620, a sibling of lane B6's
stack-built-fptr-table entry 0x120 bytes away, which is why no call-graph sweep ever
found this writer; and ServerSpyManager_CreateSpyCraft 0x008383c0.
And a correction with teeth: `spies2` is 0 in all 28 systems of a save that DOES have a
spy. The natural reading of lane W's count-0-in-11-saves was "no save has ever had one".
That reading is dead; spies2 is not the spy list, or it only fills for a deployed spy.
The research click path is written down for the first time (§4): clicking a tech node is
a PREVIEW, the bottom-left button confirms, Esc leaves without confirming, and the tree
pans only on a right-drag of about 600 px. That, not the tech cost, is what stopped
three lanes.
Saves: human-turn{5,8}-traderoutes, human-turn11-spytechs, human-turn15-spyprogram --
all --strict clean, 0 errors, 0 warnings.
clean_room_check OK, host ctest 55/55, CT111 shim cross-build OK on a fresh build directory, all
three as separate commands. The deployed instrument (par4) differs from the committed source only
by two RVA literals that the named constants resolve to identically -- said here rather than left
for a reader to find. Also flags that main moved under the branch, so the header must be
regenerated at merge, not hand-resolved.
CB pinned the seeds and got d59bb9f2 three times; this lane left the seeds free, watched client
512's single research tie-break draw resolve with a different number of rejections in each process
(1, 3, 1 words), and still got d59bb9f2 three times. Different experiments, agreeing in a way that
constrains the mechanism: whatever maps that drawn word onto a research target is NOT a uniform
index into a six-member shortlist, or three unpinned runs agreeing would be 1-in-36 on top of CB's
1-in-36. One line resolves it -- log the chosen tech id beside the draw in a probe on 0x006a8390,
whose cl_RandRange bound IS the shortlist size the k question is about.
Adds the lifetime-census result: the three AI clients arrive at their first turn 9 / 411 / 421
words into their streams while the human's generator is at word 0, and client 32 started its turn
at block index 9 in one process and 11 in another FROM THE SAME SAVE -- the rejection loops it runs
during Prepare Turn resolve differently under different seeds. So a client's generator position at
the start of a turn is not a function of the save either.
Also records what pinning the seed showed (the same three words, and the oracle bytes unchanged --
so every one of those words is a draw whose result never reaches the save, measured directly for
the first time), the facade call-site attribution that names client 512's single draw as the
research-target tie-break at 0x006a8495, and one observation this lane could NOT resolve: three
fresh processes on turn1-state gave the same autosave although 512's stream demonstrably differed,
which does not reproduce lane L5's three-different-files result on that pair.
The hypothesis under test was the lockstep discipline: that each run of an AI client consumes a
fixed number of draws regardless of the path it takes, so a reimplementation could keep the
generator aligned with the right COUNT and order of draws while getting the decisions wrong.
It is false, and it fails at four scopes. Measured with a new bracket on
StrategyClient::OnResumePlaying over the per-client generator at +0x134, six runs across VM140 and
VM145, five fresh processes; every unpinned run's autosaves are byte-identical to the published
oracle, so the instrument is behaviour-neutral (rules 19 and 26 both discharged).
across clients turn2->turn3: 3 / 0 / 0 words for AI players 32 / 496 / 512; human 0
across turns client 32: 3 words on turn 2, 7 on turn 1
across processes client 512 makes ONE cl_RandRange call on turn 1 -- the research-target
tie-break at 0x006a8495, phase 18 -- and it cost 1 word in one process and
3 in another, because RNG_NextInt is an unbounded rejection loop
per site RNG_Chance costs ZERO words at p<=0 and p>=1
Twenty-one live draw sites in an AI turn, in twelve functions (plus two provably dead ones); two
fired on the reference turn, three on turn 1. Only three are unconditional, and all three only
given that their enclosing function was called. Six of client 32's seven turn-1 words come from
the ship-design composer 0x006ad700, which is also where the only loop-carried draw lives.
Also: cl_RandFloat 0x00579c70, a third cl_* RNG facade, found twice independently. It reaches
RNG_NextFloat by a TAIL JUMP, so no rel32 sweep for the entry points can see it -- which is why
ai-turn-logic.md 5's 'zero NextFloat calls from the AI module' reads as true and is not. All 29
call sites of the three facades are inside the AI band: the cl_* RNG facade is AI-only surface.
Positives for the engine: the AI draws from nothing but its own client's generator (foreign_words
0 on every bracket), the human client draws nothing at all, and the per-turn cost is single digits.
Rung B is unaffected. Rung C needs the decisions.
C5b confirms C5a: pinning the AI client seeds to an earlier run's makes the creation
turn reproducible. Three processes, each drawing its own three seeds, all pinned to
C3's, all producing d59bb9f2... with identical gates (including player 512's target
282, the value no other run has produced) and identical element records.
The only word that differs anywhere across the three is word 3 of list 23's unnamed
Population body. Three runs with byte-identical autosaves cannot differ in a word the
applier reads, so that word is noise -- localised using the pinned pair as an
instrument, which is what a control on a k>1 workload is for.
Two agreeing is a 1/k coincidence; three is 1/k^2.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
Canonical pair turn2->turn3: the complete block set, the three heap payloads no
previous capture could read (route [272], list-10 [1728], the 24-byte Population
body), the three AI client seeds, and both output autosaves -- byte-identical to the
published oracle AND to this lane's own hooks=off control, so the stream and the save
come from the same run and the instrument did not change the turn it recorded.
Creation turn turn1->turn2: three runs. Pinning the AI client seeds to the values an
earlier run observed made a DIFFERENT process reproduce that run's block -- including
the research pick that varies -- and its autosave byte for byte. The workload three
lanes could not reproduce is reproducible given the seeds.
Two corrections to lane L4's list-23 reading (no trailing int; the body is not
turn-dependent) and one to my own list-5 record, the latter found by lane RB while
consuming this capture.
Format: JSON (raw words are ground truth, decoded is a typing) plus lane RB's own .tcb
grammar with the heap payloads filled in, so RB's reader consumes it unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
CB's VM146 capture goes through the JSON->tcb adapter and the replayer unchanged and reproduces
this lane's canonical result from a separate run on a different guest: 108 -> 62, closed 46,
regressed 0, ModCount 24. It carries the first AI seeds any capture has held (32/496/512), and
its deep dump closes two gap rows: list 8's route is [272] and list 10's vector is [1728], a
ship the input save already contains.
sots_turn --turn-commands puts /Sim/ModCount on the original's 24 with zero residual, closing
the one leaf that has been unreachable from a save all campaign. Canonical pair 108 -> 62,
closed 46, regressed 0, fresh build directory.
The .tcb capture format (line-oriented, parser-free, '?' for a field the instrument could not
read, per-client AI seeds), a converter from lane L4's shim dump, and an adapter from lane CB's
JSON capture -- CB's stays the capture of record, .tcb stays the engine's input, and the two
paths produce byte-identical replays.
A falsified prediction paid for itself: the first run regressed two leaves because list 5's
element is decoded in MEMORY order, and the memory order of the rates frame is NOT its wire
order. Memory member 1 is wire member SRsc; six members unread. Lane CB's decoder has the same
defect and should drop its list-5 record.
Two new addresses (the second and third gate-loop heads) in ghidra/addresses.d/lane-rb.json.
QEMU's command line contains ifname=tap141i0, so pgrep -f on the tap name matches
the VM alongside the capture. Stopping the tcpdump that way SIGTERM'd VM141.
Nothing was lost (all artefacts were already off the guest and it restarted with
a clean volume) but it is a plug-pull on an exclusively-held guest. Use
pgrep -x tcpdump.
Two processes, same workload. Phase 18 tries three producers; only ONE of the
three AI players reaches the candidate walk at all, which is why the other two
are stable across every run of both lanes -- different code path, not better luck.
For that player the candidate stream is ONE entry, {2, 12}, in BOTH runs -- a
category, not a tech. So arrival order in the candidate vector is not the
mechanism (a vector of one has no order), and the three-arm fallback never ran
(both probes zero, both runs). The variation is inside the resolver that turns a
category into a tech, and it produced XNC_TrnsMorr2 (techId 288) in one process
and XNC_TrnsHum2 (techId 282) in the next.
k is nameable from the shipped tech data: XNC_ROOT allows six tier-1 techs at an
identical 2000 RP, one per species, each allowing exactly one tier-2 successor --
the six XNC_Trns<Species>2. Four of the six have been observed across six runs
between lanes L4 and L5, and their costs differ (13000-30000), so the resolver is
not ranking by cost; it takes whichever member of the available set it reaches
first.
Bonus rule-19 result: run R2's autosave is byte-identical to the hooks=off control
of the same workload. Twenty detours installed, same tiebreak, same bytes -- the
only free variable in the whole turn is the tiebreak itself.
Still open and flagged: BIO_GnMod, the one observed value outside that family.
Seven more addresses in ghidra/addresses.d/lane-l4.json; the eighth collided with
lane AI4's cl_SetResearchTarget and was dropped with the agreement recorded.
Two results from the same VM session, both of which needed a workload the
corpus cannot supply.
CDiff, played forward. ref-turn2 loaded and 49 End Turns driven through the UI
helper to frame 51, with the entry hook emitting one record per turn:
50 calls, frames 2..51, EXACTLY TWO STORES
frame 2 -1 -> 0
frame 50 0 -> 1 <- the modelled tier transition, at the modelled frame
and 47 turns between them on which the writer ran and wrote NOTHING
predict_path was computed at entry from the transcribed threshold table on all
fifty turns and agreed with the cdiff region on every one. Frame >= 100 is still
a code read and is not claimed as a measurement.
The AI seed probe (asked for by the coordinator, ranked above CDiff). Hooks on
Mars::RNG::Seed and StrategyApp::RunAI, two launches from turn1-state, load
only. Every AI client seed differs between processes -- net 32, 496 and 512 all
move -- while the record structure is identical and one Seed call with seed=0
produces a byte-identical state in both runs.
So the turn1-state -> turn2 nondeterminism is a SEED effect, not the ordering
effect predicted, and the 'one of three varies' observation is explained by two
of the three empires having a research pick that is robust to the stream. This
falsifies lane AI1's 'every draw from the static generator returns 0', which
that lane had explicitly flagged as arithmetic rather than measurement.
Where the seed comes from is NOT established; the finding names the one hook
that would settle it and the six values it must reproduce.
VM140 left as found: the 8-file save set with its oracle bytes intact.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
findings/subsystems/ai-order-capture.md -- two workloads on VM145, every submitted
TurnCommands block dumped at the batch applier, plus sixteen pass-attributed entry
probes on the task bodies and the emission gates.
Headline: our emission model reproduces both real blocks exactly, list for list and
element for element, and both turns land on the measured ModCount of 12. What it did
not have: a list-23 element on every AI turn (the first element ever observed in the
free half of the cost table, and it really is free), client-allocated ids travelling
inside the commands (design 18, fleet 34 -- neither in the input save), and build,
rates and population all naming the same home system.
Two predictions falsified, both usefully: the batch is n = playerCount = 8 with the
four monster factions holding untouched slots, not n = 4; and the fleet order names
the fleet the client has ALREADY created, not the one in the save.
AITRaid's pass-0 question stays open and now says why -- the task never ran on either
board, so the list-16 zero is 'never entered', not 'entered and silent'.
Rule 19: the ref-turn2 control passed byte-identical to the published oracle with all
seventeen detours installed. Separately, the turn-1 workload is NOT reproducible --
three runs, three autosaves, differing in exactly one field: the research target of
the AI player that owns nothing.
ghidra/addresses.d/lane-l4.json: 9 entries (8 IAITask::Execute bodies + the list-16
order method). Raw logs and the two divergent autosaves in verify/results/shim/aiorders/.
Lane SV recovered the script-object subsystem statically and predicted that
SVSOSwarmQueen::RegisterHives takes one strategic-generator word per new hive
inside StrategyServer::BeginProcessTurn, which runs inside lane Z's autosave
bracket and outside both turn drivers. Nothing had ever been hooked in that
interval. Measured on VM140, and it is right.
turn 1 -> 2 (hives created) BeginProcessTurn 2 ProcessTurn 20 residual 2
turn 2 -> 3 (hives exist) BeginProcessTurn 0 ProcessTurn 19 residual 0
Two instruments that share no code path agree: the region ledger reads
170 -> 172 across RegisterHives, and the return-address draw-site table gains a
row at 0x00527714 (NextInt, 2 calls / 2 words) which is absent on the next turn.
The draws produce NextQ 30/28, TickHives' slip takes them to 31/29 -- exactly
turn2-state.sav -- and the next turn's slip gives 32/30, exactly turn3-state.sav.
So tail-rng-ledger.md's "all of it inside ProcessTurn, residual exactly zero" is
correct for every turn it measured and false as a statement about the code. The
interval a standalone must reproduce starts at BeginProcessTurn.
Also closed or corrected:
* LO/HI read live rather than fitted: NextQ = frame + 20 + NextInt(10),
inclusive; the TickHives gates are 10 (a frame floor), 5 and 3, so no queen can
spawn before frame 11 on any save.
* CDiff's threshold scan re-read independently: the tier can only ever be 0 or 1,
and "entered and stored nothing" was observed live and distinguished from
"did not run" (method rule 20).
* SnLv measured for the first time: Spica reads AFlags 0 with SnLv 0x200, so the
sensor branch is what refreshes it -- nvo-tshn-visible-owner.md §6 goes [H] to
[V]. ComputeContactLevel's documented "else 1" names one of four return tails;
the observed non-visible level is 2.
* Rule 19: the oracle reproduced byte for byte with all five new detours live,
and again with four watchpoints armed on top.
* turn1-state -> turn2 is not deterministic (lane L5 owns this). Two more runs
here make it four distinct outcomes over six runs, including two DIFFERENT
hooks=off results, and the strategic generator is provably not what varies.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
Four float constants in ComputeBudget have a width a C++ port gets wrong by
default, and the corpus exercises the boundary of exactly one. That one is now
measured against the running game, with a control build that must fail and does.
savings interest (double)0.01f boundary: treasury a multiple of 100 IN CORPUS
debt interest (double)0.15f boundary: a negative treasury not in corpus
research yield (double)0.85f boundary: research money mult of 40k not in corpus
the three ResMod summed in f32 boundary: two of three non-zero not in corpus
Three constants sitting beside those, in the same expressions, are EXACT doubles
and must not be "corrected" -- so "widen every literal" is its own defect and the
only safe procedure is to read each operand. Same pattern elsewhere in the chain:
ComputeOutputFromRates multiplies by an exact 1.5 then a widened 1.2f two
instructions later, and NormaliseOutputRates holds 1e-4 at BOTH widths.
Live result (VM146, turn1-state.sav, three runs): the game pays 499 interest on a
treasury of 50,000 and 380 on 38,100; the exact decimals pay 500 and 381. Every
divergence in the control build lands on a multiple of 100 and nothing else
diverges at all. Coverage stated as distinct states, not calls: 5 distinct
treasuries, 2 on the boundary -- against the earlier green run's 20 distinct
states, none on a boundary.
BANKRUPTCY_PROTECTION_LIMIT_FACTOR read live: 3.29999995 = (float)3.3. Its file
image is zero because the loader fills it at run time, so lane PL-3 could read the
width and had to assume the value. The assumption was right and is now measured.
Falsified: the difficulty-mods record does not sit inline at ServerPlayer+0x36c;
that field is a heap pointer on all eight players. Recorded as a hypothesis with
the measurement, not as a fact.
Second finding, from the rule-19 control: turn1-state -> turn2 is NOT a
deterministic pair. Three runs gave three post-turn autosaves differing in exactly
four leaves -- one Singularity shadow empire's research pick and the derived
checksum. Two of the three runs carried identical hooks, and the un-instrumented
run was a third value, so this is the game and not the instrument. The
determinism oracle stands for ref-turn2 -> turn3 and does not generalise to its
neighbour; no lane should use this pair as a byte-match oracle.
TShn is refreshed to Frame for every (system, player) that satisfies ServerSystem::IsKnownTo
0x00746390 -- IsVisibleTo OR (2-bit sensor contact at ServerSystem+0x24 AND CCC_AdvSens). Not
AFlags alone, which is why lane E3 could not fit it. The writer chain was confirmed live, frame by
frame, from a hardware watchpoint on Spica's NVO node; the refresh runs twice per End Turn (driver
phase 24 and combat-done phase 25).
Also: the trade and spy containers read out of a live game for the first time (both empty, zero
traps -- the workload confirmation two lanes lacked); Player.Status's predicate named as
ReqCL != 0 && Elim == 0, with Species != 4 shown to be a corpus coincidence; and all ten command
ModCount handlers named, two of them only reachable on a turn-1 workload.
Corrects objects/layouts.md's ServerSystem PID@0x274 row and closes system-visibility-record.md 7.
Runs: build w3tshn-bb81d3d-20260908T2007Z, configs shim.cfg.w3tshn / w3mod / w3control.
Rule 19 control passed -- the armed run reproduced the determinism oracle byte for byte.
findings/subsystems/players-residual.md is the deliverable: every one of the 54
leaves on the reference pair and the 24 on pair 2 attributed to a named
mechanism, with the rung split. 53 of 54 are pass-through -- the block is
unmodelled, not mismodelled, and only player 32's Sav is a number we compute and
get wrong.
Three corrections to the record:
- T31's self-check compared its post-turn result against the pre-turn stored
value, so its 6-of-8 covered only the players whose limit never moves.
- the AI difficulty column IS recoverable from the save, by recomputing BnkEl
under both columns against the value the save carries; 1 AI + 1 non-AI on all
eleven corpus saves.
- BANKRUPTCY_PROTECTION_LIMIT_FACTOR is read fmul dword ptr, so it is a float32
in the image; the decimal disagrees at every max income divisible by ten and
the corpus' seven records land where the two agree (rule 23). formula-gaps Q1
addendum + ghidra/addresses.d/lane-pl.json (3 data entries, fragment validated
to a scratch path, no duplicate names).
verify/results/standalone/{status.json,report.txt} refreshed from a build of main
aabd8a3: the committed copy was stale at 131/55, the real number is 128/54.
T34 RecordObservedDesigns is now readable off the corpus and is NOT an intel
pass: a design's creator registers the design in its own odes, its weapons in
owep, and re-stamps otnL on its techs in otch -- odes on build, otch on creation.
Both are hypotheses until a save exists where a player observes someone else's
design.
Status stays open and is flagged as NOT identifiable: eighteen fields of the
player record split the roster the same way and only two saves carry a non-zero
value. The probe is an entry hook on W2's writer.
Joins the emission side (lanes AI1-AI3) to the counting side (A2, W2). Three
results.
The cost of applying a command is a property of its list, and the boundary is
sharp: lists 1-16 each advance ModCount once per element, lists 17-27 never do.
Four of the six prologue gates bump, one is free, and the sixth has no applier
anywhere in the application path -- its cost is unknown, not zero. The batch
applies the twenty-seven lists in a fixed order that is neither list nor offset
order, with the six gates split across three separate per-player loops at three
different points, and four of the sixteen bumps inlined into the batch rather
than living in a handler, which is why a call-graph sweep under-counts them.
Lane W2's four unnamed handler EIPs are named, and so are its two inlined ones,
and the ten measured command bumps then decompose with zero residual. Four of the
ten are the research-rate gate, one per submitted block, and one of those four is
the human's. Two are list 14, on a turn that moved exactly one fleet -- which
confirms lane AI2's P1 (an AI fleet order deposits two fleet-task elements where
the interface deposits one) from the counter side, at no VM cost.
The reference game is not what the record says. ref-turn2.sav IS turn2-state.sav;
there are THREE AI players, not one, and the two dormant ones do run -- all three
set a research rate and picked a research target on turn 1; and the four
monster-faction players submit no command block at all, which is the first direct
evidence that they have no client rather than an empty task list.
Prediction committed for turn1-state: the same 12, out of a different set of
commands -- 4 rate gates, 3 research targets, and three orders from the one AI
with an empire, which are predicted to be a new design, a build order and a
system-rates command, with NO fleet order on turn 1. The trap multiset it
predicts contains two EIPs W2 has never seen and omits three it did, so it is
cheap to falsify: one save swap on W2's unchanged watchpoint module.
Also: phase 2 of the AI's turn is Hiver-only (a fifth cross-check on the species
reading, and the reason one prologue gate has never been observed set), phases
29-33 are dead because the submit latches the client before it builds the send
buffer, and cl_SetResearchTarget is AI-only surface with exactly one caller.
14 addresses in ghidra/addresses.d/lane-ai4.json; validated to a scratch path,
1,138 -> 1,152, no duplicate names.
findings/subsystems/population-growth.md -- ServerSystem::GrowCivilianPops
0x00754220 read byte for byte, its whole chain, and Ship::RepairCost
0x00815180.
The headline is a correction to the brief's premise. The pass is NOT gated
on imperial carrying capacity. The whole system's civilian delta is clamped
to 20,000,000 -- POPTYPE[1]+0x08, an int64 literal in the executable -- and
on both reference pairs that clamp decides the value: the uncapped delta is
7.5x it and the capacity headroom 25x it. The imperial capacity is pinned
at exactly Size x 1e8 from the corpus alone, by two independent behaviours
of one colony across three turns, with no data files.
Two boundary corrections, both of the rule-17 shape. GrowCivilianPops is a
loop over group types whose back edge lies outside every decompiler `if`,
so it reads as straight-line code if you stop at the first `ret`; its real
end is 0x00754b59. MaxPopGeneric ends at 0x0074a6cd, so the 0x0074a6d0 that
lanes N and E1 both cite for the capacity-surplus pair is a different
function.
A table correction with teeth: InitPopTypeTable never writes the group
ceiling at +0x28/+0x2c. The CRT static initialiser at 0x009abe20 does, to
INT64_MAX, and nothing else touches it -- so the clamp that reads it is
always a no-op. A reader who opens only the obvious initialiser sees zero
there and would cap every carrying capacity in the game at nothing.
Lane N's whole table is otherwise reproduced independently from the
six-register fxch rotation.
output-turn-path.md: out[6] is NOT the ship-repair demand. 0x007460b0 sums
0x0081f8c0, which gates on the design's carried-population bit and computes
GroupIncome over the ship's own Population -- so it is the income of
population carried in slaver and colony hulls, a slot the engine already
had under a name nobody had connected to it. Corrected in place, with
lane-c3.json's three unread stubs superseded by lane-g3.json's read entries.
Ship::RepairCost is unexercised on the corpus and that is a measurement,
not an absence (rule 20): the independent colony keeps a ten-ship fleet in
orbit over Koa'Vo on both reference pairs and its Sav closes exactly with
the demand taken as zero, which it could not do if any hull had a cost.
Engine side: sots-engine wip/growth ed6602e -- reference pair 78 -> 81
closed, 0 regressed; pair 2 36 -> 39 closed, 0 regressed.
Measured over all eleven saves with state_checksum, not derived:
* the reference pair posts TWO events (turn1->turn2) and THREE (turn2->turn3),
and only two players in the whole corpus ever hold an event -- the human and
the one AI empire that owns colonies. The dormant shadow empires pick research
targets every turn and still post nothing.
* order within a player is readable off the ids: the build pass posts before the
research pass. Ids are per player, so no cross-player order is observable.
* the event type is the EvImg string and it is composed at run time --
EVENT_ENEMY_INCOMING_Human carries a species suffix, so the type space is not
an enumeration.
Two corrections in place (rule 11):
* the turn PostEvent is handed is the FRAME, not ModCount. turn2-state.sav has
Frame 2 and ModCount 12, and every event it carries is in bucket EvTurn=2. It
is the post-increment turn: a turn run from a save at turn N posts into N+1.
* the EVENT_NO_RESEARCH gate: 0x00584e50 is TechTree::CollectResearchedTechs,
not a ListAvailableTechs, and the middle test is "nothing was researched on
this turn or later" -- not "no affordable tech". zuul-turn23 exercises it: the
human posts RESEARCH_COMPLETE on turn 22 with no no-research event that turn,
then NO_RESEARCH again on turn 23.
ghidra/addresses.d/lane-ev.json records the gate at 0x0089162a with the argument
order re-read from the instruction stream. Validated with tools/gen_addresses.py to
a scratch path (1121 entries, no duplicate); the shared header is NOT regenerated.
tools/standalone_report.py gains --engine-arg (repeatable), so a lane can feed the
standalone the operator inputs a save does not carry -- the data root, the AI
roster, which blocked phases may commit -- instead of hard-coding them. Every run
records what it was given, in the report header and in status.json.
Closes five of lane AI2's open items and corrects two published claims.
The stepping order: StrategyServer::ResumePlaying 0x007ddc90 walks the player
array in INDEX ORDER and raises SEResumePlaying at each live player; the app
callback StrategyApp::OnClientEvent 0x00838e10 delivers it inline for humans
and appends it, deduplicated, to the pending queue for AI players. So the AI
players are stepped in save player order, each at most once -- computable from
a save with no live measurement. AI2's search missed it because 0x00b29f98 is
not a pointer to the StrategyApp, it IS the StrategyApp: the enqueue writes the
absolute member address 0x00b29fb4 and never materialises the object base. The
enqueue also has zero direct callers and no vtable slot -- its address is stored
into StrategyServer+0x170 by CreateGame. Lane B6's third blind spot, twice over.
The two passes: `pass` is a tier index, not a plan/act switch. 0x006abb2a picks
between two per-candidate quota fields -- tier 0 takes +0x10, tier 1 takes +0x14
-- and the hub loops `for (i = 0; i <= pass; ++i)`. Every order-emitting exit is
gated pass == 1 (0x006bbd50, 0x006c16c0, 0x006cea50), so pass 0 claims each
task's minimum force in priority order and WRITES NOTHING. That halves the
ModCount arithmetic.
Corrections:
- AI2 §4.2: the nine "no order method" tasks are not planners. All nine emit
orders at depth 4-9; the depth-4 cut hid it. AITColonize reaches list 7 and
AITBuildPoliceShips reaches list 3, which is what their names promise.
- AI2 §3: the two priority overrides' flag polarity is inverted. The tunable
applies when bit 0 of +0x4 is SET, and "committed" is not a supported name.
- AI2 §10.6: the .data invade tunables have no loader. 650 and 750, image
constants, exactly one reader each and no writer anywhere.
Also: slot 12 named (a preemption permission, 0x006a8d20), slot 13's consumer
found (0x00696620, a range budget -- and the Zuul are exempt, a FOURTH
independent cross-check on AI2's species reading), slot 11's dispatch located.
ServerPlayer+0xf9/+0xfa -- the two bytes that decide whether a player is
AI-controlled -- sit in a hole in the serialised layout and are NOT in the save;
their writer is unfound and is the biggest remaining hole.
Static only; nothing here has run under an instrument. 160 indirect call sites
inside the AI closure are unresolved, so reachability is still a lower bound.
Four predictions with falsifiers in §7.
ghidra/addresses.d/lane-ai3.json: 15 entries, 1,105 -> 1,120, no duplicates,
validated to a scratch path.
Multiplayer: two clients on one guest, joined by typed IP and by LAN browse, launched a
2-player game and played two turns in lockstep. 44,319 packets captured outside the guest,
ZERO to any GameSpy port. Availability check fails open exactly as lane G2 read it; Join
Manually is enabled with every gamespy.com name dead, falsifying G2's own caveat (a). The
shipped MOTD is fetched live from kerberos-productions.com and tells players to host in LAN
mode -- the developer's own statement of the same finding.
Watchpoints: a new shim module arms DR0-DR3 from StrategyServer::ApplyAllTurnCommands.
ModCount takes exactly 12 writes per End Turn (lane A2's prediction, confirmed twice, both
predicted addresses exact); Frame takes exactly one, from BeginProcessTurn+0x2a, settling the
ModCount-vs-Frame naming in A2's favour. The Player.Status writer between tail phase 31 and
the autosave EXISTS and is StrategyNetworkClient::OnMessage+0xa15 -- correcting lane T2.
Rule 19 control: the armed run reproduced the determinism oracle byte for byte.
rcex: closed from the corpus alone. It is sixteen 4-bit per-player counters; nibble p is set
to 1 on the turn the system enters player p's AFlags and ticked to 0 the next turn. 7/7
across two different games.
