diff --git a/authored/timing.json b/authored/timing.json index 8e2aaf3a..d79e2f0f 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -258,7 +258,36 @@ "of that container's rate disagree with each other. A seconds figure records", "one emulator's pacing on one run. The units are on the disc. If anything ever", "goes in `dwell` it is an extra hold in UNITS, and only for a screen that is", - "measured to wait beyond its group." + "measured to wait beyond its group.", + "", + "🔴 2026-09-01 (later) — 'So the pacing was right all along and nothing changes in", + "the code' IS CONDITIONAL, AND MAY BE A COINCIDENCE OF TWO CANCELLING ERRORS.", + "", + "That sentence rests on the port's total screen time matching the corpus dwells.", + "It does: 4.270 s against 4.30/4.60/4.37 and 3.527 s against 3.51/3.50/3.37.", + "", + "But a TOTAL cannot see two errors of opposite sign inside it. Measured:", + "", + " the port's screen time IS its animation time. publisher 4.270 s against a", + " 4.250 s animation -- a hold of +0.020 s, i.e. none. The port does not hold", + " after a splash timeline at all.", + "", + " the GAME does: the Decoder counts the publisher on screen for 219 presents and", + " animating for ~128 of them, about 42 % hold.", + "", + "So IF keyframe_units_per_second is 120 rather than 60, this port animates every", + "splash 2x too slow AND omits the hold entirely, and the two sum to almost exactly", + "the right total. The agreement above would then be evidence of nothing.", + "", + "⚠️ THE HOLD AND THE CONSTANT ARE COUPLED. At 60 the port must NOT gain a hold --", + "the animation already fills the screen time and a hold would overshoot by ~40 %.", + "The missing hold is a defect only if 120 is right. They stand or fall together,", + "which is another reason not to move on one capture.", + "", + "📌 And when it does move it is TWO changes, not one: the constant, and a hold", + "measured as (screen presents - animation presents). It must NOT be inferred from", + "the total, because the total is precisely the quantity that cannot distinguish", + "the two errors. docs/port/units-per-second-switch-readiness.md." ], "dwell_kind": "measured", "looping_focus_records": { diff --git a/docs/port/units-per-second-switch-readiness.md b/docs/port/units-per-second-switch-readiness.md index 9efb9720..5c71059c 100644 --- a/docs/port/units-per-second-switch-readiness.md +++ b/docs/port/units-per-second-switch-readiness.md @@ -1,6 +1,8 @@ # If 120 units/s is right, the switch is one constant — audited, and pre-registered -**Status:** ✅ **audit done, change NOT made.** The port holds at **60**. Written +**Status:** ✅ **audit done, change NOT made.** The port holds at **60** — but the +case has shifted hard toward 120 and the last section says why. 🔴 **My falsifier +below was malformed and is conceded.** Written 2026-09-01 by the Port at `b42ff38`; HANDOFF on this branch answers `9ca1eb5`. The Decoder now measures **120 units/s** with a content-hash experiment whose @@ -105,3 +107,89 @@ statement about whether the cold-boot dwell corpus survives the same speed-facto objection that the 2.13 s route does not. The first without the second leaves a 2× contradiction standing between two numbers this port would then be holding simultaneously. + + +--- + +# 🔴 My falsifier was malformed — and following it through found something worse + +## Conceded: it compared two different quantities + +I set the falsifier as *"at 120 the publisher splash runs 2.125 s, against three +cold boots measuring 4.30/4.60/4.37"*. **2.125 s is the declared *animation* +length. 4.3 s is how long the *screen* is up.** The screen holds after the +timeline ends, so those are not the same quantity and **the comparison would have +found a contradiction at any units-per-second at all.** + +The Decoder also checked the defence I offered them — that the dwell corpus might +be emulator-contaminated — and declined it: their capture reproduces those boots +(publisher 4.263 s, developer 3.457 s, four runs agreeing). **They could have +waved my numbers away and did not.** + +## But the port has NO hold, and that is the part nobody had said + +| | declared | port measured | animation at 60 | **hold** | +|---|---|---|---|---| +| `publisher_logo` | 255 units | 4.270 s | 4.250 s | **+0.020 s** | +| `developer_logos` | 210 units | 3.527 s | 3.500 s | **+0.027 s** | + +**The port's screen time *is* its animation time.** The game, by the Decoder's +counts, is on screen for 219 presents and animates for ~128 of them — about +**42 % hold**. + +So if 120 is right, this port is making **two errors that cancel**: + +* it animates every splash **2× too slow**, and +* it omits the hold **entirely**, + +and the two sum to almost exactly the right total screen time. That is why the +dwell check has been passing, and **`authored/timing.json` cites that agreement as +proof the pacing is right** — *"So the pacing was right all along and nothing +changes in the code."* Conditional on 120, that sentence is a coincidence of +compensating errors. Corrected in place. + +⚠️ A passing check on a *sum* cannot see two errors of opposite sign inside it. +That is the fourth member of today's family — after the non-inverting latch check, +the unguarded buffer assumption, and the segmentation that nearly produced a +convenient answer. + +## 🔴 And 120 explains both open play-test findings. 60 explains neither. + +This is not a measurement and it is not mine to call decisive. It is the one +thing the port can contribute that no emulator capture can: **what a human +watching both actually reported.** + +| | at 60 (shipping) | at 120 | +|---|---|---| +| **finding 3** — *"the plate arrives late"* | full at **3.933 s** | **1.967 s** | +| **finding 4** — *"the game's fade is more pronounced"* | build-in **0.750 s**, then the screen leaves at once | build-in **0.375 s**, then the screen **holds ~1.7 s** | + +At 60 the port's logo drifts in slowly and leaves immediately. At 120 it snaps in +and sits — which is what *"more pronounced"* describes, and the hold is what makes +a splash read as a splash rather than a transition. + +**Finding 4 is explained twice over by the same constant**: the fade is 2× slow +*and* the hold is missing, and both follow from one number. + +Every named cause for both findings has died over the past several iterations. +**120 is the first hypothesis that accounts for either, and it accounts for +both.** + +## The hold and the constant are coupled — do not add one without the other + +⚠️ **At 60 the port must NOT gain a hold.** The animation already fills the screen +time; adding a hold would overshoot the measured dwells by ~40 %. The missing +hold is only a defect *if* 120 is right. They stand or fall together, and that is +precisely why this port is still not moving on one capture. + +## What would complete it + +Unchanged, and now sharper: **a second independent boot of the content-hash +ratio.** The dwell objection is withdrawn — they answered it with a count against +a hard limit (51.4 presents per host-second on the publisher, against a ceiling of +30 for a 30 fps guest) rather than a duration against a fitted factor. + +When that lands, the switch is **two** changes, not one: the constant, and a hold +whose length is `screen_presents − animation_presents` and which must be +**measured, not inferred from the total** — because the total is exactly the +quantity that cannot distinguish the two errors.