A methodology for architecture
Capability-Driven Design decomposes a system not by team, technology, or service, but by capability — a mandate-backed business function that owns its data, exposes a curated API to the channels that call it, and speaks to its peers only through events. Everything else is derived from that one commitment.
A capability is not a service, a team, or a database. It is a business function the organisation is mandated to hold — and it is the primary unit around which the whole architecture is organised.
A capability is a mandate-backed business function — the primary unit of architectural decomposition.
A capability owns one or more databases or schemas, invisible to every other capability. No shared stores, no shared entities, no reaching into another capability's persistence.
It exposes a single curated REST API for channels to call, and publishes events on a shared bus for peers to consume. You share contracts, never implementations.
Capabilities change only when the mandate changes. Technology is derived from the capability's requirements — never the reverse.
A capability is sized to fit an AI agent's context window. This is the primary decomposition constraint — small enough for one agent to hold whole.
Every capability is researched against its competitive landscape and regulatory horizon before it is drafted. A list derived from the org chart produces a shallow architecture.
The method produces a headless system specification. Channel UIs sit outside the system boundary and consume capability APIs — a separate development concern.
Two ways to build the same system.
Adopt it the way it is meant to be adopted — one capability at a time.