Syplheed-Reborn/docs/re/mission-per-record-strength.md

Per-record craft strength — the measurement works, the run does not reproduce

Status: ✅ the per-record measurement is internally consistent; 🔴 it does not reproduce across runs, and that is now the blocker; 🔴 zero arrivals and zero losses in 190 s of hunting, which does not test the event-gated model.

Follows roster-to-craft-link.md: craft point at roster_base + 0x08, so a member's live strength is how many craft point at it, and an arrival should be a 0 → n transition on one record.

✅ The measurement itself is sound

tools/re-capture/wave5_probe.py counted craft per roster record every ~20 s. The first sample:

craft=170   deployed records=24/42   strength histogram [(2, 11), (8, 2), (12, 11)]

11·2 + 2·8 + 11·12 = 170, exactly the craft total. The per-record decomposition is internally consistent, and 24 of 42 records deployed with 18 holding nothing is the same shape as the previous run's 41 of 116.

🔴 But the numbers do not reproduce across runs

run	roster records	craft	deployed	strengths
link2 (earlier)	116	300	41	2, 4, 8, 18
wave5 (this one)	42	170	24	2, 8, 12

Same disc, same save slot, same launch script, same stage.

The save has not drifted — that was the first suspicion and it is refuted: content/.../game01/savedata is unmodified since 2026-08-23 16:37; only the profile .gpd files were written today.

The guest was not frozen — the pilot's telemetry over the same 190 s shows speed varying across dozens of values and a live engagement (tgt=e007_ADAN_Turret at 259–680 m), so the game was advancing normally.

So the discrepancy is real and unexplained. Candidates, none tested:

• the probe samples at a different point in the mission's deployment and the roster-record set is still being built (argued against by the counts being completely static for 190 s afterwards — if it were still loading, it should have grown toward 116);
• gmem.extents() races the emulator's allocation, so the vtable scan sees a different set of extents between runs;
• deployment strength genuinely varies per run (turret squadrons at 18 vs 12).

Until this is understood, per-record counts cannot be used as a time series, and no cross-run comparison of them means anything. This is the same discipline already recorded for the global craft count, now needed one level down.

🔴 Zero arrivals, zero losses in 190 s

Every sample was identical: 170 craft, 24 deployed, no 0 → n, no n → n−1.

• Against the clock model, weakly: if phase-1 arrivals were at t = 90/120/170 seconds, a 0 → n should have appeared, and none did.
• It does not test the event-gated model at all, because nothing was killed. The pilot engaged continuously — closing to 259 m on turrets — but fc=0, no record lost strength, and the player's own hull never moved off 1500. It shot and missed, which pilot.py's own notes say has happened before.

What is needed next

1. Explain the 42-vs-116 discrepancy before trusting any per-record series. Cheapest test: sample the roster-record count repeatedly within one run, starting the instant flight is detected. If it climbs, it is a load race; if it is flat at a run-specific value, it is not.
2. Get a confirmed kill. Without one, the kill-versus-no-kill experiment cannot run. The pilot reaches firing range and does not destroy anything, so the gap is accuracy, not engagement.

---

The 42-vs-116 outlier does not reproduce (2026-08-24)

Status: ✅ the baseline is stable and it is not a load race; 🔴 the VA-aliasing explanation is refuted; 🟡 the outlier itself stays unexplained; ✅ losses are observable.

tools/re-capture/census_probe.py samples the raw counts every 12–20 s from the instant flight is detected, and also reports what the scan is looking at.

✅ Two further runs, both stable at 116

   t   roster   distVA   craft   defs   extents      MB
   0      116      116     300     14       272    342.2
  60      116      116     294     14       262    342.3
 120      116      116     292     14       258    342.4
 168      116      116     288     14       258    342.4

and a second run, 116 throughout, craft 296 → 280.

Not a load race. The roster count is 116 in the very first sample and never moves — it does not climb toward 116 from below, which is what a race would look like. Definitions are 14 throughout, matching Stage 02's 14 unit types.

🔴 Refuted: VA aliasing was not the cause

The leading hypothesis was arithmetic rather than behavioural: census_probe counts raw aligned vtable hits, while wave5_probe counted distinct primary_va values, and if one offset can alias to a VA another offset also claims, those are simply different numbers. Measuring both in the same run settles it: 116 raw hits, 116 distinct VAs, in every sample. They are the same number here, so the difference in what was counted cannot explain 42.

🟡 The outlier stands, unexplained

Four runs now: 116/300, 116/300, 116/296 — and one 42/170. Same disc, save, script and stage; save drift, freezing, load race and VA aliasing are all individually refuted. I do not know what produced it.

What that changes in practice: the baseline is trustworthy enough to build on, but any single run that disagrees with 116 should be discarded rather than interpreted, and a result must be reproduced in at least two runs before it is written down as a finding. Recorded rather than quietly dropped, because a one-in-four anomaly in the measurement apparatus is exactly the kind of thing that later turns into a wrong conclusion.

✅ Losses are observable; arrivals still are not

Craft declines steadily and monotonically in both runs — 300 → 288 and 296 → 280, roughly 16–20 losses over 168 s under the hunting pilot. Whether the player or the NPC crossfire is responsible is not determined here; what matters is that destruction is visible in this signal.

No arrival has yet been seen in any run. The per-record 0 → n watch is still the right instrument, and it can now be run against a known-good baseline.