diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index ceca9c1..48cd4ef 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -1023,9 +1023,20 @@ as a per-level partition rather than only in aggregate across the disc's
 8,938 records, which is what rule 3a asks for. Two trailing zero bytes are
 padding or a flag pair, not data.
 
-**What it does not.** Whether the six bytes are six `u8` fields, or an `f32`
-plus two `u16`, or something else, is unresolved -- the `u32` reading is
-excluded but no positive reading is established.
+**What it does not.** Resolved by a follow-up measurement: the six bytes are
+not an `f32` pair either, and not narrow `u16`s.
+
+- `f32 @0`: 158 of 164 finite, but the range runs to about 1e35. Not positions
+  or normals. The 6 non-finite values (3.7%) are far above the 0.05% that
+  random bytes would produce, so the field is *structured* but is not an `f32`.
+- `f32 @4`: all 164 finite, range 0 to 9.18e-5. This looks promising until you
+  notice bytes 6 and 7 are always zero, which pins this value to a coarse grid
+  and explains the tiny range. It is not independent evidence.
+- `u16 @0`, `@2`, `@4`: distinct counts 85, 90 and 80, each spanning essentially
+  the whole 0..65534 range. These are not small counts or indices.
+
+So excluded are: two packed `u32`, an `f32` pair, and narrow `u16` fields. The
+six bytes remain uninterpreted.
 
 **Process note.** The first attempt at this used `ClassEntry` and a
 hand-computed `o_class` offset instead of `ShrubClassEntry`, and every