diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index 5cf12b9..7854f82 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -640,3 +640,33 @@ accounting for before reading any field at a fixed offset.
 **Not decoded.** The layout is established and the constant positions are
 known; the fields are not named, and which of the 40 bytes are an index, a
 length and an offset is still open.
+
+## SBlk: the field values do not read as record fields
+
+**Range measured:** level 0 `SBlk`, 24..19508.
+
+**Method:** read at 4-byte alignment and rank the most common `u32` values.
+
+**Result:** the common values are `0x0` (2261), `0x1` (369), `0x7f` (168),
+`0x5a000000` (125), `0x1eff7f7f` (125), `0x1dfcc` (124), `0x19fc0` (93),
+`0x7c34240d` (91), `0x7c3821c8` (91).
+
+**This does not look like a table of records with typed fields.** A 40-byte
+record layout whose fields are an index, a length and an offset would not
+produce `0x1eff7f7f` and `0x7c34240d` a hundred times each, nor would those
+values survive a byte shift.
+
+So either the 40-byte period is not a record boundary, or the region is an
+encoded stream -- something like varint or Huffman-coded data -- that happens
+to have a 40-byte statistical period.
+
+The `0x7f` values are suggestive: in a varint encoding a byte of `0x7f` is the
+last value representable in seven bits, so it appears as a frequent
+saturated byte. That is consistent with a coded stream and inconsistent with
+a fixed-layout record.
+
+**Left open.** The 40-byte period is solid (27/27 levels, sharply isolated, its
+multiples confirm it), and the alignment with four constant zero positions is
+solid. What sits in those bytes is not a record layout, and the two findings
+are in tension in a way this project has not otherwise seen: a confirmed
+period that is not a record boundary.