A published artifact asks for trust. "Download this binary, run this installer, deploy this site" are all requests to execute bytes someone produced somewhere. A checksum answers "are these the bytes you expected"; it does not answer "did these bytes come from the reviewed source." The release machinery in this portfolio exists to close that second question.
the provenance problem
The classic gap: CI builds an artifact, uploads it, and a human later attaches it to a release. Everything between "the commit was reviewed" and "the download exists" is trust in whoever held the upload keys. If a token leaks or a maintainer laptop is compromised, the artifact can be anything, and the checksum happily confirms the anything.
The fix is to bind the artifact to its provenance at build time: the build runs in an attested environment, on an exact commit, from an exact workflow, and the release carries signed evidence of all three. Verification then replays the binding rather than trusting the channel.
what a proving release does
Ghostget's release workflow is the working example. A tag triggers the pipeline; the workflow verifies the tag's identity and ancestry before checkout, builds the artifact, and signs a provenance record binding the artifact hashes to the exact commit, workflow file, run, and attempt. The attestation job re-verifies the run's identity before it is granted credentials: the signing key is only released to the job that proved it is the expected workflow on the expected commit.
xcb's build provenance follows the same pattern at package level: the published bytes are bound to a reviewed commit and a recorded build, and the manifest carries the digests a verifier re-computes before admission.
The distinguishing feature is order: authority is verified before credentials are issued, and artifacts are admitted only after the provenance chain checks. A release that cannot prove its origin fails closed rather than shipping anyway.
how the gates chain
The chain is deliberately repetitive: each stage re-admits the evidence it depends on rather than inheriting trust from the previous stage. The promote-site workflows re-verify the exact CI run (complete job inventory, every job successful, exact commit, attempt 1) before building. The production writer re-verifies authority before pushing the production ref. Post-deploy verifiers re-probe the public bytes.
Re-verification looks redundant; it is the point. An attacker who compromises one stage inherits none of the others' authority, and a stage that received tampered inputs detects the drift instead of amplifying it.