A reopened release should dim yesterday's proof

A green check carries a lot of emotional force. It tells the room that something passed, that someone already looked, and that at least one source of uncertainty has narrowed. That is useful. It becomes dangerous when the release state changes and the same green check still looks as though it was earned for the current state.

We think old green checks should look old. If a release paused, reopened, changed artifact, changed audience, or repaired one part of its path under pressure, the proof that came before that shift should stay visible as inherited evidence, not fresh evidence. The point is not to erase work the team already did. The point is to stop the interface from making yesterday's certainty impersonate today's.

release: reopened
artifact: sha256:new
inherited-proof: route smoke from sha256:old at 10:12Z
fresh-proof-required: health smoke, audience confirmation
display: inherited checks dimmed until rerun

State changes can make an honest proof stale very quickly

This is not only about time. A route smoke from two hours ago may still be strong if the artifact and audience are unchanged. The same smoke may become weak immediately if the deploy was rebuilt, rollback posture changed, or rollout reopened on a different slice. The issue is not age alone. The issue is whether the thing being trusted still matches the thing being shown.

When the product does not mark that difference clearly, teams borrow confidence without noticing. A reopened release still shows healthy route proof, but the route proof belongs to the earlier artifact. An approval still looks current, but the rollback target it assumed is gone. A canary still shows green, but the audience percentage is now wider than the earlier smoke ever covered. None of those errors require bad intent. They only require an interface that leaves inherited proof looking fresh.

We would rather make inheritance explicit. This check passed before the pause. This approval belonged to the earlier artifact. This smoke covered 10 percent, not 40 percent. Once that distinction is visible, the room can decide what needs rerunning instead of unconsciously trusting proof that has already changed shape. The UI should not ask operators to remember which green badge is historical. It should show that boundary on purpose.

Inherited proof is useful when it stays legible as inheritance

We are not arguing that every state change should blank out the whole release record. Old proof still matters. It can explain why the team reopened at all. It can show what was healthy before the pause. It can help the next operator compare what changed between one attempt and the next. Inherited proof has real value. It just should not quietly wear the same visual confidence as fresh proof.

This matters most after rescue work. Suppose a service deploy first passed route smoke, then later needed a host-side repair, then reopened for another check cycle. The original route smoke still belongs in the story. It shows that one path worked under one earlier state. It does not deserve to keep the same bright green posture once the release is asking the room for a new decision.

The same rule helps approval chains. Reviewers can see which evidence they are inheriting and which evidence was rerun after the state changed. That makes signoff narrower and much more defensible. It also helps support and management read the release truthfully without assuming every visible check was earned against the exact system now serving traffic.

We separate what still matters from what still counts

At Ubriot, we think release memory should preserve both facts. What still matters includes older smoke checks, earlier approval context, and the last known healthy comparison point. What still counts for the next promote or widen decision may be smaller. A reopened release can carry yesterday's evidence without borrowing yesterday's authority. Once the interface makes that split clear, operators stop confusing historical reassurance with current readiness.

That makes reopen flows calmer. Instead of arguing whether the old checks are useless or still good enough, the room can see the right question directly. These checks are inherited. These others are fresh. This is the gap between the two. The product has turned a vague confidence debate into a smaller operational decision.

It also improves rollback judgement. If a newly reopened release narrows again, the operator can see which proof belonged to the earlier state and which proof actually covered the current one. That makes the next move easier to defend because the evidence boundary is attached to the state that earned it.

A reopened release should dim yesterday's proof because inherited evidence and current evidence do different jobs. We build Ubriot to keep those jobs legible under pressure. When the product dims old certainty instead of letting it impersonate fresh safety, reopened releases get less magical, approvals get narrower, and the next shipping decision gets a lot harder to fake.