diff --git a/docs/plan/pcsx2-verification.md b/docs/plan/pcsx2-verification.md
index 71d9608..d5a6945 100644
--- a/docs/plan/pcsx2-verification.md
+++ b/docs/plan/pcsx2-verification.md
@@ -455,3 +455,48 @@ 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.
+
+## Inside a sub-list payload: tagged blocks and a byte permutation table
+
+With the extent known (`count * 16`), a whole sub-list payload can be read.
+This is the packet at `0x009376f0`, count 22, 352 bytes, in full.
+
+**Range measured:** savestate slot 1, `0x009376f0`..`0x0093784f`, 352 bytes.
+
+**Result: the payload is a sequence of blocks, each opening `00 00 00 30`,**
+carrying a repeating word and then a short trailer:
+
+    00 00 00 30 | cd 00 00 00 cd 00 00 00 cd 00 00 00 cd 00 00 00
+                01 00 00 05 | 22 c1 01 6e | 00 00 00 00
+    00 00 00 30 | 00 00 00 45 00 00 00 45 1d 00 00 00 1d 00 00 00 1f
+                81 01 6d 00 | 00 00 00 00 | 00 00 a4 00
+    00 00 00 30 | bc c0 03 00 23 17 03 00 e5 dd 00 00 00 00 00 00
+                02 01 00 01 | c1 80 01 69 | 00 00 00 00
+
+The repeating word differs per block -- `0xcd`, `0x45`, `0x03` -- and the
+trailer's second word varies in its high bytes: `22 c1 01 6e`, `81 01 6d 00`,
+`c1 80 01 69`. Every block seen ends `... 6e` or `69` or `6d` at byte 23, which
+is the same `6e` the `02 01 00 01` records carried at bytes 8-9.
+
+**The payload contains a byte permutation table.** At `0x009377c4`:
+
+    00 01 02 03 3e 3f 53 54 40 41 42 43 4e 4f 50 51 04 05 06 07 08 ...
+
+This is not a position or vertex list -- it is a run of ascending byte values
+with a handful (`3e 3f`, `53 54`, `40 41 42 43`, `4e 4f 50 51`) lifted out of
+order ahead of the sequential run. Read as a table, it maps each of the 0..0x39
+symbols to a slot. That is the shape of a **code-length or symbol-ordering
+table**, and it is the first thing in this format that is self-evidently a table
+rather than data to be interpreted.
+
+**What this does not say.** Whether the table is a Huffman-style code, an index
+reorder for the vertex data that follows, or a palette permutation. The
+following bytes continue the sequence to `39` and then `23 c1 01 6e`, after
+which the next block opens.
+
+**Corroboration worth noting.** The fixed-point payload `0x00937850` begins
+immediately after this one ends at `0x00937850` exactly -- the 22-record
+identity from the previous entry made the boundary exact, and the next packet
+starts on a payload boundary with nothing in between. The two payload kinds sit
+adjacent in RAM, which is consistent with them being two records of the same
+blob rather than two unrelated objects.