diff --git a/POLL_SITE_MAP.md b/POLL_SITE_MAP.md
index 8158df3..1cde7b5 100644
--- a/POLL_SITE_MAP.md
+++ b/POLL_SITE_MAP.md
@@ -138,3 +138,46 @@ and the six training sub-steps in step 6.
 - CSDN LPDDR5 series (DDR Study blog) turned out to cover JEDEC-layer
   protocol only; no register-level help. Useful background for training
   phase names but not for our RE.
+
+## Correction 2026-04-15 late evening — sibling over-trusted
+
+User pointed out I was applying sibling names without verification
+("weights from browsing Instagram"). Going back to verify each, found
+**the d328 register naming was wrong**:
+
+- Sibling said `+0x110` in d328 = `DDRPHY_CAL_RD_VWML0` (per TRM).
+- But the blob **writes** `0xF000F000` to that offset, and TRM lists
+  `CAL_RD_VWML0` as **READ-ONLY** with bits[9:0] carrying a
+  training-result code. Writes are no-ops; 0xF000F000 as a legit VWML
+  value makes no physical sense either.
+- Reason sibling was confused: **d328's effective address is
+  `ctx->b8 + 0x8000 + offset`**, not `DDRPHY_OPB + offset`. TRM's
+  CAL_RD_VWML0 is at `DDRPHY_OPB + 0x0110`, not
+  `DDRPHY_OPB + 0x8110`.
+- What's at `DDRPHY_OPB + 0x8000..0x8FFF`? TRM does not say. Only
+  chapters elsewhere in the TRM have 0x8xxx-offset registers (DPTX
+  PHY etc. — different peripherals, not DDR).
+
+**What d328 really does:** we still don't know the semantic register
+names for its +0x8110, +0x8118, +0x8120, +0x8154, +0x8160, +0x8184
+accesses. The 0xF000F000 / 0x30003 / 0x30000 values suggest a custom
+trigger/config/ack protocol of the +0x8000 sub-block, which is likely
+a per-rank-shadow or per-slice mirror of DDRPHY's Master block —
+but without docs, naming it would just be re-guessing.
+
+**Still verified (hold):** the early-cluster + MID-cluster offsets
+that access `ctx->b8 + 0x10000 + small` (i.e. the DDRCTL register
+space):
+
+- Site 3 @ 0x7ca8 → `DDRCTL + 0x10514` = **DDRCTL_DFISTAT** ✓ TRM-verified
+- Sites 2, 4, 5, 7 → `DDRCTL + 0x10014` = **DDRCTL_STAT.operating_mode** ✓ TRM-verified
+
+And at DDRPHY OPB + small (NOT the 0x8000 sub-block):
+
+- `DDRPHY + 0xa24` = `SCHD_TRAIN_CON0` — I verified the full 32-bit
+  layout directly from TRM §2.4.3 before committing, so this one stands.
+
+**Wrong/unsafe (retracted):** the `+0x8XXX` offsets in d328. Their
+sibling-proposed names (`CAL_RD_VWML0` etc.) are TRM-registered at
+`+0x0XXX`, not `+0x8XXX`, and the blob's write access patterns
+contradict the read-only TRM bit definitions.
diff --git a/rk3588_regs_annotated.h b/rk3588_regs_annotated.h
index cd992e8..bc76fd6 100644
--- a/rk3588_regs_annotated.h
+++ b/rk3588_regs_annotated.h
@@ -175,6 +175,15 @@
                                                             (TRM HIGH) */
 
 /* -------------------------------------------------------------------
+ * CORRECTION 2026-04-15 LATE EVENING:
+ *   The 'CAL_RD_VWML0' etc. names above apply to DDRPHY_OPB + small
+ *   offsets. d328's accesses are at DDRPHY_OPB + 0x8000 + small,
+ *   which is an UNDOCUMENTED sub-block of the DDRPHY space.
+ *   Writing 0xF000F000 to a TRM-documented READ-ONLY register
+ *   would be a no-op — contradicting the blob's actual behaviour —
+ *   so those names DO NOT apply here. The `PHY_CTL_110` etc.
+ *   heuristic labels (in the block above) are the safe fallback.
+ *
  * Semantic re-interpretation of FUN_0000d328 (train_phy_block):
  *   Writes 0x30003 to CAL_CON5 (+0x160):
  *     bit[0] wrtrn_cyc_mode=1  (low-freq edge mode)