What Is Foundation Debt?

The phrase comes up in almost every project, usually on a Friday, just before a deadline: We'll clean that up later. Someone will maintain the lead times by hand for now. The pricing terms stay in the spreadsheet for the time being. The reconciliation between systems is a phase-two item. Each of these decisions is reasonable in isolation, and almost none of them ever gets revisited.

We see this pattern in nearly every assessment, and in our methodology it has its own term: Foundation Debt. This article explains what lies behind it, why the debt grows more expensive over time, how we measure it, and how to tell whether you can afford to carry it.

What does Foundation Debt mean?

Foundation Debt is the gap between the data foundation a project requires and the foundation that actually exists. How robust a data domain needs to be depends on the use case. How robust it actually is can be measured. The distance between the two is the debt.

The term is borrowed from technical debt in software development. Shipping fast and deferring the cleanup is like taking out a loan — and later changes repay it with interest. The same thing happens in the data foundation, just one level deeper. An agent running on an unresolved product master is exactly that kind of loan. The difference from a bank loan: there is no contract, and no statement arrives. Only what someone knows about gets repaid.

The reference to a specific project matters. Foundation Debt is not a report card for the entire data landscape. The same data may be perfectly adequate for a reporting system and far too patchy for an ordering agent. It is the demands of a project that turn a data situation into a debt.

Why does the debt get more expensive over time?

Because a gap in the foundation generates follow-on costs every single day, and because those costs grow with every additional system built on top of the gap.

It starts with daily workarounds. If a lead time is missing from the product record, the planning team compensates — through manual enquiries, rule-of-thumb estimates, and safety buffers on order quantities. Each individual workaround costs very little. It just happens every day, year after year. Then there are the temporary fixes that become permanent. The Excel bridge between two systems was meant as a stopgap; by now it is maintained, extended, and handed down, and at some point a process depends on it that nobody wants to touch. And finally, the gap propagates. Every new system, every report, every AI use case built on top of it inherits it. A missing product owner first frustrates purchasing, then the online shop, then the reporting team, and eventually the agent.

With AI, this calculation jumps up sharply again. We described why in the article on AI agents in production: automation removes the human compensation that used to absorb the gap. A system that takes every value literally turns a familiar nuisance into a measurable, repeating error. Gartner warns accordingly that the absence of AI-ready data puts projects at fundamental risk. Another way to put it: the moment AI encounters the debt, the interest rate spikes.

How is Foundation Debt measured?

As the difference between target and actual state, per cell, on a scale of 0 to 100. A cell is our term for the combination of a data domain — say, product master data — and one of the four levels from foundation through to autonomy. For every cell a project requires, both values are determined. The target follows from the intended degree of automation and the error costs of the process: an agent that places orders autonomously needs more than a system that merely makes suggestions. The actual state is measured against evidence from the systems, using fixed criteria with transparent scoring rules.

A worked example with fictional data. A multichannel retailer wants to automate replenishment, with exception approval by a planner. The target for the required cells is 75 out of 100. The weakest required cell — product master data at level one — scores 42 when measured. The Foundation Debt for that cell is 33 points. And because the weakest cell caps the achievable reliability of the whole project, that gap is the bottleneck for the entire initiative. The complete assessment is available in the freely accessible sample report.

Two things matter to us about this measurement. A criterion only counts when verifiable evidence exists — a data quality report, an operational log. Claims without documentation are capped downward. And two reviewers working from the same evidence must reach the same result. Otherwise the debt becomes a matter of negotiation, and that is precisely what distinguishes it from the self-assessments that typical readiness scores are built on.

The practical value is that the debt now has a location and a size. 33 points in a named cell is no longer a vague data problem — it is a quantifiable remediation effort. A set of measured gaps becomes a repayment plan with a sequence, an effort estimate, and the value each closed cell releases. The scale, the criteria, and the formulas are openly documented on the methodology page.

What distinguishes Foundation Debt from poor data quality?

The reference point. Data quality describes how complete, accurate, and current data is in its own right. Foundation Debt describes how far that state falls short of what a specific project demands. Without a requirement, there is no debt.

This may sound like a terminological distinction, but it changes where money goes. Investing in data quality as an end in itself can mean polishing domains that no project will ever need, while overlooking the one cell that is holding back the next use case. Starting from the project leads naturally to the cells it actually requires and to the largest gap among them. The same budget has more impact in the right place. The article What data does AI need? walks through the questions you can use to assess the relevant domains yourself.

When can you afford to carry debt?

When it is taken on deliberately, kept bounded, and has a repayment date. After everything above, that may come as a surprise — but honesty demands it: Foundation Debt is not inherently bad, any more than a loan is. A pilot running on manually cleaned data is a classic deliberate debt, and as an experiment it is entirely legitimate. It shows quickly and cheaply whether a use case works in practice before anyone invests in the foundation.

It becomes expensive in two situations. When the debt accumulates unnoticed — because no one consciously decided to skip a level — the interest runs silently in the background. That is the normal finding in our assessments. And when the pilot, along with its debt, moves into full production, the manual cleanup disappears, and a cheap experiment becomes a costly steady state across the full product catalog. A simple question works as a rule of thumb. Do you know, for every debt, where it sits, what it costs per month, and when it will be repaid? The moment any of those three answers is missing, the loan has become a leak.

How do you pay down Foundation Debt?

Starting from the project, one cell at a time. It begins with measurement: which use case is next, which cells does it need, how large is the gap in each. Repayment follows the order of value — the largest constraining gap first. This keeps the effort manageable, and the result can be measured after every closed cell, because the achievable reliability of the project increases. The article on agentic replenishment shows what a concrete repayment plan looks like in a worked case.

The second part is less comfortable, and it determines how long the results last: no new debt should accumulate. Every closed cell needs a named owner who maintains the standard that has been reached, and rules that surface new gaps as soon as they appear. Without both, the next cleanup is three years away with the same findings. With both, paying down the debt becomes an ascent through levels that stay passable. That is exactly what the name Foundation Ascent stands for. The assessment that starts this journey takes three weeks. What it delivers and how it works is described on the methodology page.

Sources

Source	What it says
Gartner · Lack of AI-ready data puts AI projects at risk, Februar 2025
prodct · Beispiel-Report ACME Inc. (fiktive Daten)