For release builds, which do you fund first with one quarter of platform effort: byte-identical reproducibility, or inventory and provenance on every build?

## The two investments have different shapes They are often discussed as one programme, and they behave nothing alike. | | Emitting records | Byte-identical reproducibility | |---|---|---| | Adoption | incremental — one build at a time | effectively all-or-nothing per build graph | | Value timing | the day a build starts emitting | only when somebody re-derives an artifact | | Cost driver | wiring the build to publish two files | removing every non-deterministic input in the toolchain | | What it gives you | a claim about what went in and how | a way to test that claim without trusting the builder | | Failure mode | records exist but nobody reads them | a long tail of builds that never quite reproduce | That table is the argument in miniature. One scales by coverage; the other is a property that either holds for a build or does not. ## Why records usually come first - **Coverage compounds immediately.** Every build that starts emitting is one more artifact you can answer questions about. There is no threshold to cross before the first one helps. - **The questions are real and frequent.** When something goes wrong, the questions asked are "what is in this image" and "which source and which base produced it". Records answer both; reproducibility answers neither directly. - **The work is bounded.** Wiring a build to publish an inventory and a record of the run is mostly plumbing, and a build that cannot do it can be made to fail, which converts the effort into a gate instead of a campaign. - **It is prior.** A rebuild comparison is only meaningful against a recorded recipe. If nothing recorded the source revision, the base bytes and the parameters, there is nothing to rebuild *from*, so reproducibility has no input. ## Where reproducibility earns its cost It earns it exactly where somebody outside your trust boundary needs to check a claim rather than accept it: 1. A regulated or high-assurance product whose releases an auditor will ask you to re-derive months later. 2. An artifact whose compromise would be catastrophic and whose build machine is a single point of trust. 3. A build graph already close to deterministic, where the remaining cost is a handful of timestamps and a pinned base. Outside those, it is a large, diffuse cost with a benefit nobody currently draws on. The honest question to ask before funding it is not "is reproducibility good" but **"who has ever asked us to re-derive an artifact, and what did we tell them?"** ## A defensible sequencing 1. Set a floor: every release build emits both records, keyed to the image digest, and fails if it cannot. 2. Pin bases by digest everywhere — cheap, and it is the precondition for anything later. 3. Name the short list of artifacts that must be re-derivable, and drive those build graphs to determinism. 4. Rebuild those on a schedule and compare, so the property is monitored rather than assumed. A reproducibility claim nobody tests decays the first time a dependency changes shape. 5. Report coverage on both axes separately — percentage of builds emitting records, and the named set that reproduces — because a single blended number hides which one is failing. ## The trap in either answer Saying "records, obviously" and stopping is the first trap: a record is a **claim the builder makes about itself**, and its weight depends entirely on how much you trust the machine that wrote it. Reproducibility is what converts that claim into something a third party can test, which is why the sequence ends with it rather than dropping it. Saying "reproducibility, obviously" is the second: a determinism programme that runs for a quarter and covers ten percent of the estate has produced nothing usable, while the same quarter spent on records covers everything and produces an answer to every incident question asked in the meantime. The third trap is treating the choice as permanent. The two reinforce each other — making a build deterministic forces every input to be explicit and pinned, which is the same list the record is supposed to state — so the right shape is a floor everyone meets and a raised bar for a named few, revisited as the estate and its obligations change.