By 2025, software supply-chain discussions had given teams plenty of terminology. A small engineering team still needs an everyday answer to a simple question: what exactly did we release?
Use one release record
For each deployment, retain the source revision, artifact identifier, pipeline run, relevant approvals and verification result. Link to the existing evidence instead of copying logs into a document nobody will update.
Add a brief description of the user-visible change and any operational action. If a feature requires a new configuration value, make its owner and activation sequence clear.
Verify the deployed version
A green pipeline does not prove that the intended artifact is running. Include a post-deployment check that identifies the deployed version and exercises a representative read or write operation using safe test data.
Separate an artifact’s origin from its fitness for use. Knowing which build produced a package helps investigation; it does not demonstrate correct authorisation, acceptable performance or successful recovery.
Try the record during an incident exercise. Pick an older deployment and ask someone outside the feature team to trace its origin and identify the rollback instructions. Missing links found in rehearsal are much cheaper than missing links during an outage.
Keep the format short enough that it can be generated by the pipeline and reviewed by a person.
Reference
SLSA’s v1.0 announcement provides the earlier provenance milestone behind this 2025 process topic. This checklist does not establish a SLSA compliance level.