diff --git a/documentation/audits/DRILL-chaos-night-2026-09-17.md b/documentation/audits/DRILL-chaos-night-2026-09-17.md
index 73437729..6f23edb3 100644
--- a/documentation/audits/DRILL-chaos-night-2026-09-17.md
+++ b/documentation/audits/DRILL-chaos-night-2026-09-17.md
@@ -229,7 +229,29 @@ and named the exact container** — worth recording against this project's stand
 signals are usually invisible there. The diagnosis I spent twenty minutes reaching from logs was in
 the alarm feed, correctly labelled, the whole time.
 
-### Rounds 3-12
+### Round 3 — `use` bookstack / accident: **system disk filled to 96 % for ten minutes**
+
+| the five things | |
+|---|---|
+| what the customer saw | **nothing.** wiki, status and paste all answered before, during and after. No banner, no warning, no mail — the household was never told the disk was full |
+| what the box did by itself | kept all twelve apps running on a 96 %-full root filesystem and released the space cleanly when the fill was removed (29 G used → 944 M used). The shared thin pool never moved (**39.69 %**) and the filesystem stayed writable |
+| time to steady | the box never left steady — **26 containers before, 26 after**, none restarted |
+| alarm fired / true? | **none fired**, checked twice independently after the fill was released |
+| should have fired, did not | `disk_critical` is defined at ≥95 % used and the disk sat at **96 % for ten minutes**. **But this is the ladder working as designed, not a miss:** the fill-watch is a daily sweep (03:30) plus one check ~90 s after a controller start. Predicted before the round, confirmed after |
+
+**Household loop: 12 operations, 0 failures.** The household kept using its apps normally throughout.
+
+**The finding is the silence.** The honest answer to „would the household be told their disk is
+full?" is **no** — unless the controller happens to restart while it is full. Here the timing was
+almost comic: the controller restarted at 21:28 after round 2's power cut, so its one opportunistic
+check ran about twenty seconds *before* the disk filled, and the next is not due until 03:30.
+
+**A correction, recorded where it happened:** I twice labelled a mid-window reading „end of window",
+estimating the clock instead of reading it. The readings were unchanged, but „nothing yet, five
+minutes in" and „nothing in the whole window" are different findings. From here the end-of-window
+check is taken when the round's own runner reports completion.
+
+### Rounds 4-12
 
 PENDING
 
diff --git a/documentation/audits/evidence-chaos-night-2026-09-17/round-4.txt b/documentation/audits/evidence-chaos-night-2026-09-17/round-4.txt
index 304a7dea..7f63de11 100644
--- a/documentation/audits/evidence-chaos-night-2026-09-17/round-4.txt
+++ b/documentation/audits/evidence-chaos-night-2026-09-17/round-4.txt
@@ -54,3 +54,21 @@ down and the box really was not fully healthy.
     LAN route straight to the box                traefik answered **301** throughout
 So the household's apps never stopped serving locally; what failed, and recovered, was the way in
 from outside.
+
+## A LIMIT of the household loop, stated before its numbers are read
+Through the tunnel outage the loop logged:
+    21:41:57Z paperless read ok http=301   21:41:57Z paperless dash ok http=301
+    21:43:57Z paste     read ok http=301   21:43:57Z paste     dash ok http=301
+i.e. **no failures at all**, while the public way in was returning 530.
+
+That is correct behaviour for the loop and a real blind spot at the same time. The loop does **not**
+follow redirects: it takes traefik's 301 on the box as a success, so it measures *„is the app serving
+on the box?"* and never *„can the household reach it from outside?"*. During round 4 the first answer
+stayed yes throughout, which is why it saw nothing.
+
+**Therefore: „0 household failures in round 4" must NOT be read as „the household was unaffected".**
+A household member away from home would have met 530 for about ninety seconds. The loop's number is
+true and answers a narrower question than it appears to.
+
+This is the same distinction as the front-door method correction above, and it is recorded in both
+places because the number and the label live in different files.