Limit 04 of 11
Cross-build determinism
Determinism holds within a build, identified by artefact hash. It does not hold across builds.
The problem
What actually goes wrong
Given the same input and the same artefact, Ackren produces the same output, every time, on every machine. That is the guarantee, and it is unusual enough to be the reason a regulator can re-derive an answer with a printout and a pencil.
Change the artefact and the guarantee does not carry over. A new build may have a different lexicon, different pruning, different fingerprint widths. The same question can produce a different answer, and there is no mechanism that makes the old answer reproducible under the new build.
The impact
Who this affects, and how much
For a live deployment this is the difference between "we can show you exactly how this answer was reached" and "we can show you how this answer would be reached today". For an audit of a decision made eighteen months ago, only the first is useful.
It means artefact retention becomes a compliance requirement rather than an engineering preference. If you cannot reconstruct the build, you cannot re-derive the answer, and the strongest thing about the architecture stops being available to you.
What it means
The honest reading
It means the artefact hash is load-bearing. It is in the derivation record on every turn, and a record without it cannot be re-derived and is therefore not a record. This is stated in the schema rather than left to operational discipline.
It also means we do not claim bit-identical behaviour everywhere and always. The claim is scoped: determinism holds within a build, identified by hash. Anyone quoting us as saying more than that is quoting us wrongly.
Stated position
This limit is published before anyone else finds it. It is one of eleven rows in the failure accounting, and it will not be quietly removed from this page if it becomes inconvenient.
Roadmap
What we are doing about it
- 01
Now
The hash is in every record, and the specification states the scope of the determinism claim rather than leaving it to be inferred.
- 02
Next
Build retention guidance for regulated deployments: how long to keep an artefact, how to store it, and how to prove the one you kept is the one that ran.
- 03
Later
Signed reproducible builds, so that a third party can reconstruct an artefact from source and verify the hash independently rather than trusting ours.
- 04
Never
A claim of determinism across builds. Different authored material is a different system, and pretending otherwise would make the guarantee meaningless.