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
Extraction Priority Matrix
A legibility audit tells you where the tribal knowledge is. It doesn't tell you what to fix first. That's a separate question, and the answer isn't just "whatever scored worst."
Three axes decide it. Business criticality: how much revenue or compliance risk actually sits inside the capability. Tribal knowledge density: pulled straight from the legibility audit score. Agent touchpoint frequency: how often agents are actually going to hit this capability once they're working in the system.
The rule is to multiply those three numbers, never add them. A capability that's mission-critical and completely opaque but that agents will almost never touch shouldn't jump the line ahead of one that's moderately risky and gets hit constantly. Multiplying keeps a zero on any axis from letting a capability sneak to the front, because a zero anywhere means it isn't a real candidate yet.
The result sorts into phases. A perfect score of 9 is phase one, extract now. Scores of 4 to 8 are phase two. Scores of 1 to 3 are phase three, worth tracking but not urgent. A score of 0 means the capability isn't a current extraction candidate at all, and that's useful information too. Not everything needs a contract on day one.