diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index f5f1889..3f5255e 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -1385,6 +1385,58 @@ So: the four-value claim was right, my retraction of it was wrong, and the
 retraction was made on a number from the same contaminated set. A retraction is
 not automatically better than the claim it retracts; it needs its own bounds.
 
+## The located `0xf6` terminator is inside the last packet (2026-10-11)
+
+**Range measured:** every tie LOD block on the disc, 2,177 blocks.
+
+**Method:** the last packet's end is known two ways. Its length comes from its
+record's `packet_quadwords`, and every *other* record's length is confirmed by
+the next record's pointer -- so only the last packet of each table is
+unconfirmed. Comparing its computed end against where `parse_tie_block` stopped:
+
+**the last packet's computed end lands 2 to 16 bytes past the located `0xf6`,
+on all 2,150 blocks measured.** The error is not a multiple of 16, so it is not
+a length error: a packet ending exactly at the terminator would give a
+quadword-aligned difference. The `0xf6 00` pair therefore sits *inside* the last
+packet's data, 2 to 16 bytes before its end.
+
+Two readings fit: either the terminator was located too early, or the last
+packet's length over-predicts by an amount that isn't a multiple of 16. The
+first is likelier, and the test asserts the measurement rather than the
+reading. What still holds either way: the lengths are right for every record
+but the last (12,927 of 12,927 record pairs), and the block *starts* are
+RAM-confirmed. The block *extent* is what is short.
+
+**Why the existing test missed it.** `2,177 of 2,177 blocks end on 0xf6` is
+satisfied by a false terminator exactly as well as a true one -- it checks that
+the byte it walked to *is* a `0xf6`, not that it is the block's end. A test that
+confirms the shape it walked to will pass on the wrong byte.
+
+The cost: `payload` and `padding` under-report, so anything computed from them
+is correspondingly short.
+
+### Two candidate fixes, both measured and neither clean (2026-10-11)
+
+**Range measured:** every tie LOD block, 2,169 blocks with a known last packet.
+
+**Candidate 1: the first `0xf6 00` at or after the last known packet's end.**
+Fails. The offsets found are spread (1082, 1132, 1148, 1150, 1182, 1214 ...),
+not concentrated, because the 115 records with a non-zero `strip_count` carry
+packets whose length is unknown and therefore sit after the last known end.
+The scan lands inside those.
+
+**Candidate 2: the block's data ends at a long zero run.** Fails. Walking
+forward from the last known packet's end to the first run of 8+ zero bytes, the
+byte preceding the run is not dominated by `0xf6` (2, 4, 1, 64, 3, 32, 19 ...
+across 2,169 blocks) and the runs themselves are mostly 8-31 bytes. The zero
+padding after a block is short and irregular, so run length does not
+discriminate the block's end.
+
+Recorded as negative results because both are the obvious thing to try next
+and both are dead ends. What would unblock it: a survey of which offsets *do*
+bound blocks (the 461 that work may share a property), or the level loader's
+own block-walking code, which needs the overlay relocation from Phase 3.
+
 ### Corrected header, over all 2,177 blocks
 
     +0x00  count       multiple of 16 on all; 42 distinct; never zero