Some things fail all at once.
A component burns out. A company loses its largest customer. A relationship ends after a particular event. A software deployment introduces a defect and the service stops working.
Other failures are harder to locate because there is no moment when the thing clearly broke. What worked last year works a little less well this year. Responsibilities shift without anyone formally changing them. A workaround becomes routine. A rule remains in place after the conditions that produced it have changed.
Nothing is broken enough to force attention.
The thing simply drifts.
I've tended to think of drift as something systems should resist, but I'm less certain about that now. Preventing all drift would mean preventing adaptation too. An organization that operated exactly as it did twenty years ago might have preserved its original structure perfectly while becoming increasingly unsuited to the world around it.
Sometimes changing away from the original design is the healthy response.
That makes drift harder to evaluate than it first appears.
Suppose a small business develops an informal process because five people work together closely enough that everyone knows what's happening. Years later there are twenty employees, and people begin documenting decisions that were previously handled through conversation. The operation has drifted from its original form, but the change may be exactly what allows it to preserve something more important than the original process.
The form changed because the environment changed.
Now consider the opposite case. A temporary workaround is introduced during a busy period. Nobody removes it afterward. New employees learn the workaround rather than the intended process, another workaround gets built around the first one, and eventually nobody remembers why either exists.
That is drift too.
The interesting question isn't whether change occurred. It's what the change is doing.
Some systems have relatively easy answers because we know which properties they're supposed to preserve. If replicated data begins diverging between two machines that are supposed to contain the same state, we have a problem. If a clock drifts far enough from its reference, we can measure the difference. If a manufacturing process moves outside an accepted tolerance, somebody can investigate.
Organizations and relationships are harder because the reference itself can move.
A newspaper today shouldn't look exactly like a newspaper from thirty years ago merely to demonstrate fidelity to its origins. The available technology changed. Reader behavior changed. Distribution changed. The economics changed. Preserving the old form without asking what the form was accomplishing could destroy the very thing we were trying to preserve.
So we need some way to distinguish continuity from repetition.
That usually requires asking what mattered about the earlier arrangement.
Perhaps a process existed to prevent a particular error. Perhaps a role existed because information needed to pass between two parts of an organization. Perhaps a boundary was created after somebody discovered that combining two responsibilities produced a conflict.
If we recover the problem, we can evaluate the change against something more useful than tradition.
The old solution may still be the right one.
It may also have finished its job.
This is why drift can contain information. A workaround may indicate that the formal process no longer matches the work. Employees repeatedly ignoring a particular field in a form may mean they need better training, or it may mean the field no longer captures anything useful. Customers finding an unintended way to use a product may be creating a support problem, or they may be revealing a need the designers didn't anticipate.
Deviation doesn't tell us which interpretation is correct.
It tells us where to look.
The same caution applies to prevention. Rules, constraints and standards aren't signs