A recovery rerun should state what changed
When we rerun a failed release check or deploy path, the rerun record should say what actually changed first, because repeated green or repeated red means very little without a visible delta.
A release rerun can look more informative than it really is. The command runs again. The route smoke passes this time. The deploy succeeds on the second try. The health check is still red. Everybody can see the new result, and that can create a false sense that the story has become clear. Often the real question is smaller: what changed between the first run and the second one.
We think a recovery rerun should state what changed before it states what passed. If the second deploy used a rebuilt image, say that. If the rerun happened after a queue drain, a config repair, a host restart, or a narrower smoke target, say that. If nothing changed except time, say that too. We do not think teams should have to infer the delta from scattered logs while deciding whether the rerun deserves trust.
rerun: route smoke prior-result: failed on payment callback path changed-before-rerun: rebuilt artifact sha256:next and refreshed callback secret mount current-result: passed trust-boundary: fresh only for sha256:next on current host
A rerun result is only as useful as its visible delta
This matters because a rerun can fail or pass for reasons that have nothing to do with the underlying release question. A service may simply have needed another minute to settle. A host may have restarted onto the wrong artifact. A dependent provider may have recovered. A local fix may have landed between attempts. Those are very different stories. If the release record shows only reran and passed, the room is left borrowing confidence from a result whose cause it cannot defend.
The same weakness appears when the rerun fails again. Two failures can mean the first diagnosis was right. They can also mean the team reran the same broken state without changing the boundary that actually mattered. We want the product to make that difference visible. A repeated red after no meaningful change is not new evidence. It is confirmation that the room asked the same question twice.
Visible change records also make approvals smaller. A reviewer can say I trust this rerun because it follows a rebuilt artifact plus a fresh route smoke, or I do not trust it yet because the rerun used the same artifact and the same host state after only waiting longer. That is a much cleaner decision than staring at two timestamps and guessing whether the second check means progress or just repetition.
We want reruns to distinguish repair from repetition
This becomes especially important during direct deploy recovery. When a deploy first fails, we often need to decide quickly whether the next attempt is a repair attempt or merely another try. If the product records the changed artifact, changed config, changed target, or unchanged state plainly, the next operator inherits a real release story instead of a sequence of commands.
That helps support and leadership too. They do not need every shell detail. They do need to know whether the rerun represents a real change in the release state. Passed after host restart and same artifact is different from passed after rebuilt artifact and route-specific fix. The first may justify caution. The second may justify resumed confidence. Without the delta, both can look like the same green badge.
The same record sharpens rollback thinking. If a rerun passes only after we changed one boundary, we can tell exactly which state the fresh confidence belongs to and which older state still deserves skepticism. That makes it easier to decide whether a later failure should send us back to the previous artifact, back to the previous host state, or simply back to one narrower check that never actually changed.
We also think unchanged reruns deserve explicit language. Sometimes waiting is the correct move, and a later rerun on the same artifact is honest. In that case the record should say no code or config changed, only system state settled. That tells the team something useful about the original failure and about how much authority the new green result should carry. Silence about the delta forces the reader to guess.
We build Ubriot around release memory because recovery work is full of second attempts that can look wiser than they are. A recovery rerun should state what changed because the result alone is not the lesson. The lesson is whether the system is looking at a repaired state, a narrower question, or the same state one more time. Once we preserve that difference, reruns become easier to trust and much easier to review honestly later.