diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index e2879ff3..f3bacea2 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -79,18 +79,24 @@ authored version can be deleted.
   `ptlogo_back2eff1…5`. 🟡 Those five are also the group with the **known
   unsolved paint-order tie-break** (key `0x8083`) — same screen, same elements —
   but a blend-order swap explains white-instead-of-pink poorly.
-  🟡 **A quantified cause for the GEOMETRY**: these elements' declared **pivots do
-  not match their own textures**. `ptlogo_back2`'s pivot `(500,117)` is exactly
-  half the **Japanese** sprite (1000×234), not its own English one
-  (1118×262) — off by **59 px**, the right order to make the swoosh too thick and
-  too far right. 24 of 109 title elements are off by > 8 px, concentrated on
-  `ptlogo*`, and it cuts both ways (the JP build's `ptlogo1` is off by 40).
-  ❔ Whether it *bites* depends on which pivot the compositor uses — **not
-  checked**.
+  🔴 **The pivot mismatch is NOT the cause — checked and refuted.** These elements'
+  declared pivots really do belong to the *other language's* sprite
+  (`ptlogo_back2`'s `(500,117)` is exactly half the Japanese 1000×234, not its own
+  English 1118×262; 24 of 109 title elements are off by > 8 px). **But it cannot
+  affect this render**: `blit` sizes a sprite from its **texture**, and applies the
+  pivot only as `kf.x − pivot·(scale−100)/100` — and **all seven swoosh elements
+  are scale `(100,100)` at every keyframe**, so the term is zero.
+  ⚠️ It *would* bite `ptlogo1`/`ptlogo2`, which scale 100 → 150 during the
+  build-in. Not at rest, and not on the swoosh.
   🔴 **Ruled out for the COLOUR**: every swoosh keyframe's fade is `0x??ffffff`
   (white RGB, alpha only), no tint is non-white, and the texture decodes
-  *blue*-leaning (175,174,198). The magenta must come from blending. ❔ Not
-  diagnosed.
+  *blue*-leaning (175,174,198).
+  🟡 **What is left is the BLEND.** Size and position are the texture's own and
+  match; fade, tint and texture colour are all ruled out. Seven overlapping
+  mostly-transparent sprites (`ptlogo_back2` 5.4 % opaque, its glow 10.3 %, the
+  five `eff` segments 10–23 %, all white or warm) stacked with plain alpha-over
+  saturate to opaque white — which is exactly what we draw, and would read as
+  "thicker" against the game's thin coloured stroke. ❔ Not diagnosed.
   🔴 **Refuted:** it is *not* that our dim covers the whole frame instead of
   sitting beneath the UI — the logo reads +2.36 against a background of −0.74, so
   the paint order is being honoured.
diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md
index bec151e0..de58af1a 100644
--- a/docs/re/REFUTED.md
+++ b/docs/re/REFUTED.md
@@ -35,6 +35,13 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "the title logo elements' wrong pivots (off by up to 59 px, authored against the
+  other language's sprite) explain the swoosh rendering too thick" → **mine, and
+  refuted.** `blit` sizes from the texture and applies the pivot only as
+  `pivot·(scale−100)/100`; all seven swoosh elements are scale `(100,100)` at every
+  keyframe, so the term is zero. The mismatch is real but inert here — it would
+  bite `ptlogo1`/`ptlogo2`, which scale to 150 during the build-in.
+  [`ui-title-build-map.md`](ui-title-build-map.md)
 * "the title screen loops at ≈ 2.2 s" → **mine, and doubly wrong.** The title
   *art* is near-static (wordmark sd 0.06); the 2.3 s pulse is the
   **`PRESS Ⓐ BUTTON` plate**, which is a *different build* (2, not 4). Localised
diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md
index 348efa9d..4da540c3 100644
--- a/docs/re/ui-title-build-map.md
+++ b/docs/re/ui-title-build-map.md
@@ -464,11 +464,35 @@ Note it cuts **both ways**: the Japanese build's `ptlogo1` is off by 40 px too.
 A 59 px offset on a 1118 px sprite is the right order to produce "too thick and
 extending too far right", which is what the crop shows.
 
-❔ **Whether this is the cause depends on which pivot our compositor uses** — the
-declared one or the texture's own. That was **not** checked, so this is a
-quantified candidate, not a diagnosis. And it does not explain the **colour** at
-all: nothing in the fade, tint or texture is pink, so the magenta edge must come
-out of blending.
+### 🔴 …and that candidate is refuted
+
+Checked, as promised. `ui_layout`'s `blit` takes the drawn size from the
+**texture** (`img.width`/`img.height`), and uses the pivot only for the
+scale anchor:
+
+```rust
+let ox = kf.x - (pivot_x as i32 * (sx_pct as i32 - 100)) / 100;
+```
+
+At `sx_pct == 100` that term is **zero**. And **every one of the seven swoosh
+elements is scale `(100,100)` at every keyframe** — `ptlogo_back2`,
+`ptlogo_back2eff` and `ptlogo_back2eff1…5` all report a single scale. So the
+pivot mismatch, real as it is in the data, **cannot** move or resize the swoosh in
+our render.
+
+⚠️ It is not harmless everywhere: `ptlogo1`/`ptlogo2` run scales
+`100 → 101 → 103 → 112 → 150` during the build-in, so there the wrong pivot *does*
+displace them — during the animation, not at rest.
+
+### 🟡 So the swoosh defect is a BLEND problem, by elimination
+
+Position and size are the texture's own and are right; fade is white-with-alpha;
+tint is white; the texture is blue-leaning, not pink. What remains is how the
+seven overlapping sprites are combined — `ptlogo_back2` is only **5.4 % opaque**,
+its glow 10.3 %, the five `eff` segments 10–23 %, all white or warm. Stacked with
+plain alpha-over they saturate toward opaque white, which is what we draw and
+would read as "thicker" beside the game's thin coloured stroke. ❔ Not diagnosed —
+no blend mode has been identified in the data.
 
 ### 🔴 Refuted on the way