You have already seen the tradeoffs thread (T12) across every chapter in this book. Technical debt is what happens when tradeoff decisions accumulate over time without being tracked or revisited. Here the tradeoff is Simplicity/Flexibility (AT3) deferred: the team chose simplicity now, borrowed flexibility for later, and the debt is the cost of obtaining that flexibility when the business eventually needs it. You have also seen state machines (T7) through this book: technical debt creates architectural rigidity — the codebase’s ability to move to new states (new features, new requirements) degrades as debt compounds. The shape is the same: untracked state accumulates and constrains future transitions.