diff --git a/crates/gc-extract/tests/disc.rs b/crates/gc-extract/tests/disc.rs
index f17f1e5..e1d74d4 100644
--- a/crates/gc-extract/tests/disc.rs
+++ b/crates/gc-extract/tests/disc.rs
@@ -116,7 +116,22 @@ fn unpacks_and_matches_the_committed_table() {
 
     assert!(
         report.ok(),
-        "unpacked data does not match the committed table:\n{}",
+        "u/// **THE NAME IS HISTORICAL AND SO IS WHAT IT MEASURES.**
+///
+/// This test asserts a 16-byte element with fixed-point texcoords at `i16[4]`
+/// and `i16[5]`. `e5cd3df` retracted exactly that: the tie vertex stride is not
+/// 16, roughly half of all records are a flat 16-byte array and the rest are
+/// neither that nor a VIF packet stream, and the correct stride is not yet
+/// known.
+///
+/// Kept and passing, for the same reason as its neighbour -- it is the record of
+/// what the 16-byte reading produces, so the retraction is visibly about the
+/// stride rather than the arithmetic. Renaming or deleting it would erase the
+/// thing the retraction is a retraction *of*.
+///
+/// Do not quote the 82.5% figure as a property of tie vertices. It is a property
+/// of one reading of the vertex region, on a population the retraction disowned.
+npacked data does not match the committed table:\n{}",
         report.summary()
     );
     assert_eq!(
@@ -4375,6 +4390,23 @@ fn tie_vertex_element_is_16_bytes_with_fixed_texcoords() {
 ///
 /// A constant would score 100%, so `(6,7)` at 89.5% is a real pair rather than
 /// the `4096, 0` artifact it looks like. See `docs/formats/core-data-regions.md`.
+///
+/// **MEASURES THE RETRACTED 16-BYTE LAYOUT.** `e5cd3df` established that the tie
+/// vertex stride is not 16 -- roughly half of all records are a flat 16-byte
+/// array and the rest are not, and the correct stride is unknown. The population
+/// here (89,341 + 6,271 = 95,612 "vertices") is therefore a 16-byte-stride
+/// reading that has been withdrawn, and the percentages describe that reading
+/// rather than any established element layout.
+///
+/// It is kept, and kept passing, for one reason: it is a faithful record of what
+/// the 16-byte reading produces, so the retraction can be seen to be about the
+/// *stride* and not about the arithmetic. A test that went away with the claim
+/// would leave no way to check that.
+///
+/// The per-vertex rate here and the per-distinct-value rate elsewhere disagree
+/// sharply, and both are correct -- 92.9% of vertices use the handful of UV-corner
+/// values that are multiples of 4096, while only 16 of `i16[4]`'s 1,488 distinct
+/// values are. That gap is the artifact, stated as two denominators.
 #[test]
 fn tie_vertex_layout_is_selected_by_i16_3_high_byte() {
     require_disc!();
diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index 2dc430c..a1cac0d 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -3340,3 +3340,46 @@ addresses** did not transfer, landing in NOBITS memory. A struct's field order i
 different kind of claim from an address in a program's layout, so the failure of
 one does not impeach the other -- but the distinction is real, and `PROVENANCE.md`
 now says which is which.
+
+
+## Two tie tests still measure a layout that was retracted
+
+The stride retraction (`e5cd3df`) disowned the 16-byte element reading and the
+95,612-vertex population that came with it. Two committed tests still compute
+exactly those figures and still pass:
+
+    tie_vertex_element_is_16_bytes_with_fixed_texcoords
+    tie_vertex_layout_is_selected_by_i16_3_high_byte
+
+They pass because the arithmetic is self-consistent about a **withdrawn**
+population -- the same shape as the chunk uniformity claim, one level up. The
+parser slices at 16 bytes, the test reads the slices, the numbers agree, and
+nothing in the loop can notice that the stride is wrong.
+
+Both are kept, and marked. The reason is specific: each is the record of what the
+16-byte reading *produces*, so the retraction is visibly about the stride rather
+than about the arithmetic. Deleting or renaming them would erase the thing the
+retraction is a retraction *of*, and there would be no way to check later that the
+numbers moved because the layout changed rather than because someone edited a
+constant.
+
+The marking says so at the top of both:
+
+> Do not quote the 82.5% figure as a property of tie vertices. It is a property
+> of one reading of the vertex region, on a population the retraction disowned.
+
+### Two denominators, both correct, 92.9% apart
+
+The layout test reports `(4,5)` as 12-bit fixed on **92.9% of vertices**. A
+different measurement, taken on flat records only, found that only **16 of 1,488**
+distinct `i16[4]` values are multiples of 4096.
+
+Both are right. Most vertices use the handful of UV-corner values -- `(0,0)`,
+`(0,4096)`, `(4096,4096)`, `(4096,0)` -- which are all multiples of 4096, so the
+per-vertex rate is high. The other 1,472 values are not, so the per-distinct-value
+rate is 1%.
+
+That gap is the artifact, and naming both denominators is the most useful thing
+this section can do about it. A percentage over vertices and a percentage over
+distinct values answer different questions, and only one of them was ever asked
+about.