Introduction

Fabric IQ has been in preview for a while now, and the reaction has been curiosity mixed with confusion. Many people sense that it’s important, but struggle to clearly articulate what problem it actually solves, how it differs from existing semantic layers, and why it suddenly matters so much now in a post-AI world.

On the surface, this is understandable. For years, data platforms have been steadily improving at what they’re already good at: storing more data, processing it faster, and exposing it through datasets and semantic layers. But the industry has largely treated data as a technical problem to be optimized.

Fabric IQ challenges that framing.

It doesn’t primarily target performance, scale, or even analytics. Instead, it goes after something far more uncomfortable and long ignored: meaning. More specifically, the gap between how businesses think about their operations and how those operations are represented in data systems.

Press enter or click to view image in full size

In this article, we will explore:

• Why data hasn’t solved decision ambiguity
• What the semantic meaning problem really is (and why AI exposes it)
• The limits of traditional semantic models
• How ontologies attempt to bridge that gap

To understand why this matters, let’s start with a situation every large organization has experienced at least once.

The Semantic Meaning Problem

There’s a moment that happens in most large companies. Someone asks a simple question like “What’s our inventory level?” and then the room goes quiet.

This does not mean that the data doesn’t exist. In fact, the company has databases full of inventory data.

• Real-time feeds from warehouses.
• Spreadsheets maintained by regional managers.
• API connections to suppliers.

The data is abundant and actually overwhelming.

The silence comes because no one is quite sure which answer is the right one. The finance team has one number. Operations has another. The forecasting model uses a third definition that excludes certain categories. Each is correct within its own context, each is measuring something real, but they’re not measuring the same thing.

And this is the meaning problem.

We’ve spent the last two decades solving the storage problem. We moved from constrained data warehouses to data lakes, then to the hybrid efficiency of lakehouses. We can now store petabytes cheaply and query them fast. The infrastructure works now but it was never the hard part.

The hard part is that Inventory means different things to different parts of the business. And when you deploy an AI agent to optimize inventory, it has to choose. It has to decide which definition matters, which relationships are real, and which actions are permitted.

Press enter or click to view image in full size

Without that semantic grounding, the agent does what large language models do when they lack context: it guesses. Sometimes it guesses right but often enough, it doesn’t. If you’ve spent enough time using LLMs, you know exactly what I mean here.

So the current AI struggles aren’t really about model size or compute power. Most models are extraordinarily capable. The bottleneck is simpler and older: we haven’t given our AI systems a semantic understanding of what our businesses actually mean by the words we use.

What Businesses Actually Think About

Unless you’re a data professional, no one talks about tables. Business stakeholders talk about their operations in terms of meaning, context and relationships between entities.

An airline operations manager doesn’t think in terms of dim_flight_schedule joined to fact_crew_assignments. She thinks about flights. About which pilots are certified for which aircraft. About how weather at one airport cascades through the network. About turnaround times and maintenance windows, and so on…

These are entities with properties and relationships. A flight has a status, a location, a crew. It connects to gates, which connect to ground service equipment, which connect to maintenance schedules. The business operates in this network of meaningful objects, not in normalized schemas.

This disconnect matters more now than it used to. When the primary consumer of data was a data analyst building a dashboard, the translation layer was in their head. They knew that table XYZ actually represented customer segments, even if it was named in a confusing way. They could navigate the schema because they understood the business.

But AI agents don’t have that luxury. They can’t ask a colleague “Hey, which table actually has the current supplier status?” They work with what they’re given. And if what they’re given is a collection of tables with technical names and undocumented relationships, they’re not getting the real meaning and context.

Now the issue is that this problem compounds. In a typical large company, the concept of customer might exist in dozens of tables across different systems.

• CRM has one version.
• Billing has another.
• Marketing has several.
• Support has ticket-holders who may or may not be paying customers.

Each system was built to solve a specific problem, and each has a slightly different answer to what seems like a simple question: who is our customer?

And to be fair, it’s the natural result of systems evolving independently to serve different needs. The fragmentation is real and, in most cases, was probably the right choice when each system was built.

But it creates a problem when you try to deploy any sort of AI intelligence.

An agent asked to improve customer satisfaction has to first understand: what do we mean by customer, and where is the authoritative source?

The traditional answer has been: well, the human in the loop knows. The data analyst knows to check the CRM for contact info but billing for contract status. The operations manager knows that flight delayed in the scheduling system doesn’t mean the same thing as flight delayed in the customer notification system until certain conditions are met.

This works when humans are doing the reasoning. But it breaks when we ask software to reason for us. And this is mainly due to a lack of context.

The Translation Layer We’ve Been Missing

Power BI semantic models represented a real advance. They created a layer between the raw database schema and the business questions people wanted to ask.

