diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index 4245ba4e..b7bb9e7c 100644
--- a/docs/re/METHOD.md
+++ b/docs/re/METHOD.md
@@ -58,6 +58,19 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
 * **My own last-turn result is a hypothesis too.**
 * **A global partition can understate a per-owner one.**
 * **A residual is measured against a population — name it.**
+* 🔴 **An insensitive observable fails TWICE, and the second way is worse.**
+  Two bugs in one exchange, one cause:
+  1. A leaf-composition rule was checked against **alpha**, which moves ~0.3
+     levels per keyframe unit — so a one-keyframe association error barely
+     shifted it and the rule **looked confirmed**. The same span moved `x` by
+     **1 560 px**.
+  2. Fitting `t` from that same alpha then **manufactured an 11.5 px position
+     residual that did not exist**, and sent the consumer hunting a
+     pivot/rotation mechanism to explain it. One byte of alpha quantisation is
+     worth 1.5–1.9 keyframe units, i.e. 6–8 px of sweep.
+  **Solve on the fastest-moving field; check the slow one. Never the reverse.**
+  ⚠️ The second failure is the more expensive: not-falsifying leaves you falsely
+  reassured, but **inventing a residual sends you looking for a mechanism**.
 * ⚠️ **A stated reach is a boundary, not a hedge — do not extrapolate past it.**
   `ui-render-tone-curve.md` fitted γ ≈ 1.34–1.49 on **dark flat patches** and
   wrote "nothing constrains midtones or highlights". Used above that range the
diff --git a/docs/re/structures/ui-leaf-vs-parent-alpha.md b/docs/re/structures/ui-leaf-vs-parent-alpha.md
index e586e908..28b982ca 100644
--- a/docs/re/structures/ui-leaf-vs-parent-alpha.md
+++ b/docs/re/structures/ui-leaf-vs-parent-alpha.md
@@ -140,8 +140,14 @@ At the position-derived **t = 357.7**, every observable lands:
 
 ✅ **Sub-pixel on both positions, inside one byte on both alphas** — while the
 parent's alpha is **0** throughout. And the leaf **pivot is (200, 90)** against a
-399×180 sprite, i.e. the pivot *is* the sprite centre, so rotation displaces the
-centre by nothing. There is no pivot/rotation correction to find.
+399×180 sprite, so rotation displaces the centre by essentially nothing and there
+is no pivot/rotation correction to find.
+
+⚠️ **To half a pixel, not exactly** (the port's check, and worth keeping): the
+sprite is **odd-width**, so its true centre is **199.5**, and the declared pivot
+is 200. The 0.5 px offset is far inside the −0.70 / −0.48 px agreement above and
+changes nothing here — **but do not lean on "the pivot IS the centre" for a
+sub-pixel claim.** It is the centre rounded up.
 
 ⚠️ **The methodological point is the same one this exchange started with,
 inverted.** Earlier, a rule *looked confirmed* because it was checked against