AP-007 — Evolution by design

Systems are designed to change. Regulation changes. Products change. Technology changes. A system built for rigidity will be a liability within a few years.

This bank has an additional capability that changes the calculation: AI-assisted development. A well-structured knowledge base, clear module specifications, and Claude Code means systems can be regenerated, refactored, and evolved faster than was previously possible. Building for perfect longevity matters less than building for easy regeneration.

The regeneration test: Could Claude Code rebuild this module from its wiki spec and the existing tests? If not, either the spec is incomplete or the implementation is too complex. Both need fixing.

Avoid evolution theatre. Abstraction layers added "to make future change easier" that are never used, plugin architectures for a single plugin, configuration-driven systems for a single configuration — these add complexity without delivering adaptability. Build for the change you can see. Design the boundaries for the change you cannot yet see.

Relationship to other principles

Principle	Relationship
AP-001 KISS	Evolution theatre — unused abstractions, premature extensibility — is a KISS violation. Build for the change you can see.
AP-003 Compliance by design	Regulation changes frequently; compliance-by-design makes regulatory change an implementation task, not a redesign.
AP-010 Modular by design	A well-bounded module can be replaced without touching its neighbours — modularity is what makes evolution safe.
AP-009 Robust and serviceable	Systems designed for easy regeneration are also easier to operate and recover.

See the full architectural principles index.