The estate, by state — and where it produces a confident zero_

This page's diagnosis is wrong in several places and should not be relied on. It concluded the Tower had died and the vault had gone silent. Neither was true: the Tower ran throughout, and the vault took 670 commits in the period this page calls silent. The error was a stale local clone read as if it were live.

The estate map, the state colour-coding and the gap list below still hold. The outage narrative and the gate arithmetic do not.

Read the correction →

The vault's last commit is 2026-08-08 07:30. There are no daily notes for 8–12 August. The nightly reflection, the miss log and the weekly review have all been silent for five days, and nothing reported it — it was found by the operator trying to use the estate.

The first diagnosis was wrong, and the correction is more interesting. This page originally concluded the Tower had died, on the reasoning that cron-watchdog.sh and status-digest.sh both run on it and would have died with it. A live read of GET /status on 13 Aug disproved that: hub.lastContact was eleven minutes old and fresh: true. The Tower is up. context-push has been running the whole time.

The failure is partial — the job plane that writes the vault stopped while the VM-side jobs carried on — and the reason nobody saw it is a design fault in the health check itself. signalsHealth() reads four signals from different producers on different hosts and collapses them:

lastContact = max(ts across all four)
fresh       = ANY one within its own TTL

So one healthy producer reports the whole estate healthy. That is the same error as view recording / for every surface, and the same error as a push_sent row written before the fan-out: an aggregate that conceals the member you actually need to see. It is this briefing's thesis holding in a form sharper than the original draft — not a monitor that died, but a monitor that was built to average away the failure it was watching for.

The gate arithmetic below is corrected in place and is materially worse than first reported.

The working assumption going in was that only mallory could be read, and that mallory-runtime, mallory-pebble and the vault would have to be taken on trust. All four were in fact readable. Everything here about the Tower jobs, the Goose recipes and the vault is therefore Confirmed from source. Two of the largest findings below could only be reached that way.

The 2026-08-01 deck's delivery[2] reads: "stampNudgeUrl behind tests, then notify mirrors the send and ships the stamped link." The mirror shipped. The stamped link did not — no caller anywhere sets nudgeId. The deck records an intention as a completed state, which is exactly the failure its own risks[3] warns about.

Read directly from the vault's daily notes. The window opened 3 Aug and runs ~14 nights:

Corrected 12 Aug: four usable nights out of ten elapsed. The window was to close ~16–17 Aug on fourteen nights. Even if the Tower returned immediately it would reach eight, half of them produced by a system that was intermittently dead. The 17 August gate cannot be met on its original basis and needs an explicit decision — extend it, or change what it rests on.

The five lost nights must be marked lost, not backfilled as None. The spec is explicit that inventing a miss is worse than reporting none; the inverse holds harder, because a fabricated None. would report that curation was working on nights when nothing was watching.

Two real misses in four answered nights, and both are the kind the board was reframed to catch — a demand on time, not a message awaiting a reply. On this evidence the gate is trending toward "build it", not "retire it". Confirmed.

But 4 Aug is gone, silently, from a 14-night sample — a 7% hole in the only evidence the decision rests on, and nothing surfaced it.