Responsibility drift.

One rule, many homes.

Responsibility drift is the gradual scattering, duplication, and tangling of one business responsibility across code paths, data stores, scripts, admin tools, and team assumptions, until no single place clearly owns the behaviour.

A pricing rule starts in one service. A special case lands in the admin tool, because that is where the request surfaced. A background job re-implements half the rule for invoices. A database view answers the edge cases slightly differently, and the person who knew why moved on. Every step was a reasonable local decision. No step broke anything. The rule simply no longer has one home — and from that point, changing it safely means finding all of its homes first.

The system is not failing. It works, users rely on it, and real business flows through it. That is exactly what makes drift expensive: it hides inside working software, and it is usually discovered at the worst possible time — in the middle of a change.

How it forms.

Drift is not caused by carelessness. It is what sustained business pressure does to any system that succeeds long enough to keep changing.

• Business pressure moves the system faster than its descriptions, design intent, and ownership boundaries can follow. The map falls behind the terrain.
• New requests are solved at the nearest convenient insertion point. Each choice is locally rational; globally, behaviour scatters.
• Duplication appears — sometimes copy-paste, more often “almost the same rule, built again, because changing the original felt too risky.” The copies then evolve apart.
• The safety layer decays: documentation stops matching the code, and tests stay green without proving the workflows that matter.
• Ownership concentrates in a few heads. The system becomes safe to change only for the people who remember why it is the way it is.

The symptoms are recognisable.

From inside a team, drift rarely announces itself. It is felt as a set of small, recurring frustrations:

• The same business rule lives in more than one place.
• A change in one area breaks behaviour somewhere unrelated.
• A few large files coordinate things that have nothing to do with each other.
• Code reaches around its own structure to get things done.
• Docs, comments, and runtime behaviour no longer agree.
• The test suite is green, but nobody trusts it on the workflows that matter.
• Only one or two people can safely predict what a change will touch.
• The system works — but each new feature costs more than the one before it.

If several of these feel familiar, the system is probably not “bad code”. It is drifted ownership. The research literature studies the same phenomenon under the name architecture erosion; the symptoms it documents — duplicated functionality, cyclic dependencies, violated boundaries — are the ones above.

Drift becomes visible on a map.

This is the problem the System Report is built around. The report names the responsibilities the system carries — identity, billing, eligibility rules, notifications, reporting, admin operations — and maps where each one actually lives in the code today.

That map makes three situations visible at a glance. A responsibility connected to many unrelated places is drift. One code area carrying many unrelated responsibilities is overload. A responsibility with one clear home and a few controlled collaborators is coherence — the part of the system worth protecting.

Every important claim on the map carries an evidence level — verified by running the system, observed in code, documented, or assumed — so its certainty is as honest as the access behind it.

The output is a movement strategy, not a restructuring sermon: what should move first and why, what that movement makes safer, what should stay where it is, and what should not be touched until something else is true first. Sometimes the right line is: do not extract this yet. A boundary is justified only when it removes more confusion than the coordination it adds.

The next sensible step.

Drift reverses the same way it formed — one responsibility at a time, starting from a shared map. If this page reads like your system, the System Report is the bounded way to get that map.