INTEGRATE · IN BUILD
Status
Availability and freshness of the read surface itself — separate from whether the ledger reconciles. Two different questions, two different pages.
The read surface, measured from outside itself
Six checks against the public API over HTTP, run when this page rendered — not a claim about the ledger's contents. Whether the ledger reconciles is a different question, answered on a different page, and conflating the two is how a status page ends up reassuring people about the wrong thing.
| Check | Result | Latency | Detail |
|---|---|---|---|
| assets | ∅ not as published | 665ms | FG missing or decimals wrong |
| circulation | ∅ not as published | 685ms | HTTP 200 |
| invariant | ∅ not as published | 1026ms | HTTP 200 |
| entries | ∅ not as published | 744ms | 0 malformed of 0 |
| one story | ✓ answering | — | circulation and invariant agree about the same run |
| snapshot | ∅ not as published | 1027ms | provenance headers missing — the label must travel with the data |
Measured 2026-10-09 15:06:38 UTC, fresh within five minutes. The sixth check exists because two of these endpoints once disagreed about the same fact in production; it holds them to one story. The deeper probe — twelve checks, the Merkle recomputation, the failure-explanation contract — is npm run verify:live in the repository, runnable by anyone against this host, which is the only kind of status claim worth making: one a stranger can refute.
What this page deliberately is not
A history. Uptime-over-time needs a write path, and the first write path on a surface whose security page says no endpoint here can write will not be for its own dashboard. When history arrives it will come from the scheduled verification runs already public on the repository — records kept by the prover, not the proven.