diff --git a/documentation/audits/evidence-chaos-night-2026-09-17/round-7.txt b/documentation/audits/evidence-chaos-night-2026-09-17/round-7.txt
index 954eeb0e..f4fd476d 100644
--- a/documentation/audits/evidence-chaos-night-2026-09-17/round-7.txt
+++ b/documentation/audits/evidence-chaos-night-2026-09-17/round-7.txt
@@ -183,3 +183,36 @@ attempted, so nothing could be lost. Recorded as *not exercised*, never as *pass
 
 **Rounds 8 and 9 are also ten-minute cuts** and, at ~25-minute spacing against a 15-minute cycle, one
 of them should contain a scheduled report naturally. They are not re-timed to force it.
+
+## The fifth mistimed reading — caught by the measurement labelling itself
+I checked for the post-block hub report at **22:23:28Z**. It was due at **22:23:43Z**. Fifteen seconds
+early, and the newest entry was still the pre-block push at 22:08:43Z.
+
+What stopped it becoming a false conclusion („the box never resumed reporting") is that the command
+**printed its own timestamp beside the answer**, with the due time written into the label:
+    reading taken at 2026-09-16T22:23:28Z   (too early if before 22:23:43Z)
+    guest clock: 2026-09-16T22:23:29Z
+
+That is the fix that has now worked twice, after three earlier clock errors where I estimated instead
+of reading: **make the measurement state its own precondition, so a premature reading announces itself
+rather than being mistaken for a result.** The same principle as the marker blocks that caught the
+password-file check and the command lines that caught the `vzdump` self-match — in each case the cure
+was making the instrument say what it had actually done.
+
+## ROUND 7 CLOSED — the box resumed reporting exactly on time, and nothing was lost
+    22:23:42Z  [scheduler] Running job: hub-report
+    22:23:43Z  [report] **Hub report pushed successfully (10538 bytes)**
+    (reading taken at 22:24:06Z, guest clock 22:24:08Z — after the due time, and labelled as such)
+
+The cadence held to the second: pushes at **21:53:49Z · 22:08:43Z · 22:23:43Z**, fifteen minutes apart
+each time, straight through a ten-minute network cut that sat between the second and third.
+
+**So the complete answer for round 7 is:** the box lost its way out for ten minutes, kept every app
+serving at home, restored the public path unaided in ~64 s, raised no alarm (correctly — the staleness
+threshold is 30 minutes), **attempted no hub contact during the outage because none was due**, and
+then reported on schedule as if nothing had happened. Nothing was dropped, because nothing was sent.
+
+That is a good result and a narrow one, and the narrowness is the point: this round did **not** test
+what happens to an alarm raised *while* the hub is unreachable. Rounds 8 and 9 are also ten-minute
+cuts, and at ~25-minute spacing against a 15-minute cadence one of them should contain a scheduled
+report. If it does, the drop behaviour finally gets measured; if it does not, that is recorded too.