A release is a named, immutable thing

Deployment is not activation

Code may ship with a model withheld, a surface gated, or a board unavailable — and production stays honest about it. A withheld model reads Unavailable, never a stale number under a current-sounding label. Rinehart Ratings ships an MLB vertical whose 2026 Current Board is unavailable by construction; Roster Command deploys with its startup surfaces deliberately dark.

Four different clocks — never collapsed

A newly attempted capture can honestly reproduce an old observation about an older dataset from a still older release. That is why every status record on this site keeps four separate clocks, and why collapsing them is how status pages lie:

• Source-data clock — the dataThrough boundary of the underlying dataset, as the producer states it. A dataset can end last September while its artifact was published this morning.
• Release clock — when the producer generated or published the named artifact, bound to the immutable release or version it belongs to. Labels such as Built, Staged, Freshness generated, and Boards generated remain the producer's, not interchangeable dates.
• Capture clock — every time SIGNAL attempted to fetch and validate bytes, including an outage that left the normalized state unchanged. A successful capture records the producer hash; a failed attempt records the failure. Neither proves source-data freshness.
• Observation clock — when SIGNAL first recorded a distinct normalized state. Repeated captures of identical evidence do not rewrite that history or pretend a new state change occurred.

Current is earned, stale is admitted

Freshness policies are explicit — for example, offseason boards age after 5 days and go stale after 8, measured from the newest meaningful input, never from generation time. When a board fails the check, the served verdict says stale with the failed check named. The day the trust-recovery gate was adopted, all four boards evaluated to stale — and that reading was recorded as correct, not as a regression.

Rollback preserves history

Every deployment leaves an immutable hash. Rolling back promotes a prior known-good deployment — a new publication event pointing at old bytes — and the release notes record both directions. Nothing is deleted, nothing is rewritten, and the rollback target for the current release is always written down before anyone needs it. This site follows the same rule; see the release ledger.