From b917879e1585bd560d1ee0c78ab0336232ce5105 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Thu, 17 Sep 2026 00:24:44 +0200 Subject: [PATCH] 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 Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS --- .../round-7.txt | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) 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.