Instead of writing SQL against table names, analysts could just drag Revenue onto a chart and trust that the measure knew which tables to sum, which filters to apply, which calendar to use, and so on…

This was the semantic layer’s first job: translate business language into database queries. But semantic models were designed for a specific use case: aggregation for reporting. They excel at taking millions of rows and collapsing them into totals, averages, trends.

They’re built around star schemas, optimized for slicing and dicing numerical data. The whole architecture assumes the end goal is a dashboard showing what happened.

But what semantic models weren’t designed for is reasoning about what’s connected to what, or enabling actions based on those connections.

Let’s consider an example:

A Power BI report might show: Average flight delay by airport. That’s an aggregation. It’s answering: given all these delay events, what’s the summary statistic?

But what an operations agent needs to answer is:

This specific flight is delayed. What gates are affected? Which connecting flights will passengers miss? What ground crews need to be notified? What’s the cascade effect on the next six hours of operations?

This goes beyond just an aggregation. That’s traversal.

It’s following relationships through a network of entities to understand impact. It requires knowing that Flight 1245 CONNECTS_TO Gate B7, which IS_SERVED_BY Ground Crew Team 3, who ARE_SCHEDULED_FOR five other flights in the next two hours, which CARRY passengers with specific CONNECTING_FLIGHTS.

Do you understand now?

You can’t answer that question with SUM() and AVERAGE(). You need to walk the graph of relationships. You need to know not just that data exists, but how it’s structurally connected in ways that mirror reality.

If I had to use an analogy, I would say that semantic models gave us the vocabulary. They taught the system that Revenue is a meaningful business concept. But they didn’t give us the grammar, the rules for how those concepts relate and interact. They were built for looking backward at what happened, not for reasoning forward about what might happen or what should happen next.

The gap isn’t in the technology of semantic models themselves. DAX is powerful and Star schemas are efficient. The gap is in what they were optimized for. They were built for the era when business intelligence meant helping humans understand what happened. But now we’re entering an era when intelligence means helping systems understand what to do.

That requires a different kind of semantic layer. Not one that translates questions into queries, but one that represents the business itself including its objects, its logic, its constraints, and its possibilities. We’re moving beyond the reporting layer to create a reasoning layer.

This is what an ontology provides.

What is Ontology (And How It Works)

If we strip away the academic terminology, an ontology is something simple: a model of how your business actually works.

Not how your databases are organized. Not how your org chart flows. But how the business actually operates, in terms of the objects that matter and how they connect.

In an airline, that means: there are flights. Flights have crews. Crews have certifications. Aircraft have maintenance schedules. Airports have runways. Runways have conditions. Weather affects conditions. Conditions affect which runways can be used. Runway availability affects gate assignments. Gate assignments affect turnaround times. All of it connects.

Press enter or click to view image in full size

An ontology makes these connections explicit. It says: here are the entity types that matter to our business. Here are the properties that define each entity. Here are the relationships between them, and here’s what those relationships mean. Here are the rules that govern how they interact.

The shift from semantic model to ontology is the shift from describing data to describing reality.

A semantic model might define Flight as a table with columns: flight_number, departure_time, arrival_time, status. That’s useful for reporting.

An ontology defines Flight as an entity that DEPARTS_FROM an airport, ARRIVES_AT another airport, IS_OPERATED_BY an aircraft, HAS_ASSIGNED a crew, CONNECTS_TO other flights. Those relationships aren’t just foreign keys. They’re semantic statements about how the world works.

The relationships carry verbs. Not just Flight relates to Airport but Flight DEPARTS_FROM Airport and Flight ARRIVES_AT Airport. The difference matters because an AI agent reasoning about a delay needs to know which airports are affected in which ways. The departure airport needs different notifications than the arrival airport. The relationship type tells you that.

Properties in an ontology can be more than static fields. They can be time-series data (temperature readings from sensors), geospatial data (current location), derived calculations (estimated arrival based on current speed and weather), or even action triggers (if temperature exceeds threshold, alert maintenance).

Rules codify the business logic that used to live in people’s heads or scattered across application code.

• A pilot cannot be assigned to more than one flight at the same time.
• A runway cannot be used if visibility is below 400 meters.
• If a flight is delayed more than 30 minutes, passengers with connections under 45 minutes must be rebooked.

This goes beyond just validation rules. They’re the operating principles of the business. What makes this different from previous attempts at business modeling is the shift in why we’re doing it.

Ontologies in Fabric IQ are operational. They’re not documentation of the business. They’re the substrate that powers AI agents, real-time monitoring, and decision support. When you update the ontology to reflect a new business rule, that rule immediately affects every agent and system consuming it.

This is why ontologies matter now in a way they didn’t ten years ago. The use case has changed. We’re no longer trying to help analysts retrieve the right data to answer a question. We’re trying to help autonomous agents reason about complex situations and take appropriate action.

