Developer manual · immutable releases
Release Engineering
A release is an immutable evidence target. Once v3.4.2 was frozen and published, qualification can add evidence about it, but release-critical bytes must not be silently rewritten.
v3.4.2 release identity
| Artifact | Value |
|---|---|
| Release | v3.4.2 |
| Protected commit | 6dfa3d6cc738d9369cf092d2782676bf4f2a46e4 |
| Release tree | f90bf74e29899f82d0a4ee321604346241bba4de |
| Release-origin attestation SHA-256 | 0ba4b0cc8c34688d98ef3c3425fbd70ff5b59d26183a18a15506bbad3adea0c1 |
Freeze rule
Post-freeze testing may add evidence; it may not rewrite the immutable release artifact. If training or qualification changes model weights, source, executables, schemas, protocol behavior or other release-critical hashed material, the modified system becomes a subsequent candidate/release.
Promotion sequence
- Qualify candidate and capture exact commit/tree/manifests.
- Run required repository/security/conformance checks.
- Merge through protected main.
- Create the signed/immutable release tag and GitHub Release.
- Publish release-origin evidence/sidecars.
- Mark the prior release superseded without rewriting its tag/history.
- Continue post-release qualification as separately hashed evidence.
Supersession
v3.4.1 is explicitly retained as immutable historical provenance and marked unsupported for current deployment. Supersession changes support status, not historical bytes.
Open post-release gates
RUST_COMPILED_QUALIFIED, REAL_WORLD_TRAINING, hardware-backed key custody, physical multi-host qualification, certified-device pilot, 30-day wall-clock operation, independent security audit and independent assessor receipt remain post-release qualification evidence.