Not every failure arrives as a bang. Some systems drift quietly until yesterday’s exception becomes today’s normal.
A sensor becomes slightly miscalibrated. A database field stops being updated consistently. A student’s small misconception survives because it does not yet prevent correct answers. A maintenance interval stretches by a few days, then a few weeks. A process gains one workaround, then another.
Each change is small. Together they move the system away from the condition it was designed, taught or governed to maintain.
This is state drift: the gradual divergence between intended state and actual state.
Drift Is Different From a Discrete Failure
A discrete failure has a visible transition: working → broken, available → unavailable, accepted → rejected.
Drift is more subtle. The system remains usable while its margins change.
A machine still runs but vibration rises. A school still produces reasonable marks but independent retrieval weakens. A public process still functions but informal shortcuts accumulate. A software system still serves users but configuration differs increasingly from the documented standard.
The danger is that no single step feels important enough to trigger repair.
Drift Needs a Reference State
You cannot detect drift unless the system knows what it is drifting from.
- design specification;
- known-good configuration;
- target performance range;
- calibrated measurement baseline;
- documented process;
- expected learner capability;
- legal or institutional requirement.
The reference state does not have to be perfect or frozen forever. It has to be explicit enough that meaningful deviation can be recognised.
Why Small Errors Accumulate
Drift often appears when a feedback loop is weak.
If a small deviation produces no visible consequence, there is little pressure to correct it. The system continues from its new state. A second deviation then starts from the already-shifted baseline.
The result is compounding. What looked like ±1 at each step becomes a large difference after many steps.
Measurement Drift
Measuring systems themselves can drift.
A sensor may slowly change response. An instrument may wear. A scoring rubric may be interpreted differently over time. A dataset may change composition so an old model no longer describes the same population.
This creates a dangerous possibility: the system can drift while its measurement says everything is normal because the measurement drifted too.
Calibration and independent checks exist partly to prevent the observer from drifting with the observed.
Process Drift
Processes also change through local adaptation.
A workaround saves time today. Nobody removes it. New staff learn the workaround as if it were the process. A second exception is added. Months later the documented workflow and actual workflow describe different systems.
Some adaptation is intelligent. The problem is not change itself. The problem is unobserved change without revalidation.
Capability Drift
Human capability can drift too.
A learner once knew a method but has not retrieved it for months. An organisation once had an expert who quietly left. A team once rehearsed an emergency procedure but has since changed staff and tools.
The formal system may look unchanged while the capability that made it work has decayed.
This is why maintenance must include people and memory, not only equipment.
Configuration Drift
Technical systems often begin with a defined configuration and slowly diverge as patches, local fixes and one-off changes accumulate.
Two machines that were once identical may behave differently because their actual states no longer match the reference. The same applies to institutional procedures, classroom routines and local operational practices.
Drift converts one system into a family of undocumented variants.
The Normalisation Problem
If a deviation persists without immediate harm, people can begin treating it as acceptable.
The new state becomes the reference state in practice even though nobody formally approved the change.
This is one reason small deviations deserve attention when they affect safety, integrity or critical capability. The question is not only whether the deviation caused damage this time. It is whether repeated tolerance is rewriting the system’s operating envelope.
Worked Example: A Student’s Fraction Knowledge
A student learns fraction operations well enough to pass a topic test. Later, the skill is used less often. Retrieval becomes slower. Under time pressure the learner starts using shortcuts that work on easy questions but fail on mixed forms.
No dramatic failure occurred. Capability drifted.
The repair is not necessarily reteaching from zero. It may require spaced retrieval, mixed practice and a check that the old representation still holds under changed conditions.
Worked Example: Maintenance
A component’s vibration rises slowly but remains under an alarm threshold. Operators become accustomed to the new sound. The next maintenance interval arrives and the reading is still “within limit.”
The important information may not be the absolute value. It may be the trend.
Drift detection therefore often needs rates of change, baselines and historical comparison rather than one current snapshot.
Detecting Drift
- Baseline comparison: compare current state with a known reference.
- Trend monitoring: watch whether deviation is increasing even if still within threshold.
- Cross-checks: compare independent measurements or records.
- Revalidation: periodically test the actual function, not only the recorded configuration.
- Receiver feedback: look for human consequences that internal metrics miss.
This links state drift to measurement, feedback and maintenance.
Not All Drift Should Be Reversed
Sometimes the environment changed and the old reference is no longer desirable.
A system may have adapted usefully. A teaching method may improve. A workflow may discover a better sequence. A technology may change the available operating envelope.
The correct question is therefore not “How do we force everything back?” It is “Is the current state an uncontrolled deviation or a legitimate new design?”
If the change is good, update the reference deliberately. Turn drift into governed evolution.
The Backward Drift Test
- Define the current state.
- Define the last trusted reference state.
- Identify every small change between them.
- Ask which changes were approved and which simply persisted.
- Find the first point where feedback failed to restore or formalise the deviation.
- Decide whether to restore, adapt or redesign.
This is often more useful than blaming the final person who noticed the problem.
The Civilisation Lesson
Civilisations rarely lose capability only through dramatic collapse. They can also lose it through slow erosion: maintenance postponed, standards interpreted loosely, institutional memory thinned, skills not renewed and workarounds allowed to become permanent.
A strong civilisation therefore needs ways to compare present capability with intended capability and to distinguish healthy adaptation from silent degradation.
State drift is what happens when yesterday’s small exception becomes today’s starting point without anyone deciding that it should.
Continue through How State Synchronisation Works, How Maintenance Works and the master How X Works hub. The next article moves from drift inside a system to leakage across its boundary.