"Works in staging, fails in prod" is the oldest line in engineering. The code usually passed every check you put in front of it. What moved was the environment around it.
A merge gate governs one moment. At the merge decision you evaluate a change and approve it against the state of the world at that instant. The Production Reliability Index scores that moment, so an engineering leader makes a deliberate ship decision instead of a post-incident discovery. That is the point of scoring at the gate. But the moment does not hold still after you approve it. Dependencies update, config drifts, traffic patterns shift, and adjacent merges keep landing on the same service. The state you approved and the state now running in production separate a little more with every deploy that follows yours.
Call that distance drift. The Production Reliability Index measures reliability at the gate. Drift measures how far production has walked from the gate since. A merge decision that was sound on Tuesday can be governing a system that no longer resembles the one you approved by Friday — and not because anyone did anything wrong. Everything around the change kept moving while the approval stayed frozen at the instant it was made.
A signal is not a gate
We have a line for this at Tomosu. A signal is not a gate. A gate makes a decision at a point and stands behind it. A signal reports a number and asks you to interpret it. The failure mode worth naming is a gate that quietly turns into a signal. It made a real decision once, then never re-evaluated — so the decision it is still standing behind describes a system that has drifted out from under it. A coverage threshold that fires once at merge and never looks again does this. So does any control that treats approval as permanent.
A gate makes a decision at a point and stands behind it. A signal reports a number and asks you to interpret it.
That is the honest limit of any merge-time score, including ours. Scoring the merge decision tells you whether the change was sound when it landed. It says nothing about how long that judgment stays true. The longer production runs and the more it changes, the less your merge-time governance is actually governing.
Making the aging visible
The practical consequence is that every merge decision has a half-life. You do not need drift to be zero, and chasing zero would mean freezing the environment — which no team running real traffic can do. You need drift to be visible. A rising drift measure on a critical service is a signal that the merge decision behind it is aging, which is your cue to re-check that path before the gap turns into an incident. The point is not to prevent the environment from moving. The point is to know when it has moved far enough that an old approval no longer holds.
The Production Reliability Index tells you what you approved. Drift is the next question we are building toward: how much of that approval still holds today.
Tomosu builds merge-gate governance infrastructure. If you're operating production AI-assisted development workflows and need a governance record that ages gracefully, we're opening a small design partner cohort.
Talk to us → · Questions: contact@tomosu.ai