One feed, every workspace, nobody can quietly edit.
Every workspace that seals an audit-ledger checkpoint publishes it here, hash-chained to the entry before it. No run content and no customer name — the workspace identifier is a random value, not derived from anything about you. It does carry each checkpoint's sequence number, which is the count of entries sealed at that point, because the chain cannot be verified independently without it; over time that is a coarse signal of how much a given workspace records. What it buys is that we cannot keep two divergent histories, since a second, different head for the same checkpoint cannot even be written quietly. Publishing is per-workspace and can be turned off in Settings.
Paste a log id.
Every workspace with a sealed ledger has one, visible on its own Audit ledger page and embedded in its public status badge — rbl_ or rba_followed by 24 hex characters, or log_ followed by 32.
No account, no Runback software.
# The full feed, or one workspace's slice of it
curl https://runback.dev/api/transparency
curl https://runback.dev/api/transparency?log=rbl_xxxxxxxxxxxxxxxxxxxxxxxx
# Each entry: entry_hash = sha256(prev_hash + RFC8785({ckpt_seq, head_hash, log_id, merkle_root}))
# Archive a response today; re-fetch tomorrow; the archived entries must reappear
# byte-for-byte with the same entry_hash, or the feed was rewritten.What this page does not claim.
- A per-workspace lookup shows that workspace's entries but cannot verify the full chain on its own — other workspaces' interleaved entries are what the linkage depends on. Fetch the unfiltered feed to actually verify the chain.
- This proves the feed hasn't been silently rewritten. It does not prove what happened inside any run — that's what a workspace's own audit export and @runback/verify are for.