diff --git a/docs/re/structures/unit-struct-runtime.md b/docs/re/structures/unit-struct-runtime.md
index 04f3413..f8fb1b4 100644
--- a/docs/re/structures/unit-struct-runtime.md
+++ b/docs/re/structures/unit-struct-runtime.md
@@ -320,7 +320,36 @@ disc, the rules recover **65 (unit, field) values in units that have never been
 visited**: `Size_Y` in 21 of the 21 units that omit it, `Size_Radius` in 22 of 26,
 `FCSRange` in 14 of 56, `DefencePoint` in 8 of 60.
 
+### Cross-check against the weapons: this is NOT an engine-wide mechanism
+
+The obvious worry is that four rules from 21 units are coincidence. The
+`Weapon`/`Shell` capture is the control: **complete coverage, 126 records**, with
+the same "defaulted on disc" classification. Running the identical sweep there
+(confirmed rows, non-zero values, offsets required to differ) finds **no sibling
+rule at all** — the single 100 %-agreement candidate (`Shell.Length ←
+`Shell.Volume`, 5 records) has one distinct value, i.e. it is really the constant
+`Length → 10` coinciding with `Volume = 10`. Weapon defaults vary per record just
+as unit defaults do (10 of 14 `Weapon` fields, 16 of 17 `Shell` fields), so the
+phenomenon is general; the *sibling* explanation is not.
+
+So `Size_Y ← Size_X` is **specific to the unit schema** (plausibly the size block
+defaulting its axes), not a property of IDXD default resolution. Two consequences:
+the rule cannot be justified by appeal to a general mechanism, and the two
+two-unit hypotheses (`FCSRange`, `DefencePoint`) lose the support they would have
+borrowed from one — treat them as **coincidence-not-excluded** until a new stage
+tests them.
+
+`Size_Y ← Size_X` itself survives this scrutiny, and was re-checked at the raw
+token level rather than through the sub-record merge: `UN_e105_ADAN_Cruiser`,
+`UN_f105_TCAF_Cruiser` and `UN_f101_TCAF_Acropolis` each declare `Size_X`,
+`Size_Z` and `Size_Radius` and **no `Size_Y` at all**, and each reads back its own
+`Size_X` (600 / 700 / 400) at runtime.
+
 **How to falsify:** the rules predict a specific number for units in stages not
 yet captured. Load any new stage, snapshot, and compare — one disagreement kills
-the rule. That test is also the cheapest use of the next mission that gets
-loaded, whatever it is loaded for.
+the rule. Note what is *not* a useful test: Stage 01, the only other reachable
+stage, adds just four uncaptured units (`e010`/`e106` variants) whose predictions
+are the same numbers their already-captured base variants gave, so it would
+re-measure rather than test. A real test needs a stage with unfamiliar classes,
+i.e. story progress — which is now the *only* thing story progress is needed for
+here.