Every organisation has some version of the same challenge:
- What counts as an "active customer"?
- Does revenue get measured net or gross?
- Does a "sale" include returns?
The answer exists somewhere: in a finance director's head, in an outdated document, or as a DAX measure in a Power BI model that only one person knows how to maintain. A new analyst joins the team, asks the question, and gets a different answer depending on who they ask.
This ambiguity has always carried a cost in wasted time and inconsistent reporting. However it becomes sharper with AI agents in the mix, because an agent cannot ask a colleague to clarify what "active" means. It works only with the definitions available to it, and inconsistent definitions produce inconsistent answers.
This is a live problem across the industry, not one specific to any single vendor. Databricks recently took Unity Catalog Business Semantics to general availability and open-sourced its core implementation in Apache Spark, explicitly framing the effort around giving analysts, engineers and AI agents a single trusted source of metric definitions, and Snowflake released Semantic Views for the same purpose.
Microsoft's answer sits within Fabric IQ, a workload in Microsoft Fabric built around a feature called Ontology, currently in public preview. This article looks at what Fabric IQ and Ontology are, how an ontology differs from the semantic models many organisations already use, where the approach earns real business value, and where the platform trade-offs sit. It follows on from our earlier piece, A Look at Microsoft Fabric, which covered Fabric's approach to unifying data across engineering, analytics and data science on a single platform.
What Fabric IQ Is
Fabric's original pitch was about unifying where data lives. OneLake gave engineers, analysts and data scientists a shared foundation to work from, removing the friction of exporting data between disconnected tools.
Fabric IQ extends that unification a layer further, toward unifying what the data means. It brings business context into the platform through two core items, Ontology and semantic models, both built on OneLake. Semantic models continue to deliver trusted metrics for reporting. Ontology defines the shared business language behind those metrics. A graph component supports relationship and impact analysis across entities, and data and operations agents draw on all of it to interact with live and historical data through consistent definitions rather than raw schemas.
What an Ontology Actually Is
In Fabric IQ, an ontology is a structured description of the concepts that make up a business and the relationships between them. A customer is a concept. An order is a concept. An order belongs to a customer. Each concept carries defined properties, a clear description, and relationships to other concepts.
The useful comparison for anyone who has built a semantic model in Power BI is to notice what's similar and what's different. A semantic model is a technical artefact with tables, columns, relationships and DAX measures, tied to how the underlying data is physically structured. An ontology operates a level up, describing what a concept means independent of how the data behind it is stored. A single ontology concept, such as "Customer", might map to one table, several tables across different systems, or a calculation spanning multiple sources.
Ontologies and semantic models are designed to work together rather than replace one another. Ontologies can be generated directly from existing Power BI semantic models, so organisations with mature reporting already in place have a starting point rather than a blank page. An ontology is built from a small number of components: entity types, the reusable logical model of a concept such as Customer or Shipment; entity instances, the concrete occurrences of that concept populated from real data; and properties and relationships that attach detail, such as a customer's name or the fact that a customer places an order. Underlying all of this is a queryable graph, built from data bindings and relationship definitions, that allows relationships to be traced rather than buried inside join logic.
Why This Matters for AI
Reporting and analytics have functioned without a formal ontology layer for years, because a trained analyst can navigate ambiguity and apply judgement when a definition is unclear. However, AI agents need a concrete, structured answer about what a question means before they can act on it, and cannot rely on judgement to fill the gap.
Agents that draw on an ontology see business entities, their relationships and the rules that govern them, rather than raw tables and columns. This gives them a structured map of the business to reason over, producing more consistent, explainable responses.
Ontology also supports a natural language query layer, NL2Ontology, which converts business questions phrased in plain language into structured queries against the ontology's definitions, respecting the filters, units and validity rules already published there rather than guessing at joins. Business rules embedded directly in the ontology can trigger alerts or automated actions when a defined condition occurs, such as inventory falling below a threshold, without custom code.
The Business Case: Cost, Risk and Speed
An ontology layer earns its place through three mechanisms.
Cost reduction through reuse:
Once a concept such as Customer is defined centrally, every subsequent project draws on that definition rather than rebuilding it. A churn model, a customer service agent and a regulatory report can all reference the same entity with the same properties and constraints, removing the duplicated engineering effort of maintaining separate versions of "what a customer is" across teams. This is the same logic Databricks cites from early Unity Catalog Business Semantics adopters, where standardising metric definitions cut the ongoing workload of reconciling conflicting numbers across dashboards.
Risk reduction through traceability:
Every ontology-bound answer traces back to its source data and definition. In audit-sensitive and regulated environments, an agent that can show which entity, property and rule produced a given answer sits in a materially stronger position during a compliance review than one that cannot account for its own reasoning. This matters increasingly as agents move from producing dashboards to taking operational actions.
Speed to value in agent deployment:
Building an AI agent typically involves substantial work translating business intent into queries against unfamiliar table structures, work usually repeated for every new agent. With shared business definitions in place, that translation is done once and inherited by everything built afterwards. Microsoft's own framing of this is that agents gain the operational context needed to understand how a business runs, making their behaviour explainable rather than dependent on how one developer happened to interpret the schema.
Taken together, these mechanisms point toward a platform that becomes more valuable with each project built on it, rather than one where every new initiative starts its definitional work from zero.
How to Prepare Your Data for Fabric IQ
Understanding what an ontology is and why it matters naturally raises a more concrete question: what does an organisation actually need in place before it can build one?
Data that already lives in OneLake:
Ontology only binds to data inside Microsoft Fabric - static data in OneLake lakehouse tables, or time series data in OneLake or an Eventhouse. Data sitting outside Fabric needs to be brought into OneLake first, whether through direct ingestion, mirroring or shortcuts, before it can be modelled as part of an ontology.
Two starting points, depending on what already exists:
Organisations with an established Power BI semantic model can generate an ontology directly from it, inheriting entity types and relationships from work already done. Organisations without one build the ontology manually, binding entity types directly to OneLake tables and defining relationships from scratch. The first path is considerably faster.
Clean, well-structured source data:
Data should already be organised and have gone through the ETL a business requires before binding begins, with all the information needed to model it present in the source. Ontology doesn't clean or transform data on the way in. It expects data that's already fit for purpose, meaning governance and quality foundations matter as much here as anywhere.
Technical requirements before design starts:
Ontology has specific requirements for the lakehouse tables it binds to. They must be managed tables without OneLake security enabled, and without column mapping enabled, which can be triggered automatically by certain naming conventions or import-mode semantic model tables. These are the kind of details that catch teams out mid-build rather than at the planning stage, so it's worth an early technical review against an organisation's actual table structures rather than assuming compatibility.
A defined entity key for every concept:
Each entity type needs at least one property, or combination of properties, that uniquely identifies each record, established during static data binding before any time series or streaming data can be layered on top. This is standard data modelling discipline, but it means the exercise of properly defining a business concept, rather than simply pointing at a table, has to happen before any binding work begins.
Considerations:
It's worth considering that adopting Fabric IQ's ontology means investing engineering effort in Microsoft's specific modelling approach, tied to OneLake and the Fabric tenant. That is a commitment for anyone weighing platform risk, and it sits within a wider industry response to the same problem, not a decision made in isolation.
Databricks has taken a different position on portability, open-sourcing the core implementation of Unity Catalog Business Semantics in Apache Spark and stating explicitly that its goal is business meaning that is open and portable across an existing ecosystem, without lock-in.
Snowflake's Semantic Views take a similarly warehouse-native approach, while tools such as dbt's MetricFlow are built to be vendor-agnostic by design, generating SQL that runs against whichever warehouse an organisation uses rather than tying metric definitions to one platform.
None of this means Fabric IQ is the wrong choice for organisations already committed to the Microsoft stack. It does mean the decision to build into it should be weighed against the same questions any platform-specific investment deserves: how difficult would it be to migrate this definitional work elsewhere, and how much of the organisation's data strategy is already tied to this vendor regardless of this specific feature.
What This Means for Tech Leaders
Fabric IQ and Ontology are in public preview, not general availability, and the tooling reflects that stage. Defining concepts, properties and relationships currently involves more manual configuration than the finished product is likely to require, and for an enterprise modelling hundreds of concepts, that overhead is considerable.
Readiness for this depends on groundwork that has nothing to do with Fabric IQ specifically. A mature Power BI semantic model gives an ontology something to bootstrap from rather than starting from scratch. Established data governance, with clear ownership and lineage, gives the ontology layer trustworthy data to bind to. Organisations without that foundation are likely to find that an ontology surfaces the same definitional disputes it's meant to resolve, in a new location rather than a resolved one.
There's also a skills dimension worth planning for. Ontology modelling is a distinct discipline from both data engineering and traditional BI development, closer to the kind of conceptual modelling more familiar in data architecture and knowledge management. Teams comfortable building semantic models in Power BI will find some concepts transfer, but should expect a genuine learning curve rather than treating this as an extension of existing DAX skills.
Enterprise controls are maturing alongside the feature, with Fabric IQ now supporting granular sharing and permissions management for ontology items, and Azure Private Link integration for network isolation, which is a reasonable signal that Microsoft is treating this as a governed enterprise capability rather than an experimental add-on.
Conclusion
Fabric's original contribution was to unify where enterprise data lives. Fabric IQ, through Ontology, is Microsoft's attempt to unify what that data means, and it arrives alongside comparable moves from Databricks and Snowflake that point to the same conclusion from different directions: AI agents need governed business meaning, not just access to tables.
For organisations already running mature Power BI semantic models and established data governance on Fabric, a scoped pilot ontology covering one well-understood domain is a reasonable step to take, ahead of general availability, precisely because the bootstrap path from existing semantic models lowers the initial cost of finding out whether the approach fits.
For organisations earlier in their data governance maturity, or invested primarily in a different platform, the more useful action is tracking how Fabric IQ, Unity Catalog Business Semantics and Snowflake's Semantic Views mature over the next year, rather than committing engineering effort to any one of them today. The underlying idea, giving data a consistent, governed meaning that both people and machines can share, is worth planning for regardless of which vendor's version an organisation eventually adopts.
