diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md
index 30610493..f52ab86b 100644
--- a/docs/port/DECISIONS.md
+++ b/docs/port/DECISIONS.md
@@ -4497,3 +4497,58 @@ a 127–255 range looks entirely plausible, and nothing reports it.**
 ✅ And a free second instance of the loop-length decode from a pak neither of us
 was looking at: `py_ranking_btn01f`'s ramp ends at **t=90 inside a declared 120**
 — 30 units of hold, the same shape as the plate's 105-in-120.
+
+## Their "do not draw all five flashes" flag — checked, and it does not apply here
+
+The Decoder armed a draw capture before the title exists and caught the build-in
+on the console: `ptlogo_back2eff1` in frames 130–131, `eff2` at 133, `eff4` at
+133–135 — and **`eff3` never drawn at all.** Not a miss: a flash's peak is 2
+keyframe units, which at that run's pacing is **0.85 of a presented frame**, so
+which flashes get sampled is a matter of phase. The console shows a *subset* on
+any given play, and the warning was that drawing all five would read heavier than
+the real thing.
+
+**Checked rather than reasoned about.** Sweeping the port's build-in with
+`--no-hold`:
+
+| t | flashes drawn |
+|---|---|
+| 54, 56 | `eff1` |
+| 58 | `eff2` |
+| 60 | `eff2`, `eff3` |
+| 62 | `eff3`, `eff4` |
+| 64 | `eff4`, `eff5` |
+| 66, 68 | `eff5` |
+
+**The port draws them sequentially, never more than two at once**, and the two
+only overlap where their declared windows abut. That is the stagger the disc
+declares, not a pile-up — the pile-up was the `rest()` bug, and it is fixed.
+
+⚠️ **So the difference from the console is presentation rate, not content.** At
+60 fps each 2-unit flash gets ~2 frames; at the console's pacing it gets 0.85, so
+some are skipped. **A frame-by-frame comparison of the build-in against a console
+capture will therefore show flashes the console missed, and that is a fact to
+know rather than a bug to fix.** It is also why the settled-frame comparison —
+the one `verify-capture` makes — is unaffected: at t=198 none of the five is
+drawn.
+
+### Three things of theirs worth recording
+
+✅ **My top-level restriction was verified, not merely accepted**: top-level
+`[160, 236]` width 76, versus `[269, 540]` width 271 with the `ptloop` leaves
+included — an instant *after every top-level element has exited*. Worth having on
+their page, because the rule as described permits the wrong reading.
+
+✅ **The 120-unit loop is confirmed from the guest's own vertex data**, not
+inferred from pixels: the glow quad's per-vertex colour alpha *is* the element's
+fade alpha, giving an observed range of **0…80 against a decoded peak of 80**,
+exact and unfitted, over 20 cycle starts. Fitting the decoded ramp gives RMS
+13.16 alpha levels against **38.18 for the same ramp reversed** — if the shape
+carried no information those would be equal.
+
+📌 **A trap noted for whenever this port grows draw-stream tooling:** a 2D draw's
+identity is its **vertex geometry, not its bound texture**, because these sprites
+sample large shared pages. Matching on texture dimensions told them first that no
+flash is ever drawn, then that `ptbase2` and `pteff04` are drawn in frames 75–105
+— which are the intro movie, whose YUV planes are 640×360 targeting 1280×720.
+Two errors, opposite directions, one pass, neither loud.