Keep the approval snapshot beside the release
A rollout is easier to reopen, pause, or hand off when the current approval keeps its exact artifact, audience, and rollback context attached, instead of leaving signoff as a detached note.
Approval often starts life as a clear operational decision and ends life as a vague social memory. Someone reviewed the artifact, checked the audience, accepted the rollback posture, and said move. A few hours later the rollout is still active, the system has changed around it, and the approval survives mostly as a label that says approved.
We think the approval snapshot should stay beside the release the whole time. If a rollout is live, paused, or reopened, the product should still show which artifact was approved, which audience that signoff covered, what rollback state was considered acceptable, and which evidence made the reviewer comfortable. Approval is more useful when it remains attached to the trust target it actually described.
approval: active artifact: build-421 audience: android beta 10% rollback: build-418 still deployable evidence: signed artifact match plus clean health slice
A detached signoff turns specific judgement into atmosphere
Release teams rarely mean to be vague. Vague approval usually arrives through separation. The reviewer note lives in one screen. The rollout state lives in another. Rollback proof lives somewhere else again. When the team is under pressure, everybody remembers that approval exists without being forced to keep its boundaries in view.
That separation matters because release state moves. Audience scope widens. Store processing completes. A fallback artifact disappears. A pause becomes a reopen. None of those transitions automatically invalidate approval, but all of them can change what approval really means. If the snapshot stays attached, the team can judge those changes against something concrete. If it does not, the room starts borrowing confidence from a signoff that may already be narrower than the current rollout.
This is why we care about the approval snapshot rather than approval status alone. Status says whether someone once felt comfortable. Snapshot says what they were actually comfortable with. Operators need the second answer when the release state is drifting underneath the first.
A visible snapshot also improves handoff. The next operator should not need to chase the artifact digest, the approved audience slice, and the rollback note through separate tools before deciding whether the rollout can keep moving. If the release is still relying on that signoff, the signoff should still travel with the release.
The snapshot should update or expire on real boundary changes
Keeping the snapshot visible does not mean freezing it forever. The point is to make change legible. If the artifact digest changes, the old snapshot should stop posing as current approval. If the audience grows beyond the reviewed slice, the system should say that the existing approval is narrower than the current release. If rollback posture weakens, that should be visible too.
This gives the team a cleaner operational choice. Refresh the snapshot because the trust target moved. Keep the snapshot because the trust target is still the same. Either answer is stronger than letting a detached approval label keep lending confidence to a release that no longer matches its original context.
It also makes incident review sharper. If a rollout later needed to pause, the team can see whether the approval snapshot stayed aligned with the release or whether the release drifted beyond its approved shape. That is much easier to learn from than a postmortem that says approval existed but was somehow stale.
The same discipline helps support and management. A compact snapshot tells them what exactly was approved without forcing them into engineering archaeology. That matters when a release is paused in front of non-engineers who still need a truthful answer about what confidence actually covered.
Release memory is stronger when approval remains attached to evidence
We build Ubriot around release memory because commands are only part of shipping. Approval, audience, rollback, and evidence are the context that makes those commands defensible. A release tool should carry that context forward as the rollout moves, not leave it behind in a note that goes stale the moment the state around it changes.
Keep the approval snapshot beside the release because approval is not a sticker. It is a bounded judgement about a particular artifact, a particular audience, and a particular fallback story. When that judgement stays visible, pauses become clearer, reopens become safer, and handoffs stop depending on whoever remembers the old signoff best.