diff --git a/docs/NOW.md b/docs/NOW.md
index 5327d705e..db7fe1967 100644
--- a/docs/NOW.md
+++ b/docs/NOW.md
@@ -1,7 +1,13 @@
-# NOW — test: synth gate asserts ZERO transparent latches (2026-08-08)
+# NOW — docs: seed-lottery marginality is placement-level, Heisenbug-confirmed (2026-08-08)
 
 Last updated: 2026-08-08
 
+## docs: record that seed-lottery marginality is a PLACEMENT property, not a register bug (Refs #1764)
+
+- Ran the last diagnostic for the on-silicon seed-lottery: on-chip observability. Widened the UART result dump from 4B (y) to 12B `{z1, z0, y}` so a glitching seed would reveal WHICH register diverges first (hidden pre-activations vs output). The instrumented design output ALL-ZERO on every seed tried — adding the probe re-placed the shared core past its (unconstrained) timing edge
+- This is a genuine **Heisenbug**: instrumenting the deep combinational path *moves* the result, which is itself the evidence that the fault is a timing/placement property of the WHOLE path, not a localizable single-register bug. The fix remains a real multicycle timing constraint (commercial P&R) or a structural pipeline — not an RTL change
+- Documented in `docs/SILICON_TRAINING_METHODOLOGY.md` "Honest limits". Docs only. Refs #1764
+
 ## test: catch gen-verilog latch inference that reaches silicon (Refs #1764)
 
 - Motivated by a root-cause hunt for the on-silicon seed-lottery marginality. Finding: the gen-verilog GF-T cores (GftSmul/GftSadd) infer dozens of latches during yosys `proc` (function locals conditionally assigned), but `synth_xilinx` optimizes them ALL away -> the final netlist has 0 latch cells. So latches are NOT the marginality cause here (nor were setup or hold -- all three hypotheses killed board-independently). But a latch that SURVIVED synthesis would be a level-sensitive / placement-sensitive silicon-reliability hazard that iverilog verification never catches
diff --git a/docs/SILICON_TRAINING_METHODOLOGY.md b/docs/SILICON_TRAINING_METHODOLOGY.md
index 31cff94ed..0ec562d93 100644
--- a/docs/SILICON_TRAINING_METHODOLOGY.md
+++ b/docs/SILICON_TRAINING_METHODOLOGY.md
@@ -70,6 +70,15 @@ no Docker, native macOS arm64.
   limitation — a commercial P&R would close the path directly — not a design flaw. A
   design's microcode step count predicts its marginality (more steps per frame = more
   chances for a glitch).
+- **The marginality is a placement property, not a localizable register bug — confirmed
+  by instrumentation.** We tried on-chip observability: widen the UART dump to expose the
+  hidden pre-activations (z0, z1) alongside the output y, so a glitching seed would reveal
+  *which* register diverges first. Adding the probe changed the design's behaviour from
+  "computes (marginally)" to "outputs all-zero" — the extra logic re-placed the shared
+  core past its (unconstrained) timing edge. This is a genuine Heisenbug: the deep path is
+  marginal enough that instrumenting it *moves* the result, which is itself the evidence
+  that the fault lives in the timing/placement of the whole path, not in one microcode
+  step. The fix is a real timing constraint (commercial P&R), not a code change.
 
 ## Reproducibility