diff --git a/docs/plan/pcsx2-verification.md b/docs/plan/pcsx2-verification.md
index f74479a..7728f3e 100644
--- a/docs/plan/pcsx2-verification.md
+++ b/docs/plan/pcsx2-verification.md
@@ -211,3 +211,45 @@ as data by something, not stored as a tag.
 `0x6d` marks a payload that the loader expands. That needs the same records
 compared one by one against their disc spans, which is the next step and is
 now cheap because the anchor exists.
+
+## Following the pointers: packet payloads differ by type
+
+The header pointers found above are live, so they can be dereferenced. Two
+consecutive records from the level 0 table at `0x22a6b8` were followed.
+
+**Range measured:** savestate slot 1, reading `0x00936a70` (from the record at
+`0x22a6b8`) and `0x009376f0` (from the record at `0x22a6e8`), 64 bytes each.
+
+**Result: the two payloads have nothing in common.**
+
+`0x00936a70` -- fixed-point vertex data:
+
+    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   (repeating)
+
+Every high byte is `0x80` or `0x7c`, and the pattern repeats on a 8-byte
+boundary. Read as `s16` these are large negatives in a narrow band around
+-32500. That is consistent with Q16.15 fixed-point rather than `f32`, and with
+a stride of 4 `s16` per vertex.
+
+`0x009376f0` -- a tagged sub-list, not vertex data:
+
+    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
+
+Structurally different: small integers, a repeating `0xcd`, and `0x30` tags in
+the high byte. Nothing here is position data.
+
+**What this supports.** Two records 0x30 apart in the same table hold payloads
+of entirely different kinds. That is direct evidence for the type reading of
+the header: the table is a tagged collection where the tag selects what the
+payload is, not a uniform array of one thing.
+
+It also rules out the alternative I could not previously exclude -- that the
+16-byte tiling was a single uniform record format and the varying bytes were
+all fields of it. Two adjacent records with unrelated payloads is not that.
+
+**Still open.** The mapping from tag value to payload kind. The `0x30` 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.