diff --git a/docs/re/two-entity-enumerations.md b/docs/re/two-entity-enumerations.md
index 27113b29..307a654b 100644
--- a/docs/re/two-entity-enumerations.md
+++ b/docs/re/two-entity-enumerations.md
@@ -40,6 +40,46 @@ no runtime roster is reproducible across runs unless the stage is verified first
 | `UN_f101_TCAF_Acropolis` / `bf001_SchlosBase` / `f201_Tanker` | 1 each | **0** |
 | **total** | **116** | **30** |
 
+> # ❌ CORRECTED 2026-08-26 — "the absence is structural" is WRONG
+>
+> Everything below about capital ships being absent from the `+0x130` method is
+> an artifact of **how I sourced the entities**, not a property of the game.
+>
+> I enumerated by taking `moving()` triples and testing `+0x130`. `moving()`
+> requires a position to **change between two samples**. A capital ship holding
+> station changes by *exactly* zero — which is why dropping the floor to `lo=0`
+> did not help either, and why parked `ArrowHead` wingmen were missing too. The
+> whole-map scan failed for the same reason: the filter, not the range.
+>
+> `navigator.py` already does it correctly, and says so in its header — it
+> searches for the **definition pointer** and takes `position = hit - 0x130`,
+> *"which finds every entity whether it is moving or not"*. Running the existing
+> `mission_state.py scan` on Stage 02 finds **149 entities**, capital ships
+> included:
+>
+> ```
+> UN_f101_TCAF_Acropolis    (  +5000,     +0,     +0)  hull= 25000.0  HP= 25000.0  frac=1.000
+> UN_e105_ADAN_Cruiser      ( -29500,   +500,  +3219)  hull= 30000.0  HP= 30000.0  frac=1.000
+> UN_e106_ADAN_Destroyer    ( -25500,  -1000,  +7041)  hull=  9150.0  HP= 10000.0  frac=0.915
+> UN_f106_TCAF_Destroyer    (  +1504,   -498,  -1937)  hull=  9579.2  HP= 10000.0  frac=0.958
+> UN_f001_..._Player        (  -6676,   +882,  +1004)  hull=  1500.0  HP=  1500.0  frac=1.000
+> ```
+>
+> `hull(+0x154) == definition HP` for **129 of 149**, the rest already damaged.
+>
+> ❌ So this specific claim is withdrawn outright: *"an autopilot that must
+> protect the Acropolis cannot locate it through the `+0x130` method at all."*
+> It can. The Acropolis is right there at `(+5000, 0, 0)` with its hull readable
+> and falling. `INDEX.md` had already recorded this — ACROPOLIS 25000 → 23038
+> over 240 s — which makes this the eighth time this session that the corpus
+> held the answer before I measured.
+>
+> What survives from below: the two enumerations really are **different
+> structures** in different regions (0/116 vtable instances lie in the `+0x130`
+> region), and the vtable scan is still the one that sees stations and scenery.
+> What does **not** survive is any claim that the `+0x130` model is limited to
+> four types.
+
 ## ✅ The absence is structural, not a filter artifact
 
 The obvious explanations were tested and **both fail**: