The Capabilities Graph

A contract makes one piece of business logic legible. Chapter 4 asks the next question: what happens when every piece is? The answer is the capabilities graph, a map of every capability in a system, its dependencies, its owner, and the contract that governs it.

The chapter introduces the capability as a new atomic unit of software design, defined by three properties: headless (no assumptions about how it's presented), portable (it runs wherever it's called from), and contract-defined (its boundaries and rules are declared, not inferred by reading the code). That's a different way of decomposing a system than the service boundaries most teams already have.

The result isn't a diagram for a slide deck. It's a structure a new hire can read in twenty minutes instead of losing two days to, and a structure a coding agent can navigate instead of guess at. The chapter walks through what a capability is, how to draw its boundaries, and how the graph accumulates one capability at a time.