1. Retrieval is about finding information.
2. Reasoning is about understanding implications.

When a temperature sensor in a refrigerated truck reports 8°C instead of the required 4°C, retrieval can tell you that’s above threshold.

Reasoning tells you: this shipment contains vaccines, the customer is a hospital with a just-in-time order, the spoilage window is 6 hours, the nearest backup inventory is at warehouse B which is 3 hours away, the hospital has an SLA requiring 4-hour notification of delays, and therefore the correct action is to initiate replacement shipment from warehouse B and send notification to the hospital procurement team.

Do you see the pattern now?

That chain of reasoning requires an understanding of not just that these entities exist but how they meaningfully connect.

This is the shift from retrieval to reasoning. And it’s what makes ontologies essential infrastructure for AI rather than an interesting academic exercise.

How Fabric IQ Works (And How to Get Started)

As of the time of writing this (January 2026), Fabric IQ is still relatively new. The product is in preview, patterns are emerging but not established, and real-world production deployments are limited. But like any MS release, you can expect things to evolve significantly over the coming months with the feedback of the community.

Press enter or click to view image in full size

The core idea is straightforward: if you have Power BI semantic models, you can generate an ontology from them. The system reads tables as entity types and relationships as edges. What was structured for reporting can also becomes structured for reasoning.

Press enter or click to view image in full size

This seems useful as a starting point, though it’s worth noting that the generated ontology inherits whatever structure your semantic model had, including its limitations. If relationships were ambiguous or entities poorly defined, those issues transfer.

The ontology can bind to multiple types of data:

• Static data from lakehouses through column mapping (straightforward table-to-entity binding)
• Real-time streams from Event House. This would let you combine historical context with current state in the same model.
• Geospatial data
• Operational systems for write-back

How well these integrations work in practice, especially the write-back scenarios, isn’t fully clear from available information. The demos show read scenarios but operational write-back seems more theoretical at this stage.

The implementation uses a Labeled Property Graph model with GQL (Graph Query Language) as the query interface. GQL is a new ISO standard, which suggests some intent toward interoperability rather than lock-in.

Press enter or click to view image in full size

The architecture appears to federate rather than centralize. When you query the ontology, the engine supposedly pushes work to specialized engines like KQL for time-series aggregations, or SQL for dimensional joins, rather than moving all data into graph structures.

This would matter for cost and performance if it works as described. You wouldn’t be duplicating your entire data estate. But federated execution also introduces complexity because query performance depends on multiple engines and how well the optimizer distributes work.

Potential Use Cases

Certain scenarios seem like natural fits for Fabric IQ:

1. Cross-domain questions that span multiple data systems.

If you need to traverse from customer engagement (CRM) to order fulfillment (ERP) to support interactions (ticketing system), and these live in separate domains with separate semantic models, the ontology could provide unified traversal.

Whether this actually works better than well-designed data integration is an open question. The value would depend on how often you need cross-domain reasoning versus domain-specific analytics.

2. Network-shaped relationships.

Supply chains, infrastructure systems, organizational structures, basically anything where entities connect in complex patterns rather than clean hierarchies. Graph models handle many-to-many relationships and recursive structures more naturally than star schemas.

Again, the question is whether your specific use case needs this. If your relationships are mostly simple one-to-many, the additional complexity might not pay off.

3. Combining real-time and historical data for operational decisions.

A maintenance agent that needs both equipment history (lakehouse) and current sensor readings (event stream) to decide when to schedule service. Or inventory optimization that combines sales patterns (historical) with current stock levels (real-time).

The value here would be in having one model that spans both temporal domains rather than maintaining separate views.

What Remains Unclear (For Now)

Several important questions don’t have clear answers yet:

• How does schema evolution actually work?

When source systems change for example: tables get renamed, columns split, data types modified. What breaks? How do you manage ontology updates without disrupting consuming systems?

Documentation suggests manual binding updates. Whether there are tools to detect drift or manage migrations isn’t clear.

• What’s the performance envelope?

How do complex graph queries over federated sources actually perform at scale?

The demos show small datasets. Production scenarios with billions of rows across multiple engines are less documented. I hope we will get more community feedback in the future.

• How do you version and test changes?

The preview version apparently lacks built-in version control. You export to JSON and manage externally. This seems workable for experimentation but unclear for production operations where changes need testing before deployment.

• How does multi-agent write-back actually work?

The vision of agents coordinating through the ontology implies bidirectional sync with operational systems. The mechanics of keeping the ontology in sync with source systems that agents modify aren’t well documented.

The Broader Pattern

About the author

Y, Mahboub (09/07/2026) Microsoft Fabric IQ and the Future of Semantic Models. Microsoft Fabric IQ and the Future of Semantic Models | by Mahboub Yassine | Medium