Release evidence needs an expiry time
A green check is only useful while its assumptions still match the artifact, configuration, and destination in front of the operator.
A release screen can preserve every check and still make a weak claim. The build passed. The signing check passed. The smoke test passed. The record is complete, but the operator is looking at it two days later after configuration changed and a new artifact entered the queue.
Nothing in the old evidence is false. It is simply no longer answering the current release question. At Ubriot, we think release evidence needs an expiry time. Not one universal timer, but a clear boundary after which a check becomes inherited context rather than current proof.
1. Tie freshness to the thing the check actually proved
A build result belongs to an artifact. A signing result belongs to a credential context and artifact. A device smoke belongs to an app build, operating system, and test path. A store validation belongs to the package that was submitted and the rules applied when it was checked. These results should not all expire together.
If the artifact digest is unchanged, a deterministic package-content check may remain valid. If an environment variable changed, a runtime smoke may need to run again even though the source commit did not move. If the destination track changed, the approval may need another look while the build result stays useful. The expiry rule should follow the dependency, not the wall clock alone.
2. Show why evidence became stale
Stale is not enough information for an operator. The release record should say what crossed the boundary: a newer artifact replaced the checked artifact, release configuration changed, the destination changed, the allowed time window closed, or a later failure invalidated an earlier green result.
That explanation turns rerunning from ritual into a decision. The operator can see whether one focused check needs refreshing or the whole release needs to return to review. It also makes inherited proof easier to use. A result marked stale because the destination changed may still tell us something valuable about the artifact. A result marked stale because the artifact changed does not.
3. Keep expired evidence visible
Expiry should not erase history. The previous check still explains why the team once believed the release was safe to move. It may help diagnose a later difference, compare two artifacts, or understand when a configuration change entered the path.
We prefer to label old results as inherited evidence and keep their original scope visible. That is more honest than either presenting them as fresh or hiding them as if they never happened. An operator reviewing a reopened release should be able to say that the build proof still belongs to this artifact, the environment smoke is stale because configuration changed, and the store check has not yet run for this destination.
The timestamp still matters, but it should support the scope rather than replace it. A check that ran five minutes ago against the wrong artifact is already irrelevant. A reproducible package check from yesterday may remain valid when the artifact digest and toolchain are unchanged. Showing both the checked scope and elapsed time gives the operator enough context to judge the evidence without treating freshness as a decorative badge.
4. Make the next required check explicit
Once evidence expires, the interface should name the smallest check that restores confidence. If only runtime configuration changed, rerun the targeted smoke. If the artifact changed, rebuild the proof chain from the new digest. If the release moved from internal testing to production, ask for the checks attached to that audience boundary.
This keeps release review from collapsing into rerun everything. Broad reruns cost time and can produce a new wall of green results without clarifying which assumption actually changed. A focused refresh is easier to explain, easier to audit, and less likely to hide a remaining gap. The release record should make that narrow path obvious before an operator reaches for the largest available workflow.
We built Ubriot around the idea that release state should remain attached to the exact artifact and decision. Expiry is part of that state. It keeps a green check from silently making promises beyond the conditions that earned it.
Release evidence needs an expiry time because proof is scoped. When the scope changes, the record should preserve what was true, explain what is no longer current, and point directly to the next check that can make the decision honest again.