From 530555de9f9490a53ab6cb1b92d0adfda1771661 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Mon, 10 Aug 2026 20:09:14 +0000 Subject: [PATCH] =?UTF-8?q?re:=20the=20weapons=20are=20the=20control=20?= =?UTF-8?q?=E2=80=94=20sibling-default=20inheritance=20is=20unit-schema-sp?= =?UTF-8?q?ecific,=20not=20engine-wide?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Four rules from 21 units invites the coincidence objection, so run the identical sweep against the Weapon/Shell capture, which has COMPLETE coverage (126 records). It finds no sibling rule at all: the one 100%-agreement candidate has a single distinct value and is really a constant default. Weapon defaults vary per record exactly as unit defaults do, so "defaults are computed" is general while "defaults come from a sibling field" is not. Size_Y <- Size_X survives, and is now checked at the raw-token level rather than through the sub-record merge: e105, f105 and f101 each declare Size_X/Size_Z/ Size_Radius and no Size_Y, and each reads back its own Size_X at runtime. The two two-unit hypotheses are demoted to coincidence-not-excluded. Also records a negative for planning: Stage 01, the only other reachable stage, adds four uncaptured units that are variants of already-captured ones, so it would re-measure rather than test the rules. Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/structures/unit-struct-runtime.md | 33 +++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) 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.