diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index 11a1bab..02e14e4 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -627,6 +627,39 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   🟡 Whether `Stage30`–`Stage33` exist on disc (33 table slots, 28 scripts) is
   still open.
 
+* ✅🔴 **(2026-08-27) THE CONFIG IS AN INI, IT SHIPS NEARLY EMPTY, AND EVERY STAGE
+  TAKES `PLANE = 200` / `VESSEL = 20`.
+  [structures/isl-condition-builtins](structures/isl-condition-builtins.md).**
+  🔴 **Correction to my own label.** I called `sub_824480D0`/`sub_82448AA0`/
+  `sub_824482D0` an *XML* config reader on the strength of the pak census's 40
+  `<?xml` entries. Those 40 are **XPR2 resource manifests** (`<RDF Version="XPR2">`,
+  `<XBGMesh>`, `<Texture … D3DFMT_DXT1_SRGB>`) — mesh/texture declarations, not
+  config.
+  ✅ **The real config is a loose `config.ini` at the disc root**, header comment
+  「アプリケーション/ゲームパート初期設定テーブル」 — "application / game-part
+  initial-settings table", noting that `SYSTEM` holds what the game and every game
+  part share. That matches every key this code touches (`SYSTEM`, `GP_SCRIPT`,
+  `SCRIPTS`, `Resource2D`, `TABLE`, `GRAPH_PATH`, `EX_FONT`, `SCRIPT_ID`,
+  `SCRIPT_PATH`, `BASE_INFO`, `PLANE`, `VESSEL`, `STAGENN_UNIT_MAX`) — they are INI
+  section and key names.
+  🔑 **The shipped file is 400 bytes**: `[SYSTEM]` (empty) and `[LANGUAGE]`
+  (`= eng` default plus `#0x01…#0x06`). **No `[STAGENN_UNIT_MAX]` anywhere**, and
+  `UNIT_MAX`/`VESSEL` appear in **0** pak entries.
+  ✅ **The absence is CONTROLLED.** The same scan over all 41 paks decompressed
+  **26 443 entries** and found `MSG_DEMO` 192×, `mapmesh_box_500km` 162× and
+  `<?xml` exactly **40×** — the census number. ⚠️ Last iteration's null was
+  worthless: that hand-rolled scan used `s[8:]` instead of `s[10:]` for the `Z1`
+  header and searched the index file rather than the `.pNN` data. **Using the
+  corpus's own reader (`unitgroup.py`) was the whole difference.**
+  ⇒ **The lookup always misses, so every stage runs on the defaults: `PLANE = 200`,
+  `VESSEL = 20`.** For the port these are hardcoded fallbacks, not per-stage data.
+  🟡 A hash search (in case the section were name-hashed like a pak entry) found
+  **0** of `name_hash("STAGE01…33_UNIT_MAX"/"PLANE"/"VESSEL")` as pak entry keys;
+  8 of 35 appeared as 4-byte words inside entries, seven in the 1.1 GB `sound.pak`
+  — the chance rate for a 32-bit needle at that size, not a finding.
+  🟡 Still open: who CONSUMES `[phase+356]`/`[phase+360]`, and whether
+  `Stage30`–`Stage33` exist on disc.
+
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
 
 `XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the
diff --git a/docs/re/structures/isl-condition-builtins.md b/docs/re/structures/isl-condition-builtins.md
index 2063228..fc8a1e0 100644
--- a/docs/re/structures/isl-condition-builtins.md
+++ b/docs/re/structures/isl-condition-builtins.md
@@ -335,6 +335,60 @@ offsets recur, and the one ISL-region hit that looked promising
 (`0x82273400 lwz r11, 360(r11)`) is a **vtable slot 90 call** — `r11` is the
 vptr — which is built-in 123, consistent with the known mapping.
 
+### ✅🔴 (2026-08-27) The values: the config is an **INI**, it ships nearly EMPTY, and every stage takes the defaults
+
+🔴 **First, my own label from the previous pass is wrong.** I called
+`sub_824480D0` / `sub_82448AA0` / `sub_824482D0` an *XML* config reader because
+the pak census counts 40 `<?xml` entries. Those 40 are **XPR2 resource
+manifests** — `<RDF Version="XPR2">`, `<XBGMesh Name=… DataFile=…/>`,
+`<Texture Name=… Source=… Format="D3DFMT_DXT1_SRGB"/>` — mesh and texture
+declarations, nothing to do with game config.
+
+The real config is a **loose INI at the disc root**, `config.ini`, whose header
+comment reads *「アプリケーション/ゲームパート初期設定テーブル」* — "application /
+game-part initial-settings table" — and notes that the `SYSTEM` section holds
+settings the game and every game part share. That matches every key this code
+touches: `SYSTEM`, `GP_SCRIPT`, `SCRIPTS`, `Resource2D`, `TABLE`, `GRAPH_PATH`,
+`EX_FONT`, `SCRIPT_ID`, `SCRIPT_PATH`, `BASE_INFO`, `PLANE`, `VESSEL`,
+`STAGENN_UNIT_MAX` — INI section and key names.
+
+**And the shipped file is 400 bytes.** In full it has two sections:
+
+```
+[SYSTEM]
+
+[LANGUAGE]
+        = eng   ; default
+#0x01   = eng   ; XC_LANGUAGE_ENGLISH
+#0x02   = jpn   ; XC_LANGUAGE_JAPANESE
+… deu / fra / esp / ita
+```
+
+`[SYSTEM]` is **empty**, and there is no `[STAGENN_UNIT_MAX]` anywhere.
+
+| check | result |
+|---|---|
+| `.ini` files on the extracted disc | **1** — `config.ini`, 400 bytes, printed in full |
+| `[STAGENN_UNIT_MAX]` sections in it | **0** |
+| `UNIT_MAX` in any pak entry | **0** |
+| `VESSEL` in any pak entry | **0** |
+
+The pak scan is **controlled**: the same loop over all 41 paks decompressed
+**26 443 entries** and found `MSG_DEMO` 192×, `mapmesh_box_500km` 162× and
+`<?xml` exactly 40× — the census number. So the reader works and the absence is
+real. (An earlier hand-rolled scan used `s[8:]` instead of `s[10:]` for the `Z1`
+header and searched the index file rather than the `.pNN` data — that one's null
+result was worthless.)
+
+> ⇒ **The lookup always misses, so every stage runs on the defaults:
+> `PLANE = 200`, `VESSEL = 20`.**
+
+🟡 A hash search was run too, in case the section were name-hashed like a pak
+entry: `name_hash("STAGE01…33_UNIT_MAX")`, `name_hash("PLANE")`,
+`name_hash("VESSEL")` — **0 hits as pak entry keys**. Eight of the 35 hashes did
+appear as 4-byte words *inside* entries, seven of them in the 1.1 GB `sound.pak`;
+that is the chance rate for a 32-bit needle in a blob that size, not a finding.
+
 🟡 Its neighbours belong to the same cluster: `builtin103` reads
 `[phase+10156]` and `[phase+10152]` (9 and 7 writers), and a sibling vtable stub
 clears `[phase+10152]`. The shape is an engine→script status trio, but that is a