diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index 10d24b1b..b8f2c25f 100644
--- a/docs/re/METHOD.md
+++ b/docs/re/METHOD.md
@@ -275,3 +275,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   against the stale binary and produced byte-identical "before" and "after"
   renders — which reads exactly like "the change had no effect" rather than "you
   ran the old code". Run the binary cargo actually wrote, or `cargo run`.
+* **A pivot-equality test conflates rounding with real breakage.** Checking
+  `pivot == texture/2` over `GP_TITLE` flagged 74 % as mismatched, which reads as
+  a systemic decode failure. Split by magnitude it is 17 exact, 54 off by ≤ 1 px
+  (odd dimensions rounding), and only **24 off by > 8 px** — and those 24 are the
+  real finding, concentrated on one element family. Bucket a mismatch by size
+  before reporting a rate.
diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md
index ddaf6ddb..348efa9d 100644
--- a/docs/re/ui-title-build-map.md
+++ b/docs/re/ui-title-build-map.md
@@ -425,8 +425,50 @@ share key `0x8083`, the game paints them `14,15,18,16,17`, the stable sort paint
 (22 568 px) and against `eff4` (32 395 px)". **Same screen, same elements.**
 
 ❔ But a blend-order swap is a poor explanation for *white instead of pink* — that
-looks like a tint or blend-mode problem, so I would expect a second cause. **Not
-diagnosed**, and recorded as two candidate leads rather than one answer.
+looks like a tint or blend-mode problem, so I would expect a second cause.
+
+### 🟡 A quantified cause for the GEOMETRY: the pivot belongs to the other language
+
+The fade and tint fields are **not** the culprit — every keyframe of every swoosh
+element carries `0x??ffffff`, white RGB with only alpha varying, and no tint is
+anything but `0xffffffff`. Nor is the texture pink: `ptlogo_back2.t32` decodes
+**blue**-leaning (175, 174, 198) and its glow warm (255, 253, 234).
+
+What *is* wrong is the **pivot**. Checking every `GP_TITLE` element whose texture
+we decode (109 of 178) against the rule *pivot = texture ÷ 2*:
+
+| | |
+|---|---|
+| exact | 17 |
+| off by ≤ 1 px (rounding) | 54 |
+| off by ≤ 8 px | 14 |
+| **off by > 8 px** | **24** |
+
+and the gross ones are **concentrated on the title's logo elements**:
+
+```
+a60fcb85 ptlogo_back2.t32     pivot (500,117)  texture 1118x262 -> implies (559,131)   off 59.0
+a60fcb85 ptlogo_back2eff.t32  pivot (507,126)  texture 1133x280 -> implies (566,140)   off 59.5
+a60fcb85 ptlogo2.t32          pivot (449, 46)  texture  992x104 -> implies (496, 52)   off 47.0
+b483e6e6 ptlogo1.t32          pivot (451, 50)  texture  822x100 -> implies (411, 50)   off 40.0
+```
+
+**Why:** build 4's `ptlogo_back2` pivot `(500,117)` is *exactly* half of the
+**Japanese** texture (1000 × 234), not its own English one (1118 × 262). The
+layout record is authored once and shared while the `.t32` sprites are swapped per
+language — the effect
+[`structures/ui-rat-layout.md`](structures/ui-rat-layout.md) warns about in
+general, here measured on the screen where the render disagrees with the game.
+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.
 
 ### 🔴 Refuted on the way