Show the running image before the fix command
Recovery gets safer when the team sees the artifact it is about to replace before a familiar maintenance command turns into an accidental rollback.
Operational recovery commands often arrive wrapped in ordinary language. Restart the service. Pull the image. Recreate the container. Sync the host. Clean things up and move on. Those phrases sound procedural, which is exactly why they can hide risk. The moment a command can swap the running artifact for a different one, it is no longer just maintenance. It is release movement under a less dramatic name.
We think the system should show the running image before the fix command is allowed to feel routine. If the host is serving digest A and the next command will trust digest B, the operator deserves to see that replacement plainly before the command starts. Otherwise a familiar recovery step can quietly become an accidental rollback.
That matters most when production drifted away from the registry without everybody feeling that drift in the moment. A locally built image may have carried an urgent fix. CI may have stopped publishing while direct host work kept the service moving. The registry tag may still look normal. A later pull can then reintroduce older behavior while everybody involved believes they are simply restoring order.
Routine wording can hide provenance change
Teams move faster when commands are familiar. That is good until familiarity starts covering over the artifact boundary that really changed. Pull latest sounds harmless if everyone assumes latest still points at the artifact production had in mind. Once that assumption breaks, the wording becomes misleading. The operator is not just refreshing a service. The operator is choosing a new trust target.
We want the screen to say that out loud. Running artifact sha256 Y from current host state. Incoming artifact sha256 X from registry. Last proven rollback target sha256 Z. Those sentences are not ceremony. They keep the operator from borrowing confidence from a command name that no longer describes the real decision.
This also helps the team ask a better question. Not should we rerun the usual fix command, but what evidence says the incoming artifact is safer than the one the service is already using. If the answer is thin, the pause is valuable. If the answer is strong, the team can proceed with clearer understanding of what is changing.
That visibility becomes even more important during incidents. People under pressure naturally reach for standard recovery motions. If the product leaves artifact identity implicit, the fastest hands can accidentally move the service backward while trying to make it healthier. Showing the running image first slows only the dangerous kind of speed.
It also improves review after the fact. When we can see which image was live before the command and which image arrived after it, the conversation becomes more precise. The question is no longer why did recovery feel strange. It becomes which trust boundary moved, and whether that movement was actually the safest option available at the time.
Fix commands need release memory, not only success output
A recovery action should leave behind the same sort of memory a deliberate deploy leaves behind. What was running. What replaced it. Why did we believe the replacement was safer. Which rollback target still remained after the change. Without that record, the next operator inherits a cleaned-up service but not the trust story that explains how it got there.
That record also changes who can recover safely. When the replacement boundary is visible, the next engineer on call does not need to personally remember which host-only fix was still in production or whether the registry publish path had stalled earlier in the week. The product carries the artifact truth forward, which makes recovery less dependent on one person's memory under pressure.
That gap becomes expensive when symptoms return. The team may waste time reading recent source changes when the more relevant event was artifact replacement during a recovery step. Or they may blame the fix command itself when the deeper issue was stale provenance the system failed to expose before the command ran. Better release memory separates those cases quickly.
We build Ubriot around release memory because shipping is not only about the commands that finished successfully. It is also about preserving the judgement around which artifact was trusted, which artifact was displaced, and what proof existed at the time. Recovery deserves that same discipline because recovery commands can change production just as surely as planned releases do.
Show the running image before the fix command because a familiar command name is weak proof. The team needs to see the current artifact, the incoming artifact, and the last safe fallback in the same place. Once that evidence is visible, maintenance stops pretending to be harmless whenever it is actually making a release decision.