Why Most Enterprise Knowledge Graph Projects Die in Year Two

Knowledge Graph Practitioner’s Guide: Overview | Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 | Part 9 | Part 10 | Part 11a | Part 11b | Part 11c | Appendix A | Appendix B | Appendix C | Part 12

The Year Two Conversation

It is roughly 21 months into a knowledge graph initiative at a Fortune 500 company. The first 12 months were spent on ontology design: workshops with domain experts, alignment with FIBO (or a clinical taxonomy, or a manufacturing standard), repeated revisions, careful versioning of terms. Months 13 through 18 were spent loading data: writing R2RML mappings, running entity resolution, building dashboards to track quality. The graph holds 200 million nodes and a billion edges. The platform is up. The dashboards are green.

The conversation in the steering committee, in month 21, is not about the next milestone. It is about whether the program will be funded for year three.

The product team that was supposed to build the customer 360 application on top of the graph never did, because their roadmap moved on while the KG was being built. The compliance team that was supposed to query the graph for lineage built their own SQL-based reporting because they could not wait. The platform engineer who built the ontology editor is interviewing elsewhere. The CTO who sponsored the initiative has rotated to a different remit.

The graph still works. Nobody is using it.

This is the year two conversation, and some version of it happens at most enterprise knowledge graph projects. It is not a story about RDF versus property graphs, or triple stores versus graph databases, or which vendor’s platform was chosen. It is a story about the patterns of organizational decay that kill KG initiatives long before any technical limitation surfaces.

In Part 1 of this series we used LinkedIn’s Economic Graph to introduce the four moving parts of a knowledge graph: entities, typed relationships, identity, and inference. This article is the prerequisite to all of the design content that follows. Before we teach you how to design a KG, we want you to know what kills them. The lessons in the next thirteen articles all sit on top of the failure patterns described here.

How Often Do KG Projects Fail?

There is no single published failure rate specifically for knowledge graph initiatives. What we have are adjacent statistics that triangulate the answer.

Gartner forecasts that 80 percent of data and analytics governance initiatives will fail by 2027 due to a lack of a real or manufactured crisis. Gartner separately predicted that 30 percent of generative AI projects would be abandoned after proof-of-concept by the end of 2025, and that 60 percent of AI projects unsupported by AI-ready data would be abandoned through 2026.

A figure widely cited in the semantic-layer space puts the failure rate of large, multi-year, top-down enterprise data modeling initiatives at 70 percent (cited by Timbr and others; we have not been able to trace it to a primary study, so treat it as vendor-reported color, not a verified benchmark). The same body of work observes that “80 percent of AI projects fail to move beyond the pilot phase because they lack a unified semantic layer.”

Knowledge graph initiatives sit at the intersection of all three failure modes: they are governance initiatives, they are data modeling initiatives, and increasingly they are AI-supporting initiatives. The expected failure rate is not lower than the surrounding categories; it is at least as high.

The good news is that knowledge graphs are now positioned on the Slope of Enlightenment in Gartner’s 2024 Hype Cycle for AI, and the global KG market is growing at a 36 percent compound annual growth rate. The technology has matured. The failure modes have not.

The rest of this article describes three of those failure modes in detail, illustrated with composite case studies. None is a real organization. Each is synthesized from publicly documented enterprise KG failures and from patterns I have watched repeatedly in adjacent data-platform programs: the catalog nobody queried, the glossary that grew to thousands of unused entries, the lineage store no consumer trusted. The KG failure modes rhyme with failures I have seen up close in Data Governance and MDM, even though the substrate itself is new to most of us. Names and details are invented; the patterns are real.

The three patterns hit at predictable points in a project’s lifecycle. Knowing when each one tends to surface helps with both prevention and triage:

Pattern One: The Boil-the-Ocean Ontology

The most common failure pattern is also the most seductive. The team gathers, looks at the wide variety of data the organization holds, and decides that the right first step is to model everything.

The composite case

A national logistics company decides to build a knowledge graph to power a new generation of supply-chain analytics. The architects bring in domain experts from procurement, transportation, warehousing, customs, finance, and customer service. Twelve workshops are scheduled.

