rebuildable, and then a machine died
Two constraints define reproducibility here, and they arrived years apart. The first is that the executable which ran must be regenerable from a pinned state of the record. So a manifest binds the built artifact's content hash to the exact revision it came from, and a separate offline mode recomputes a single live decision from stored inputs alone. The running system's output can be re-derived without the running system.
That was checked by rebuilding from the committed tree on a second machine and comparing the results, then treating the comparison as an audit rather than a smoke test.
The second constraint arrived uninvited. A machine stopped responding and was assumed lost. The first question asked was not how to repair it but which sealed results could no longer be reproduced. The audit walked the sealed measurements and answered: none. Not because they had been copied elsewhere, but because each was a function of pinned inputs and committed code, which is the only sense in which a sealed result means anything.
The hardware was later recovered — a storage controller, reset — and the same verification was re-run against the restored machine rather than assumed to still hold. What it proves is that reproducibility is treated as an operational property with a test attached, so a machine failure costs a rebuild instead of a result.
drawn from: a build-provenance audit and the durability audit that followed a hardware failure
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.