When Compensation Becomes Architecture
Technology categories are rarely defined by the problem they were meant to solve. They are defined by the first implementations that solved a workable fraction of it. Once an implementation becomes dominant, everyone with a stake in the category, including vendors, consultants, analysts, buyers, and the press, begins to optimize around that implementation rather than the original problem. The implementation’s limitations stop being treated as limitations and become the accepted shape of the category. Over time an entire economy grows on top of them, and the question that started the category quietly disappears.
Enterprise resource planning is the clearest case study available.
How ERP forgot its own purpose
ERP began as an attempt to represent and coordinate the operations of an enterprise in a single, coherent model. Its lineage runs through material requirements planning and manufacturing resource planning, the production-scheduling systems of the 1970s and 1980s advanced by practitioners such as Oliver Wight. Gartner introduced the term “enterprise resource planning” in 1990 to describe the generalization of those ideas beyond the factory floor. The premise was sound. If a business could hold a faithful, shared model of what was actually happening across purchasing, production, inventory, and finance, it could coordinate decisions that had been fragmented.
That premise was never fully delivered. The systems that shipped could represent a great deal, but not everything, and not always faithfully. What happened next is the pattern worth studying. Each gap in the operational model was closed not by improving the model, but by adding a layer on top of it.
When the standard data model did not fit a business, the answer was customization. When customization made systems brittle and expensive to upgrade, the answer was configuration frameworks and best-practice templates. When one system could not hold the whole enterprise, the answer was integration middleware. When integrated systems disagreed, the answer was reconciliation and master data management. When the authoritative record could not be trusted, the answer was reporting layers, data warehouses, and an unbounded population of spreadsheets. When none of that produced trustworthy data, the answer was data governance as a permanent function. And when the software still did not reflect how the business actually worked, the answer was implementation methodology, a discipline built to manage the distance between the system and reality.
Each of these layers is a genuine engineering response to a genuine problem. None is fraudulent. But notice what they share. Every one compensates for an operational substrate that does not, on its own, hold a complete and faithful record of what the business is doing. They are not features of a well-formed model. They are scaffolding around an incomplete one.
The decisive moment arrives when the scaffolding is mistaken for the building. By the 2000s, customization, integration, reconciliation, governance, and methodology were no longer understood as compensations. They were understood as intrinsic characteristics of ERP, and the founding question changed with them. That question had been architectural: does the system faithfully represent operational reality? The questions that replaced it were remedial:
How do we customize it?
How do we integrate it?
How do we govern the data?
How do we improve adoption?
How do we reconcile inconsistent systems?
Each manages the consequences of an incomplete substrate. None asks whether the substrate is complete. They became the accepted agenda precisely because the definition of the category was no longer open for examination.
How a settled definition defends itself
Two forces keep it settled. The first is what has been spent. Every compensating layer is an investment: customization consumes budgets, integration sustains middleware vendors, master data management employs teams, governance becomes a standing function, and implementation methodology supports a global consulting industry whose fees routinely run to several multiples of the software license, a ratio documented across decades of industry surveys. Once an industry has invested this much in compensating for a deficiency, the deficiency can no longer be named without implying that the investment was misdirected. The firms and careers built on the compensation layers are rationally incentivized to defend the definition that requires them. This is the sunk cost fallacy at the scale of a category, and few misallocations in enterprise technology rival it for size.
The second force is subtler, and it is epistemic. Once the machinery exists at sufficient scale, its existence is taken as evidence that the approach was correct. The maturity of the tooling, the depth of the consulting bench, the breadth of analyst coverage, and the sheer number of implementations become, in the market’s reading, a form of proof. An entire industry, the reasoning goes, cannot be wrong. But the scale of a compensation measures the deficiency it compensates for. It is not a certificate of the design that required it. A large and permanent economy of workarounds around a product is a symptom, and read honestly it is the strongest available evidence that the substrate underneath is incomplete. Read as the market reads it, ubiquity is mistaken for validity, and the apparatus grows so elaborate that it is mistaken for the system itself. That is how a compensation becomes an architecture.
The principle underneath
This failure is neither unique to software nor new. W. Edwards Deming named the underlying error decades ago in manufacturing. His third principle for management, from Out of the Crisis (1986), is to cease dependence on inspection to achieve quality, and to eliminate the need for inspection on a mass basis by building quality into the product in the first place. Deming’s point was not that inspection is useless. It was that inspection is a confession. If quality has to be inspected in at the end, the process was not capable of producing quality on its own, and inspection can only sort acceptable output from defective output after the cost has already been incurred.
Every compensating layer described so far is inspection by another name. Customization, reconciliation, master data management, and after-the-fact governance all operate on state that has already been written. They sort and correct a record the substrate failed to produce correctly. Deming’s principle states the general rule: trustworthy output cannot be reliably inspected into existence after the fact, because by then the cost is already sunk into the record. It has to be engineered into the process that creates it. That rule is not about ERP. It is a test any category can be held to, and there is a new one forming right now that has not yet been held to it.
AI is repeating the pattern
Artificial intelligence in the enterprise is early enough that its definition is not yet fixed, which is exactly why the pattern is worth naming before it sets.
The public definition of AI is being shaped by its most visible implementations rather than by a rigorous account of what enterprise use requires. It is shaped by consumer chatbots, by science fiction, by impressive demonstrations, by anthropomorphic language that describes software as if it reasons and intends, by productivity narratives, and by vendor positioning. These forces set expectations about what AI is and what it is for, exactly as early ERP implementations set expectations about what ERP was.
Now follow where the serious enterprise conversation goes. Almost all of it concerns governing the AI itself: prompt guardrails, output inspection, AI governance frameworks, runtime monitoring, trust reconstruction, execution governance, context engineering, and semantic layers assembled to give models something coherent to read. Much of this work is valuable and technically sophisticated. But held to Deming’s test, its shape is unmistakable. It is an inspection regime placed around the model, operating on outputs after they have been produced.
Relatively few people are asking the prior question: is the enterprise substrate itself capable of faithfully representing operational reality? Because if it is not, every one of those governance layers is compensatory in exactly the way ERP’s layers were. An output inspector cannot certify a conclusion drawn from an operational record that was never complete. A monitoring layer cannot reconstruct trust the substrate never produced. A semantic layer can reconcile representations, but it cannot manufacture a faithful record where none exists. These technologies provide real value, and they will continue to. The difficulty is that they optimize around an assumption inherited from an incomplete foundation, and that assumption stays invisible for as long as the foundation goes unexamined.
Building quality into the substrate
If the deficiency is an incomplete foundation, the answer is to build quality into the substrate rather than inspect it afterward. This is the perspective Mimir Labs works from. Its premise is stated plainly: enterprise data systems need to be a complete and faithful record of the operational reality before any path through them can be reliable. Reporting, auditing, integration, and enterprise AI are all paths through the record. If the record is incomplete, no path through it can be more reliable than the record itself.
The consequence is to approach the problem from the substrate upward rather than from the application or the model downward. Two examples illustrate what that produces. Ratatosk examines existing enterprise systems to identify semantic conflicts, governance gaps, and structural inconsistencies, on the premise that the first honest step is to see where the current substrate fails to represent reality. Yggdrasil ERP moves governance into the transaction boundary itself, so that an admissible business action becomes a prerequisite for creating authoritative operational state, rather than something checked after the state already exists. In Deming’s terms, quality is engineered into the process rather than inspected after it. These are consequences of the thesis, not the thesis itself. The thesis is that the substrate is the thing that has to be correct.
The choice AI still has
History shows, repeatedly, that technologies are defined by what their early implementations could achieve rather than by what the underlying problem actually required. ERP is not an isolated case. The category that formed around its early limitations went on to spend decades refining the compensations rather than revisiting the definition.
Enterprise AI has a narrow and closing opportunity to avoid that outcome. The compensatory layers now being built around models are useful, and some will be permanent. The window does not close by decree. It closes the way ERP’s did, through accumulated investment, because every budget, vendor, and career committed to inspecting and governing the model makes the architectural question more expensive to ask, and because the growing apparatus will be read, as ERP’s was, as proof that it was needed. If those layers become the definition of enterprise AI before anyone examines whether the underlying substrate can faithfully represent operational reality, the industry will have institutionalized another compromise, and it will spend the following two decades optimizing it. The alternative is not more sophisticated inspection. It is a foundation that does not require it. That choice remains open, but only for as long as the assumptions stay visible and the sunk cost stays small.