diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index 352f13b..469f503 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -349,6 +349,12 @@ search cannot find a *schedule*.
   file offsets. 🔴 **Two payload readings refuted** by generalising from the one
   object they were fitted to (a "bounding-sphere radius" float, and "leaf arrays
   of `count × 4` bytes"). The payload is float-dominated and otherwise ❔.
+  ✅ **2026-08-26: the other three sections have strides** — 12 / 96 / 48 bytes,
+  with `counts[0..2]` as their record counts (section 1's remainder is exactly 0
+  and section 2's exactly 96, in 11/11). **Section 0 is a point list**
+  (13 467/13 467 inside the bbox) and **section 2 is a plane list** — unit normal,
+  signed distance, and a point, with `n·p + d = 0` to float round-off in
+  **133 573/133 573**. Section 1 (96 B) still ❔.
   See [`structures/regn-map-grid.md`](structures/regn-map-grid.md).
 * 🔴 **`hidden/DefTables.pak` is NOT it** (checked 2026-08-24). The three
   unnamed schemas are more **model/render** tables in the same vocabulary as the
diff --git a/docs/re/structures/regn-map-grid.md b/docs/re/structures/regn-map-grid.md
index f44d453..ca41a5b 100644
--- a/docs/re/structures/regn-map-grid.md
+++ b/docs/re/structures/regn-map-grid.md
@@ -143,3 +143,61 @@ So `.rgn`/`REGN` is stage navigation/path data referenced by the stage record,
 and `.col`/`MCOL` is the stage collision mesh. This does not by itself validate
 either of the two refuted cell-payload readings recorded above, but it does
 explain why the payload looks like a grid of route data.
+
+
+## ✅ Sections 0, 1 and 2 have record strides — and section 2 is a PLANE list
+
+**2026-08-26.** The three sections the page called undecoded are fixed-stride
+record arrays, and `counts[0..2]` are their record counts. Dividing each
+section's byte span by its count over all 11 objects:
+
+| section | stride | evidence |
+|---|---|---|
+| 0 | **12 bytes** | `count × 12` fits with a remainder of 0–12 in **11 / 11** |
+| 1 | **96 bytes** | `count × 96` fits with a remainder of **exactly 0 in 11 / 11** |
+| 2 | **48 bytes** | `count × 48` fits with a remainder of **exactly 96 in 11 / 11** |
+
+Section 1 landing on a zero remainder in every object, and section 2 on the same
+96-byte tail in every object, is what makes these strides rather than a
+coincidence of division.
+
+### ✅ Section 0 is a point list
+
+12 bytes is three `f32`. Over **13 467** records across all 11 objects, **every
+one lies inside that object's own header bounding box — 13 467 / 13 467 (100 %)**.
+Values land on the box corners (`±250 000`) and inside.
+
+### ✅ Section 2 is a plane list — 48 bytes, and the plane equation closes
+
+Read as twelve `f32`:
+
+    [0..3]   zero
+    [4..6]   unit normal          |n| = 1 ± 0.02 in 133 573 / 133 573 (100 %)
+    [7]      signed distance d
+    [8..10]  a point on the plane, inside the bbox in 133 573 / 133 573 (100 %)
+    [11]     1.0 exactly           in 133 573 / 133 573 (100 %)
+
+**The check that makes this a decode**: for a genuine plane, `n·p + d` must be
+zero. Over all **133 573** records:
+
+    |n·p + d| / scale :  median 2.29e-08   p90 6.78e-08   max 2.15e-07
+
+That is float round-off, not a fit — the relation holds to the last bits of a
+32-bit float in **every record on the disc**. Three independent 100 % properties
+(unit normal, point in bbox, trailing 1.0) and an exact algebraic identity are
+well past what a wrong reading survives.
+
+So a `REGN` object carries, alongside its uniform grid, a **point list** and a
+**plane list** — which is the shape of collision or region-boundary geometry,
+and consistent with `MCOL` sitting beside it.
+
+### ❔ Still open
+
+* **Section 1** (96 bytes/record, 60 631 records disc-wide) is untouched. Its
+  content is float-dominated with both large coordinates and mid-range values.
+  96 bytes is 24 floats — a plausible shape for a 4×4 matrix plus extras, or for
+  two 48-byte plane records, but nothing is measured.
+* **What the planes are for.** "Collision or region boundary" is a reading of the
+  shape; nothing here shows what queries them.
+* The **zeros at `[0..3]`** of every plane record, and the constant `96`-byte
+  tail after section 2, are unexplained.