diff --git a/docs/re/structures/regn-map-grid.md b/docs/re/structures/regn-map-grid.md
index b5d2cba..6b0b37a 100644
--- a/docs/re/structures/regn-map-grid.md
+++ b/docs/re/structures/regn-map-grid.md
@@ -21,7 +21,7 @@ untouched here; the name and the size range read like mesh collision.
 
 ```
 0x00  char[4]  'REGN'
-0x04  u32      section-data size
+0x04  u32      size of the data area  (the POF0 table starts at 0x04-value + 16)
 0x10  f32[4]   bbox min   (x, y, z, 1.0)
 0x20  f32[4]   bbox max   (x, y, z, 1.0)
 0x30  f32[4]   extent     (max - min)
@@ -77,6 +77,41 @@ Two more invariants from the same sweep:
 
 Most cells are occupied: 878–998 of 1 000, 123 of 125.
 
+## ✅ It is a serialised object graph with a `POF0` fixup table
+
+Every one of the 11 objects contains the tag **`POF0`**, always near the tail,
+and its position is exactly **`header[0x04] + 16`** — on **11 of 11**:
+
+```
+e993b93e  header +0x04 = 0x0b100   POF0 at 45328 = 45312 + 16
+e4155d94  header +0x04 = 0x235d70  POF0 at 2317696 = 2317680 + 16
+… 11 of 11 identical relation
+```
+
+`POF0` is a **pointer-offset (fixup) table**: the file is a serialised C++ object
+graph, and the loader patches the recorded slots into real pointers. That
+explains a detail that would otherwise be odd — the "offsets" inside the cell
+index are absolute **file** offsets, because that is what a fixup table rewrites.
+
+So `header[0x04]` is the size of the data area, and everything past
+`header[0x04] + 16` is relocation bookkeeping rather than content.
+
+## 🔴 Two readings of the cell payload, both refuted by generalising
+
+Both came from the smallest object and both died the moment they were checked
+against the other ten — recorded because the temptation to keep them was real:
+
+* **"the `f32` at record `+0x1c` is the grid's bounding-sphere radius."** On
+  `e993b93e` it is 86 689 against `√3 × 50 000 = 86 603`, a ratio of **1.001**.
+  On the other ten the ratio runs **0.13 – 0.27**. Fitted to one sample.
+* **"a record's `(count, offset)` pairs point at leaf arrays of `count × 4`
+  bytes."** True for the first record of `e993b93e`; across the objects the
+  offset deltas fail that rule on **every** object checked (0 of 11 clean).
+
+What survives is only descriptive: the payload area is dominated by **float
+data** — the "strings" a printable-run scan finds are all byte patterns like
+`0x46`/`0x47` high bytes, i.e. medium-magnitude floats, not text.
+
 ## ❔ The other three sections
 
 Their offsets scale with the object, and `counts[0..2]` scale with them —