What is drift?

What drift means

In software and AI systems, drift is any gap that opens between two things that are supposed to match: the requirement and the spec, the spec and the code, the docs and the behavior, the model and the world it models. Every form of drift follows the same shape: one record is declared authoritative, reality moves on, and the record stays behind. The gap grows a little at a time, and nothing announces it. A system can be deep into drift while every one of its dashboards is green.

The word appears across the industry with this shared meaning. In machine learning, model drift and data drift are established terms for performance decay as live data shifts away from what a model was trained on. In software engineering, architectural drift names the erosion of a codebase away from its intended architecture. The taxonomy below collects the forms that matter for building and running software with AI in the loop.

The taxonomy

Fourteen forms follow. Each entry gives a plain-language definition, how it shows up in practice, what it costs, and how it is caught or contained. The forms overlap at their edges: requirement drift often becomes spec drift, and spec drift always ends as implementation drift if it goes uncaught. Overlap is fine. The point of a taxonomy is that each form can be named, and each name points at where the containment belongs.

Spec drift

Definition. The gap between what was intended and what got written down. The conversation settled on a decision; the spec captured something else, or only part of it.

How it shows up. A meeting agrees on behavior for edge cases that never reaches the spec. A PRD says one thing, the tech spec says another, and both were written from the same conversation. Two authors edit different sections until they contradict each other, and nobody compares them.

What it costs. Every downstream artifact inherits the wrong spec. The code matches the spec, the tests match the spec, and the product is still wrong, because the spec was wrong. This is the most expensive drift to discover late: everything built on it must be rechecked.

How it is caught or contained. Treat the spec as the record that will be executed, and gate it before anything builds: cross-check the PRD against the tech spec for contradictions, missing coverage, and unstated assumptions. In driftless, the Gate stage runs those checks and blocks execution until the spec is clean, because a contradiction left in a spec always resolves itself in code, at the worst possible place.

Requirement drift

Definition. Requirements change over the lifecycle and the written record does not change with them. The decision moved; the record stayed.

How it shows up. A stakeholder changes the plan in a conversation or a chat thread, work proceeds on the new understanding, and the requirement document still describes the old one. Renames, scope adjustments, and dropped features that live only in someone's head.

What it costs. The team builds against a moving target with a stale map. Verification checks old requirements, so passing tests prove the wrong thing. New team members read the record and inherit decisions nobody made anymore.

How it is caught or contained. Route requirement changes through the same record the work executes from, in the same change as the decision. Keep the traceability chain live, requirement to spec to task, so a change to one forces a visit to the others.

Implementation drift

Definition. What was built diverges from what was specified. The spec says one thing; the code does another.

How it shows up. The implementation quietly skips a case the spec covers, handles an edge differently, or adds behavior the spec never asked for. With AI agents writing code, it appears as a confident implementation of an adjacent problem: the code is coherent, tested, and a few degrees off the brief.

What it costs. The system behaves in ways its record does not predict. Debugging goes through the spec, so the search starts in the wrong place. Features interact with the undocumented behavior, and the divergence compounds.

How it is caught or contained. Write testable acceptance criteria before the code exists, then verify the shipped result against those criteria rather than against the author's summary of the work. In driftless, Verify runs exactly this check and failures route back to the stage that caused them.

Documentation drift

Definition. Documentation stops describing what the system actually does. The docs age while the system moves.

How it shows up. A README that describes an interface three versions back. Setup steps that reference files that no longer exist. API docs that miss the parameter added last quarter. The drift is invisible to the writers, because they stopped checking.

What it costs. Every new engineer pays the cost again, onboarding against fiction. Integrations get built on promises the code does not keep. Support tickets trace to instructions that used to work.

How it is caught or contained. Keep docs next to the code they describe and update them in the same change as the behavior. Treat a doc update as part of the definition of done for any interface change, and spot-check docs against behavior during verification.

Behavioral drift

Definition. Agents or systems stop behaving as designed over time. The behavior was specified once; the running system has wandered.

How it shows up. An AI agent that followed instructions precisely in week one starts skipping steps in week six. A prompt change made for one case degrades another case nobody was watching. Successive small changes, each reasonable alone, accumulate into a system that behaves differently than its design.

What it costs. Trust in the system erodes output by output. Failures arrive as surprises, because the record of how the system works says everything is fine. Rollback becomes archaeology: no single change explains the new behavior.

How it is caught or contained. Test behavior, and keep testing it: an evaluation suite that runs on every change catches a system that quietly stopped following its instructions. Log what the system actually did, so behavior can be audited against design rather than inferred from outcomes.

Context drift

Definition. The working context an agent or team operates from diverges from the actual state of the project. The map in hand is stale.

How it shows up. An AI coding agent works from a summary written before the last three changes landed, and edits a file that was renamed. A team plans around an architecture diagram that stopped matching the repository months ago. Long sessions carry old assumptions forward because nothing refreshed them.

What it costs. Confident work built on outdated facts. The agent's output is internally consistent and wrong about the current world. Humans make the same error in slower motion: decisions made against last month's reality.

How it is caught or contained. Rebuild context from the source of truth at the start of each unit of work instead of trusting a cached summary. Keep summaries attached to the state they describe, with a visible age, and refresh what the work depends on.

Memory or knowledge drift

Definition. Stored state goes stale or contradictory, and keeps getting treated as current. The system remembers; the memory is wrong.

How it shows up. A knowledge base holds two entries that contradict each other, both alive. An agent's long-term memory keeps a fact that was superseded, and cites it weeks later. Notes that were true once keep riding along in every prompt because nobody prunes.

What it costs. Stale memory contaminates every decision that consults it, and the contamination is invisible: the wrong fact arrives with the same confidence as the right one. Contradictory stores make the knowledge base itself an argument.

