A deploy plan should name the image production is already running

Teams usually write deploy plans to describe what they want production to become. Build this image. Promote this artifact. Roll forward to this tag. That is useful, but it leaves out one fact that becomes critical the moment anything narrows: which image is production already running right now. When that answer is left to memory, a deploy can still look well planned while the room quietly loses the baseline it would need for rollback, comparison, or incident truth.

We think a deploy plan should name the image production is already running before it says what should replace it. If the live service is on digest X, say that. If the current mobile release path is still anchored to build 441, say that. If production is temporarily trusting a host-built artifact because the normal publish path is still being repaired, say that too. Shipping gets safer when the plan starts from the exact state reality already holds.

target: api-web
live-now: ghcr.io/acme/api@sha256:8c2f...
proposed: ghcr.io/acme/api@sha256:9f14...
rollback-baseline: live-now
replace-only-if: health smoke and route proof stay clean

The current live image is part of the deploy decision, not setup trivia

Operators often assume the running artifact is obvious because somebody can always look it up later. In practice, later is exactly when ambiguity gets expensive. A smoke check narrows confidence. A restart happens on the wrong host. A rollback discussion begins while different people are naming different baselines from memory. Once that happens, the team is no longer deciding between a proposed artifact and a known live one. It is deciding between a proposed artifact and a blurry recollection of what production probably had before.

That blur causes real mistakes. One person compares the new release against the last published image, while production is actually still carrying a host-only fix. Another assumes the currently running digest matches the registry tag, even though the incident path already proved otherwise. The plan may still have a healthy target and a healthy proof list, but its comparison point is already weak. We do not think that is a documentation problem. It is a release-memory problem.

Naming the live image at plan time keeps rollback discussions honest too. Rollback is not only the idea of going back. It is a claim about which known artifact the system can return to without guesswork. If the plan records the running image explicitly, the room can tell whether rollback means return to the exact current state, to a prior published state, or to some narrower emergency baseline that has to remain visible until normal proof returns.

Baseline identity makes proof easier to read under pressure

The same discipline improves routine proof. Health smoke is more useful when the plan already says what the service was running before the change. A clean route check means more when the operator can compare the proposed digest against the actual live digest instead of a remembered tag name. Even approval gets better, because reviewers can see whether they are authorizing a simple increment from the live baseline or a bigger shift than the version label first suggests.

This matters even more after interrupted release paths. A registry may lag production. A manual host fix may be the real baseline for a few hours. A canary may carry a newer image than the broader audience. Those are not rare corner cases. They are exactly the moments when deploy plans need stronger baseline truth, not weaker assumptions that the room will piece the live state together later.

Support and incident response benefit too. When the deploy plan names what production is currently running, later questions become smaller. Did the issue begin after the proposed replacement or while the old image was still live. Did rollback restore the exact previous digest or only the tag that looked closest. Those answers are much easier to defend when the plan preserved the live baseline before motion began.

We do not want operators performing archaeology during a deploy. We want them reading a release surface that already states the current trust boundary plainly. Live now. Proposed next. Rollback baseline. Those three lines remove a surprising amount of ambiguity from both ordinary releases and rescue decisions.

Release memory should preserve what production already trusted

We build Ubriot around release memory because shipping safety depends on more than the next artifact in line. It depends on keeping the current one legible too. If the deploy plan records the image production is already running, comparisons sharpen, rollback stories stay real, and interruptions are less likely to drift into false certainty.

A deploy plan should name the image production is already running because every proposed release is judged against a baseline, whether the product records that baseline clearly or not. We would rather make it explicit, current, and usable before the first promote command ever runs.