A reopened release should not inherit stale approval

A release pause can last long enough for the underlying facts to move. The artifact is rebuilt. A store status changes. A rollback target disappears. Someone narrows the audience and then widens it again. By the time the team reopens the rollout, the old approval note may still be sitting there as though nothing operationally important changed.

We think a reopened release should not inherit stale approval. If the thing being resumed is not meaningfully the same release state that was approved earlier, the system should ask for approval again and say why. The previous approval may still be useful context. It should not continue posing as current proof.

release: reopen
previous-approval: expired
expired-because: artifact digest changed after pause
needs-now: fresh reviewer signoff plus rollback target check

A pause does not freeze the evidence

Teams often speak about paused releases as though time simply stopped. In practice, a paused release can keep drifting. The build may be rerun to fix signing. A host deploy may replace the artifact the release note originally referenced. The audience assumptions may change because support asked for a smaller rollout path. None of those moves are dramatic on their own. Together they can make yesterday's approval narrower than today's release state.

If the product leaves the old approval active, it lends confidence to a state the reviewer never actually saw. That is how approval turns from evidence into atmosphere. The label still says approved, so the room relaxes. Meanwhile the artifact, rollback posture, or delivery path may already be different enough that a fresh decision is the honest requirement.

This matters even when the change seems operationally small. A rebuilt artifact with the same version label can still be a different trust target. A reopened rollout that lost its previous rollback candidate is not carrying the same safety posture. A release that moved from one audience slice to another may now expose a different risk pattern even if the binary stayed unchanged.

Approval should expire on evidence boundaries, not on a timer alone

Many teams treat approval expiry like a time-based rule. Twelve hours passed, approve again. That can be useful, but it is not enough by itself. The stronger trigger is an evidence boundary. If artifact identity changed, if audience scope changed, if rollback readiness changed, or if the proof that originally supported approval is no longer current, the approval should expire even if only a few minutes have passed.

That boundary-based expiry helps reviewers too. They are not being asked to rubber-stamp because time passed. They are being asked to look again because the release state actually changed in a way that affects trust. That keeps approval tied to real operational judgement rather than habit.

It also improves automation. A release system can detect digest drift, missing rollback identity, or widened audience scope much more reliably than it can infer whether a human still feels the old approval probably covers the change. Once those boundary changes are machine-visible, the safer product behavior is to expire the approval automatically and ask the reviewer to inspect the release as it now exists.

It also keeps incidents cleaner. When a reopened release fails later, the team can see whether fresh approval was missing, whether stale approval was allowed to survive too long, and which change should have invalidated it. Without that structure, postmortems often describe the failure as a vague process miss instead of a precise proof-boundary mistake.

We want reopen to mean review again when the trust target moved

We build Ubriot around release memory because paused work is still live operational work. Reopen should therefore be a first-class transition, not a casual return to motion. If the trust target moved during the pause, the product should carry that fact forward and make fresh approval explicit.

That approach also improves handoff. The next operator does not have to infer whether the old signoff still applies. The product can say it plainly. Previous approval expired because the artifact changed. Previous approval still valid because evidence and audience are unchanged. Those are small sentences with large operational value.

A reopened release should not inherit stale approval because approval is only useful while it still points at the same trust target. Once that target moves, the safer move is simple: preserve the old approval as history, ask for fresh approval as proof, and let the reopened rollout carry evidence that is actually current.