Most technical debt doesn't get documented. It lives in the mental models of senior engineers, surfaces during code reviews, gets discussed in Slack threads, and then disappears when those conversations end. The next engineer who touches that part of the codebase encounters the same problem fresh, without the context of why it exists, how severe it is, or whether anyone planned to address it. Documenting and tracking technical debt doesn't eliminate it, but it changes the team's relationship with it. Problems that are written down, categorized, and scored are problems that can be reasoned about systematically. Teams that maintain an inventory can have productive prioritization conversations. Teams without one are stuck arguing about gut feelings with no shared reference point. Why Mental Models Fail at Scale For very small teams, the "everyone knows where the problems are" approach mostly works.…