Legibility Audit Framework

Before you can decide what to extract first, you need a way to measure how illegible a capability actually is. Not a gut feeling about which parts of the codebase feel scary. A score.

The audit runs on one diagnostic question: could you hand this capability to a capable engineer who's never spoken to your team, and still expect a safe change, using only what the system makes available? Underneath that question sit four more specific ones. Can someone tell why the capability works this way, not just what it does? Can they see what was tried before and why it failed? Can they understand why it calls what it calls instead of the obvious alternative? Can they find every exception path driven by a customer, a regulation, or something that happened three years ago?

Score each question a full point for yes, half a point for partially, zero for no. Capabilities that score low aren't a judgment on the engineers who built them. They're a map of where tribal knowledge is doing the most load-bearing work, and therefore where an agent (or a new hire) is most likely to walk into something nobody wrote down.

The lowest-scoring capabilities are exactly the ones that feed into the next step: ranking what actually gets extracted first.