CHAOS NIGHT round 7 closed: reporting resumed on time, nothing lost

The post-block hub report fired at 22:23:43Z - "Hub report pushed successfully
(10538 bytes)" - and the cadence held to the second across the whole accident:
21:53:49Z, 22:08:43Z, 22:23:43Z, fifteen minutes apart, with a ten-minute
network cut sitting between the second and third.

So round 7's complete answer: the box lost its way out for ten minutes, kept
every app serving at home, restored the public path unaided in ~64 seconds,
raised no alarm (correctly - staleness is 30 minutes), attempted no hub contact
during the outage because none was due, and then reported on schedule. Nothing
was dropped because nothing was sent.

Good, and deliberately narrow: this did NOT test what happens to an alarm raised
WHILE the hub is unreachable. Rounds 8 and 9 are also ten-minute cuts and one
should contain a scheduled report naturally.

Also recorded: the fifth mistimed reading of the night, caught this time by the
measurement labelling itself - the command printed its own timestamp next to the
due time, so a reading taken fifteen seconds early announced itself instead of
becoming "the box never resumed reporting". Same principle as the marker blocks
that caught the password-file check and the command lines that caught the vzdump
self-match: make the instrument say what it actually did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

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.