Each of the three headline remedies for ontology scar tissue is real, and each solves something.
None of them was designed to solve the specific failure Post 1 identified — a semantic layer nobody is structurally required to keep honest. Worth checking each against that standard directly, rather than against its own marketing.
Three remedies, one test
Zhamak Dehghani’s data mesh assigns the ontology’s ownership problem to an actual owner: each domain team holds its own data as a product, under a federated governance layer that sets the shared rules everyone else has to honor. This is the one remedy on this list that targets Post 1’s root cause directly — an owner of record — rather than a symptom of its absence. McKinsey’s own architecture guidance recommends the same shift toward “flexible ontologies and knowledge graphs” mapped to distinct classes of data rather than one monolithic schema.
What it relocates: federated governance is the hard half of the model, and it is also the half most organizations skip. Dehghani’s own team, five years into watching adoption at scale, reports the pattern plainly — data mesh “has not been implemented fully, and in many cases, it has been implemented poorly, with ‘me-too’ tools making big promises and failing to deliver.” Decentralization without a built, enforced federated governance layer does not distribute accountability. It just distributes the absence of it to more teams at once — a faster way to accumulate the same scar tissue, not a different kind of tissue.
The mistake is assuming extraction equals authorship. Microsoft Research’s GraphRAG method builds a knowledge graph directly from source documents using an LLM, then generates summaries over clusters of related entities to answer questions a standard retrieval system can’t reach. It measurably improves comprehensiveness on the class of questions it targets, and it removes a real cost: someone no longer has to hand-map every entity before the system is useful.
What it relocates: the graph GraphRAG builds is machine-extracted from documents, not authored and owned by a person accountable for what each node means to the business. That is not an implementation gap that better tooling closes — it is what the method is. A schema someone owns can drift because nobody maintains it. A graph nobody was ever meant to own cannot drift, because there was never a stable, agreed meaning to drift from. Bain’s research on agentic AI architecture describes what a knowledge graph is for at its best — “shared memory across agents” that keeps decisions “aligned to enterprise truth” — but that description assumes the graph is a governed asset. An LLM-derived graph is closer to a very good index than to an ontology, and treating the two as interchangeable is exactly the mistake Post 1’s four scars predict.
Automatic lineage and metadata enrichment — tagging, classifying, and mapping relationships across data assets without manual reconciliation — is a genuine, structural fix to a real cost driver. Bain’s own research on agentic AI data foundations lists exactly this kind of automatic enrichment as a prerequisite for scaling governed AI at all. Enterprises no longer have to reconstruct lineage by hand or by institutional memory, which is precisely the kind of manual reconciliation that made the 80/20 trap expensive in the first place.
What it relocates: lineage answers where data came from and which systems touch it. It does not, by itself, answer what a term means to the business, or who is accountable for that meaning when it changes. Those are two different questions, and vendors selling automated lineage tooling have a commercial incentive to blur them — marketing lineage, cataloging, and “semantics” as one unified capability instead of naming the gap between them. Automated lineage is a strong answer to “where,” not to “why,” and an enterprise that stops at lineage and calls the ontology problem solved has fixed discovery, not accountability.
The one remedy that actually gives PROV
There is a fourth pattern in active use that wasn’t on the original list, and it is the least glamorous of the four. dbt Labs’ model governance features — contracts, versioning, and access control — require that any change to a model’s structure pass through version control, get reviewed before merge, and either match the contract or fail to build. Ownership is explicit: models are grouped and assigned an owner, and breaking changes require a deliberate new version rather than a silent overwrite.
This is the only one of the four patterns examined here that is structurally alignment-grade rather than coordination-grade, in Luminity’s terms: a human with standing has to look at the change and approve it before it reaches production. It doesn’t scale to every kind of ontology work, and it wasn’t built to. But it is the clearest available evidence that the fix for ontology scar tissue was never a smarter graph. It was always a review step nobody could route around.
The warning, restated
None of the three headline remedies solves the accountability problem by default. Decentralization solves it only where the federated governance half actually gets built, which most deployments skip. GraphRAG solves the labor cost, not the ownership question, because the graph it produces was never meant to be owned. Automated lineage solves discovery, which is valuable and is not the same problem. The pattern that actually restores accountability is the one that looks like ordinary software engineering discipline, not a new architecture — which is exactly why it gets the least attention in a market currently selling the other three as the ontology fix.
Two of the three remedies enterprises are buying to close a decade of ontology scar tissue relocate the accountability gap instead of closing it, and the third solves a real but different problem that gets mistaken for the same one. The only mechanism in this post that actually restores PROV — version-controlled, human-reviewed schema change — is the least novel and the hardest to sell, which is exactly why it is underused relative to how well it works.
Post 3 applies the SACS framework (Source, Action, Context, Scope) to all four patterns examined across this series, to show precisely which surface each one covers and which it leaves exposed.
