Technical debt is about quality of code, not about changes in your conceptual model. Lets say I had a warehouse that stored food, all stored neatly in its own

Technical debt is about quality of code, not about changes in your conceptual model. Lets say I had a warehouse that stored food, all stored neatly in its own section, each with the least frequently moved at the top where I need a forklift to access, and the most frequently used at the bottom where they are easy to access. Someone orders too many boxes of rice, and there's no room in the rice section, but there's room on the lower shelves of the sauces so it gets stored there, and some are left on the floor, partially blocking forklift access. The immediate problem of rice storage is solved, but every time I need sauces I have to grab the forklift, and it may take longer to get there and back because the route is blocked. This will persist until I refactor the warehouse so that there is more space to store the rice appropriately. Now the manager decides we should be able to store refrigerated goods, and I have no refrigerators yet. The work to refactor the shelves to make room for the refrigerators is a conceptual change in how I use the warehouse, and not a direct consequence of how I've previously been storing goods. It's not tech debt.