diff --git a/docs/re/f6-unit2-parent-alpha-multiplies.md b/docs/re/f6-unit2-parent-alpha-multiplies.md
index b139fc02..9dbcf2e8 100644
--- a/docs/re/f6-unit2-parent-alpha-multiplies.md
+++ b/docs/re/f6-unit2-parent-alpha-multiplies.md
@@ -1,4 +1,48 @@
-# F6 unit 2 — the parent's alpha **IS** multiplied into the sweep leaf
+# F6 unit 2 — parent alpha multiplying in: 🟡 WEAKENED, not established
+
+> ## 🔴 CORRECTION, same day — the identification was wrong, and so was my presentation
+>
+> The port challenged the by-size identification: both sweep sprites are the same
+> size, so size cannot separate `pteff03` from `pteff03a`, and the two leaves have
+> different alpha floors (128 and 0). **They were right that it was broken, and it
+> is broken in a third way neither of us named.**
+>
+> Their proposed discriminator — the leaves travel in opposite directions — is in
+> the capture, and it says:
+>
+> ```
+> 1.38x3.15  n=1140  x centre -1.690 -> +0.500   drift +2.190  LEFT->RIGHT
+> 1.39x3.15  n= 614  x centre -1.685 -> +0.495   drift +2.180  LEFT->RIGHT
+> ```
+>
+> **Both rows travel the same way, so both are `pteff03`.** The 0.7 % size
+> difference is per-frame rounding splitting ONE element across two keys — not two
+> elements. `pteff03a` (declared right-to-left, 800 % scale, AABB ≈ 3.62 NDC) does
+> **not appear in this capture at all.**
+>
+> 🔴 **And my own presentation misled.** The "alphas 8 24 33 50 58 …" I quoted were
+> `sorted(set(...))[:9]` — the nine **lowest distinct** values, not the series. Read
+> as a trajectory they look like a ramp from 8. They are a tail. The actual counts:
+>
+> ```
+> below 128:  9 of 1140  and  5 of 614   =  14 sub-floor samples out of 1754
+> ```
+>
+> **So the bound argument survives in shape and collapses in weight.** Every sample
+> below 128 is still unexplainable by a leaf that floors at 128 — but 14 of 1754 is
+> a thin tail, and a tail is exactly where a vertex-grouping slip or a partial frame
+> would show up. **Downgraded to 🟡: not refuted, not established.**
+>
+> **What would settle it:** the same capture read as a *series* rather than a set —
+> alpha against frame across `t=70…100`, where a multiplying parent must produce a
+> monotone ramp on nearly every frame, not 14 stragglers. That is one more read of
+> data already on disk, and it is the next unit.
+>
+> The port was right to hold the renderer. Adopting this would have changed a
+> rendering rule on every screen with a leaf, on 14 samples I had presented as a
+> trajectory.
+
+
 
 **Status: ✅ measured ⟨capture⟩.** 2026-09-02.