# ✅ The UI clock is FRAME-based: **1 unit per present**, verified by a forced frame rate

**Status: ✅ measured, by a designed test that REFUTED my own previous claim.**
2026-09-01. Instrument: ⟨capture⟩ ×3, one of them at a deliberately altered
presentation rate. Answered against
[`time-based-clock-preregistration.md`](time-based-clock-preregistration.md),
committed before the run.
Data: [`data/forced-framerate-test.txt`](data/forced-framerate-test.txt).

---

## The test, and it went against me

I claimed the clock was **time**-based and that `units/second ≈ 60` was the
invariant. I predicted that halving the frame rate would **double** the alpha step
and **leave** the dwell unchanged. I ran `--framerate_limit=30`:

| | frame-based | **time-based (my claim)** | **measured** |
|---|---|---|---|
| presents/s | ~27 | ~27 | **28.4** |
| modal Δα per present | 17 unchanged | 34 doubled | **17 — unchanged** |
| units/s | ~30 halved | ~60 unchanged | **30.2 / 30.3 — halved** |
| publisher dwell | ~8.5 s | ~4.2 s | **8.450 s — doubled** |
| developer dwell | ~7.0 s | ~3.5 s | **6.923 s — doubled** |

**Every discriminating row went to the frame-based column. My claim is refuted.**

Both controls passed first, as pre-registered:

* **Control 1, read before the step:** the limiter took effect — 28.4 presents per
  host-second against 51–55 before, and the interval histogram's mass moved from
  **one** 60 Hz vblank to **two** (422 of 468). Had this failed, neither
  prediction would have been tested.
* **Control 2:** all **8/8** splash quad rects identical to the reference set, so
  nothing but the frame rate differs between runs.

## What is actually true

> **The UI clock advances exactly 1 unit per presented frame.** The step is
> **17** on every quad in every capture — at 28.4, 51.4 and 54.8 presents per
> second. `255 × 1 / 15 = 17` with the declared `T = 15`.

So `units/second = presents/second`, and the *seconds* are whatever the frame
rate makes them. The dwell in seconds is **not** a property of the game.

## The conclusion for the port is unchanged, and now properly grounded

The guest, unconstrained, presents **once per 60 Hz vblank** — measured before the
limiter was applied (one vblank 71.7 %, two 24.6 %), and confirmed by this run
moving cleanly to two vblanks when told to. One unit per present at 60 presents
per second is **60 units/s**.

**The port's 60 is right.** It was right when I first said so for a bad reason,
right when I withdrew it, right when I replaced it with 120, and right now — the
difference is that the mechanism is finally tested rather than inferred.

## 🔴 What this withdraws, including of my own

* **`units-per-frame-is-not-a-constant.md` is WRONG in its central claim** and is
  superseded by this page. Units per frame *is* a constant; it is 1.
* **My "dwell is stable across runs because a time-based clock is immune to
  dropped frames"** was a real prediction and it **failed** — the dwell doubled.
  The four-run agreement at 4.2 / 3.5 s that I read as evidence for a time-based
  clock was just four runs at similar frame rates.
* ⚠️ **`h3-units-per-frame-measured.md`'s `+34` is now the anomaly**, not the rule.
  It reports 34 per label at 27.2 labels/s; this capture reports 17 per present at
  28.4 presents/s. **Both cannot be presents.** The likeliest reading is that an
  `h3` label is not one present, and until that is checked its "2 units per frame"
  should not be used. I have not checked it, and I am not asserting it is wrong —
  only that it and this disagree at nearly the same rate, which one of them must
  explain.

## The methodological point, since this is the fourth reversal today

Three of my four positions on this number came from **inference over a measured
quantity**; this one came from **changing an input and watching what moved**. The
opportunistic comparison — two captures that happened to differ — pointed exactly
the wrong way, because I had no control on what else differed between them. The
designed test cost one capture and settled it against my own expectation.

📌 And the pre-registration did its job in the only way that really counts: it
made the refuting result **unmissable**. Had I not written down "34, doubled"
first, "17" would have been easy to read as confirmation of something.

## Reach

⟨capture⟩ ×3 at two deliberately different rates, one machine, English locale.
The invariance of the step is the load-bearing part and now rests on a
manipulation rather than a coincidence. ❔ Whether the console presents at 60 is
still an inference from the vblank cadence — a short one, since a 360 vblanks at
60 Hz, but an inference.