port: my predictor holds 5/5, but the evidence separating it from width does not

The Decoder concluded width does not predict settle-pose quality but my
transient-peak/late-arrival predictor does, on the grounds that the splashes are
narrower than the menu (window 8) and win by 75x.

The predictor holds 5 of 5 on my capture-backed screens: mid-ramp count is 2 on
exactly the two screens where settle loses and 0 on the three where it wins.

But their splash window disagrees with my export by 20x. Recomputed from raw
top-level keyframe times, publisher_logo is [0,15,30,45,235,239,251,255] whose
widest gap is 45->235 = 190; developer_logos gives 145. We agree exactly on title
(76) and main_menu (12), so the divergence is specific to the splashes.

Consequence: the splashes are the WIDEST of my five, not the narrowest, so width
and mid-ramp predict identically and are perfectly confounded across my screens.
The case that separated them evaporates -- my predictor is not established as
better than width by this evidence, which is a different claim from being wrong.

My numbers also make their own census coherent: at window 8 the splashes would sit
in the 40.9% bucket while showing zero mid-ramp elements, a paradox; at 190/145
they sit in the wide bucket where zero is what the census predicts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-155 sections. Search this before re-deriving anything.
+156 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -166,6 +166,7 @@ dies, which is what this file is for.
 * [Adjudicating the Decoder's `rest()` replacement against the game](#adjudicating-the-decoders-rest-replacement-against-the-game)
 * [The boot's own end frame, scored against the game for the first time](#the-boots-own-end-frame-scored-against-the-game-for-the-first-time)
 * [Refutation attempt: the settle-instant candidate is **not** uniformly better](#refutation-attempt-the-settle-instant-candidate-is-not-uniformly-better)
+* [My own predictor holds — and the evidence that made it *better than width* does not](#my-own-predictor-holds--and-the-evidence-that-made-it-better-than-width-does-not)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -9027,3 +9028,66 @@ seconds** — 3000 units, past the end of everything. Both poses returned RMSE 5
 different inputs producing exactly the same output is not a result; it is the
 instrument saying it ignored the input. Same tell as the two `--script` runs that
 came out bit-identical because the capture fired before the first press.
+
+## My own predictor holds — and the evidence that made it *better than width* does not
+
+The Decoder censused my `ptmsg` failure mode disc-wide (25.5 % of elements caught
+mid-ramp at their screen's settle instant) and concluded that **window width does
+not predict quality but my predictor does**, on the grounds that the splashes are
+*narrower* than the menu — window **8** — and win by 75×.
+
+✅ **The predictor itself holds, 5 of 5** on my capture-backed screens:
+
+| screen | mid-ramp at settle | measured outcome |
+|---|---|---|
+| `title` | **0** | settle wins 9× |
+| `publisher_logo` | **0** | settle wins 75× |
+| `developer_logos` | **0** | settle wins 33× |
+| `main_menu` | **2** (`ptmsg`, `pteff10`) | settle **loses** |
+| `extras` | **2** (`ptmsg2`, `pteff20`) | settle **loses** |
+
+🔴 **But their window figure for the splashes disagrees with my export by 20×**, and
+that figure is the whole of the argument.
+
+| screen | their window | mine |
+|---|---|---|
+| `title` | 76 | **76** ✅ |
+| `main_menu` | 12 | **12** ✅ |
+| `publisher_logo` | 8 | **190** ❌ |
+| `developer_logos` | 8 | **145** ❌ |
+
+Recomputed independently from the raw top-level keyframe times rather than read
+off my own `settle_window` field: `publisher_logo`'s times are
+`[0, 15, 30, 45, 235, 239, 251, 255]`, whose widest keyframe-free gap is
+**45 → 235 = 190**. `developer_logos` gives `45 → 190 = 145`. We agree exactly on
+the two screens where our methods coincide, so this is a divergence specific to
+the splashes, not a difference of definition throughout.
+
+### Why this matters more than a corrected number
+
+**The splashes are the *widest* of my five, not the narrowest.** With that, the
+data reads:
+
+| screen | window | mid-ramp | outcome |
+|---|---|---|---|
+| `publisher_logo` | 190 | 0 | wins 75× |
+| `developer_logos` | 145 | 0 | wins 33× |
+| `title` | 76 | 0 | wins 9× |
+| `main_menu` | 12 | 2 | loses |
+| `extras` | 12 | 2 | loses |
+
+🔴 **Width and mid-ramp now predict identically and are perfectly confounded.** My
+five screens cannot separate them, and the case that did separate them — narrow
+splashes winning hugely — evaporates. So my predictor is *not established as
+better than width* by this evidence. It may still be the mechanism; that is a
+different claim from having shown it.
+
+✅ **And my numbers make their own census coherent**, which is the strongest thing
+I can say for them. Their buckets run 40.9 % mid-ramp on windows under 10 and
+11.7 % on wide ones. At window 8 the splashes would sit in the worst bucket while
+showing **zero** mid-ramp elements — a standing paradox. At 190 and 145 they sit
+in the wide bucket, where zero is exactly what the census predicts.
+
+⚠️ I am not claiming their tool is broken; `--settle` may report a different
+quantity than the widest keyframe-free gap. But one of the two readings is wrong,
+and until it is settled the width hypothesis is **not** refuted.