diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md
index 4369a145..6fed9461 100644
--- a/docs/port/BLOCKED.md
+++ b/docs/port/BLOCKED.md
@@ -171,9 +171,16 @@ measured blend moved 26 319 px at phase 20 while reporting exactly zero here.
 What is unverifiable on my side is whether *my renderer* now reproduces it. One
 capture of the title with the plate at a visibly mid-pulse instant closes it.
 
-⚠️ Cheap alternative if a fresh capture is expensive: the plate's alpha at a known
-phase, from the existing `plate-pulse-measured.md` run, would let me check the
-level rather than the picture.
+✅ **NARROWED 2026-08-31, and the cheap alternative is no longer needed** — the
+ramp was already in my own export. `ptbtn00f` declares eight keyframes on a
+120-unit loop peaking at α **80** and holding it across **t = 35…50**, and the port
+reproduces that ramp at **r = +0.9982** against the declared values. So *when* and
+*how strongly* the port draws the highlight is verified without an oracle.
+
+📌 **The ask is now one capture in a named window: t mod 120 ∈ [35, 50].** Only the
+composite is open. The existing capture provably cannot answer it — at t=237 the
+phase is 117 (α ≈ 0), and the harness independently pins phase 0 (α exactly 0);
+both readings of the clock agree.
 
 ## New ask, 2026-08-31 — three, derived from today's completed blend delivery, port `HEAD` `49a6333`
 
diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md
index b8dd7789..475dce80 100644
--- a/docs/port/DECISIONS.md
+++ b/docs/port/DECISIONS.md
@@ -16432,3 +16432,40 @@ plate cannot see the plate's pulse.** Now stated in the tool, next to the pose.
 ⚠️ **Not verified against the oracle.** The blend is theirs and measured; that the
 *port* now draws it correctly is not something any capture I hold can confirm,
 because every title-plate capture is at the blind phase. Filed.
+
+### The plate's ramp was already in my export, and the renderer applies it correctly
+
+The Decoder is paused and could not take the capture I asked for, and pointed out
+that the disc half might not need them. It did not — **and it was already in
+`export/screens/title/press_start.json`.** `ptbtn00f` carries eight keyframes on a
+120-unit loop, alpha in the high byte of `fade_argb`:
+
+| t | 0 | 6 | 29 | 35 | 50 | 58 | 97 | 105 |
+|---|---|---|---|---|---|---|---|---|
+| α | **0** | 6 | 74 | **80** | **80** | 74 | 6 | **0** |
+
+✅ **Two things follow without an oracle.**
+
+**1. The blind phase is confirmed from the disc.** α is *exactly 0* at phase 0 —
+so `verify-capture`'s pose sees nothing, and that is a property of the data, not an
+artefact of how I rendered it.
+
+**2. My renderer applies the ramp faithfully.** Rendered contribution against
+declared α across the cycle:
+
+| phase | 0 | 20 | 40 | 60 | 80 | 100 |
+|---|---|---|---|---|---|---|
+| declared α | 0 | 47.4 | 80.0 | 70.5 | 35.6 | 3.8 |
+| rendered Δ | 0.00 | 20.70 | 32.55 | 29.24 | 16.55 | 2.59 |
+
+**r = +0.9982**, slope 0.4036 levels per α unit. So *when* and *how strongly* the
+port draws the highlight is right; only the **composite** is unverified.
+
+📌 **And the capture cannot settle it, under either reading of the clock.** It is
+posed at t=237; 237 mod 120 = **117**, where α ≈ 0 — and the harness independently
+pins `--loop-phase=0`, where α is exactly 0. Both readings agree, which is worth
+stating because I did not have to assume which clock the record runs on.
+
+⚠️ So the ask narrows to one number and gets a precise window: **a capture anywhere
+in t mod 120 ∈ [35, 50]**, where α holds at its peak of 80. Everything else about
+the plate is now settled on my side.