The deploy record should name what got replaced

Deployment records usually give all their attention to the new thing. New build, new artifact, new tag, new timestamp, new release note, new environment state. That focus is understandable because the team is trying to answer one immediate question: what just went live. Another question matters almost as much once anything goes wrong: what exactly did this deploy replace.

We think the deploy record should name that displaced state directly. If the new release replaced build 418 from the beta channel, say so. If it replaced the last production artifact that support still trusted, keep that in view. If it replaced a locally built image that never reached the registry, that difference matters too. A deployment becomes easier to trust when the team can see both sides of the handoff, not only the new side.

A live deploy is also a removal event

Teams often describe deployment as promotion alone. In reality, every deploy also removes a previously running state from the audience that had been relying on it. That removed state may have been healthy, partially healthy, or already suspect. It may have been the last artifact with known rollback value. If the system records only the incoming release, the outgoing one disappears into memory at the exact moment it becomes operationally important.

That gap becomes expensive during rollback. The team can usually find the new artifact quickly because it is the one everyone just touched. The harder question is which exact binary, store submission, or channel state was displaced when the deploy happened. Without that answer, rollback starts to sound simpler than it really is. People say go back to the previous version when the record never clearly preserved what previous means.

Replacement identity changes how incidents are read

Suppose a deploy goes live and error reports rise within minutes. A release surface that only records the new artifact tells half the story. The stronger record also says what left the stage. Was the replaced build already carrying a narrow warning. Was the replaced channel state partially rolled out to one audience only. Was the replaced artifact built from the same source but signed differently. Those details shape the next decision because incidents are often about differences between states, not only defects inside the newest one.

The same is true when nothing fails loudly. A rollout may look healthy while quietly replacing the last build that had strong proof on a sensitive device class. A store submission may look complete while replacing a release candidate that support still understands better. Keeping the displaced state visible helps the team judge whether the new release truly improved confidence or merely changed which uncertainty is now live.

The outgoing artifact is part of rollback proof

Rollback is safer when the outgoing artifact never stops being explicit. We want the release record to say promoted build 421, replaced build 418, last known healthy evidence from 418 was iOS tester install plus Android production health through 09:10 UTC. That is not extra ceremony. It is the minimum context the next operator needs if the release stalls, if store behavior drifts, or if runtime evidence starts narrowing the audience again.

This is also where direct deployments and registry deployments can diverge in dangerous ways. If the running target replaced a local image newer than the registry copy, the displaced state may be operationally newer than the tag history suggests. A record that names only the incoming tag hides that risk. A record that preserves the exact displaced artifact makes the trust boundary much harder to fake by accident.

We want deploy memory to keep both sides of the handoff

Ubriot is built around release memory because teams ship into moving systems, not blank space. Each deployment is a handoff from one proven or partially proven state to another. We want the record to preserve the artifact that arrived and the artifact that stepped aside, so rollback, support, and approval all start from the same concrete history.

The deploy record should name what got replaced because the outgoing state is not yesterday's trivia. It is the baseline the new release is asking the team to stop trusting. If that baseline stays visible, the next deploy judgement gets narrower, calmer, and easier to defend.