Put one clock on the release handoff
Release evidence becomes ambiguous when build, approval, submission, and smoke times use different clocks. A compact handoff should make freshness comparable at a glance.
A release handoff says the build passed at 21:14, approval arrived at 20:32, the store submission began at 9:07, and the production smoke is fresh.
Every line may be accurate. Together, they can still be unusable. One timestamp came from a runner in UTC, one from a local browser, one from a phone set to another region, and fresh has no timestamp at all. The next operator has to reconstruct chronology before deciding whether the evidence belongs to the same release.
We think a release handoff needs one clock. That does not mean every system must change its internal timezone. It means the handoff normalises the decision-bearing times into one explicit standard and keeps the original event time available when it matters.
Which clock should the handoff use?
UTC is usually the least surprising shared reference for release systems. It does not move with daylight saving time, it travels across regions, and most build and store APIs already expose it cleanly. The handoff can still render a local time for the person reading, but the durable record should include the UTC value and its offset rather than an unlabeled hour.
An exact timestamp is more useful than relative language. Five minutes ago will mean something different when the next shift opens the record. Today becomes ambiguous around midnight. Fresh cannot be compared with a build, approval, or configuration change. We store the event time so the interface can offer friendly relative text without losing the fixed point underneath it.
Do all release events need timestamps?
Only events that affect the next decision need to compete for attention, but those events should be comparable. The build completion, artifact creation, approval, submission, configuration change, rollout start, smoke result, and rollback decision are common examples.
The handoff does not need to become a raw event stream. It can show a short ordered sequence and keep lower-level logs behind each item. What matters is that the operator can answer three questions without timezone arithmetic: what happened last, which proof happened before the latest change, and how old is the evidence now.
Some times describe occurrence, while others describe observation. A store may accept a submission at one moment and report it to us later. A smoke may begin at one time and finish at another. When the distinction changes the release decision, we keep both. observedAt is not a substitute for occurredAt, and startedAt is not the same as completedAt.
artifact_created_at: 2026-09-09T00:41:18Z approved_at: 2026-09-09T00:48:03Z submitted_at: 2026-09-09T00:51:27Z smoke_completed_at: 2026-09-09T01:06:44Z configuration_changed_at: 2026-09-09T01:12:09Z status: smoke proof predates latest configuration change
What does one clock reveal?
It reveals stale proof quickly. In the example, the smoke passed, but a configuration change happened later. The problem is not that the smoke was false. It is that its scope no longer covers the current release state. Once the times are comparable, the product can reopen only the proof touched by that change instead of treating the whole release as either green or untrusted.
It also reveals impossible sequences. Approval before the artifact existed may indicate a reused approval, delayed event ingestion, or a clock that was never normalised. A production smoke before rollout began may be attached to the prior artifact. These are not cosmetic ordering issues. They change which evidence can authorise the next action.
One clock also makes expiry rules honest. If a credential check is valid for a limited window, the handoff can calculate that window from a durable completion time. If a store session or deployment approval has aged out, the interface can state the exact boundary it crossed. The operator does not have to infer freshness from the colour of an old badge.
What belongs in the final handoff?
We want the handoff to stay compact: one explicit timezone, an ordered list of decision-bearing events, the artifact identity, the current time-sensitive proof, and the first event that invalidated any earlier proof. Local display time can help the reader, but it should never replace the canonical timestamp.
The record should also show clock quality when it is uncertain. A device-reported event may be marked as client time until a server observation anchors it. A delayed provider callback can retain both the provider occurrence time and our receipt time. Hiding uncertainty behind a neatly sorted list would make the handoff look calmer while weakening it.
We build Ubriot around release memory because operational confidence depends on sequence as much as outcome. Put one clock on the release handoff, and the next operator can see what is current, what expired, and what changed after the last green check. That turns timestamps from decoration into part of the release proof.