re: the swoosh's pivot belongs to the Japanese sprite, and the colour is

not in any field I can find

Chasing the swoosh defect. The colour half is a clean negative and the
geometry half now has a number.

Ruled out for the colour: every keyframe of every swoosh element carries
fade 0x??ffffff -- white RGB with only the alpha varying -- and no tint
is anything but white. The texture is not pink either; ptlogo_back2
decodes blue-leaning at (175,174,198) and its glow warm at (255,253,234).
So the magenta edge the game draws comes out of blending, and I have said
that rather than leaving "wrong colour" as an undifferentiated mystery.

The geometry half: the declared pivot does not match the element's own
texture. Build 4's ptlogo_back2 pivot is (500,117), which is exactly half
the JAPANESE sprite at 1000x234, not half its own English one at
1118x262 -- off by 59 px, the right order to make the swoosh too thick
and extend too far right. The layout record is authored once and shared
while the sprites are swapped per language, which ui-rat-layout.md warns
about in general; this is that warning measured on the screen where our
render disagrees with the capture. It cuts both ways -- the Japanese
build's ptlogo1 is off by 40.

Marked as a quantified candidate rather than a diagnosis, because whether
it bites depends on which pivot our compositor uses and I did not check.

One METHOD line, because the first version of that check was misleading:
a pivot-equality test conflates rounding with real breakage. Equality
flagged 74 percent of title elements. Split by magnitude it is 17 exact,
54 off by a pixel from odd dimensions, and 24 genuinely off -- and those
24 are the finding.

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.

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