What causes decision drift?

Decisions get made in conversations — Slack, standups, ticket comments — and are never written down where the people or agents doing the work will see them. Over time, the work diverges from the decision.

How do you detect decision drift?

Compare changes against the set of approved decisions. The cheapest place to do this is at the pull request, before code merges — flag anything that conflicts with an approved decision.

How is decision drift different from spec drift and configuration drift?

Spec drift is code diverging from a written spec. Configuration drift is a running system diverging from its declared configuration. Decision drift is work diverging from what the team decided, and the decision often was never written down at all, so there is nothing to diff against until someone records it.

Decision Drift

Decision drift is the gap between what a team decided and what its code, docs, and AI agents actually do — decisions made but never delivered to the work.

Decision drift is the gap that opens between what a team decided and what its code, documentation, and AI agents actually do. It happens when a decision is made in a place the work never looks — a Slack thread, a meeting, a ticket comment — and is never delivered to the engineers and agents who need it.

Put shortly: a decision that was made but never delivered. Nobody disagreed with it. The work simply never heard about it.

Decision drift vs spec drift vs configuration drift

The three get confused because all three are "drift." They differ in what the work drifts away from:

Spec drift: code diverges from a written spec. Both artifacts exist, so you can compare them and see the gap.
Configuration drift: a running system diverges from its declared configuration (someone changed a server by hand, and the infrastructure-as-code file no longer describes reality). Tools can diff desired state against actual state.
Decision drift: work diverges from what the team decided. Often the decision was never written anywhere, so there is no file to diff against. That is what makes it the hardest of the three to see, and frequently the cause of the other two: a stale spec is usually a decision that never reached the spec.

Examples (illustrative)

These are composite examples to show the shape, not reports from specific teams.

The quiet scope cut. In a Slack thread, the PM and tech lead agree to ship v1 without SSO. The ticket still lists SSO in its acceptance criteria. A week later an engineer, working from the ticket, starts building it.
The reversed API convention. The team decides in a meeting to return amounts in cents. The meeting notes say so; the API guidelines page doesn't. New endpoints keep shipping in dollars because that's what the guidelines show.
The agent that missed the memo. The team retires a legacy auth helper. An AI coding agent, starting a fresh session with no record of that decision, imports the helper again because it's the most common pattern in the codebase.

What causes it

Decisions live where work doesn't look. Chat, calls, and comment threads are where calls get made; tickets, specs, and code are where work happens.
Recording is homework. Filing a decision is a separate step after the conversation, and it's the step that gets skipped.
No owner, no status. Without an owner and a status, nobody can tell a binding decision from an idea someone floated.
Reversals don't propagate. The new call gets made; the old one stays in every doc that quoted it.

Why it's getting worse

Drift used to cost you one confused engineer who could ask a question. Now an AI coding agent can violate a missed decision confidently, at machine speed, across many repositories — before anyone notices.

How to detect it

Code review. A reviewer who remembers the decision catches the violation. This works until the reviewer wasn't in the conversation either.
A decision log. A decision log gives you something to compare against: if a change contradicts an accepted entry, that's drift.
PR checks. Comparing each pull request against approved decisions turns detection from memory into a check that runs on every change, before merge.

How to prevent it

Prevention means closing the distance between where a decision is made and where the work reads. Capture decisions where they happen, give each one an owner who approves it, deliver approved decisions to the engineers and agents working the affected code, and supersede old decisions instead of silently editing them.

Catching it

The durable fix is a decision record that files itself, is approved by an owner, reaches every human and agent, and is enforced at the pull request. That's the loop Lockstep runs: it captures decisions from Slack, Notion, Jira, Confluence, Google Docs, and GitHub PRs, the owner approves each one in one click, engineers and AI agents get briefed over MCP, and a PR check flags changes that conflict with an approved decision (it warns by default; blocking is opt-in).