Fabric IQ and Ontology: Giving Data a Shared Business Meaning

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