Technical Debt
A choice that raises the cost of future change. Deliberate and bounded is a strategy; accidental and unnamed is the thing that compounds.
A design or implementation choice that increases the cost of future change. Not ugliness, not old code, not a library you would not have picked — and the metaphor was originally about deliberate shortcuts.
A shortcut taken knowingly is a strategy — if the trade-off is understood, the impact is bounded, and someone knows the way out. Two of those three are usually missing.
Debt nobody chose: an unclear domain, requirements that moved, a rushed design, missing tests, people who left. It is the larger half, and it is not a moral failure.
The shortcut is the principal. The interest is that every later change in that area costs more — and because later changes are built on earlier ones, the cost grows rather than staying flat.
Five fields per entry — Problem, Impact, Risk, Owner, Trigger — and a hard rule about size. A register with two hundred entries is not a register, it is a wishlist nobody reads.