The Core Model

Overview

The toolkit rests on four concepts, and the docs define each of them in a single sentence: legibility, capability, contract, capability graph. That's the right length for a reference card. It's the wrong length for actually understanding how the pieces fit together, why the order matters, or what goes wrong when a team applies one of them halfway. This cluster of pages exists to close that gap, one concept at a time, at the depth the book gives them across Chapters 2 through 6.

Start with legibility, because it's the diagnostic the rest of the model responds to. From there, capability defines the unit being diagnosed, and contract defines what you write down once you've decided a capability is worth the effort. The capability graph is what you get when contracts accumulate across a whole system. The rest of the pages are more operational: the minimum fields a contract needs, the extended fields for capabilities that carry more risk, how a contract's version number actually gets decided, the specific ways contracts drift when nobody's watching, and the arc a capability travels from invisible logic to something a contract governs.

Pages in this area

• Legibility

  What the term means precisely, the four questions used to score it, and how `cdad check` turns that scoring into a number.

• Capability

  The business-facing unit the whole model is built around, and why it cuts a system along different lines than a service boundary does.

• Contract

  What a contract actually has to declare before an agent, or a new hire, can act on a capability without guessing.

• Capability Graph

  The dependency map that emerges once contracts accumulate, and how humans and agents read it differently.

• Minimum Viable Contract

  The exact fields a contract needs to be useful, no more and no less, field by field.

• Extended Contract Fields

  Dependencies, performance, error handling, trust zones, constraint history: the fields for capabilities carrying real operational weight.

• Contract Versioning

  Why a version bump is decided by downstream compatibility, not by how large the text diff looks.

• Contract Anti-Patterns

  Five specific, recognizable ways a contract drifts away from what it's supposed to do, with real examples.

• Capability Lifecycle States

  How a capability moves from invisible logic nobody's named to a node the graph and an agent can both trust.