Every complex system starts simple. A small team, a clear problem, a handful of components. The architecture is obvious. Decisions are fast. The system does what it is supposed to do.

Then it grows.

New requirements arrive. Edge cases accumulate. Components multiply. The team changes. The original designers move on. New engineers join and inherit a system they did not build, documented in ways that reflect decisions no longer remembered.

At some point — and the timing varies, but the pattern does not — the system becomes difficult. Not broken. Difficult.

What difficult looks like

Changes take longer than they should.

A modification that seems straightforward turns out to touch components that were never intended to be related. Every change requires investigation before implementation. The investigation often reveals surprises.

Confidence in changes decreases.

Engineers who know the system well begin qualifying their estimates. “It should work, but…” becomes a common preamble. Testing coverage increases but anxiety does not decrease. The system has become hard to reason about.

Architectural decisions accumulate without record.

Someone decided, at some point, that a particular component should behave a certain way. That decision made sense at the time. The context that made it sensible is gone. What remains is the behavior — now a constraint on everything that depends on it — with no record of why it exists.

Consistency erodes.

Similar problems get solved in different ways in different parts of the system. Not because the engineers were careless, but because each solution was local, reasonable, and made without full visibility of what existed elsewhere. Over time, the system stops feeling like a coherent whole.

Governance becomes reactive.

Architecture review happens after the fact, if at all. New features are evaluated on whether they work, not on whether they fit. The architecture drifts from whatever it was originally intended to be — gradually, quietly, and without anyone deciding it should.

Why this happens

The root cause is not poor engineering. Most of the engineers who worked on these systems were competent and well-intentioned.

The root cause is that architectural decisions are made continuously, under time pressure, in local contexts — and the relationship between those decisions and the system’s foundational principles is never made explicit.

Without that relationship:

  • There is no way to know whether a new decision is consistent with the architecture or contradicts it
  • There is no way to trace a current behavior back to the principle that originally justified it
  • There is no way to evaluate a proposed change without understanding the full dependency chain
  • There is no way to govern evolution without relying on the memory of individuals who may not be available

This is not architectural drift as a failure of discipline. It is architectural drift as the natural consequence of a missing structural property.

The missing property

What these systems lack is a stable architectural layer from which all decisions can be derived — and to which all decisions can be traced.

When that layer exists, a change is not just evaluated on whether it works. It is evaluated on whether it is derivable from the architecture that authorized it. If it is, it can be made with confidence. If it is not, the architecture itself must be explicitly evolved — and that evolution is recorded, reasoned about, and traceable.

This is the property that Derivable Architectures is designed to establish and preserve.

Who this affects

This pattern appears wherever systems are large, long-lived, and maintained by teams that change over time.

Software systems are the most obvious case. But the same dynamic appears in legal systems, institutional frameworks, organizational procedures, and any other structure that accumulates decisions over time without a mechanism for relating them to a stable foundational layer.

The engineering problem and the governance problem turn out to be the same problem.

If this describes a system you are responsible for, the conversation is worth having.