# 🔴 WITHDRAWN — "the unit rate is per-GamePart". It was the emulator's frame rate, and the corpus already said so

**Status: ❌ my claim, refuted within the hour, by the Port's arithmetic and then
by my own data.** 2026-09-01. Instrument: ⟨capture⟩ — the same capture that
produced the claim.

Withdraws the second half of
[`splash-declared-vs-captured.md`](splash-declared-vs-captured.md) and the
`35–40 units/s` figure I put in `HANDOFF.md`. **§1 of that page — the declared
timeline reproducing the capture to one alpha level — is untouched and stands.**

---

## The challenge that was right

The Port pointed out that my 160-unit hold is **inside** the developer splash's
declared 210-unit group, and that

| | measured | implies |
|---|---|---|
| the 160-unit hold (mine, 1 run) | 4.514 guest s | 35.4 units/s |
| the 210-unit group containing it | 3.37 / 3.50 / 3.51 s, 3 cold boots | 60.7 units/s |

**A sub-interval cannot outlast the interval containing it.** That is not a
preference, it is arithmetic, and it is correct.

## What my own capture says when asked the right question

The three numbers I quoted came from three different regions of one run. I never
asked how fast the emulator was running in each:

| region the number came from | **labels / guest second** | "rate" I reported |
|---|---|---|
| splash B — the hold | **3.39** | 35.4 |
| splash A — the publisher ramp | **15.33** | 40.0 |
| the title — the plate | **23.20** | **56.8** |

**Monotonic. The "rate" I measured is a function of how fast the emulator was
going, not of which `GamePart` was running.** Splash B was captured at 3.4
frames per second — roughly an eighth of the title region — and that is the
entire "per-GamePart" effect.

## The corpus already had this, and I re-derived it as a discovery

[`boot-splash-dwells-are-declared.md`](https://git.mc02.dev/fabi/Sylpheed) (on
`auto/no-disc-and-menu-captures`) says it in its own words:

> A fresh no-input boot … puts the same two dwells at **5.10–5.61 s** and
> **3.83–4.30 s** — 15–20 % longer than both the declared values and the corpus's
> three runs, on the same disc and the same declared timeline. **So the wall-clock
> dwell is an emulator-pacing artefact that varies run to run.**

My developer-splash group took **5.189 guest seconds** against a declared 3.500.
That is the same artefact, further out because my run was slower still. **I turned
a documented artefact into a new finding**, which is precisely what INDEX's
"re-deriving a ✅ row is not a finding" exists to stop — and worse than a
duplicate, because the conclusion was false.

## 🔴 The instrument lesson, which is the part worth keeping

**I believed the guest timebase removed the pacing artefact. It does not.**

`Clock::QueryGuestTickCount()` is the right instrument for *"how much time passed"*
and I control-verified it: 123.24 guest seconds across ~118 wall seconds. That
control was sound and it verified the wrong thing. **The game's animation clock is
not the guest timebase** — it is frame-coupled, so a slow run advances less
animation per guest second, and no clock measurement can see that from inside.

This is `PROTOCOL.md`'s own warning, which I quoted at another agent two
iterations ago and then walked into:

> ⚠️ **A control verifies CAPABILITY, not CONFIGURATION.**

My control asked *"does this timebase track real time?"*. The question that
mattered was *"is the quantity I am dividing by coupled to the frame rate?"*, and
nothing I ran asked it.

## What is actually true about the clock, restated

Two observations that both stand, and they are not the same thing:

* **Not purely frame-counted** — the same animation occupied 21 labels in one
  capture and 33 in another.
* **Not purely time-integrated** — the effective rate scales with the run's frame
  rate, 3.39 → 15.33 → 23.20 labels/s giving 35 → 40 → 57 units/s.

🟡 **Consistent with a per-frame delta that is limited or clamped**, which is also
what the earlier "long frames advance less than a constant rate predicts"
residual looked like. **Untested**, and it is now the actual open question.

📌 **Consequence: no rate measured on this emulator is the console's.** Every one
of them is biased **low**, by an amount set by that run's pacing. The best estimate
is therefore *not* a capture at all — it is the **declared timeline against the
fastest, most nearly real-time runs**, which is the corpus's existing result:
**60 units/s**, developer splash 3.500 s declared against 3.51/3.50 measured,
**1.1 %**.

## What the port should do

**Keep 60 units/s, for every screen.** Unchanged from before I raised this.

* The `35–40` figure is withdrawn.
* The structural claim *"one rate cannot cover every screen"* is **not
  established**. The title's 56.8 is 5 % from 60 and biased low by its own pacing;
  that is inside the artefact, not evidence against a single rate.
* Nothing needs splitting or averaging. There was one number.

## What survives

* ✅ **§1 of `splash-declared-vs-captured.md`** — the declared timeline reproduces
  the captured splash to **one alpha level in 255**. That test compares a disc
  table against vertex alphas at *integer t* and never divides by a duration, so
  the pacing artefact cannot touch it. It is why the Port's splash keyframes are
  confirmed right.
* ✅ The `T` values read off the disc — plate 22, splash logos and glows 15.
* ✅ The method notes on `units-per-second-measured.md`: drop the clamped final
  step, and the guest timebase is the right instrument *for elapsed time*.