# Drift register

> A drift register records when a system changes from its previous doctrine, decision, code, route or public language — classified and either accepted, reversed or escalated — so change is visible rather than silent.

Category: Systems
Also searched as: change tracking, decision drift, configuration drift
Source: Mediator Solutions — https://mediatorsolutions.io/learn/#drift-register
License: free to read, learn, cite, and apply, with attribution to Mediator Solutions.

## What it is

The dangerous change is the one no one recorded. A drift register makes change a logged event: when wording, policy, data, source, code, operation or authority moves from what it was, the drift is recorded, classified and dispositioned. Silent drift is how a system ends up somewhere no one decided to go.

## Why it matters

The dangerous change is the one no one recorded, because a system that drifts silently ends up somewhere no one decided to go, and no one can say when or why. A drift register makes change a logged, classified, dispositioned event — wording, policy, data, source, code, operation or authority — so the current state is the sum of recorded decisions rather than accumulated silent moves. The discipline is to treat a change from the prior state as an event worth recording even when it seems minor, because the costly drift is always the one that looked too small to log.

## When to use it

- Any change to a system’s wording, policy, data, source, code, operation, or authority.
- A change seems too small to log.
- You want the current state to be the sum of recorded decisions, not silent moves.

## Principles

- A change from previous doctrine, decision, code, route or language is recorded as drift.
- Classify the drift: wording, policy, data, source, code, operational, authority.
- Every drift is dispositioned: accepted, reversed, or escalated.
- Silent drift is the failure mode; the register exists to make change visible.

## Practice

1. When something changes from its prior state, log it as a drift event.
2. Classify what kind of drift it is.
3. Decide and record: accept, reverse, or escalate.
4. Review the register so accumulated drift does not become an undecided destination.

## Where it fails

- **Silent change** — A change goes unrecorded, so the system drifts somewhere no one decided to go and no one can say when or why.
- **Too-small-to-log** — The minor change is skipped, and the costly drift is always the one that looked too small to record.
- **Unclassified event** — Changes are logged without type or disposition, so the register exists but cannot be reasoned over.

## In practice

A policy threshold is nudged, a data source is swapped, a prompt is reworded — each small, none recorded. A year later the system behaves differently and no one can reconstruct how it got there. The drift register makes each change a logged, classified, dispositioned event: what changed, which type, who decided, why. The current state becomes the sum of recorded decisions. The discipline is to log the change that looked too small to matter, because that is precisely the drift that costs the most.

## Verification

Consequential changes appear in the drift register, classified and dispositioned, so a reviewer can see the system’s current state was arrived at by recorded decisions rather than silent drift.

---

Previous: https://mediatorsolutions.io/learn/#saturation-discipline
Next: https://mediatorsolutions.io/learn/#agentic-authority-boundaries