sots-engine/docs/AC-predictions.md

Lane AC — predictions, written before the workload was built

Rule 2. Committed before the game was started, before the first End Turn, and before any probe counter was read. Guest VM141 (sots-re-win10-b, 192.168.10.143), starting from lane L3's human-turn15-spyprogram.sav.

The question: does the strategic-turn tail draw RNG when the trade and spy containers hold active contents rather than merely present ones? Lane L3 retired lane W3's risk for populated containers; the residual condition it named is freighters in service (tsnumflt > 0) and a deployed spy (spyon != 0).

---

0. One fact from the save that changes the prior before anything is run

Lane L3's §3.5 says "every trade sector has tsnumflt = 0 — no freighters in service". Read out of the save L3 shipped, that is not true. human-turn15-spyprogram.sav, trdmgr, sector TradeID 816 (tsgridID 5):

tssec 2   tsct 2   tsnumflt 1   tsflt 2736

and the fleet with id 2736 is Freighters, PID 32 — the AI's. Its six member systems (tssys 192, 288, 304, 336, 352, 464 → indices 9, 15, 16, 18, 19, 26) are all AI-owned. The single serialized route record trdmgr.rt (tro 32, trfow 1, trto 16, trtow 1, trfr 18, trtc 10) is likewise the AI's.

So across L3's seven instrumented turns the game already had a trade sector with a freighter in service and an active route, and TradeManager::Slot13RngCalleeA/B were entered 0 times anyway. The five sectors with tsnumflt = 0 are the ones the human player owns or shares.

This does not make the experiment pointless — it sharpens it. It rules out "any freighter anywhere" as the gate before I spend a turn, and it means the surviving trade-side hypotheses are narrower: a per-player gate, a count threshold, a route-state condition (TROUTESTATUS_* is Inactive/New/Developing/Established/Shutting Down), or the raid-candidate list being the thing that is empty rather than the roll being un-taken.

---

1. Predictions

P1 — the trade half (primary)

Freighters in service on the human player's own trade sectors will NOT make TradeManager::Slot13RngCalleeA (0x00820ca0) or Slot13RngCalleeB (0x0088b440) fire. Both stay at calls = 0 on every instrumented End Turn, while ServerTradeManagerImpl::vslot13 (0x0088ef80) and vslot15 (0x0082cca0) stay at exactly 1.

Confidence: moderate-to-high, and it rests on §0 rather than on L3's stated reason. An AI freighter has already failed to trip it for seven turns; the only way a human freighter trips it is if the gate is per-player, which is possible (vslot13 may loop players) but is not the simplest reading of "entered once per turn".

Falsification and its symptom. If A or B reports calls >= 1 on the first turn after tsnumflt goes non-zero on a human sector, P1 is dead and the answer to the lane's question is "yes, the tail draws under active contents". Symptom: a non-zero calls in the probe_entries table on the post-turn Autosave record, with installed = true on that row.

P2 — the trade half, second order

If P1 holds, then either (a) the gate is not "a freighter exists" at all, or (b) it is a threshold above 1. I predict (a). Falsifier: if the callees fire only once the human side reaches TRADE_ROUTE_MAX_FREIGHTERS = 5 on a sector, (b) is right and P2 is wrong; symptom is a step change in calls exactly at the turn tsnumflt reaches 5.

P3 — the spy half

A deployed spy (spyon != 0, tdep >= 0, spyat set) WILL make SpyManager::Slot13RngCallee (0x008408e0) fire, at 1 entry per turn per deployed spy.

Confidence: low-to-moderate, and deliberately opposite in sign to P1. The reason to split them is that the spy path has a per-turn stochastic element the trade path does not obviously have — sdet ("spy detection", −1 in the save) and deat are per-spy fields that a deployed spy must have rolled for each turn, and a detection roll is exactly the shape of thing Slot13RngCallee would be. cbh, cm, cmo, ncp are all still zero on the undeployed spy.

Falsification. If a spy reaches spyon != 0 and Slot13RngCallee still reports calls = 0 on the following End Turn, P3 is dead and both containers are confirmed inert at every reachable state — which closes lane W3's risk outright. Symptom: calls = 0 with installed = true on that row while the save shows spyon != 0.

P4 — spies2

spies2 will become non-empty in exactly the system a spy is deployed at, and nowhere else. i.e. spies2 is a per-system spy list and it fills only for a deployed spy. That is the second of the two readings L3 left open, and it is the one I expect.

Confidence: moderate. spies2 sits on ServerSystem, and a built-but-docked spy has no system to belong to (tdep = -1, spyat = 0), so a container keyed by system cannot hold it.

Falsification. If a spy is deployed and spies2 is still 0 in all 28 systems, then spies2 is not the spy list and the first reading is right; the rule-6 flags on spies2, SysMem and mts stay up and the field needs a different explanation. Symptom: post-deploy save parses with spies2 count 0 everywhere while spymgr.spy.spyon != 0.

P5 — reachability of the active spy state at all

Deploying a spy in this save may be unreachable, and if so I will say so rather than infer. The engine's own refusals require a system that is not mine, has no enemy fleet present, has no spy already, and has an asteroid belt. ARes2 on ServerSystem is the asteroid-resource field (its non-zero values 1703–2531 sit inside SYSTEM_MIN/MAX_ASTEROID_RESOURCES 1500–3000). In the turn-15 save only five of 28 systems have ARes2 > 0:

idx	id	name	ARes2	owner
1	64	Ka'Palum	2061	unowned
4	112	Regulus	1703	unowned
10	208	Kam'Tara	1948	unowned, AI fleet present (Omikron Fleet II, 4 ships)
12	240	Downbelow	2172	mine
27	480	Hitomi	2531	player 576, AFlags 128, position (0,0,0)

No AI-owned system has an asteroid belt. So the textbook target — an enemy colony with a belt — does not exist here. I predict the reachable routes are, in order: deploy at an unowned belt system (Regulus is 9.01 ly from the tender's berth at Epsilon Eridani against a hull range of 9.0, so this is marginal and node travel may or may not save it); or wait for the AI to colonize Kam'Tara, where it already has a fleet, and deploy once its fleet leaves.

Falsification. If the Special menu offers Deploy Spy at an unowned belt system, P5's pessimism is wrong and the path is short. Symptom: the menu entry is enabled and the action is accepted.

---

2. What would make me wrong about the whole framing

• The outer callees may not iterate the containers that were measured. vslot13/vslot15 are entered once per turn regardless of container contents, which is equally consistent with their loop being over players or over encounters and the trade/spy containers being read further in. If so, "active contents" is the wrong axis entirely and no workload on these two vectors will ever trip the inner callees. Symptom: a static read of the gate shows a predicate on neither container.
• The instrument may not be armed. probes=11 is L3's config and is line-for-line comparable with lane H, but lane H bisected probes=11 as not determinism-neutral (the detour on probe index 8, GenerateTradeRaidEncounters, suppresses a draw elsewhere). probes=8 is the largest proven byte-neutral configuration and it still installs indices 0–7, i.e. all four outer callees and all three inner ones. I will take the primary reading at probes=8 for that reason and cross-check at probes=11 for comparability, and I will report installed= for every row rather than a bare zero (rule 20; and lane L3's own hooks=off watch=on defect is the worked example of 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.