In this section: Chapters
- Ch.1: The Day After
- Ch.2: Tribal Knowledge Is the Bottleneck
- Ch.3: Contracts Are the Answer
- Ch.4: The Capabilities Graph
- Ch.5: Extraction Over Refactoring
- Ch.6: The Contract Lifecycle
- Ch.7: The Architect
- Ch.8: The Developer
- Ch.9: The PM / PO
- Ch.10: The Designer
- Ch.11: The Leadership Team
- Ch.12: The Company That Gets There First
- Appendix
- Appendix A: Contract Schema Reference
- Appendix B: Legibility Audit Framework
- Appendix C: Extraction Priority Matrix
Contract Schema Reference
Understanding what a contract is and knowing how to write one are different things. This is the artifact that closes that gap: two schemas, both shown against the same capability, `payment/retry`, the toolkit's own real worked example of what undeclared knowledge actually costs.
The minimum viable contract is the starting point. It contains the fields a team needs to make one capability navigable today, whether that's the first contract in a brownfield extraction or the first contract a new capability ships with from sprint one. The extended contract adds dependency, behavioral, and evolutionary layers on top, for the capabilities where it's worth going past sufficient.
Neither schema is done when every field is filled in. It's done when it passes the same diagnostic used throughout the book: could a capable engineer with no tribal knowledge navigate this capability safely using only what the contract makes available? The minimum viable contract is built to clear that bar. The extended contract is built to clear it with room to spare.
The full YAML schemas and a completed working example live in the companion repository, alongside the open-source CLI that scaffolds and validates contracts against them.