From 0f750488495419a1f0bf1902bd8b7048269b08e5 Mon Sep 17 00:00:00 2001 From: alex Date: Tue, 8 Sep 2026 20:35:31 -0400 Subject: [PATCH] AC: prediction addendum from the static gate decode, before any active-state measurement --- docs/AC-predictions.md | 87 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) diff --git a/docs/AC-predictions.md b/docs/AC-predictions.md index 06559c6..7ea2064 100644 --- a/docs/AC-predictions.md +++ b/docs/AC-predictions.md @@ -138,3 +138,90 @@ is wrong and the path is short. Symptom: the menu entry is enabled and the actio a config that reports a confident nothing). - **A control that does not agree with itself is not a control** (rule 26). The `watch=on`/`watch=off` pair goes on `ref-turn2.sav` in two fresh processes before any workload number is trusted. + +--- + +## 3. Addendum — written after the static decode of the gates, before any measurement of an active state + +The gates on all three inner callees were decoded out of the instruction stream (`sots.exe`, +image base 0x00400000) before the workload was played. That changes what is worth measuring, so the +new predictions are written here rather than fitted afterwards. **Nothing below had been measured +when it was written**; the only live readings so far are the VM141 determinism-oracle control +(matched the published hashes exactly) and the shim banner showing the watchpoint module armed. + +### The decoded gates + +`Slot13RngCalleeA` (Q, 0x00820ca0) and `Slot13RngCalleeB` (R, 0x0088b440) are called **directly** +from `ServerTradeManagerImpl::vslot13` (0x0088ef80) at 0x0088f036 and 0x0088f042. That function +does **not** iterate trade routes or trade sectors — it iterates +`StrategyServer+0x64..+0x68`, the **fleet** vector, and for each fleet requires: + +- `StarFleet+0xa0` (`LocID`) to resolve to a node whose kind word (`node+0x14`) is **2**. Kind is + set by the `StarMapNode(int)` ctor: `StarSystem` passes 0, `StarFleet` 1, **`TradeSector` 2**. So + the fleet must be located *at a trade-sector node*, not at a star. +- the fleet's `Pos` (`+0x18`) to be **bit-equal** to the sector's `Pos` — arrived, not in transit. +- `sector+0x90` (`tscr`) to have the **fleet owner's player-index bit set**; +- and if `sector+0x8c` (`tsct`) also has that bit, the fleet to carry `FtFlg & 0x800`. + +`SpyManager::Slot13RngCallee` (P, 0x008408e0) is called from `ServerSpyManager::vslot13` +(0x008877b0) at 0x00887af2, behind: `deat != 0` (deployed at a real system), `sdet != -1` +(**already detected on an earlier turn**), `turn - sdet >= 3`, the system still owned, and owned by +someone other than the spy's owner. + +### P6 — the trade half is structurally closed to both real players in this save + +`tscr` is **252 = 0b11111100** on all six sectors of `human-turn15-spyprogram.sav`, and the save has +eight player slots: index 0 `re` (human), index 1 `The Eternal Empire` (AI), and indices 2–7 the +six `NPC = true` slots (`Spengler` ×2 rebel-AI, `Alien Menace`, `Peacekeeper Enforcer`, +`Von Neumann`, `Independent Colony`). **252 is exactly the NPC set and excludes both real players.** + +So I predict: **parking a player-owned fleet exactly on a trade-sector node — even flagged as a +raider — will NOT make Q or R fire.** Trade raiding is an NPC mechanic; `TRADE_RAID_ODDS_NPC` and +`TRADE_RAID_ODDS_REFUGEE` exist for that reason and `TRADE_RAID_ODDS_PLAYER` is what a *raid against* +a player pays. + +Falsifier: Q reports `calls >= 1` on the turn after a player fleet is parked on a sector node. +Symptom: non-zero `calls` on the `TradeManager::Slot13RngCalleeA` row with `installed = true`. +That result would kill the `tscr`-is-a-player-mask reading and reopen the ledger. + +This is the experiment worth running because it separates two explanations that seven turns of +L3's workload could not: "no lane ever parked a fleet on a sector node" versus "players are excluded +by `tscr`". The AI's own `Freighters` fleet (`LocID 816`, the id of trade sector `TradeID 816`, +`Pos` bit-equal to that sector's) **already passes the node-kind and position gates** and is still +rejected — which is the first evidence for the mask reading and is why P6 is stated with confidence +rather than as a coin flip. + +### P7 — the spy half WILL make the tail draw, but not through an entry probe + +This is the prediction that matters most, and it is the one L3's instrument could not have seen. + +The `sdet == -1` arm of `vslot13` (taken at 0x00887856 → 0x00887c5b) is the **detection roll**: +it calls `FUN_0081f570(spy, system, owner)`, tests `FUN_00743f80(system) & 1`, and on that bit rolls +`FUN_008e6dd0(StrategyServer+0x16c /* RNG */, spy->sdo)`, then stamps `sdet = turn` and posts +`EVENT_SPY_DETECTED`. That roll is **inline in the outer callee**, not inside P. + +But it is unreachable today because the gate *before* it is `deat != 0` at 0x0088781d, and the +corpus spy has `deat = 0` (`tdep = -1`, `spyon = 0`, docked to its tender). + +So: **deploying the spy is predicted to make `OnAllCombatDone_Tail` consume more RNG words per turn +than it does with the spy docked, while all three inner-callee entry probes still read 0.** +Roughly one extra draw per deployed spy per turn, conditional on `FUN_00743f80(system) & 1`. + +If that holds, the honest headline is **yes, the tail draws under active contents** — the RNG ledger +and the standalone's generator model do need extending — and the reason seven instrumented turns +said otherwise is that the probe table measures *entry into P/Q/R* while the draw lives in the +outer function. That is rule 20 pointing the other way: instrumenting the entry is necessary and +was not sufficient. **The primary measurement is therefore the `side.rng` word delta on +`OnAllCombatDone_Tail`, not the probe counts.** + +Falsifier: the tail's word delta is unchanged after deployment. Symptom: identical +`rng.after.words - rng.before.words` on the tail hook across the docked and deployed turns of the +same save lineage. + +### P8 — where the spy can go + +`ARes2` is the asteroid-belt field, and the only non-own system with a belt in this save is +**Hitomi** (idx 27, id 480, `ARes2 2531`), owned by player index 7 `Independent Colony` +(`AFlags 128`). Not the AI. So the deploy target, if one exists at all, is Hitomi — two fleet moves +from the tender's berth at Epsilon Eridani via Aldebaran. If Hitomi is undiscovered or unreachable, +the active spy state is out of reach in this save and I will report that rather than infer around it.