A telco estate is not designed so much as accumulated. Over decades, operators layer each new generation of technology on top of the last, from 2G through 5G, bolt on best-of-breed systems chosen department by department, and inherit whole stacks through mergers and acquisitions. Regulation, country-by-country operations, and legacy commercial arrangements add even more complexity, and the result is an estate no one ever designed as a whole. The deeper problem is not the number of systems but what they disagree about: each one holds its own definition of the same core concepts, so “customer,” “subscription,” and “charge” mean something different across CRM, CPQ, charging, and billing, and every one of those meanings has to be kept in sync with every other.
Keeping those meanings in sync has a cost, and it does not grow in a straight line. Past a certain point, the money spent translating between systems exceeds the value those connections return. That crossover is semantic bankruptcy. It was expensive when humans were reconciling the gaps. It becomes dangerous when AI starts acting on top of them.
Why more integration stopped working
Operators have run ETL and point-to-point integration for dozens of years, and for most of that time it worked well enough. Each new system got wired to the handful of others it needed to talk to, one project at a time, and the estate grew one connection at a time. The reason that approach quietly stopped scaling is arithmetic.
Point-to-point integration scales as N(N-1)/2, so the number of connections grows with the square of the number of systems. Take an illustrative estate of 200 systems. The arithmetic (200 x 199 / 2) implies up to 19,900 possible integration paths to build, test, and keep alive. Nobody wires all of them, of course. But the curve is the point: every system you add does not cost you one more integration, it costs you a share of everything already connected. That is an O(n squared) curve, and somewhere on it there is a crossover, the point where the money spent translating between systems exceeds the value the integration returns. That is semantic bankruptcy: the point where keeping systems aligned costs more than the business value those connections create.
The scale of the estate is not hypothetical. MuleSoft’s 2026 Connectivity Benchmark says the average organization manages 957 applications and reports that most organizations leave up to 70% of their applications unintegrated. Telecom sits at the heavy end of that distribution: most estates carry hundreds of systems, far more of them disconnected than anyone designed on purpose.
There is a timing problem layered on top of the scaling problem. AI capabilities now evolve in weeks. Integration projects still take quarters. So the gap between what an operator could do with its data and what its plumbing actually supports widens every release cycle. We have argued the qualitative version of this before, that semantic drift across systems produces fallout and leakage; see BSS modernization: the lines matter more than the boxes for the full mechanism. This piece does something different. It quantifies what you are missing.
Where semantic fragmentation hits the P&L
Semantic fragmentation is not an abstraction. It shows up as four cost lines an operator can actually put a number on.
The first is the cost to keep an estate running. Keeping a fragmented estate running consumes 40% to 50% of the IT budget at scale, and a growing share of that goes not to serving the business but to translating between systems. That is the translation tax: the consultants and custom code spent bridging the gaps between systems, a recurring drag that grows with the estate.
The second is the cost to upgrade. Because every system is wired to so many others, every transformation has to unpick and rebuild that web, and the price grows with the sprawl. BCG’s TeBIT 2024 benchmark puts tier-1 and tier-2 telco transformations at $200M to $500M over two to three years, with 30% abandoned before completion, and even the ones that finish typically need redoing within three to five years as technology moves faster than the timeline. The estate does not just cost more to run, it costs more to change, and that cost climbs every time you add a system.
The third is revenue leakage. When systems disagree about what a customer actually has, money slips through the gaps, and it does so in more than one way. Two examples make it concrete. The first is order fallout: order-management benchmarks from TM Forum industry analysis and Salesforce put the share of telecom orders that drop out of automated flows and need manual intervention at roughly 15% to 25%. Every one of those is a manual touch, a rework cost, and sometimes a failed truck roll; we walked through how a CPQ-to-billing mismatch produces this in Telecom quote-to-order, part I. The second is definitional mismatch: the catalog and the charging system disagree about what a customer bought, so the customer is provisioned for one thing and billed for another. TM Forum research puts revenue leakage at around 1% to 2% of revenue; for a $20B operator that is roughly $200M to $400M a year. These are examples, not the whole list. Revenue also leaks when a service stays degraded because root-cause analysis is slow and the systems disagree on what is affected. Not all leakage is semantic, and we will not claim it is, but the part that is compounds silently.
The fourth is the AI tax. According to BCG’s TeBIT 2024 study, telcos have scaled only about 26% of their AI use cases, despite sitting on more operational data than most industries. The reason is not model quality. It is that agents operating across inconsistent definitions cannot be trusted to act. We covered why a read-only data platform does not fix this in Your data lake won’t fix your telco AI problem; the cost belongs on the same P&L as the other three.
Are you semantically bankrupt?
The threshold is measurable, and any operator can test for it. A few signals, applied honestly, tell you where you sit on the curve.
Start with your budget. As a rule of thumb, once an operator spends more than 30% of its IT budget on integration and the systems that keep meaning in sync, that is a strong signal the estate may have crossed into diminishing returns.
Then ask three diagnostic questions. Is order fallout running above roughly 15%, with a manual-intervention team that keeps growing? Are AI pilots stalling on the way to production, clearing the demo and dying in the handoff to real operations? Is the integration backlog growing faster than the headcount you can hire to work it down? Answer yes to two of those and the crossover is behind you, not ahead. The cost of translation has started to outrun the value it creates.
Change the exponent
Here is the uncomfortable conclusion the math forces. You cannot out-integrate an O(n squared) problem. Buying more point-to-point connectors, or funding another multi-year transformation to rationalize the estate, adds capacity to a curve that punishes capacity. Every system you connect makes the next connection more expensive.
The only way to win is to change the exponent. Instead of translating between every pair of systems, you define each concept once (one canonical definition of “customer,” “subscription,” “service,” “charge”) and map every system to that shared model. Map once, reuse everywhere. That turns N-squared pairwise integrations into N mappings, one per system. The curve flattens because the meaning lives in one place, not in the gaps between every pair of systems. This is the mechanism behind the lines, not the boxes argument, now expressed as arithmetic.
The Totogi Ontology as the fix
The Totogi Ontology is how you change the exponent without ripping anything out. It is an overlay, not a rip-and-replace: it sits above the systems you already run and maps each one, once, to a shared operational model, then reuses that meaning across every workflow and agent. Under the hood that model spans three layers, a data layer that connects to your existing systems, an ontology layer that holds a machine-readable model of your real-world telco, and an AI layer of ontology-aware agents that map, validate, and act. But the layers are secondary. The argument is the mapping: because meaning lives in one place, AI reasons from coherent meaning instead of reconciling contradictions at runtime.
The economics are the argument. We tallied the cost of the old path earlier: BCG puts major transformations at $200M to $500M over two to three years, with 30% abandoned before completion. An overlay changes the shape of the bet. Ontology-overlay programs are typically framed in the $5M to $20M range, with value landing in weeks rather than years. In one reported case, a tier-1 North American operator’s billing-system migration went from a four-to-eight-month effort to 14 days, with 18 interfaces auto-mapped.
Be clear about the scope. An overlay removes the friction of keeping meaning in sync; it does not make every hard part of a transformation disappear. Totogi Charging handles rating and charging; billing remains in the operator’s billing environment. The Totogi Ontology reduces the semantic friction around those systems rather than replacing every function. What it does is stop the estate from getting more expensive every time it grows. See the Totogi Ontology for how the overlay connects.
The takeaway
Semantic bankruptcy is not a technology problem you can spend your way out of. It is an arithmetic problem. As long as meaning lives in the gaps between systems, every system you add makes the estate more expensive to run, more expensive to change, and more likely to leak, and every AI agent you deploy inherits the contradictions. The fix is not more integration. It is to define meaning once and let every system, and every agent, reason from it. Change the exponent, and modernization stops being a transformation you survive and becomes a capability you keep.
About Totogi: The Totogi Ontology is a governed, machine-readable layer that sits above your CRM, catalog, CPQ, charging, billing, and core systems. It enables AI agents to reason safely and act correctly across your entire operational domain. Learn more at totogi.com.
