diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index c79967e..0193b95 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -2245,3 +2245,46 @@ Both were mine, and both produced confident nonsense before being caught.
 The same shape as every other correction in this log: a clean, small, plausible
 number read as conclusive because it was not checked against a control that
 could have disagreed.
+
+### The reference that did not generalise
+
+Level 0's `data.bin` -- the level's file descriptor -- contains the value
+`799204` exactly once, at `0xab6360`, and `799204` is byte-for-byte the offset
+of the 20-record candidate table above. A single 4-byte match in 13.3 MB has a
+chance expectation of about 0.003, which is suggestive enough to be worth
+checking properly rather than assuming.
+
+It does not hold up. Taking each level's own best 144-byte table and searching
+that level's own `data.bin`:
+
+    level   candidate offset   records   references found (chance ~0.0035)
+      0        1,810,724          32      0
+      1        1,884,884         386      0
+      2        2,066,804         224      0
+      3        2,438,228         365      0
+      4        2,677,780         114      0
+      5        1,255,780          14      0
+      6        2,496,020         115      0
+      7        2,062,072         311      0
+
+Not one of the eight is referenced. The level 0 match at `0xab6360` sits in a
+neighbourhood of high-entropy bytes, and level 0's own *best* table -- a
+different offset, 32 records, not the 20-record one -- is not referenced either.
+So the single hit does not generalise and is most likely coincidence.
+
+The consequence is worth stating plainly because it retracts what the previous
+section implied: **nothing links a 144-byte float table to volumes.** The table
+is reached by walking structure rather than by an explicit pointer, so the
+approach that would have settled it does not work, and the candidate stands
+exactly where it did.
+
+What would settle it, and none of these are cheap:
+
+  * The game's own volume code, which has the same byte-order problem as the
+    collision anchor did -- a GP-relative string search returning nothing.
+  * Ground truth: a count of level 0's trigger volumes from a map or a guide,
+    to match against a table's population.
+  * A correlation with a *named* class, since `gameplay.bin` resolves ids
+    through its dispatch records. If an id in the candidate resolved to a class
+    whose name is a volume trigger, that would be decisive. No class name
+    containing "volume" exists on the disc, which is why this is not available.
diff --git a/docs/roadmap.md b/docs/roadmap.md
index e95716e..2a871bd 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -417,7 +417,10 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       bugs on the way are written up: a validity test that counted zero as
       world-plausible scored zero-filled memory perfectly, and the 144-byte stride
       rested on four eyeballed offsets that the gap histogram did not support.
-      Not located. Nothing examined so far presents itself as a
+      A promising lead also failed: level 0's `data.bin` references one candidate
+      offset exactly once (chance ~0.003), but **none** of seven other levels'
+      candidates are referenced by their own `data.bin`, so the table is reached
+      by walking structure and nothing links it to volumes. Not located. Nothing examined so far presents itself as a
       volume: `core_data`, the chunk region and `gameplay.bin` all yield
       structures that are accounted for by something else.
 - [~] `level_overlay` — header, constant block and level data parsed