What problem is Fabric IQ solving?#

Most organizations store their data in tables and columns, but people and business processes talk in business terms: "customer," "shipment," "cold-chain breach." Someone has to translate between the two. Today that translator is usually a human domain expert, and without a shared layer that captures those business concepts, every AI system asking a business question has to go through that manual translation from raw tables and schemas into business meaning — which is described as unfit for high-stakes decisions, because it doesn't scale and isn't consistent from one person or one system to the next [S1].

Fabric IQ is Microsoft Fabric's answer: a workload that turns raw OneLake data into shared business meaning, so both people and AI agents can reason about concepts like customers and shipments consistently, without redefining them every time [S1].

Fabric IQ ontology architecture

Where Fabric IQ sits in the bigger picture#

Fabric IQ isn't a standalone product — it's one of four pillars of a broader "Microsoft IQ" enterprise-intelligence layer. The other three are Work IQ (employee work context), Foundry IQ (organizational policy/document context), and Web IQ (web context). Fabric IQ's specific job in that lineup is supplying business-entity and data context [S1].

Concretely, Fabric IQ brings three layers of business context into Microsoft IQ — unified data, business intelligence, and operational intelligence — delivered through two core Fabric items: the ontology (preview) item and the semantic model [S1].

The two anchor items#

Semantic model. This is the existing Power BI item — a curated analytics layer that Fabric IQ reuses rather than replacing [S1].

Ontology (preview). This is the new item. An ontology defines core business entities, relationships, properties, rules, and actions, and it exposes a natural-language query layer called NL2Ontology that converts business questions into structured queries [S1]. In other words, the ontology is where "customer," "order," and "shipment" get defined once, along with how they relate to each other and what rules and actions apply to them — and NL2Ontology lets someone ask a plain-language question and have it turned into a structured query against that definition.

Importantly, you don't have to build an ontology from a blank page. Ontologies can be generated or aligned directly from Power BI semantic models already in production, so business terms and KPIs stay consistent across reports, agents, and applications instead of being redefined per experience [S1]. That means production BI investments can bootstrap the ontology rather than starting over [S1].

The rest of the IQ workload#

Beyond the ontology and semantic model, the IQ (preview) workload groups several other items: Plan (preview) for planning/forecasting, Graph for storing and traversing connected data, Data agent for natural-language Q&A, and Operations agent (preview) for monitoring live data and triggering governed actions [S1]. The operations agent specifically is an AI agent that reasons across business concepts to monitor real-time data, detect anomalies, and recommend or trigger governed business actions — and it's shared with the Real-Time Intelligence workload [S1].

That sharing isn't unique to the operations agent. Fabric items can belong to multiple workloads at once: the semantic model item is shared with the Power BI workload, and Graph and the operations agent are shared with Real-Time Intelligence [S1]. Underneath all of it, OneLake is the unifying data substrate — it isn't formally listed as an IQ workload item, but every item in the workload relies on and interacts natively with OneLake data tables [S1].

A worked example#

A logistics company already has a Power BI semantic model defining "Order" and "Shipment." They generate an ontology aligned to that model, so those definitions carry over rather than being re-typed [S1]. A sensor on a truck reports a temperature excursion. Because the ontology has declared the relationship chaining Order to Shipment to sensor, the system can traverse that graph relationship to connect the excursion to the specific order and shipment — flagging a cold-chain breach — instead of a person manually joining tables across systems [S1]. That cross-domain reasoning via graph traversal, faster onboarding because concepts are declared once, and governance from enforcing consistent definitions across teams are the stated benefits of this approach [S1].

What goes wrong#

  • Skipping the ontology and letting each team/AI system define "customer" or "order" its own way. This is the exact gap Fabric IQ exists to close — without a shared ontology layer, every business question needs manual expert translation, which doesn't scale for high-stakes decisions [S1].
  • Treating the ontology as a rebuild from scratch. If a production semantic model already defines the business's core terms, the ontology can be generated or aligned from it directly — building fresh is unnecessary rework [S1].
  • Assuming OneLake is a listed IQ item you configure directly. It isn't part of the IQ workload's item list, but it's still the data substrate every IQ item depends on — so gaps in OneLake data quality or access still surface as gaps in Fabric IQ [S1].
  • Not realizing an item can serve double duty. Because items like the semantic model, Graph, and the operations agent are shared across workloads (Power BI, Real-Time Intelligence), changes made for one workload's purposes can affect another [S1].

AI-generated deep dive (beyond the verified knowledge base)#

The section below is AI-generated from model knowledge and pending-verification sources, not from verified Fabric Codex claims. Fabric IQ is new and fast-moving — verify against current Microsoft documentation.

What is an ontology, in plain terms? It's a written-down agreement about what your business concepts are. Not a table, not a report — a definition. "A Customer is a party with at least one account; a Shipment belongs to exactly one Order; an Order can have many Shipments." An ontology captures the things (entity types), their facts (properties), and how they connect (relationships), plus rules that keep everyone's version of those definitions consistent. Think of it as the company glossary made machine-readable, so software can follow the same definitions people do.

A small business example. A bakery chain has a "Store," a "Product," and a "Daily Sale." In an ontology you'd declare those three entity types, give Store properties like name and region, and declare relationships: a Daily Sale happens at one Store and for one Product. Once declared, a question like "which region sold the most sourdough last week?" doesn't require anyone to remember which tables to join — the relationships already encode the join paths.

How this relates to semantic models and data agents. A Power BI semantic model is analytics-shaped: tables, measures, and KPIs tuned for reports. An ontology sits at a higher altitude — business concepts elevated above any single table, so the same "Customer" can be backed by different columns in different sources without fragmenting its meaning. Microsoft's pending documentation describes ontologies as bound to real OneLake data (lakehouse tables, eventhouse streams, or semantic models) and materialized as a queryable instance graph, with natural-language questions (NL2Ontology) constrained to the published definitions rather than guessed from raw schema. A data agent, by contrast, is the conversational front end — it benefits from the ontology because the definitions it reasons over are governed instead of inferred per question.

How to start small. Don't try to model the whole enterprise. Pick one process with a clear pain point — say, order-to-delivery — and define the three to five entity types it actually needs, bootstrapped from an existing semantic model where possible. Two practical caveats from the pending source material: the graph capability is a tenant setting that must be enabled, and upstream data changes are not reflected automatically — the graph needs an explicit or scheduled refresh. Both are worth confirming with your Fabric admin before a pilot.

What isn't public yet. Fabric IQ's ontology item is in preview (late 2025), and details like pricing, capacity consumption, quotas, and the GA timeline are not something to rely on from this lesson — check current Microsoft documentation and the Fabric roadmap directly.