Immutable artifact promotion
Promote a tested content identity across environments while recording configuration separately and preserving the evidence needed to reproduce a release decision.
On this page
The question for today
What you’ll understand
- Distinguish a mutable tag from a content digest.
- Define the artifact and configuration identities needed for an auditable promotion.
- Explain why provenance and byte identity do not establish application correctness.
A release should make it possible to answer a concrete question: are the bytes running now the bytes that passed the intended checks? Building a fresh package for every environment makes that question harder because each build can introduce a new difference. Immutable promotion retains one artifact identity while applying the environment-specific configuration and policy checks needed for the target.
Identify bytes rather than a movable label
A container tag is a convenient name whose target can change. A digest identifies content under the selected digest scheme, so a deployment pinned to that digest is not silently redirected when somebody moves a tag. Verify the retrieved content through the platform's supported mechanisms and record the expected digest in desired state. A multi-platform image index and one platform-specific manifest are different content objects: identify which digest was approved and which platform actually ran. Immutability of a reference also does not guarantee that its registry remains available forever.
Promote the same approved artifact rather than recompiling from a branch name for production. Source revisions, locked dependencies, toolchain versions, and build parameters help explain how it was produced, but a source commit alone does not uniquely specify every possible output. If a transformation signs, repackages, or changes the content, give the resulting artifact its own identity and verification step. A retention policy should preserve the promoted object and necessary evidence through the rollback window instead of depending on a developer's temporary cache.
Configuration is another release input
The same image can behave differently with different flags, resource limits, secrets, model weights, or external endpoints. Record the configuration revision and compatible schema or protocol requirements alongside the artifact. Secrets should be referenced through appropriate managed identities or versions rather than copied into public release notes. An immutable image plus an unversioned mutable configuration is not a fully specified release. In AI infrastructure, a model checkpoint, tokenizer, serving code, and feature pipeline can each need a content identity or explicitly versioned contract.
A promotion record can bind an artifact digest, target environment, configuration revision, evidence references, and the policy decision. That record should distinguish intended state from observed running state. A successful configuration commit does not establish that every workload pulled the expected image or became ready. Conversely, a node cache can still run the correct digest even when a tag no longer points to it. Observe the actual platform-specific identity and application health without treating a tag display string as definitive evidence.
Identity narrows uncertainty rather than eliminating it
Provenance can describe a build process, and a signature can authenticate a statement under a trusted identity. Neither proves that the code has no defect, that dependencies are harmless, or that production data matches a test case. Preserve functional tests, compatibility checks, staged exposure, and recovery plans as distinct controls. When a rollback is requested, select a known retained digest and a compatible configuration/state combination. Rebuilding a historical source revision under today's dependencies is a new build that needs its own evidence.
The cache lab gives a narrow reuse analogy. Reset, set both C=4 and s=4, predict twelve hits among the initial sixteen fixed requests, then Play or Step. Separately Reset, set both C=4 and s=1, predict zero initial hits, then Play or Step. Four recurring identities fit the first toy LRU stream. It does not hash, fetch, sign, or verify artifacts and contains no registry behavior. Use the contrast only to discuss retaining known immutable objects, then explain why a cache hit is not an authorization or correctness decision.
Work it through
Build once; keep environment configuration separate
An illustrative release pipeline targets four environments. One reproducible candidate build consumes eight CPU-minutes and each environment's separate verification consumes three CPU-minutes. Compare rebuilding in every environment with promoting the same built artifact.
Four independent builds consume 4×8=32 CPU-minutes, before the 4×3=12 CPU-minutes of environment verification. The modeled total is 44 CPU-minutes.
Building once consumes eight CPU-minutes and the four target verifications still consume twelve. Promotion therefore uses twenty CPU-minutes in this deliberately fixed-work accounting.
The modeled saving is 24 CPU-minutes. Each target still records its configuration and observed artifact identity; this calculation does not say that copying or verifying takes zero wall time or that one environment's health proves another's.
Reusing an approved content object reduces one source of variation and repeated work. Environment-specific behavior and policy remain separate evidence.
The living notebook
Explore the model
Interactive lab · cache
Retain known content identities
Reset, set both C=4 and s=4, predict twelve initial hits of sixteen, then Play or Step. Separately Reset, set both C=4 and s=1, predict zero, then Play or Step. The fixed LRU stream is only an object-retention analogy; it performs no digest, signature, registry, or policy verification.
- Hits / requests
- 0 / 16
- Hit rate
- 0%
- Address-stream period
- 16 addresses
A fully associative LRU cache starts empty and requests address (i·s) mod 16. Hits move an address to the newest position; misses evict the oldest when full. Playback starts with 16 requests and adds two per second, capped at 4096 explicitly simulated requests. This toy stream is not a processor-cache benchmark. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forReusing an identity can avoid repeated production work, while integrity, authorization, and application health still need their own checks.
Pause & reason
Check your understanding
Your turn
Try it yourself
A deployment records an immutable image digest but reads an unversioned feature configuration that changes at noon. Can the image digest alone reproduce behavior observed at 13:00? Name the additional evidence needed.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
List mutable inputs outside the image and distinguish intended from observed state.
Compare with the solution
No. Record the configuration or flag version and relevant evaluation context, compatible data/schema state, external model or asset identities, and the observed running artifact/platform identity. Preserve the release decision and test evidence as well. The digest reproduces one content object, not every input influencing the application's behavior.
Keep the idea
Take it with you
- Promote an approved content identity instead of rebuilding a movable source label.
- Version configuration and compatible state alongside executable bytes.
- Provenance, identity, availability, and correctness establish different properties.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.