diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md
index ab5c9099..e582b619 100644
--- a/docs/port/DECISIONS.md
+++ b/docs/port/DECISIONS.md
@@ -16515,3 +16515,44 @@ number could not settle this even at peak α.
 ⚠️ Their gate `wait_plate_pulse.py` fires on a green-glyph count in [500, 2500] and
 has logged 740 and 1004, so the window may come free or may sit outside [35, 50]
 entirely. Their caveat, carried across rather than assumed away.
+
+### The plate identification is confirmed by size; the frame spacing does NOT fit my ramp
+
+Reading the Decoder's existing title draw log from the ref
+(`captures/ui-draws/blend-title-2026-08-31.log`), the additive quad they point at
+is draw 8/19/…, `blend=0x01010101`, per-vertex `col=44FFFFFF` / `43FFFFFF` /
+`38FFFFFF` — α **68, 67, 56**.
+
+✅ **Identification confirmed independently, by size.** The quad measures
+**537.6 × 75.6** px and `ptbtn00f.png` ships at **537 × 76**. That is the plate's
+highlight, and it settles it without using their attribution.
+
+✅ **And their free check on my ramp holds:** all three alphas are ≤ my declared
+peak of **80**, none equals a keyframe value, so the game interpolates rather than
+steps. Two independent decodes agreeing — mine from the export, theirs from the
+command stream.
+
+🔴 **But the frame-to-frame spacing does not fit, and I am recording that rather
+than passing over it.** `HANDOFF` Q1 gives **2 units per rendered frame**. On my
+falling segment (slope −1.744 α/unit) that predicts, from α=68:
+
+| | frame 1 | frame 2 | frame 4 |
+|---|---|---|---|
+| observed | 68 | **67** | **56** |
+| my ramp at 2 units/frame | 68 | 64.5 | 57.6 |
+| at 1 unit/frame | 68 | 66.3 | 62.8 |
+| at 0.5 | 68 | 67.2 | 65.4 |
+
+**No constant rate fits both steps** — 0.5 matches frame 2 and misses frame 4 by
+9; 2 matches frame 4 and misses frame 2 by 2.5.
+
+⚠️ **Three candidates and I cannot separate them:** my ramp is wrong somewhere; the
+log's frame numbering is *captured* frames rather than engine frames (**it skips
+from 2 to 4**, so it is demonstrably not a dense engine sequence); or emulator
+pacing varies between them. The middle one is the most likely and the cheapest to
+check, and it is theirs.
+
+📌 This does **not** disturb the ramp's *shape* or *ceiling*, which the alphas
+confirm. It disturbs only the claim that I could pose my renderer at their captured
+instant by stepping units — so the vertex alpha remains the right readout, and
+**inferring the phase from a frame index would have been wrong.**