diff --git a/documentation/audits/evidence-chaos-night-2026-09-17/phase0-notes.txt b/documentation/audits/evidence-chaos-night-2026-09-17/phase0-notes.txt
index 6b55813e..f0908d7d 100644
--- a/documentation/audits/evidence-chaos-night-2026-09-17/phase0-notes.txt
+++ b/documentation/audits/evidence-chaos-night-2026-09-17/phase0-notes.txt
@@ -402,3 +402,23 @@ been established, it is a `systemd-run` transient unit (`household.service`, act
 than recording where it sits. It hits the guest's traefik from one hop closer than DooPlex would, so
 it does NOT exercise the LAN path between DooPlex and the box; anything that breaks only on that hop
 is invisible to it. The `use` rounds, which DO run from DooPlex, cover that hop.
+
+### Fences and the pre-block baseline, checked mid-night (2026-09-16 ~21:38Z)
+**Standing guests untouched.** `qm list` on demo-hp shows only VM **336** (this drill's own box);
+containers 9201 and 9202 are running. 9201 still carries its full standing set —
+adventurelog(+frontend,+postgres), **bentopdf**, bookstack(+db), calibre-web, cloudflared, docmost
+(+postgres,+redis), felhom-controller, filebrowser, kimai(+db), opengist, paperless(+postgres,
++redis), privatebin, romm(+db,+redis), traefik — and 9202 its three (controller, filebrowser,
+traefik). Nothing of theirs was stopped, removed or redeployed tonight. `drill-r50` does not exist on
+this host and was not created.
+
+**Firewall baseline on demo-hp, recorded BEFORE the internet-block rounds (7–9) need it:**
+    iptables -S FORWARD   ->  `-P FORWARD ACCEPT`  (nothing else)
+    physdev rules         ->  **0**
+    net.bridge.bridge-nf-call-iptables = **0**
+
+This is a control taken before the experiment, not after: rounds 7, 8 and 9 flip that sysctl to 1 and
+insert two `--physdev-in` rules for this VM's tap. When they finish, the same three readings must
+come back identical. Without the „before" reading, „it looks clean afterwards" would be an assertion
+rather than a measurement — and this host also carries the two standing demo guests, so an abandoned
+rule would be a fence breach rather than an untidy drill.
diff --git a/documentation/audits/evidence-chaos-night-2026-09-17/round-3.txt b/documentation/audits/evidence-chaos-night-2026-09-17/round-3.txt
index 76daeb2c..8b04fc87 100644
--- a/documentation/audits/evidence-chaos-night-2026-09-17/round-3.txt
+++ b/documentation/audits/evidence-chaos-night-2026-09-17/round-3.txt
@@ -69,3 +69,21 @@ end-of-window check remains owed rather than quietly satisfied by this reading.
 **What that already establishes, independent of how the window ends:** the household's twelve apps
 keep running and serving with the system disk at 96 % full, and after five minutes nobody has been
 told anything. The apps do not fall over; the silence is the finding.
+
+## A third mistimed reading — and why it matters more than it looks
+At 21:36:00Z I took what I labelled „the end-of-window alarm check". The fill window runs
+**21:29:49Z -> ~21:39:49Z**, so that was again mid-window, the third time tonight I have estimated
+the clock instead of reading it (the earlier two: „the window ends ~23:39" and the 21:34 reading).
+
+The readings themselves are consistent and unchanged — newest event still `controller_started` at
+21:28, **no `disk_critical`, no `disk_warning`, no `health_degraded`** — so no conclusion is altered.
+What is wrong is the LABEL, and the label is the whole point here: „nothing has fired yet, five
+minutes in" and „nothing fired in the whole ten-minute window" are different findings, and only the
+second one answers „would the household be told?".
+
+**Corrected practice for the rest of the night:** the end-of-window check is taken when the round's
+own runner reports completion, not when I think the clock has moved far enough. The runner knows when
+it released the fill; I was guessing.
+
+This is the seventh item on tonight's list of my own instrument errors, and it has the same shape as
+the rest — **a confident label on a measurement whose precondition was not met.**