diff --git a/tools/podium-repro/README.md b/tools/podium-repro/README.md
index 6b81e73..ba2af1a 100644
--- a/tools/podium-repro/README.md
+++ b/tools/podium-repro/README.md
@@ -223,6 +223,30 @@ exits, no exception. Then the cdb logs turned out to carry no
 weaker even than the earlier light-page-heap ones. Its only value is as one
 more sample of the crash failing to happen on its own.
 
+**2026-08-14, FOUR pods, FULL page heap (`flags 0x3`), driven, podium ON:
+no crash. This is the first properly instrumented negative.** Everything the
+diagnosis points at ran and survived: `WinnersCircle: 4 placed on 8 spots`,
+`own vehicle given an exterior` (the podium's second
+`MakeEntityRenderables` pass on the LOCAL pod), full `Application::Shutdown`
+teardown, four clean exits, no exception on any pod. Scores 553..997 - pod D
+at 553 means real collisions and damage, not a parked field.
+
+This is the run all the earlier ones were pretending to be. Full page heap
+traps a double free at the second free AND an overrun at the guard page, in
+the culprit's own stack. Neither fired. So on this configuration - four pods,
+loopback, one teardown - the bug does not happen.
+
+It also settles the address-space question: 2 works, **4 works**, 6 dies. The
+fatal night's six-pod population is NOT reachable under full page heap on one
+machine, so that population and this instrument cannot be had at the same
+time here.
+
+What is still different from the fatal night, in the order worth attacking:
+repetition (one sample of an intermittent bug is nearly nothing - loop the
+4-pod full-PH run many times), then the real network (three machines, so the
+podium and its teardown land at genuinely different moments per pod, instead
+of loopback's near-simultaneous ~0 ms).
+
 ### What the two clean runs change
 
 Light page heap traps a **double free** at the second free. It does NOT trap