Building an Ontology in Microsoft Fabric IQ: A Practitioner’s Approach

A data platform on its own is tables and relationships that a machine understands structurally but not meaningfully. It knows a column joins to another; it does not know that this represents an order placed by a customer and fulfilled from a plant. An ontology is the layer that adds that meaning — the model of how your business actually fits together.

This matters more in the agentic era than it did for dashboards. A report author brings the business meaning in their head; an AI agent does not. Point an agent at raw tables and it infers structure and guesses meaning, inconsistently. Fabric IQ's ontology is what gives the agent your actual business context to reason from, so its reasoning follows how the business works rather than how the tables happen to be shaped.

So building an ontology is not a modelling nicety — it is the prerequisite for agents and people to reason over shared meaning instead of each reconstructing it. That is the whole point of Fabric IQ.

An ontology has three things: entities, relationships and measures. Entities are the nouns of your business — order, customer, product, plant, shipment, supplier. Relationships are how they connect — an order belongs to a customer, is made at a plant, contains products. Measures are how you quantify them — OEE, OTIF, margin, fill rate — each with one definition.

The value is in the consistency. When "plant" is one entity everyone references, when OEE is defined once and inherited everywhere, an agent asked about plant performance by two different people gives the same answer, and a dashboard and an agent agree because they read the same definition. The ontology is the single place that meaning lives.

It sits on top of your unified data, not instead of it. The ontology models meaning; OneLake holds the data; the two together let Fabric IQ expose a business the platform can reason over. Neither works without the other — meaning over fragmented data is a confident fiction, and unified data without meaning is just a bigger pile of tables.

Here is the part teams underestimate: modelling the entities is the easy half. The hard half is getting the business to agree what they mean. Finance, operations and supply chain each have a definition of OEE or margin, and they differ — that is exactly why your numbers disagree today. An ontology forces one definition, which means someone has to decide, and that is a business negotiation, not a technical task.

Treat definition-setting as the core of the project, not a preliminary. Bring the business owners together, surface where definitions fork, and get a decision on each measure that matters — with a named owner accountable for it. The technical modelling then encodes decisions that have already been made, which is straightforward. Skip this and you encode the ambiguity, and the ontology inherits the chaos it was meant to fix.

This is also why an ontology cannot be outsourced wholesale to a vendor. A partner can facilitate, model and build, but the definitions must be owned by the business, because only the business has the authority to say what OTIF means for the business. Our role is to run that process and encode the outcome, not to invent the meaning.

The instinct with an ontology is to model the whole enterprise before anyone uses it. That is the way to spend a year and ship nothing. Build it incrementally, starting from the decisions and questions that matter most — the ones an agent or a dashboard needs to answer — and model only the entities, relationships and measures those need.

This keeps the work anchored to value and gets a usable ontology into people's and agents' hands quickly, which is also how you validate that the definitions are right. Each new use case extends the model with the entities and measures it requires, and the ontology grows in the direction of what the business actually asks of it rather than an abstract completeness.

Assign ownership as you go. Every entity and measure needs a business owner who keeps its definition current, because an ontology, like any shared model, drifts without stewardship — and a drifted ontology reintroduces exactly the disagreement it removed.

Build a Fabric IQ ontology in this order: unify the data in OneLake first, because the ontology reasons over a single foundation; start from the decisions and questions that matter, not an enterprise-wide model; run the definition negotiation with the business and assign owners; encode the agreed entities, relationships and measures; then connect agents and analytics to reason over it, extending incrementally as new use cases arrive.

The mistake that wastes the most time is treating it as a technical modelling exercise. The modelling is the encoding; the substance is the agreement on meaning, and that needs business authority and facilitation more than it needs a data modeller. Budget the project accordingly.

Done well, the ontology is the asset that makes every subsequent AI use case cheaper and more trustworthy, because they reason from shared meaning instead of rebuilding it. That is why Fabric IQ is a foundation for agentic operations, not a reporting feature — and why the definitions are worth the argument.