A reproducible build produces identical specified artifacts from the same source, build environment, and instructions. Recoverable source means the required source material is available; it does not establish that the application can be rebuilt or that another build will produce the same artifacts.
A successful build, a reproducible build, and a traceable deployed release establish different properties. The first produces an artifact. The second establishes repeatable artifact identity. The third connects what is running to the inputs and activity that produced it.
The build environment is an input
Source files do not determine an artifact alone. Compiler and linker versions, dependencies, generated files, configuration, and build instructions participate in the result. An implicit dependency on a developer’s working directory can remain invisible until the build moves elsewhere.
Recovering a build therefore requires more than finding a repository. The repository must correspond to the deployed application, and the inputs needed to transform that source into the required release must remain obtainable and usable.
Suppose a project builds on the original workstation because a library was installed manually years earlier. A clean environment fails because the library is absent. The source was recovered; the build dependency was not. Copying the successful executable to the new machine preserves execution but does not resolve the missing build input.
Define the artifacts being compared
Reproducibility applies to specified outputs under stated conditions. A comparison needs to identify which artifacts matter and which environment properties the claim fixes. Without that boundary, differences caused by timestamps, paths, or generated metadata remain uninterpretable.
A second build independent of the original working directory tests whether the written inputs and instructions are sufficient. Artifact digests then compare the selected outputs. A matching digest supplies evidence of byte identity; it does not explain whether the program meets a business requirement.
A working repeatable build is a useful recovery milestone even before byte-for-byte reproducibility is achieved. It should be named accurately. Calling that milestone reproducible conceals the remaining artifact differences rather than resolving them.
Provenance records the production history
Build provenance describes the inputs and activity associated with an artifact. SLSA v1.1 distinguishes the build definition from details of an individual run and treats resolved dependencies as best-effort information. A provenance record therefore does not guarantee that every dependency was captured.
Availability is a separate property. A record can name an exact compiler or library that the organization no longer possesses. The history explains how an artifact was produced without supplying the means to reproduce it.
Source and artifact identities must also remain distinct. A release tag is a repository reference, and Git permits tag replacement. Recording a tag name alone does not establish immutable build input or prove that a deployed binary came from that input.
Demonstrate maintenance, not only rebuilding
A recovered build supports change only when the available maintainers can use it. A small controlled modification tests knowledge of the build, deployment, and application behavior together. The result must still pass the accepted workflow checks.
This exposes a different gap from missing artifacts. A complete toolchain can exist while nobody can explain a critical calculation or safely modify a component. Conversely, an experienced operator can understand the process while lacking the source or tools needed to alter the implementation.
What the evidence preserves
A useful release record connects source revision, toolchain, dependency information, build instructions, selected artifact identities, and acceptance results. Recovery preserves the inputs and the previous release as well as the record describing them.
The scope of the claim remains explicit: obtainable source, a working build, verified reproducibility, or a demonstrated maintenance path. None of those properties guarantees secure dependencies, functional correctness, or future availability by itself. Together they distinguish possession of software from the ability to sustain it.