az-turn23-tarka-comraid.sav is 89,285 B not 73,385 (that number was the
turn-11 file's). Both saves are now on the guest as well as in the repo.
az-turn11-16destroyers.sav is the same game with the 16-destroyer fleet
still alive and Commerce Raiding already in hand - it saves ten turns of
play for anyone retrying the player's own raider, though the AI's first
routes do not appear until turn 16.
Static half, verified and correcting two published sentences:
FUN_00820af0 short-circuits on the ROUTE OWNER being Hiver (0x00820bc2),
on the RAIDER's crew species being Hiver (0x00820bd7), and only then on
SpeciesDef+0x144 (Human, Zuul). The campaign's 'Human or Zuul draws
nothing, every other species draws' is incomplete on both sides. And the
short-circuit sets frac = 0.0, not 1.0 - corrected in ag.json in place.
Live half NOT taken. hooks=off throughout; no instrument was armed. The
workload was built to within one conjunct: az-turn23-tarka-comraid.sav is
the corpus's first Tarka empire, has Commerce Raiding, three AI routes and
five AI Tarka fleets parked on sector nodes with Pos bit-equal, two of
which clear G0-G4. The failed conjunct is G_B3 - the qualifying raiders
own every route, so relation-to-self is 3 and B empties its candidate
list. The next workload is named from that: give player 0 a route sourced
in sector 768, where the AI raider already stands.
tscr reads 127 on this map, not 252/253 - the mask is not a corpus
constant and my own P3 gave the right count for the wrong reason.
BP has a per-PROCESS input (two pinned processes disagree); this lane has a
per-HISTORY input (two load processes agree with each other and disagree
with the continuation). One datum against the ASLR reading as stated: the
exe base was identical in all five VM145 processes (0x00f40000, delta
+11796480), so any image-base hypothesis has to name which allocation it
means. Probe 3's ledger taken twice on ar-oracle-A-pre - once by
continuation, once by load - now speaks to both.
Both committed predictions are wrong, in different and useful ways.
1b FALSIFIED: ar-oracle-A-pre.sav + load + one End Turn gives 4c356f59...,
not 7a8b3d5e... - and gives it byte-for-byte in two fresh hooks=off
processes. 23 leaves apart from AR's continuation, 17 of them one AI fleet
(Zeta Fleet V moved in the continuation and stayed put after a load). So
AR's second hash may NOT enter determinism-hashes.txt as a load->turn pair;
the load form is certified instead. The resave canonicalisation is
exonerated: the pre-turn round trip differs in exactly one leaf,
/CD[1]/NPrvVa, +5.00 per load - which also corrects determinism-oracle.md's
"nothing else varies".
Probe 1: the two files DIFFER, and /Sim/RNG, /Sim/trdmgr and every player-0
fleet are identical as predicted - but ZERO TechTree and ZERO ResTNm leaves
differ. Both processes picked BIO_GrvAdpt. The 144 leaves are a combat at
Venkman: Auto Resolve Peacefully means the human commits no ships, not that
no combat occurs, and the planet's defences killed two raiders in one
process and one in the other.
The producer run (config already on the guest, no build) names why the pick
agreed: producers A and B both returned null, Player[32] reached the
candidate walk, and candidatesTried=1. The outcome set is a singleton by
COUNT, not by producer gate - so ResTNm == '' is necessary for research
exposure, not sufficient.
VM145 restored byte-for-byte and released.
shim.cfg back to hooks=off, binkw32.dll back to the pre-BP file, both autosaves
restored byte-identical, game process left not running as found.
ad-turn27-two-raiders.sav is deliberately left on disk, so the Load-dialog rows
have moved on this guest.
P1 falsified. Two processes with identical pinned AI client seeds produced
different turn-28 autosaves from ad-turn27-two-raiders.sav, so a per-process
input other than the seed reaches a rich turn and C-exact is false on this
state. Resolution trigger, handed back rather than chased.
But the pin did almost all the work. AD's unpinned pair differed in 94 leaves
across designs, ship records, money, both build queues, ModCount, NumFlts,
DesignIDs[] and FleetIDs[]. This pinned pair differs in 35 of 61147, and all 35
are one transposition: fleets 1970 and 1986 exchange their entire contents.
Every decision leaf is identical.
The command block says the same from the input side. Runs L (unpinned) and A
(pinned to L's observed seeds) wrote BYTE-IDENTICAL autosaves, which gives a
noise mask no previous lane could build for this state; against it, A and B
differ in exactly three words - one fleet-move fleetId and two systemIds - and
list 10's fleet ids are in the same order in both. The id counter is
deterministic; what varies is which newly formed ship group each id lands on.
Also measured: the save has seven non-human players and the engine builds THREE
AI clients (RunAI fires 3x, ids 32/496/512); the four NPC factions get no client
and no seed.
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.
Probe 2 of the 2026-09-09 resolution: pin the AI client seeds on
ad-turn27-two-raiders.sav -- the richest AI turn the campaign owns, and the one
whose hooks=off control varies in 94 leaves -- and run two fresh processes.
Committed prediction: the two autosaves are byte-identical and state_checksum
prints IDENTICAL over ~67k leaves. If they differ, reading 3 is alive on rich
states, C-exact is false on the turns that matter, and that is a resolution
trigger rather than a lane result.
Also records, before any run: the exposure facts for all eight players read off
the input save, and the observation that four AI players enter this turn with
ResTNm == '' while contributing none of AD's 94 leaves -- all four have
NumOwn == 0, so 'ResTNm == emptystring names a pick turn' is necessary and not
sufficient.
Lane BQ (VM145) takes the seed-exposure predicate's first forward test.
Part 1b: ar-oracle-A-pre.sav + one End Turn from a LOAD must reproduce
7a8b3d5e... (it has only ever been reached by continuation). Part 1:
ar-oracle-A-post.sav in two fresh hooks=off processes must DIFFER, confined
to Player[32]'s research leaves, because that save carries ResTNm == '' for
the one player that can research.
Also records the exposure facts (ResTNm / NumDes / NumOwn / completions) for
every player on both inputs, and names a false-positive class in the predicate
before the run: four NPC players carry ResTNm == '' on the very turn whose
control agreed, and all four have NumOwn == 0.
The brief's gate ('Human or Zuul draws nothing, every other species draws')
is incomplete in two places, found by reading FUN_00820af0 before touching a
guest: species 1 (Hiver) short-circuits too, and the ROUTE OWNER's species is
a gate of its own. The species enum is read from the InitTable jump table as
bytes: 0 Human, 1 Hiver, 2 Tarkas, 3 Liir, 4 _NPC, 5 Zuul, 6 Morrigi.
Corpus counted against the predicate (rule 28 practice 5): 0 of 30. 24 saves
hold a Tarka AI - a drawing species - but tscr is 253 in every one, so the AI
has no Commerce Raiding and never rolls. The workload has to be built.
Tarkas chosen: the tech data gives it a 100% path to CCC_ComRaid via
CCC_FTLEcon, where Hiver has 0% on both edges.
Decides lane AG's section 3.3 final paragraph, which lane AD correctly reported
it could not separate on sector 832.
STATIC: FUN_00841700 is the writer AG's section 7 lists as not found. It resizes
the +0x0c vector to the length of the systems vector -- the container trfr indexes
-- and fills it with containingSector[system.Idx] = sector. It runs from the
deserialiser, so a loaded save has it populated. G_B1a cannot reject a valid trfr.
LIVE: four raiders parked (2 CR on sector 832, 2 DE on sector 816), probes=8.
Slot13RngCalleeA entered 4x/turn at 4 words every turn; on turn 42 the pick fired
at 0x0088b613, calls=1 words=1, and the tail cost 5 words against 4 elsewhere.
The same run carries its own control: B entered on 832 twice at 0 words.
B costs ONE word, not two: FUN_00820af0's third short-circuit is a flag word
InitTable sets only for Human and Zuul, so AG's committed 3-words-on-success is 2.
Two hooks=off processes gave byte-identical autosaves, and so did a probes=8
process -- an oracle pair and a whole-save byte-neutrality proof for the
instrument, both firsts on this lineage.
Also first firings of 0x008939ee (rule 20's case study) and 0x00820c1b.
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.
Includes the static decode of FUN_00841700 -- the writer of TradeManager+0x0c that
lane AG's section 7 lists as not found -- stated as a falsifiable prediction (P0)
with the symptom of each way it could be wrong. Also corrects the route count in
ad-turn27-two-raiders.sav: five rt records, trfr 18/16/14/20/14, not three.
One row per statically reachable draw site in BeginProcessTurn u ProcessTurn u
OnAllCombatDone_Tail, each carrying a measured firing or a decoded predicate on
save fields plus the 22-save corpus count. No total is reported: 31 rows (30
distinct sites plus one grouped SVSO row) are unread gates, and that visible
blank column is the deliverable.
Three gates decoded:
0x0082cdb8 = the addiction spread roll (Chance ADDICTION_SPREAD_ODDS 0.2f);
corpus 0 of 22 -- nadct is 0 on all 28 systems of all 22 saves. Writer found:
ServerSystem_BeginAddiction has exactly two callers, both inside vslot15, so
an INTER-EMPIRE route plus a species addict tech must seed it first.
0x0088dc43 = the spy counter-mission roll, p = cmo accumulating 0.2f per turn,
so Chance costs 0 words from the fifth turn on; corpus 0 of 22 by deat/cm.
0x0088b613 = the raid target pick. RNG_NextInt has no zero-bound early-out, so
a single-candidate list still draws -- which proves lane AC's B returned
before the draw. Failed conjunct named: the raider sat on sector 832 while
all four rt records source in 816/816/768/752. Next workload: sector 816.
Six draw sites no firing-indexed table could hold: five behind
CreateRaidEncounter's empty-candidate-list gate, and 0x00820c1b again from
Slot13RngCalleeB -- so B costs 2 words on a success, not 0.
SVSO generator closed: all 17 drawing overrides use GetGame()->+0x16c.
Rule 17 again: ServerSpyManager_vslot14 really ends at 0x0088dd2b, not 0x0088dd03.
TradeManager::Slot13RngCalleeA, entered 0 times in every measurement any lane
had taken, is entered 1x/turn once a player fleet is parked on a trade-sector
node, and OnAllCombatDone_Tail's RNG word delta goes 0 -> 1. Lane W3's open
risk is realised, not retired: the RNG ledger and the standalone's generator
model need extending by one draw site.
The gate is neither freighters nor a deployed spy. It is a fleet whose LocID
resolves to a node of kind 2 (TradeSector), positioned bit-equal to the
sector, whose owner's bit is set in the sector's tscr mask -- which the
CCC_ComRaid tech sets, taking tscr from 252 to 253 and setting ServerPlayer
CnRad. Before the tech the game refuses in as many words: 'Alpha Fleet cannot
raid trade sector.'
Control: same guest, same build, same shim.cfg.l3probe, one End Turn on lane
L3's turn-15 save -> all three inner callees 0, tail delta 0. Guest adoption:
ref-turn2 hooks=off reproduces the published determinism oracle exactly.
Corrects lane L3 §3.5 (the turn-15 save already had a freighter in service --
the AI's -- so 'freighters' was falsified before this lane started) and lane
V2's 'trade slot 13 is draw-free'. The spy half is decoded but NOT reached:
no AI system in that game has an asteroid belt, so a deploy was impossible,
and spies2 is therefore still untested and stays a rule-6 hypothesis.
Two new corpus saves; expect the coverage ratchet to break on CnRad,
tscr=253, three rt records and a fleet whose LocID is a TradeSector.
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.
TacReport in particular: TRnc is a count and TRships/TRsats/TRshipsL are ONE
interleaved loop body, not three trailing runs -- which is why two lanes could
not settle it from a flattened linear recovery with TRnc == 0 everywhere.
Also two corrections the conformance binding found: Game::CombatReport's auto
and cdst are bools and dur/cdt/cdi are floats (cdt was being read as
1070805848 instead of 1.598), and Game::CombatWeaponReport's damage quartet is
flat with float dami/damt -- the nested 'dams' frame the shape modelled does
not exist, and modelling it also inflated the coverage denominator by one per
weapon report.
FTPnts stays carried and labelled: the one item the recovery itself marks
unresolved, count 0 everywhere, element framing a property of the helper.
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.
