# 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](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.