Drift is the gradual deviation of a running system from its specified scope, accumulated through changes that are individually reasonable and collectively corrosive. The term is borrowed from statistical process control, where it describes the slow excursion of a process from its specification, not a failure in any single measurement, but a pattern of measurements trending away from the declared reference.
Drift is not the same as change.
Intentional change is declared, reviewed, and documented. The specification evolves deliberately. The running system evolves to match. Drift is what happens when change occurs without this alignment discipline. A new integration added to solve an urgent problem, without the architecture document being updated. A configuration parameter adjusted to resolve an incident, without the security model being reviewed.
Change that updates the specification is evolution. Change that diverges from the specification is drift. The distinction is not about the change itself; it is about what happens to the reference afterward.
Why drift compounds.
A single small deviation is invisible. Ten small deviations over a quarter are still difficult to see. Fifty small deviations over eighteen months produce a qualitative shift: the system no longer matches its documented design, its threat model, or its compliance posture. Remediation at that point is no longer reversing individual changes; it is reconciling two systems, the one that exists and the one that was designed.
Why periodic audits do not catch it.
A compliance audit conducted twice a year surfaces the sum of six months of drift, all at once, without attribution and without timeline. The auditor sees the cumulative condition. Remediation is slow because the timeline of causation has been lost. A continuous instrument surfaces each deviation at the moment it appears, with timestamp, scope attribution, and context.
Specification, deviation, continuous conformance.
In statistical process control, a specification defines the acceptable range for a measured process. Variation within limits is normal. Variation outside is investigated. The discipline depends on two prerequisites: the specification must be explicit, and the measurement must be continuous. Neither is common in enterprise software. Most specs are out of date. Most systems are measured periodically.
The SolarNorth method reproduces both prerequisites. Illuminate establishes an explicit, current specification. Plumbline provides continuous measurement against it. Deviation is surfaced as it occurs.
Drift is a governance problem.
Drift is not a technical problem. It is a governance problem expressed in technical symptoms. Treating it as such changes what the category of tool required looks like. Continuous, read-only, reference-based conformance is the shape of the instrument.