Why the website deployment receipts were withdrawn.

What failed

• The receipt recorded the digest of a CI-local rebuild. It did not hash the bytes deployed by Vercel or the bytes served at the reported URL.
• An endpoint response did not bind the reported URL to the commit or to the locally rebuilt bytes.
• Signed and publishing revisions exposed signing and release authority to a workflow selected from the event-named commit. The repository establishes an unsound isolation boundary. It does not establish that signing material was exfiltrated or misused.
• Later revisions narrowed several claims but still allowed the deployed commit to select the verifier and minter that interpreted the event.

An intact receipt could therefore prove what the selected workflow recorded without proving the identity of the deployed or served artifact.

What changed

The event-triggered generator, signer, publisher, and current public receipt claim were removed. Repository gates reject the reviewed direct and ordinary constructions that could restore that path. Those static gates do not prove absence across encoded, indirect, external, or unrecognized constructions.

A replacement requires a trusted release path that is not selected by the deployed commit, a provider- or artifact-derived deployed-byte manifest, exact served-output reconciliation, isolated signing authority, and non-clobbering retained evidence.

Historical records

The 52 release assets observed on 2026-07-27 remain byte-for-byte unchanged as historical evidence. They are not current deployment evidence. Their release titles and bodies are marked WITHDRAWN.

The machine-readable registry records each original metadata hash, asset identity, byte length, and asset digest. GitHub release metadata remains mutable, and a detached copy of a historical asset does not contain an embedded withdrawal notice.