Contracts Are the Answer

The instinct, once tribal knowledge is named as the problem, is to write it down. More documentation. A better wiki. Clearer onboarding docs. Chapter 3 argues that every one of these responses is a genuine attempt that treats the symptom without touching the underlying condition, because a wiki page describes a system. It doesn't let an agent act on it.

A contract is different in kind, not just in polish: a structured, machine-readable declaration of what a piece of business logic does, why it does it, and what would break if you changed it. Specific enough for a human to trust. Structured enough for an agent to parse without a person translating first.

This is the chapter that defines what a contract actually has to capture, not a template to fill in casually, but the minimum a system needs to declare about itself before an agent (or a new hire) can act on it safely. It's the hinge point of the book: everything before it names the problem, everything after it is how you build the fix.