SYSE.32:5 - Archetypal Grounding
In a constructed ParcelWorks example, integrated source revision r17 produces artifact h1. The labels h1 and h2 stand for distinct artifact digests, not actual cryptographic values. The address-transformation tests exercised h1 under their stated conditions. A staging job later rebuilds r17 and obtains h2 because a build input changed.
The team wants to move the tested software to a candidate runtime. Its immediate question is whether the selected artifact carries the required evidence, not whether that runtime is already usable.
| Candidate situation | What is established | Next action |
|---|---|---|
| The consumer receives h1, and the required results concern h1 under applicable conditions. | Identity and those stated evidence relationships are preserved. | Return the artifact basis; deploy and test the target separately. |
| The consumer receives h2 with h1’s test result. | The source label matches, but the tested artifact does not. | Select h1 or qualify h2 as a new candidate. |
| Provenance names h1 while the consumer receives h2. | Artifact/provenance correspondence fails. | Stop the dependent authenticity claim and inspect the mismatch. |
| Provenance is correctly signed but names an unexpected builder or source. | Signature validity does not meet the consumer’s expectation. | Resolve the unexpected origin through the configured trust decision. |
| The verifier is unavailable. | Verification has not been observed. | Restore verification or obtain an explicit bounded exception; do not report a pass. |
For the normal branch, the consumer obtains the retained h1 bytes through the supported artifact store. The expected identity comes from the qualified build/evidence result, not merely from the same mutable label used for downloading. The consumer verifies the required identity and authenticity conditions. Destination configuration c2 remains separate and has not yet been exercised in a runtime.
The resulting statement is narrow: h1 is available with the named applicable evidence for the intended next use. SYSE.41 must still install h1 with c2, observe the actual target state and perform the bounded deployment test. An application-form defect not covered by the earlier tests remains possible.
In the adverse branch, the staging system insists on rebuilding. The team can either change that delivery mechanism to consume retained h1 or explicitly qualify h2. It cannot retain the claim of unchanged-artifact promotion while taking the second route. If the old artifact is no longer retrievable, the first route is unavailable even though its digest and logs remain.
A second supplier signs a package with a valid key, but the supplied build uses an unapproved source location. Automatic acceptance based only on signature success would admit the wrong origin. The consumer rejects this build for its unapproved source despite the valid signature.
What changes in practice is that a test result follows the artifact it actually exercised, while installation, target configuration, authenticity and release remain separately answerable questions.