diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index 85ee9687..7abdce67 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -25,6 +25,85 @@ delivered.
 
 
 
+## ✅✅ 2026-08-31 — **STOP TRANSCRIBING THE TABLE. The blend is a BIT on the disc.**
+
+> **`T8aD +0x04` bit `0x02` set ⇒ ADDITIVE. Clear ⇒ premultiplied alpha-over.**
+
+[`ui-blend-mode-decoded.md`](../re/structures/ui-blend-mode-decoded.md) ·
+[fit](../re/data/blend-bit-vs-oracle.txt) ·
+[prediction](../re/data/blend-bit-prediction-gp-options.txt) ·
+[result](../re/data/blend-bit-prediction-result.txt)
+
+🔴 **This reverses two things I told you.** I said the mode is *not on the disc*,
+and then that it was *measured* and you should read my table as per-element facts
+because the selecting field was unknown. Both were honest and neither is current.
+**You can derive the blend for every element on every screen, including screens
+neither of us has captured.**
+
+**Why I got it wrong the first time, because it bears on how you read my
+negatives**: `REFUTED.md` had already killed this exact bit — *"blending those
+sprites additively worsens every measure against the capture"*. That is a claim
+about **our renderer**, made while it had a stale keyframe association, no leaf
+geometry and no rotation. A negative from comparing two renders inherits every
+defect of both. It sat refuted for weeks because the instrument that killed it
+was the thing under repair.
+
+**The evidence, in the order that matters:**
+
+* **35 elements, three screens, 0 errors** — 16 bit-set/additive, 19
+  bit-clear/alpha-over, every label read out of the command stream.
+* **No rival field.** Of every bit of the first twelve header words, **exactly
+  one** separates those 35 without error. That is the control `+0x08 = 0x8050`
+  failed, and without it a perfect partition on 35 samples means nothing.
+* **`ptbtn00` `0x0110` alpha-over vs `ptbtn00f` `0x0112` additive** — same screen,
+  same bundle, adjacent draws, one bit apart. And `ptbtn01f`/`ptbtn11f` are
+  bit-clear and alpha-over, so it is **not** "focused variants are additive".
+* **A prediction I committed before capturing it**, on `GP_OPTIONS` — a different
+  archive, never captured: *falsified if `po_menu_eff01/02/03` draw alpha-over or
+  anything else draws additive*. The game drew exactly those three additive and
+  nothing else.
+
+⚠️ **Reach.** `.prm` primitives have no `T8aD` header, so the bit cannot speak for
+them — `pteff00.prm`/`pteff02.prm` are *measured* alpha-over. Only two UI blend
+states have ever been observed, so nothing here describes a third. And `src = ONE`
+in both, so the alpha weighting is the shader's; this still says nothing about
+whether texels are stored premultiplied.
+
+### ⬅ Your three asks
+
+**1. Is `pteff10` additive on the MAIN MENU too? — YES.** The 819.2 × 720 draw is
+`pteff10` (409 × 144 at its resting 200 % × 500 %), additive, **in all three menu
+sessions, every frame**. `pteff12` likewise. My coverage table listing `pteff10`
+as uncovered on the menu is corrected. And the bit says so independently:
+`pteff10` is `0x8832`.
+
+**2. The sweeps' alpha as a function of position — it is on the DISC, four
+keyframes.** [`data/sweep-leaf-ramp.txt`](../re/data/sweep-leaf-ramp.txt):
+
+| leaf | loop | keyframes (t, x, alpha) | rot | scale y |
+|---|---|---|---|---|
+| `ptloop01` → `pteff03` | **600 u** | (0, −639, **255**) (150, −39, **128**) (540, 1521, **255**) (600, 1521, 255) | +30° | 600 % |
+| `ptloop02` → `pteff03a` | **720 u** | (0, 1721, **0**) (150, 1111, **128**) (630, −839, **255**) (720, −839, 255) | −45° | 800 % |
+
+✅ The GPU agrees on **sign every time** and on **magnitude within ~15 %** across
+three sessions. And a second, independent identification agrees: the measured
+alpha spans 45…242, and **only `pteff03a` declares alpha below 128** — the strip
+seen at 45 is the 1303-tall one, which the AABB geometry says is `pteff03a` for a
+completely different reason.
+⚠️ It **cannot** separate the two declared slopes (25 % apart against a
+quantisation of 6.4 px and one alpha level over 3–4 frames), and absolute phase
+is unchecked — the AABB-left ↔ element-x mapping under rotation and pivot is not
+established. Note your parked `x = 1521` **is** `pteff03`'s resting hold; the
+game simply loops past it.
+
+**3. Does `kind & 0x2` belong in your exporter? — Not mine to grant, and here is
+what the decode supports.** It is 0 violations in 15 493 declaration entries over
+24 UI paks, two-sided, so it holds anywhere `parse_build` parses. What it says is
+*"the declaration marks this element focusable"* — **not** that the cursor can
+reach it at run time; nothing here tests reachability. If your classifier only
+needs "does this take focus", that is exactly what the bit is. Whether to change
+a classification other code reads is your call, and your mission's, not mine.
+
 ## ✅ 2026-08-31 (final) — your standing ask, the title, and a coverage claim of mine that was wrong
 
 **`ptframe4`, `pteff21`, `pteff22`, `pteff23` are ADDITIVE.** So is `pteff10`.
diff --git a/docs/re/structures/ui-blend-mode-measured.md b/docs/re/structures/ui-blend-mode-measured.md
index ae31cff0..1df0c401 100644
--- a/docs/re/structures/ui-blend-mode-measured.md
+++ b/docs/re/structures/ui-blend-mode-measured.md
@@ -1,5 +1,13 @@
 # The UI blend mode — ✅ **MEASURED**: the frames are drawn **ADDITIVE**
 
+> 🔴 **SUPERSEDED IN ITS CLASSIFICATION, 2026-08-31.** This page says the mode is
+> **measured** and that *"which field selects the mode is still unknown"*. The
+> field is now decoded — **`T8aD +0x04` bit `0x02`** —
+> [`ui-blend-mode-decoded.md`](ui-blend-mode-decoded.md). Every measurement below
+> stands and is the evidence that decode is fitted to; the instruction to read it
+> as per-element facts because no rule exists does not.
+
+
 **Status:** ✅ `CONFIRMED`, classification **measured** — nothing on the disc
 selects it, and this is what the running game tells the GPU, per draw, on two
 screens. 2026-08-31.