A regulator asks you to prove deployed bytes came from a source revision built four years ago, on a platform since decommissioned. What holds up?

## Why the archived attestation may not be enough A provenance statement is a signed claim: this artifact digest came from this source revision, via this build definition, with these inputs, produced by this builder. Verifying it later needs three things that live *outside* the statement — the issuing identity, whatever lets you establish that the signature was made by that identity, and the policy record showing that this builder was the one authorised to produce this artifact. All three are organisational, and all three decay. Build platforms are retired. Signing identities are rotated and revoked. The team that wrote the policy has moved on and the policy itself was never versioned anywhere durable. Four years on you can hold a perfectly well-formed statement and be unable to say anything an auditor will accept about who made it. Internally it is still a useful record; as **evidence to a third party** it is close to inert, and overstating it — presenting a signature you cannot actually verify as proof — is worse than saying plainly what you have. This is the specific weakness of testimony-shaped evidence: its value is tied to the continued existence and standing of the witness. ## Why a deterministic build ages differently A reproducible build produces evidence that does not route through anyone's continued existence. If the build is deterministic and the inputs are preserved, an auditor takes the source revision, the dependency artifacts and the toolchain, runs the build in their own environment, and compares the resulting digest to the bytes that were actually deployed. Nobody is being believed. There is no key to check, no platform to still be operating, no vendor relationship to still be current. The proposition "these bytes follow from that source" has become checkable arithmetic. For an audit-truth asset — a regulated pricing or scoring model, safety-relevant firmware, anything where a regulator may ask years later what exactly was in production — that difference is the whole point. The question is not "did you have good controls" but "demonstrate, now, that this specific deployed binary corresponds to that specific reviewed source." ## What this actually costs This is where the judgement sits, because "just make it reproducible" understates the programme by an order of magnitude. **Determinism has to be designed in at the time.** You cannot retrofit it four years later onto bytes that already shipped. Whatever timestamps, absolute paths, embedded hostnames or unordered outputs the build had are baked into the artifact permanently. **You must archive inputs, not references to inputs.** A lockfile records coordinates and digests; it does not keep the content alive. Upstream packages get deleted, registries change hands, hosts disappear. Long-horizon evidence means storing the actual dependency artifacts and the actual toolchain, under your own retention control. **You must preserve the environment, not just the toolchain binary.** Builds are sensitive to more than the compiler — the base operating environment, locale, filesystem layout, sometimes the path the source sits at. Capturing that faithfully is the hardest part. **Unexercised evidence rots.** A rebuild path nobody has run in three years does not run. The only way to know your archive still produces the digest is to periodically rehearse it and record the result. That rehearsal, with its dated outcome, is itself strong evidence — arguably stronger than the archive. **Do both legs where it matters.** Archive the attestation together with everything needed to evaluate it later, *and* retain the ability to re-derive the artifact. They fail in different ways, and the combination is what survives. ## Scoping the decision The wrong answer is "we will do this for every artifact": the cost is real and recurring, and most services have no obligation that outlives their deployment. The right answer is to derive scope from the **retention obligation** — statutory or contractual — and apply the expensive treatment to the small set of systems that carry one. Then write the retention period, the archive contents and the rehearsal cadence into the pipeline's own policy, so it is a property of how those artifacts are built rather than something a team reconstructs under audit pressure. And be candid about the gap for anything already shipped without it. If the honest answer for a four-year-old artifact is deployment records, change tickets and a chain of custody rather than cryptographic proof, say so, and treat the finding as the trigger for making the next four years different.