diff --git a/docs/plan/pcsx2-verification.md b/docs/plan/pcsx2-verification.md
index 7728f3e..da06e12 100644
--- a/docs/plan/pcsx2-verification.md
+++ b/docs/plan/pcsx2-verification.md
@@ -253,3 +253,66 @@ all fields of it. Two adjacent records with unrelated payloads is not that.
 appears in record bytes 8-11 in RAM also appears at the head of the second
 payload, which is suggestive but is one coincidence so far and should not be
 written up as a link until it is seen in more than one record.
+
+## The tag values map onto three payload kinds
+
+Following the pointers out of the level 0 table, all nine that carry the `0x30`
+tag at byte 11 and an EE pointer at 12..15 were dereferenced and read 32 bytes
+each. They fall into exactly three classes, three payloads each, with no
+overlap.
+
+**A -- Q16.15 fixed-point vertex data** (3 of 9)
+
+    00936a70  8d 8c 80 80 89 87 7c 80 8d 8c 80 80 89 87 7c 80
+              4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80
+    0093cde0  8a 8a 7f 80 92 90 84 80 8a 8a 7f 80 92 90 84 80
+              4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80
+    009cf4f0  6e 6f 68 80 6e 6f 68 80 6e 6f 68 80 6e 6f 68 80
+              54 54 51 80 54 54 51 80 54 54 51 80 54 54 51 80
+
+Every high byte is `0x80` or `0x7c`, each payload repeats on an 8-byte
+boundary, and the values differ between payloads while the `4e 4e 4c 80` tail
+is shared by two of them.
+
+**B -- a `0x30` sub-list with a repeated count** (3 of 9)
+
+    009376f0  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
+    00998880  00 00 00 30 c0 00 00 00 c0 00 00 00 c0 00 00 00
+              c0 00 00 00 01 00 00 05 11 c1 01 6e 00 00 00 00
+    009d2da0  00 00 00 30 c8 00 00 00 c8 00 00 00 c8 00 00 00
+              c8 00 00 00 01 00 00 05 1d c1 01 6e 00 00 00 00
+
+Structurally identical apart from the repeated word: `0xcd`, `0xc0`, `0xc8`.
+All three carry `01 00 00 05` at offset 16 and a `.. c1 01 6e` at 20.
+
+**C -- an index/attribute list** (3 of 9)
+
+    00939700  00 c0 05 6d 3e 00 00 00 01 00 00 00 12 00 00 00
+              18 00 c0 00 fe 00 fe 00 ff 00 ff 00 11 01 17 01
+    009c1540  00 c0 05 6d 36 00 00 00 01 00 00 00 08 00 00 00
+              13 00 93 00 c9 00 c9 00 ca 00 ca 00 d2 00 d5 00
+
+Both open `00 c0 05 6d`, then a count, then a run of small ascending `u16`.
+
+**The mapping.** The tag vocabulary measured on disc -- `0x00`, `0x30`,
+`0x6d`, `0x80` at record byte 7 -- is not decorative:
+
+| tag | payload |
+|---|---|
+| `0x30` | class B, the `00 00 00 30` sub-list |
+| `0x6d` | class C, the `00 c0 05 6d` attribute list |
+| `0x00` | class A, the fixed-point vertex data |
+
+`0x30` heads the class B payloads and `0x6d` heads the class C payloads, which
+is the link flagged as a single coincidence two entries back. It is now seen in
+three payloads each, so it is a rule rather than an accident.
+
+`0x80` did not appear among these nine. Its meaning is still open -- it is the
+fourth value in the vocabulary and there is no sample of it here.
+
+**A correction.** The record spacing in this table is not uniformly `0x30`. The
+`find` output shows `0x30`, `0x10`, `0x30`, `0x30` between consecutive packet
+headers, and only 9 of the 5,632 bytes scanned carry both the `0x30` tag and an
+EE pointer. The earlier "records at 0x30 spacing" was inferred from a truncated
+list of hits and does not hold.