Temporary release rules need expiry markers

Release teams create temporary rules for good reasons. CI is down, so we build on the host. A registry tag stopped being trustworthy, so we pin the running digest directly. One service needs a narrower smoke before the full suite is healthy again. Those rescue decisions can be disciplined. The weakness usually comes later, when the room remembers the exception but not the condition under which it should stop applying.

We think temporary release rules need expiry markers. If we allow a host-built artifact while the normal publish path is impaired, the release record should say when that allowance ends. If we accept a narrower smoke because one dependency is under repair, the product should say what fresh proof retires that narrower standard. Rescue work stays much safer when the exception arrives with its own exit condition.

temporary-rule: host-built artifact allowed
introduced-because: registry no longer reflects newest proven image
applies-while: ci publishing remains unavailable
expires-when: registry proof and route smoke match the promoted digest
after-expiry: approvals must use normal publish path again

A rescue allowance can outlive the rescue

This is where release memory often weakens. The emergency rule solved a real problem on Tuesday, then quietly remains in force on Friday because nobody preserved the exact condition that made it exceptional. Later approvals start leaning on the workaround as though it were normal process. A direct host build becomes the assumed baseline. A narrowed verification step becomes the habitual one. The organization stops feeling the weight of the exception because the product never taught the exception to expire.

We have seen the cost of that kind of drift in ordinary operations. Once a temporary path loses its expiry marker, rollback stories become less honest. Reviewers may think they are comparing a proposed release against the usual registry lineage when production is still carrying a rescue artifact from an earlier interruption. Support may hear that the deploy followed the normal path when the live trust boundary is actually narrower. The room still has a process, but the process is now borrowing authority from memory instead of from visible state.

Expiry markers keep the rule attached to its reason. They let us say this workaround is valid only while CI publishing is unavailable, or only until the rebuilt artifact has fresh route proof on the exact host now serving traffic. That makes later decisions much easier to defend. The release no longer has to guess whether the exception still deserves to travel with it. The answer is recorded at the moment the exception is created.

We want exceptions to decay on purpose

An expiry marker does not need to be complicated. It can be a timestamp, a replacement proof, a restored dependency, or a named next check. What matters is that the marker is concrete enough to remove the rule without a debate about organizational mood. Once the condition clears, the rescue path should stop carrying normal approval authority. The product should make that transition visible instead of waiting for someone to remember that the rule felt temporary at the time.

This also improves reruns. If a deploy succeeds under a temporary rule, the rerun record can say whether the same rule still applies or whether the room has returned to the stronger path. That is much more useful than a second green check with no context. The operator reading later can see whether confidence grew because the underlying release posture improved, or because the system kept asking the same emergency path to do more work than it should.

Approval chains benefit too. A reviewer can approve one move under an explicitly expiring rule without accidentally blessing that rule for every later deploy. The release surface can show that today's permission depends on a constrained circumstance and that tomorrow's deploy must return to the ordinary path unless fresh proof says otherwise. That is narrower, safer, and much closer to how careful operators already think when the tooling helps instead of hiding the distinction.

We build Ubriot around release memory because the dangerous part of an exception is often not the day it is introduced. The dangerous part is the quiet week after, when the reason has faded and the workaround still looks available. Temporary release rules need expiry markers because rescue discipline is not only about knowing when to bend. It is also about making sure the bend does not harden into an invisible permanent rule.