diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index 8b96969..0e38a54 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -86,11 +86,23 @@ See [`mission-freeze-heap-exhaustion.md`](mission-freeze-heap-exhaustion.md).
   between tool calls.** Sequential tool calls *within* one turn are fine; it is
   ending the turn that kills it.
 
-❔ **The world-unit measurement is still not made.** Flight was reached and the
-screen classifier agrees, but `entities2.py self` reports **0 unit definitions** —
-its committed VA window `0xBD00_0000`–`0xBE00_0000` does not match this run, the
-same run-dependent-address problem this file documents for the OB counter. The
-next attempt must hunt the range rather than trust the stored config.
+❔ **The world-unit measurement is still not made** — but the blocker under it is
+now GONE. The entity scan works: see
+[`entities-live-roster.md`](entities-live-roster.md), **13 unit definitions and 42
+named live instances** with 52 moving triples, on 2026-08-26.
+
+The old note here blamed `entities2.py`'s committed VA window. That was the wrong
+suspect: ✅ the real cause was the **navigation route**. Runs that reach a mission
+through `MISSION SELECT` scan 0/0; the route that populates the world is
+`launch_mission.sh`'s **title → LOAD GAME → slot 01 → YES → READY ROOM → TAKE
+OFF**, which is what `structures/unit-struct-runtime.md` used when the constants
+were first derived.
+
+What remains for the measurement itself: this run reached the mission but the
+flight **HUD was not yet up** (green 0.03 %, against 1.3–1.5 % in flight), so
+there was no on-screen distance readout to compare world-unit positions against.
+Next attempt: get to a live HUD, then read a target's position triple and the
+HUD's own distance to it.
 
 ---