re: why each archive is low-coverage -- two different reasons, cleanly separated

Splitting every unnamed entry by magic turns the coverage percentages into an
explanation.

The three low-coverage UI archives have ZERO unnamed IDXD.  GP_HANGAR_ARSENAL
is 180 IDXD, 180 named, 0 unnamed -- its 1191 unnamed entries are 1149 T8aD/RATC
plus 42 LSTA, i.e. sprites.  GP_MISSION_SELECT and GP_DEBRIEFING_PILOTLOG hold
no IDXD objects at all.  So "22.6 % named" is misleading: every data table in
that pak is named, and these three are the same artwork-naming phenomenon as the
blocked 2D and READY_ROOM archives.

DefTables is the only genuine data gap: 1425 IDXD, 130 named, 1295 unnamed, in
17 record-name shapes -- Generic + Level_0..Level_3 (807, LOD sets) and Default +
EnumMotions + Generic + ReferenceFrames +/- Motion_break/dead/down (463, motion
sets).  One LOD and one motion table per model.  Level_0, EnumMotions and
ReferenceFrames appear in no document.

Control: the 100 % archives have no unnamed entry of any kind, and GP_MAIN_GAME_E
is 667/337 IDXD with zero unnamed artwork -- two failure modes, not a gradient.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/structures/archive-naming.md

@@ -67,6 +67,50 @@ redo the work.
 is now iterated **sorted** — a plain `set` gave a different winner for collided
 hashes on each run and the artefact failed its own byte-identical check.
 
+## ✅ WHY each archive is low-coverage — two different reasons (2026-08-27)
+
+Splitting every **unnamed** entry by its magic turns the percentage table into an
+explanation. The three "low-coverage" UI archives are not missing data at all:
+
+| archive | IDXD | named | **unnamed IDXD** | unnamed T8aD/RATC | unnamed LSTA |
+|---|---:|---:|---:|---:|---:|
+| `GP_HANGAR_ARSENAL` | 180 | **180** | **0** | 1 149 | 42 |
+| `GP_MISSION_SELECT` | 0 | 0 | **0** | 64 | 2 |
+| `GP_DEBRIEFING_PILOTLOG` | 0 | 0 | **0** | 148 | 8 |
+| `DefTables` | 1 425 | 130 | **1 295** | 0 | 0 |
+| `GP_MAIN_GAME_{D…S}` | 1 004 | 667 | 337 | 0 | 0 |
+
+🔑 **`GP_HANGAR_ARSENAL`'s "22.6 %" is misleading: every one of its 180 data
+tables is named.** Its 1 191 unnamed entries are **sprites and bundles**, and
+`GP_MISSION_SELECT` / `GP_DEBRIEFING_PILOTLOG` contain **no IDXD objects at
+all**. Those three are the *same* phenomenon as the 🔴 blocked 2D and
+`GP_READY_ROOM` archives — unreachable **artwork** names — not a data gap.
+
+🔑 **`DefTables` is the only genuine data gap on the disc**: 1 295 unnamed IDXD
+objects, in **17 record-name shapes**, and two families cover almost all of them:
+
+```
+Generic + Level_0 … Level_3          807   LOD sets      (cf. EnumLODSet_*.tbl)
+Default + EnumMotions + Generic +    463   motion sets   (cf. EnumGameModel_*.tbl)
+  ReferenceFrames (+ Motion_break /
+  Motion_dead / Motion_down)
+```
+
+`stage-definition-table.md` and `stage-mission-tables.md` own the *names*
+`EnumLODSet_*.tbl` / `EnumGameModel_*.tbl`; **the record shapes above are not in
+`docs/re/` anywhere** — `Level_0`, `EnumMotions` and `ReferenceFrames` appear in
+no document. So what `DefTables` withholds is **one LOD table and one motion
+table per model**, keyed by model names the disc does not spell out.
+
+⚠️ The 40 `<?xml` entries in `DefTables` are **already identified** —
+`isl-condition-builtins.md` calls them XPR2 resource manifests
+(`<RDF Version="XPR2">`, `<XBGMesh …/>`, `<Texture …/>`) and corrects an earlier
+"the config reader is XML" claim. Not new here.
+
+**Control:** `GP_TITLE` and the other 100 % archives have no unnamed entry of any
+kind, and `GP_MAIN_GAME_E` splits 667 named / 337 unnamed IDXD with zero unnamed
+artwork — the two failure modes are cleanly separated, not a gradient.
+
 ## What that means for the 419
 
 The in-game HUD's asset paths are not "missing". **Nothing in the 2D paks is