From a64afe151085c50b272d030cb903e01371650f99 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 12:57:39 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 66 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 6ef54504..198e8de5 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -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) ## 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.