Rollback approval belongs to one artifact
When we say a prior release is safe to fall back to, that approval should stay attached to one exact artifact identity, because rollback confidence becomes fiction the moment it drifts onto a tag, branch, or rebuilt image that never earned the same proof.
Rollback language often sounds stronger than the evidence behind it. A team says we can always go back, and everybody hears stability. In practice, that sentence is only as trustworthy as the artifact it refers to. If the room cannot point to one exact digest, build, or bundle that actually earned the earlier proof, rollback has already started turning from a recovery option into a comforting story.
We think rollback approval belongs to one artifact. When we mark an older release as the trusted fallback, we want that approval attached to the specific artifact identity that passed the route smoke, health proof, and support reality that made it trustworthy. The approval should not spread automatically to the same tag rebuilt later, a branch tip with the same version string, or a host image that only resembles the earlier state.
rollback-approved: ghcr.io/acme/api@sha256:7f14... approved-from: route smoke, support slice, health checks not-covered-by-approval: ghcr.io/acme/api:stable rebuilt later replacement-needed-if: approved digest no longer exists on target host
A rollback promise gets weaker when identity becomes approximate
This matters because teams often preserve rollback intention better than rollback truth. Somebody remembers that version 42 was good. Somebody else remembers that the stable tag pointed at the healthy build last week. Another operator sees a matching branch name and assumes the old safety story still applies. Under pressure, those approximations feel close enough. They are not. One rebuilt artifact can carry different dependencies, environment assumptions, or side effects while still wearing the same human label.
We would rather make the approval narrower and more honest. If the approved fallback is digest A, the product should say digest A. If digest A is no longer available on the target host, that is not a small implementation detail. It means the original rollback answer is gone and a new recovery question has to be asked. The room may still find a safe path, but it should stop borrowing certainty from an artifact that is no longer the one under discussion.
The same precision matters when a team rebuilds what looks like the same release later. A recreated image with the same version label may still deserve trust, but it has to earn that trust again on its own proof. We do not want the product to silently inherit rollback approval across rebuilds just because the human-facing name stayed familiar. Rebuilds change the object under review, and rollback language should be strict enough to notice that change immediately.
Narrow rollback identity improves review before anything breaks
This is useful long before an incident. Reviewers can approve a release more clearly when they can see the exact fallback artifact that would carry the first retreat. Support can understand whether a rollback plan still points to a known-good state or only to a version label that now hides drift. Operators can verify that the fallback still exists on the right host before they need it urgently. That is much better than discovering the ambiguity halfway through recovery.
It also keeps postmortems sharper. If a rollback failed, we want to know whether the team restored the approved artifact and still saw trouble, or whether the room thought it had restored the approved artifact while actually pulling a different image with the same social name. Those are different failures. One is product behavior. The other is release memory failure. Exact artifact approval lets us tell them apart.
We do not think this requires heavy ceremony. The product can keep one compact line for the approved fallback identity and one compact line for the proof that granted it. What matters is that later operators inherit the same precise answer the earlier operator meant. If the answer changes, the record should change too, rather than asking the old approval to stretch across a new object.
We build Ubriot around release memory because rollback confidence is one of the first things teams overstate when the room gets tense. Rollback approval belongs to one artifact because recovery promises need the same identity discipline as promotions do. Once the fallback stays exact, the team can retreat faster, review more honestly, and stop confusing familiar labels with proven safety.