How it is caught or contained. Curate memory as a first-class operation: promote what stays true, demote what faded, and record when knowledge was superseded rather than letting it linger. Driftless gives agents and users a shared curation model for exactly this, with promotion and demotion as explicit acts.

Model drift

Definition. A model's performance decays as the world it learned from changes. In machine learning this is established usage: the model stayed still, the live data moved, and the gap shows up as accuracy loss.

How it shows up. A classifier whose precision quietly falls over a quarter as the input population shifts. An LLM application that handles today's traffic worse than the traffic it was tuned on. Alerts fire downstream of the decay, never at its source.

What it costs. Decisions made on degraded model output, with the degradation invisible until the outcomes pile up. Retraining done late costs more than monitoring done early.

How it is caught or contained. Monitor model performance against live data on an ongoing schedule, not once at launch. Track input distributions and output quality metrics together, so a shift in what arrives is visible next to what it did to performance.

Data drift

Definition. The distribution of input data shifts over time, away from the distribution the system was built for. Also established ML usage, and the upstream cause of much model drift.

How it shows up. A pipeline built for one data shape starts receiving another. Spam patterns evolve past the filter's training set. A product launch changes who the users are, and the old assumptions about what normal looks like quietly stop holding.

What it costs. Systems silently operate outside their design envelope. Downstream models and rules were tuned on the old distribution, so every consumer of the data inherits the shift.

How it is caught or contained. Instrument the data: track distributions at the boundary, and alert on significant change before it reaches conclusions. Version datasets, so any model or rule can be traced to the data it was built for.

Scope creep

Definition. The project boundary expands without a decision. Requirements accrete, and no single addition ever looks like the one that broke the budget.

How it shows up. Each small ask arrives alone and gets absorbed. "While we're in there" becomes the default unit of planning. The spec grows in the margins of conversations, and the deadline holds still while the work under it doubles.

What it costs. Deadlines slip with no decision to point to, because the work grew without one. Quality thins out as the same effort spreads wider. The team ships everything and finishes nothing.

How it is caught or contained. Keep the boundary written and make every expansion a visible decision against the plan: accept it, defer it, or trade it. Lock acceptance criteria when work starts, so added scope has to arrive as a new scoped task instead of sneaking into an old one.

Architectural drift

Definition. The implementation erodes away from the intended architecture. The design stays in the diagram; the code takes its own course.

How it shows up. A layering rule holds for a year, then one deadline excuses one exception, and the exception becomes the pattern. Bypasses around the sanctioned interface multiply until the interface is ornamental. The architecture document describes a codebase that no longer exists.

What it costs. The properties the architecture bought, and there were reasons for every rule, erode with the rule. New work gets harder in ways that resist explanation: the system's structure no longer matches its load. Each violation makes the next one cheaper.

How it is caught or contained. Encode the architecture's rules where they can be checked automatically, dependency direction, module boundaries, interface use, and run those checks on every change. Make exceptions rare, reviewed, and documented, so a violation is a decision instead of a habit.

Process drift

Definition. The team stops following the defined process, and shortcuts become the norm. The process stayed on the wiki; the work took the fast path.

How it shows up. Reviews get skipped under deadline. The checklist gets filled in from memory after the fact. The definition of done quietly narrows to "it was deployed." Each shortcut saves real time once, and the second time it costs nothing to notice.

What it costs. The guarantees the process existed to provide evaporate while the process still nominally exists. Audits find a paper trail that describes a practice nobody follows. Defects arrive that the skipped steps were there to catch.

How it is caught or contained. Move the process into the software so following it is the path of least resistance: gates that block work instead of guidelines that ask, and records the platform writes instead of notes someone keeps. A process that depends on discipline erodes at exactly the pace of the busiest week.

Priority drift

Definition. Work gets sequenced against stale priorities. The plan said one order; reality changed it in a hallway conversation, and the board never heard.

How it shows up. The priority list was set weeks ago and never revisited. Urgent work displaces important work by default, with no record of the tradeoff. Two teams each act on the priority they most recently heard, and they heard different things.

What it costs. The most important work waits behind work that only arrived latest. Effort lands on problems that stopped being the problem. Strategy and execution separate until the roadmap describes a plan the organization no longer has.

How it is caught or contained. Keep a single written priority list as the thing work is sequenced from, and make resequencing a recorded decision, visible to everyone building. When direction changes, change the list, so the work that follows is following something current.

Conversational drift

Definition. An exchange drifts away from its original intent. It started as a question about A and quietly became a negotiation about B.

How it shows up. A long chat with an AI assistant asks for a small change and ends three rewrites later with a different feature. A review thread starts on a bug and ends in a redesign debate. Each turn follows plausibly from the last, which is exactly why nobody notices the destination changed.

What it costs. The original question goes unanswered while a lot of adjacent work gets done. With agents, the drift executes: the conversation wanders and the code wanders with it, at machine speed.

How it is caught or contained. Anchor long exchanges to a written brief and check the work against it at the end, not against the last turn of the conversation. Break big asks into scoped tasks with their own acceptance criteria, so each unit of work gets verified against what it was for.

Catching and containing drift

Every entry above ends the same way, because containment has a shared shape: write down what the system is supposed to be, check the artifacts against that record at the moment they are created, and route failures back to where they started. Drift caught at the gate costs a rewrite. Drift caught in production costs an incident.

driftless exists because the taxonomy above describes one failure mode wearing fourteen coats: the record and reality separating quietly. The platform contains that separation directly. The Cascades methodology shows how each phase catches drift at the boundary where it is cheapest: gates that block contradictory specs before code, verification against acceptance criteria written before implementation, records the platform writes instead of summaries people keep. The AIDLC operating cycle shows how that containment runs in practice when agents do the building.