The ontology grows. By month four it has 240 entity types and 800 relationship types. By month six the team is running into ontology contradictions: customer service models a “customer” as the recipient of a shipment, while finance models the same customer as the contracting party that pays the bill. Resolving these conflicts takes months, requires executive arbitration, and produces an entity hierarchy six levels deep.

By month nine the architects realize the ontology no longer matches anyone’s day-to-day vocabulary. The procurement team stops attending workshops. By month twelve the project is on a 24-month timeline. By month fifteen the customer service team launches its own customer 360 effort using a relational database, citing the KG team’s velocity as the reason. By month eighteen the head of architecture leaves. By month twenty the funding committee asks why the KG has not yet shipped a single user-facing capability.

Why it dies

The boil-the-ocean ontology fails because it makes a category error: it treats the ontology as a comprehensive description of the business when it should be a contract for solving a specific problem. The Cutter Consortium identifies this exact pattern: “Most key stakeholders don’t really understand the principles of data; they just want a near-term solution to an isolated use case.” When the architects insist on a comprehensive ontology, the stakeholders disengage and pursue point solutions.

The deeper issue is that ontologies designed in the abstract diverge from the operational data they are supposed to govern. Timbr’s analysis notes that “enterprise ontologies are designed to define business meaning, but in practice they fall out of sync as data models, dashboards, and application logic evolve independently.” Once the ontology and the operational reality drift, the KG team is in a perpetual catch-up mode that nobody funds past year two.

What survives

Successful KG initiatives in this same domain start with a single bounded use case (a specific reporting question, a specific customer-facing experience, a specific compliance check) and grow the ontology as that use case demands. The same logistics company, in a recovery scenario, would have started with a “track a shipment from origin to destination across modal handoffs” use case, modeled the eight or twelve entity types that question requires, shipped it in 90 days, and earned the right to expand.

For practitioners: when a KG vendor or consultant proposes a six-month “ontology design phase” with no shippable use case at the end, walk out. The successful equivalent of that engagement is a 90-day phase that ends with a working application backed by a 20-entity ontology, with a clear plan to extend the ontology in the next 90-day phase.

Pattern Two: The No-Consumer Knowledge Graph

The second failure pattern is technically excellent and operationally invisible.

The composite case

A global asset manager builds a KG to consolidate beneficial-ownership data across its 40 portfolio companies. The data engineering team is highly capable. They pick a property-graph platform, design a clean ontology aligned with FIBO, run sophisticated entity resolution across legal entity sources, and stand up a query interface in 11 months. The graph contains 4 million nodes and 80 million edges. Quality metrics are strong.

There is no application using the graph.

The compliance team that was supposed to be the first consumer was never co-designing with the KG team; they had been told the data would arrive, and built their workflows around the existing fund-administration system in the meantime. By the time the KG is ready, the compliance team has six months of investment in an alternative path. They will not switch.

The KG team commissions an internal “champion” workshop. Three product teams come; none of them have a use case that requires graph traversal. The data scientists could conceivably benefit, but the KG’s query interface is SPARQL, and none of the data scientists know SPARQL. The KG’s API is bespoke, the documentation is sparse, and the onboarding cost for any new consumer is two weeks of paired-programming time the KG team does not have to give.

By month 18 the KG is referred to internally as “the dictionary.” It contains the right answers. Nobody asks it.

Why it dies

The no-consumer KG fails because the team that builds the platform is not the team that builds the consumer. The two teams have different incentives, different roadmaps, and different definitions of done. When they are not co-designing from week one, the platform team optimizes for properties (Data Quality, completeness, ontology rigor) that the consumer team cannot benefit from until they have already invested in their own pipeline.

This is the operational cousin of Gartner’s “pilot purgatory” phenomenon. The KG itself has shipped, but the use cases have not, so the KG is functionally a pilot indefinitely. As the original sponsor moves on or budgets contract, the KG is the easiest line item to cut because no consumer experience depends on it.

