Concept and mechanism
A traceable release links source, dependencies, build, configuration, test results, and distributed artifacts. A mutable label or latest link can change destination; it is insufficient to identify the reviewed package. Retain suitable identifiers and confirm that promoted content is what received validation. Integrity and functional correctness differ: proving that a file matches the published artifact does not establish business suitability or freedom from defects. Likewise, an evidence report’s existence does not guarantee coverage of every readiness condition. Review evidence contents and limitations as well as checking that the file exists.
Guided application
In a fictional exercise with GitHub immutable releases enabled, prepare the draft and attach artifacts before publishing. After publication, assets and the tag are protected, while title and notes can remain editable under the inspected documentation. A binary correction requires handling a new version rather than silently replacing the old file. In GitLab, a release-evidence snapshot gathers related data, such as test artifacts and matching packages where supported. Inspect which elements were actually included. These mechanisms support traceability but do not replace technical or operational acceptance or authority to make the release available in the intended environment.
An attestation can confirm a match to published content without proving functional correctness.
Common pitfalls
Latest treated as fixed identity; integrity treated as defect freedom; snapshot treated as full coverage; replacing a binary without a new version.
Related topics: Scope, version, and outcome · Sequence, capacity, and dependencies · Readiness and gradual exposure
Preserve identity and history while checking what evidence does and does not establish.
Reference: Immutable releases · Google SRE release and canary guidance; GitHub immutable releases and GitLab release evidence and deployment safety; DORA five-metric model; inspected 2026-10-01