Trust the running digest before the registry tag
A release team gets safer decisions when the product shows the exact artifact serving traffic right now, because a registry tag can look current while production is actually trusting something narrower, older, or manually repaired.
A registry tag is easy to read and easy to over-trust. It looks like a stable name for the thing production is running, so teams start speaking as though the tag and the live artifact are naturally the same fact. Most of the time that assumption feels harmless. It becomes dangerous the moment a release path has drifted, paused, or been repaired under pressure.
We think the release surface should trust the running digest before the registry tag. If the host is serving digest A, start there. If the tag called latest now points at digest B, that is useful metadata, not proof about what customers are actually hitting. Safe deploy judgement begins from the artifact reality is already serving, not from the most convenient label attached somewhere else.
service: api running-now: ghcr.io/acme/api@sha256:7f14... registry-tag: ghcr.io/acme/api:latest -> sha256:9c21... rollback-baseline: running-now promote-only-if: route smoke and health proof stay clean
A clean tag can still describe the wrong baseline
This is not a theoretical edge case. Release paths often acquire temporary exceptions. A host-built repair may be serving traffic while CI is down. A canary host may have advanced while the wider audience has not. A routine pull may refresh a tag while production has not yet restarted onto it. If the product begins its reasoning from the tag, the team can compare against a state that was never the real baseline in the first place.
That weakens every next decision. Approval becomes blurrier because reviewers think they are authorizing one replacement while operations is really replacing something else. Rollback gets less honest because people say go back to the previous image when they have not first named which exact digest is already live. Incident review gets slower because the room has to reconstruct what was serving traffic before it can judge whether the change caused anything.
We do not think this belongs only in runbooks. The active release surface should carry it plainly. Running now is one line. Proposed next is another. Registry context can stay visible too, but it should not outrank the artifact the host is already trusting.
Baseline truth is what makes rollback and comparison real
Rollback is where this shows up fastest. Teams often say they can revert, but revert to what. The last published image. The last approved tag. The digest still serving the broader audience. Those may all be different. If the product records the running digest first, rollback starts from a concrete answer instead of an argument about naming.
The same baseline truth improves deploy proof. A clean smoke after deployment is more useful when the product can show exactly which digest replaced which digest. Without that, the room may celebrate a green check while still being uncertain whether the system actually moved to the artifact it thought it promoted.
This matters for communication outside engineering too. Support, incident leads, and managers do not need the full container story every time, but they do need a product that can answer a plain question accurately: what was live before this change. A tag often sounds like that answer. The running digest actually is that answer.
That answer also improves restraint during rescue work. When operators can see the exact digest still serving traffic, they are less likely to run a second move just because the registry looks newer. They can compare the live baseline against the proposed fix and decide from evidence instead of from label anxiety.
Release memory should preserve what traffic is really touching
We build Ubriot around release memory because shipping confidence decays whenever key facts are left to recollection. The artifact customers are actually touching is one of those facts. If the product remembers the running digest before it leans on the registry tag, approvals get narrower, rollbacks get cleaner, and manual repair windows stop creating hidden baseline drift.
Trust the running digest before the registry tag because production safety starts with what the host is serving now, not with the nicest label attached elsewhere. Once that baseline is visible, the rest of the release conversation gets much harder to fake and much easier to defend.