Last time, I argued that ontology drift isn’t a reason to abandon formal, top-down modeling. It’s evidence that most ontologies are scoped wrong: one layer trying to be both permanently stable and constantly current, which is a contradiction, not a design. The fix is separation. A stable, domain-neutral core. A domain layer underneath it that’s allowed, expected, to change, on a defined cadence, with an owner.
That’s the theory. This post is about what it takes to actually run that in practice, and specifically, whether the tool a lot of us are now building on, Fabric IQ, supports it today.
Versioning Meaning Is Not Versioning Schema #
Software versioning is a solved problem. You bump a number, you write a changelog, you deprecate an endpoint with a sunset date, everyone downstream adjusts on their own schedule. We’ve had decades to get good at this.
Versioning an ontology is harder, because the thing that changes isn’t a data type. It’s a contested definition. Changing what counts as an “active customer” isn’t a breaking API change in the technical sense. It’s a decision that finance, sales, and whoever owns churn reporting all have opinions about, and those opinions frequently disagree. A schema migration has a clear notion of correctness: does the new structure parse. A definition change doesn’t. Two reasonable people can look at the same proposed change to “active customer” and land in different places, and there’s no compiler that tells you who’s right.
So an ontology versioning practice needs something software versioning doesn’t: a place where that disagreement gets resolved, on the record, before the change ships. Not a pull request. A decision, with an owner attached to it, and a visible trail of what changed, when, and why, so that six months later nobody has to reconstruct the reasoning from memory.
Downstream, this needs to be more than a courtesy notification. Anything bound to an entity type, a semantic model, an agent, a report, needs a signal that the ground moved, ideally before it silently starts returning different numbers than it did last week.
What Fabric IQ Actually Supports Right Now #
Fabric IQ as a whole reached general availability at Microsoft Build 2026, but the Ontology item specifically is still in preview, and Microsoft’s own documentation is upfront that not every capability inside the workload has graduated at the same pace. [1] That distinction matters if you’re deciding how much to build on it today.
On versioning specifically: there isn’t a mature, built-in deprecation workflow yet. The most useful account I found comes from the team at Team400, who exposed a Fabric IQ ontology as an MCP server for external AI agents to consume. Their conclusion, after watching what breaks: once agents are pointed at your ontology, removing an entity type or renaming a property is a breaking change for every one of them, and they’ve started treating ontology versioning the same way they’d treat a public API: semantic versioning, deprecation windows, a changelog. [2] Worth noting: that’s a practice they built themselves on top of the platform, not something Fabric IQ ships out of the box.
That’s an important distinction. It means the discipline I described above, an owner, a resolution process, a downstream signal, currently has to be assembled by the team running the ontology. The platform gives you the artifact. It doesn’t yet give you the governance workflow around it. If you’re standing up an ontology in Fabric IQ this year, budget for building that yourself, and don’t assume future tooling updates will backfill it before you need it.
Someone Has to Own the Definition #
Which brings me to the part that’s organizational, not technical, and the part I think actually determines whether any of this works.
In the previous post in this series, I quoted Constellation Research analyst Michael Ni’s blunt observation that ontologies don’t build themselves. The quality of your ontology reflects the quality of your shared understanding of the business, and if sales and finance already disagree about what revenue means, a new artifact type doesn’t make that disagreement go away. It just makes it visible.
Visibility is progress, but only if someone is actually accountable for resolving what it surfaces. That’s a role, not a tool purchase: a small governance group with the authority to make a call on a contested definition, a review cadence that isn’t “whenever someone complains,” and a documented process for what happens when two domains genuinely need different definitions of the same word and both are legitimate. Sometimes the answer is one entity type with two views. Sometimes it’s two related entity types that share a common ancestor in the domain layer. Either way, somebody has to decide, and it can’t be whoever happened to build the bootstrap ontology from the semantic model last quarter.
What “Grown” Gets Right #
I was hard on the “grown, not built” argument in the last post, and I stand by that critique. But it’s not entirely wrong, and there’s a version of it worth stealing rather than dismissing.
Usage tells you things a design session doesn’t. Which entities agents actually query. Which relationships never get touched and are quietly dead weight. Where an agent fails, repeatedly, for lack of context, which is a pretty direct signal that something in the domain layer needs attention. None of that requires abandoning formal versioning. It’s a feed into it: usage telemetry as evidence that a review is due, evaluated and approved through the same governed process as any other change, not a substitute for one.
Built and grown aren’t actually opposites. Built gives you an auditable, governable structure. Grown, treated as a signal rather than a replacement, tells you where to point that structure’s maintenance effort next.
Where This Leaves the Series #
Three posts ago I argued the ontology should sit above the semantic model, which should sit above the dimensional model, each one a narrower projection of the layer before it. I still believe that. But a hierarchy only holds up if the top layer is actually maintained, and maintenance isn’t a project with a launch date. It’s a job, with an owner, a budget, and a process for handling the fact that the business underneath it will keep moving.
Get that part right, and the rest of the hierarchy holds. Skip it, and you’re back to the photograph the LinkedIn post warned about, just with a more impressive-looking frame around it.
What is your experience with ownership in general, and ownership of vague business concepts in particular? I’d like to hear about it, so please reach out on LinkedIn or BlueSky.
References #
[1] Emergent Software. Fabric IQ Explained: Connecting Data, Semantics, and AI Across the Enterprise. 2026. https://www.emergentsoftware.net/resources/insights/fabric-iq-explained-connecting-data-semantics-and-ai-across-the-enterprise/
[2] Team 400. Exposing Fabric IQ Ontology as an MCP Server for External AI Agents. April 2026. https://team400.ai/blog/2026-04-fabric-iq-ontology-mcp-server
[3] Microsoft Learn. Ontology (Preview) Frequently Asked Questions. 2026. https://learn.microsoft.com/en-us/fabric/iq/ontology/resources-frequently-asked-questions
Photograph by Mike Peel (www.mikepeel.net). - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=125587798