An approval note should name its expiry trigger

Approval is often written as though its meaning will stay obvious later. A reviewer signs off on a rollout, the release moves forward, and everybody assumes that approved status will remain intelligible until the work finishes. In practice, release state keeps moving underneath that label. The artifact changes. The audience widens. The fallback artifact disappears. A pause turns into a reopen. Yesterday's signoff may still be visible while its actual boundary is no longer clear.

We think an approval note should name its expiry trigger. If the approved state depends on a particular artifact digest, a particular audience slice, or a particular rollback condition, the note should say which future change would make that approval stale. Signoff is stronger when it carries the line beyond which it no longer deserves to be treated as current proof.

approval: active
artifact: build-421
audience: ios beta 20%
expires-when: artifact digest changes or audience widens
rollback-required: build-418 still deployable

Approval goes stale through state drift, not only through time

Teams sometimes talk about stale approval as though it were mostly a time problem. A day passes. A week passes. The signoff feels old. Time can matter, but the more important issue is state drift. Approval should age when the release no longer matches the thing that was actually reviewed. That could happen in ten minutes or not at all for several days. The key question is whether the trust target moved.

Without an expiry trigger, later operators have to infer that boundary from scattered evidence. They compare the current rollout to old notes, try to remember what the reviewer had in mind, and decide whether the differences are small enough to ignore. That is a poor use of attention in moments that are already operationally narrow. The approval record should do more of that boundary work itself.

This matters because release systems are full of transitions that feel small locally and large in aggregate. A paused rollout reopens with a new audience percentage. A rebuilt artifact keeps the same version name. A support issue removes the old rollback target from easy reach. None of those changes automatically make the release unsafe. They do change what yesterday's approval can honestly be said to cover. Naming the expiry trigger keeps that shift visible.

It also helps teams stop borrowing confidence from a label that survived after its proof narrowed. Approved is one of the easiest words in release work to over-trust. The expiry trigger turns that word back into a bounded operational statement. Approved while this artifact, this audience, and this rollback posture still hold. That is much easier to act on honestly.

An expiry trigger makes the next decision narrower

The value is not bureaucracy. The value is shrinking the next question from does this old approval still feel okay to has one of the named expiry conditions actually happened. If the audience widened, refresh approval. If the artifact digest changed, refresh approval. If the rollback target is gone, block the rollout or gather new proof. The decision becomes concrete enough that a handoff does not depend on whoever remembers the old context most vividly.

That narrower decision also improves pause and reopen handling. A product can preserve the previous approval for history, show exactly why it expired, and ask for fresh signoff only when the named boundary moved. This keeps approvals current without forcing teams to repeat ceremony when nothing meaningful changed.

Incident review gets sharper too. If a rollout kept moving on stale signoff, the team can see whether the failure came from missing evidence or from a note that never said what would make it stale in the first place. That is easier to fix than a generic conclusion that approval somehow drifted.

The same structure helps non-engineers. Support leads, managers, and release approvers can read one line and understand why fresh signoff is needed now. They do not need a long engineering explanation to know that the current release no longer matches the original approved shape. The product has already named the trigger.

Release memory is stronger when approval carries its own boundary

We build Ubriot around release memory because release tools should preserve the judgement around commands, not only the commands themselves. Approval is part of that judgement. If signoff can expire, the release record should say what expires it. Otherwise the product is leaving one of the most important trust boundaries to human recollection and optimistic interpretation.

An approval note should name its expiry trigger because signoff is only useful while it still points at the same release state. Once the record says what would make approval stale, the next operator can reopen, pause, or continue the rollout with a much clearer sense of what proof still exists and what proof now needs to be renewed.