Article · Continuum Attest
The software is delivered. Its evidence should be too.
Portable evidence remains useful when software leaves the environment that built it. The signed receipt travels with the file instead of staying only behind a job link.
What gets lost in transit
In the producer’s workspace, context is nearby: files, commands and logs sit together. Once the archive moves to another machine, its recipient may have only a filename and an explanation sent separately.
Keeping a receipt with the artifacts reduces that loss of context. The record identifies the recorded build and declared fingerprints. Its signature makes changes to the record detectable.
Prepare a useful set of materials
Recipients need the receipt, relevant artifacts and required trust material. Recomputing some hashes also requires the corresponding workspace. An evidence archive can transport materials required for the checks it supports.
Public keys must be approved by the recipient. Placing a key in the same directory as the receipt does not justify trusting it. Transporting a key and deciding to trust it are different operations.
Verify before depending on the network
A simple exercise is to prepare the materials, disconnect from the build system and run the planned checks. Offline verification describes the CLI’s different modes.
Read which checks ran and any reported errors. A successful signature check does not mean missing files were compared. The test must match the question being asked about the delivery.
Start small
Follow the CLI documentation to produce a first signed receipt. Then read the receipt format to understand its contents and signing rules.
Keep that example as a reference: one build, its declared files, its receipt and a verification result. Repeat it when the build process changes.
Continuum Attest gives this practice a concrete object: portable evidence a recipient can examine using their own verification tools.