Interpret a dashboard absence

Two views of one ledger

The dashboard renders constellation/state.json, a generated evidence ledger (ADR 0011). It has two forms:

• the committed snapshot is deliberately bare — it is machine-reproducible, so it does not read the member repos. Every per-member fact (channel, release, wired, conformant, docs) reads — / absent. This is identical on every machine and in CI's bare clone, which is what lets collect --check gate drift.
• the observed view reads the materialized siblings and carries the real values. The published site regenerates this at deploy time, so the live /dashboard shows the truth. The deploy also runs the runtime-endpoint probe (ATLAS_COLLECT_PROBE=1, atlas#523): for each system with a configured live node (constellation/runtime.json) it reads the node's own attestation — endpoint admitted means the node's self-asserted endpoint(<system>, <url>) fact is admitted into its record. In the committed snapshot the node link appears unprobed.

So a wall of — is not "everything is broken" — it means "this snapshot didn't read the member repos."

Steps

1. Read the live page, not a local build — the deploy regenerates the observed view. On the live site you'll see real channel edge / current yes / wired yes / conformant no / docs present.

2. Trust the Violations panel as the health signal: "None — every collected fact holds" means every fact that was collected is consistent.

3. Regenerate the observed view locally (needs the siblings checked out beside atlas):

   ATLAS_COLLECT_OBSERVE=1 node bin/atlas.mjs constellation collect   # add --probe for the runtime nodes
   git checkout -- constellation/   # restore the bare committed snapshot afterward
   

Notes

• Never commit the observed state.json — the committed file must stay bare, or collect --check will see machine-dependent drift.
• A draft or downstream member legitimately has no substrate facts yet; an absence there is expected, not a regression.