What survives

Successful KG initiatives ship a thin, ugly, but real consumer application in the first 90 days. The ontology in that release is small. The data is partial. The query interface is whatever the consumer can use today (REST endpoint over a graph traversal, not raw SPARQL or Cypher). The application is real enough that pulling the graph would visibly break the consumer.

The KG matures because the consumer demands more from it. The consumer matures because the KG can answer questions the old platform could not. They evolve together. This is the difference between a knowledge graph as a platform deliverable and a knowledge graph as a capability.

What this looks like in practice. In a composite drawn from publicly documented retail-banking KG efforts, the customer 360 KG that survived year two was the one whose first consumer was a single-page internal app used by branch relationship bankers to see the customer’s full household relationship before a meeting. The KG had roughly a dozen entity types and a similar number of relationships at launch. The bankers used it in their first conversation. The KG team had a real customer.

Pattern Three: The Governance-Vacuum Knowledge Graph

The third failure pattern arrives latest. The KG ships, the consumer is real, the data flows. Then nobody owns it.

The composite case

A regional health-insurance company successfully ships a KG that powers a member-search-and-disambiguation application for the call center. The first 18 months are a success. Average call handle time drops by a double-digit percentage (illustrative, not instrumented). The KG is operational.

In month 19, a new product line launches. New entity types are needed. The original KG team has been moved to other priorities; the platform engineer who designed the ontology has left for another company. The product line team submits a change request. There is no defined process for ontology changes. The request sits.

Six weeks later the product line team makes the changes themselves, by directly inserting new edge types into the graph without updating the ontology document. Six months after that, the original ontology and the live graph have diverged. New consumers are warned to “check the live schema, not the docs.” Trust in the graph erodes. By month 30, two product teams are extracting subsets of the graph into their own stores rather than query the increasingly chaotic graph directly.

The graph is not abandoned. It is decaying. Its useful lifespan is shortening because its meaning is shortening.

Why it dies

This is the failure pattern Alation describes as “enterprise ontology decay”: “the ontology you ship on day one is already drifting by day thirty,” and “an ontology without a feedback loop is a snapshot.” The ontology, designed as a project deliverable, has no maintenance owner. The graph, treated as a finished system, has no evolution process.

This is also where Gartner’s broader point about governance initiatives applies. Gartner’s prediction that 80 percent of D&A governance initiatives will fail by 2027 cites the absence of a real or manufactured crisis. The KG is functioning, so no crisis arrives. The governance need accumulates as technical debt that no single decision-maker is willing to pay down.

What survives

KGs that survive past year three have a named ontology owner with executive backing, a documented change process, and an evolution ritual. The ontology owner is not a part-time architect; it is a data product manager whose performance is measured by graph adoption, query satisfaction, and ontology drift metrics. The change process is enforced by tooling: schema changes go through a pull-request flow, breaking changes have explicit deprecation timelines, the live ontology and the documented ontology cannot diverge silently.

Some organizations split the role. Netflix’s Upper metamodel (covered in our Netflix Data Governance teardown) is a self-describing upper ontology that all domain models extend, with a platform layer owning the metamodel and individual domains owning their own models on top of it. Lakeside Trust Bank’s reference architecture in Part 11 of this series will use the same split: a platform team that owns the metamodel and a separate owner for each major domain ontology.

The agent-era restatement: every AI agent that retrieves from a stale knowledge graph produces stale knowledge. Year-two governance failure becomes a real customer problem the moment the graph is connected to an agent that answers customer questions. We will return to this in Part 9.

The Pattern Across the Patterns

Three failure modes, three composite stories, one underlying cause: the KG was treated as a deliverable, not a capability.

A deliverable has an end state. A capability has an evolution rhythm. A deliverable is owned by a project. A capability is owned by a product manager. A deliverable is funded once. A capability has an annual budget that grows and shrinks with adoption. A deliverable is finished. A capability is never finished.

The four-part lens from Part 1 maps cleanly onto the failure modes:

