When Cleaning Up Means Betting Blind

The first three articles built to an uncomfortable place . Projects fail for missing information about how the work runs (one) ; much of that information was never decided and must be declared, an act that changes the process (two) ; and those declarations are entangled and costly, with the bill falling in a paradoxical order — you must decide before you can discover (three) .

The process-rationalization case offers an operating setting for a repeated step whose purpose may be underdescribed. Trace the protected dependency and compare acceptable alternatives. A cleaned inventory prepares evidence; it does not itself establish that the supported function can be discontinued.

There is an obvious way out. Then stop discovering piece by piece. Declare the whole target architecture once, design the best process from the start, and rebuild toward it. The evidence even seems to encourage it: the AI deployments that succeed are overwhelmingly those sitting on a coherent, well-architected foundation. So architect everything up front, and be done.

This article is about why that move is not the clean escape it appears to be. The rebuild has a cost — that was the third article. What this one adds is that it also has a risk , of a kind you cannot price in advance, because it lives in exactly the part of the estate you cannot see.

To design the best possible target, you need to know your current process. But you don’t — that was the whole argument. The most ordinary symptom is scale: organizations that believe they run two hundred applications discover six hundred, and counting. If you cannot say how many systems you have, you cannot say how complex your process really is, and you cannot claim to be designing the best version of something you have not finished finding.