One public history. No quiet rewrites.
Workspaces publish their audit-log checkpoints here. Each entry is linked to the one before, so a rewrite shows.
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 recorded 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.
Numbers skip where an insert was refused; the hash links show no entry is missing.
Look up one workspace.
Paste its log id. Every workspace with a signed audit log has one, on its own 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.