KG component	Failure mode in pattern 1 (boil the ocean)	Failure mode in pattern 2 (no consumer)	Failure mode in pattern 3 (governance vacuum)
Entities	Too many types, none well-modeled	Right types, ungrounded in real queries	Original types decay as new types are added without rigor
Typed relationships	Hundreds of relationship types in conflict	Clean relationship model with no consumer to validate semantics	Relationships proliferate without naming convention
Identity	Identity work delayed because ontology not stable	Identity work done well, but no app exercises it	Identity rules drift as new sources arrive
Inference	Never reached	Could be added, but no consumer demand	Stops as soon as ontology decays

Two leading indicators predict where a KG initiative will land at the year-two review: how broad the ontology is, and how well-aligned the project is with a real consumer application. Plotting these two against each other gives a useful triage tool:

Compress the three stories into three rules. Use them whenever you propose, evaluate, or rescue a KG initiative.

Rule	What it prevents	What it requires
Ship a real consumer application within 90 days, even with a tiny graph	The boil-the-ocean ontology and the no-consumer KG	A product partner who is co-designing from week one and a willingness to launch ugly
Name the ontology owner before you load any data	The governance-vacuum KG	A data product manager role, executive backing, and ontology drift metrics
Treat the ontology as a contract for the use cases on the roadmap, not a model of the entire business	All three patterns	Discipline to say “no, we will not model that yet” and a roadmap that surfaces the next 90 days of needed entities

These three rules do not guarantee success. They prevent the most common forms of failure. The next thirteen articles are largely about how to do the things these rules require: how to design a small ontology that does not box you in (Part 4), how to handle identity and entity resolution (Part 5), how to source and build the graph (Part 6), how to govern quality and provenance (Part 7), how to operate and evolve it (Part 8), and how to plug it into the consumer applications that will actually use it (Parts 9 and 10).

Why This Series Treats KGs as Capabilities, Not Products

The framing in the rest of the series follows from the failure patterns above.

We will spend Part 3 on what a knowledge graph actually is, with rigor, so you have the vocabulary to push back on vendor pitches that promise turnkey solutions. We will spend Parts 4 and 5 on the design choices most projects get wrong (ontology granularity, identity model, inference scope). We will spend Parts 7 and 8 on the operational concerns that matter in years two through five, not month one. The capstone in Part 11 will not be a turnkey deliverable; it will be a 90-day-and-then-iterate plan for a mid-size US bank, designed to be defensible against the failure patterns above.

If you read just one article in this series before proposing a KG inside your organization, this is the one. Then read Part 11 to see what the alternative looks like in practice.

Do Next

Priority	Action	Why it matters
This week	Audit any KG initiative in your organization. For each, identify: the named consumer application, the named ontology owner, the smallest scope it could ship at. If any of the three are missing, the project is at risk.	The three rules above. Apply them as a triage.
This week	Read the Cutter Consortium piece on KG implementation obstacles and the Alation post on ontology decay. Together they describe most of the operational pathologies the rest of this series is designed to prevent.	Independent perspective on the same patterns this article covers.
This month	Map your organization’s “shadow KG-like efforts” (Data Lineage, MDM, semantic layer, customer 360, master reference data). Each is a candidate first consumer for a real KG initiative. The wrong question is “should we build a KG?” The right question is “which of these existing efforts is closest to needing a graph?”	Avoids the boil-the-ocean trap by starting from a real, funded, partially-staffed effort that can absorb the KG.
This month	Identify your candidate ontology owner. Is there a data product manager (or someone who could be) who would own the graph as a product? If not, the governance-vacuum failure is more likely than not.	The owner question is the leading indicator of year-two outcomes.
This quarter	Do not propose a KG initiative until you have read at least Parts 3, 4, and 11 of this series. The vocabulary and the reference architecture in those articles are the two things you will need to defend the proposal in front of skeptical executives.	The vocabulary is in Parts 3 and 4. The reference architecture is in Part 11.

---

Part 3 of this series, “What a Knowledge Graph Actually Is (and Is Not): From Tables to Triples to Meaning,” is the conceptual core of the series. Read it next.