diff --git a/docs/plan/pcsx2-verification.md b/docs/plan/pcsx2-verification.md
index fdd1a87..71d9608 100644
--- a/docs/plan/pcsx2-verification.md
+++ b/docs/plan/pcsx2-verification.md
@@ -408,3 +408,50 @@ probably a companion structure, not the missing discriminator.
 Still open: what distinguishes a fixed-point payload from a sub-list payload
 when the records carrying them look identical in bytes 0-3 and 11. The most
 likely place to look is the count at byte 8 against the payload's own length.
+
+## The count at byte 8 sizes the sub-list payload: exactly 16 bytes per record
+
+The previous entry left one test: compare the count at byte 8 against the
+payload's own extent. Pointer spacing gives the extent, since the packets are
+laid out in ascending order in EE RAM.
+
+**Range measured:** savestate slot 1, the 17 packets in RAM
+`0x22a000..0x24037f`, each with its record address, byte-8 count and pointer,
+sorted by pointer so the next packet is the next object in memory.
+
+**Result: eight packets sit exactly `count * 16` bytes after their predecessor
+-- an integer ratio of 16.00 in every one, with no rounding.**
+
+    record      count      ptr   gap   gap/count
+    0x22a6e8       22  009376f0    352    16.00
+    0x22a728       36  00939c50    576    16.00
+    0x22a768       23  0093cc70    368    16.00
+    0x22a7a8       36  00998880    576    16.00
+    0x22a7e8       25  009c19c0    400    16.00
+    0x22a828       24  009cf370    384    16.00
+    0x22a868       41  009d2da0    656    16.00
+    0x22a8a8       21  009f5aa0    336    16.00
+
+Eight exact hits at a ratio that has to be an integer is not sampling luck. The
+count at byte 8 is the **record count**, and these payloads are 16 bytes per
+record.
+
+**And these are exactly the sub-list payloads** -- `0x009376f0`, `0x00939c50`,
+`0x0093cc70`, `0x00998880`, `0x009d2da0` were all read directly in earlier
+passes and all open `00 00 00 30` followed by a repeated word.
+
+**What the other nine are.** Their ratios are 168, 419, 559, 31288, 7985,
+3458, 764, 6452 -- no shared factor, and far too large to be a record count
+times anything. So either their payload is not followed immediately by the next
+packet in the pointer order (other data intervenes), or they are not 16 bytes
+per record. Both readings are open; what is ruled out is that they follow the
+same rule.
+
+**This resolves byte 8.** It was measured as "a count, 0x0b to 0x29" two entries
+ago and is now shown to size a payload exactly, in eight independent cases,
+within a single level. Whether it also sizes the fixed-point payloads is the
+open half.
+
+Still open: why the fixed-point packets do not follow the same rule, and what
+the 16 bytes per sub-list record are -- the repeated word (`0xcd`, `0xc0`,
+`0xc8`, `0x78`) differs per packet, so the records are not identical.