Aiger Data
Pattern 01 · Extend over modify

Extension over modification.

A business runs into the limits of what its core platform can do for a specific local market or capability. The temptation is to modify the core; the discipline is to extend instead.

Exercises · Decisions · Workflows

The situation

A regulated business sits on a core platform — finance, supply chain, customer — and runs into the limits of standard functionality for a specific local-market dynamic or specialised capability. The teams closest to the work want a fix soon; the platform owners want a fix that does not make every quarterly upgrade a regression-test marathon.

The default move is to modify the core. It is faster on day one, expensive on day three hundred, and unbounded in compound cost. Every modification is a tax on every future upgrade, every certification, every standardisation conversation with the platform vendor. The technical debt curve steepens quietly.

The discipline

The discipline is to extend, not to modify. Build the capability on a side-by-side platform; integrate cleanly; keep the core unmodified. The first one or two extensions feel like more work than the in-core route would have been. The third and fourth recover the difference. By the fifth, the side-by-side pattern is the obvious answer and the discipline is self-reinforcing.

The hard part is the decision boundary — the explicit rule for when a request justifies an extension and when it does not. That decision belongs in writing, owned by the platform team, reviewed against actual requests as they come. Without the written boundary, every conversation about a new requirement re-litigates the principle from scratch.

Where it sits

This pattern exercises two of the four foundations directly. Decisions, because the boundary between “extend” and “modify” is itself a decision right that must be encoded — who decides, on what criteria, with what threshold. Workflows, because the engineering process for building extensions is fundamentally different from the process for modifying the core, and the team learns the new process through the first few extensions.

In the five-level autonomy model, this pattern is what makes a credible move to Level 3 in any domain that touches the core platform possible. A core that has been modified through years of expedience cannot host an agent that acts on its data with confidence. A core that has been kept standard, with extensions running alongside, can.