TL;DR
Fabric ontology is the Microsoft Fabric IQ item that turns enterprise data into a shared model of the business. It defines things like Customer, Order, and Asset once, with their properties and relationships. It then binds those definitions to real data in OneLake, including lakehouse tables, eventhouse streams, and Power BI semantic models, without copying anything. A built-in graph and a natural language query layer let people and AI agents ask questions in business terms. Fabric IQ became generally available at Microsoft Build 2026, but the ontology item itself is still in preview. Start with one business decision, generate a first draft from a trusted semantic model, and plan around the preview limits.
Key Takeaways Fabric ontology is an item in the Fabric IQ workload that models entity types, properties, relationships, and rules, then binds them to data already in OneLake. Fabric IQ reached general availability at Build 2026, while the ontology item remains in preview with no versioning and manual refresh. Each entity type takes one static binding from OneLake plus any number of time series bindings from eventhouses or lakehouses. A first ontology can be generated from a Direct Lake Power BI semantic model, but keys, time series, and relationship bindings still need hands-on work. Data agents, operations agents, Foundry IQ, Copilot Studio, and any MCP client can use the same ontology as their source of business meaning. Kanerika used a governed Fabric ontology to standardize 85+ KPIs for a global pharma enterprise and cut investigation time by 70%. Watch on YouTube
Fabric IQ Explained: Business Context for AI Agents
A short Kanerika walkthrough of how Fabric IQ gives AI agents the business context they are missing, which is exactly the job the ontology item does inside Microsoft Fabric.
Why Microsoft Put an Ontology at the Center of Fabric IQ “AI is only as good as its understanding of your business.” The Microsoft Fabric team wrote that line in its own FabCon 2026 update on Fabric IQ ontology . It also explains why the ontology item exists at all.
Most enterprises already solved where their data lives. OneLake, shortcuts, and mirroring put sales, supply chain, and sensor data in one governed place. What stayed scattered is meaning. The definition of an active customer or a late shipment still lives inside individual dashboards, SQL views, and people’s heads.
An AI agent cannot read those heads. Instead, it sees tables and columns, guesses at what they mean, and answers with confidence either way. The Fabric ontology gives that agent, and every analyst next to it, one agreed model of the business to reason over. That is why getting it right matters more than any single report.
What Is Fabric Ontology? Fabric ontology is a Microsoft Fabric item that stores a machine-readable model of the business. The official ontology overview frames it as the enterprise vocabulary and semantic layer that unifies meaning across domains and OneLake sources. It sits inside the IQ workload, next to Power BI semantic models, graph, data agents, and operations agents.
The Ontology Item in Plain Terms An ontology answers three questions about a business. What things exist, what facts describe them, and how they connect. In Fabric, therefore, those map to entity types, properties, and relationship types.
The item then does two more jobs that a diagram on a whiteboard never could. It binds each definition to live data in OneLake. It also builds a queryable graph from those bindings, so people and agents can ask business questions instead of writing joins.
A catalog of concepts. Product, Order, Plant, Sensor, and Route are each defined once and reused everywhere.Data bindings. Each concept points at the lakehouse table, eventhouse stream, or semantic model that holds its data.A graph. Related instances are linked as nodes and edges for exploration, lineage, and traversal.A query surface. Questions start from concepts, not tables, and can run across several sources at once.Where Ontology Sits Inside Fabric IQ Fabric IQ is one of four context layers under Microsoft IQ, alongside Work IQ, Foundry IQ, and Web IQ. Microsoft’s Fabric IQ documentation splits it into three layers. OneLake is the unified data layer, Power BI semantic models are the business intelligence layer, and ontologies are the operational intelligence layer.
That layering matters for planning. The ontology does not replace the Fabric lakehouse or the semantic models above it. Instead, it sits on top of them, reads from them in place, and hands a consistent picture of the business to the agents above it. For the wider context on the workload itself, Kanerika’s guide to Microsoft Fabric IQ covers the IQ layers in more depth.
Data flows up the stack in one direction. Source systems land in OneLake through pipelines, OneLake shortcuts , or mirroring. Bindings map that data onto entity types, the graph links instances, and agents query the result.
What a Fabric Ontology Is Not A Fabric ontology is not a copy of the data. Instead, bindings reference tables and streams where they already live, so there is no second store to reconcile.
It is also not a replacement for a Power BI semantic model. Semantic models still own measures, hierarchies, and fast report visuals, while the ontology owns shared definitions, relationships, and rules that cross domains. Kanerika’s breakdown of ontology vs semantic layer explains that split in detail.
Finally, it is not a finished, production-hardened product yet. That status question deserves its own section, because it shapes how far a team should go today.
Is Fabric Ontology Generally Available? Status, Settings, and Limits Fabric IQ as a workload is generally available, but the ontology item inside it is still in preview. At Microsoft Build 2026, Microsoft’s Azure data announcement declared Fabric IQ, graph, and operations agents generally available. The same post said ontologies were “expected to be generally available in the coming months.”
As of September 2026 the Learn pages for the ontology item still carry the preview label. As a result, that gap between the headline and the item is where most early projects misjudge risk, so it helps to see each component side by side.
Table 1: Fabric IQ Component Status (September 2026)
Component Status What it means for planning Fabric IQ (workload) Generally available since Build 2026 Commercially supported, runs on existing Fabric capacity Ontology item Preview, GA expected in the coming months Expect UI and behavior changes, design for rebuild Graph in Fabric Generally available Stable engine behind the ontology graph Operations agents Generally available Ontology as their knowledge source follows ontology preview status Fabric data agent Generally available Can add an ontology as a data source today Ontology in Microsoft Foundry and Agent 365 Preview Good for pilots, not yet for regulated production use
Tenant Settings and Capacity Prerequisites A Fabric administrator has to switch on the Enable Ontology item (preview) tenant setting before anyone can create an ontology. The required tenant settings page also lists separate settings for data agents and operations agents, including the Azure OpenAI and cross-geo processing options.
The workspace needs a Fabric-enabled capacity. Using the ontology as an MCP server needs a paid F2 or higher capacity, or a P1 or higher Power BI Premium capacity with Fabric turned on. Operations agents do not run on trial capacities. Sizing that capacity is covered in Kanerika’s guide to Microsoft Fabric capacity .
Preview Limits to Plan Around A handful of preview gaps change design choices, not just timelines. These come straight from the ontology FAQ , troubleshooting, and region pages.
No versioning. The item has no built-in version history, so change control has to come from Git integration and process.Manual refresh. New rows in upstream tables do not appear until the graph model is refreshed, either on a schedule or by hand.Region gaps. The Fabric region availability list currently shows the ontology item as unavailable in South Central US.Decimal columns. Graph does not support the Decimal type yet, so Decimal properties return null until they are rebuilt as Double.None of these block a well-scoped pilot. However, they do mean the first ontology should be treated as a learning asset, with the business definitions captured somewhere durable outside the item.
Datasheet
Microsoft Fabric Ontology for Governed Analytics and AI
Kanerika’s datasheet explains how a governed Fabric ontology standardizes KPIs across Power BI and grounds AI agents, with the delivery approach behind a global pharma rollout.
View the Datasheet → The Building Blocks: Entity Types, Properties, Relationships, and Instances Every Fabric ontology is built from four parts. Getting each one right early saves rework, because deleting a property removes it everywhere it is used, including keys and relationships.
Entity Types and Keys An entity type is the reusable model of a real-world concept, such as Shipment, Truck, or Freezer. It standardizes the name, description, identifiers, and properties for that concept, so every team means the same thing by “shipment.”
Each entity type needs an entity type key, the property or set of properties that uniquely identifies a record. In addition, keys must be string or integer values, and a missing key is the most common reason a graph comes out sparse. Names must be 1 to 26 characters, using letters, numbers, hyphens, and underscores.
Properties Properties are the named facts about an entity, each with a declared data type. The ontology supports integer, boolean, datetime, double, and string types, mapped from the matching lakehouse and eventhouse column types.
One useful detail most guides skip is untyped properties. By choosing Define at binding, a modeler can capture a business concept before anyone has found the source column. The data type is then set when the binding happens. Property names must also be unique across the whole ontology unless two properties share the same type.
Relationship Types A relationship type is a named, directional link between two entity types, such as Driver drives Truck or Store operates Freezer. Relationships can carry attributes and cardinality rules. They are what let an agent trace a chain like Order to Shipment to Sensor to cold chain breach.
Relationship names must be unique. A known issue with duplicate relationship names breaks natural language queries, so it is worth enforcing a naming convention from day one.
Entity Instances An entity instance is a concrete occurrence of an entity type, such as one specific store or one freezer. Instances are populated from data bindings, keep track of which source created them, and become the nodes in the ontology graph.
Semantic Enrichment Descriptions, synonyms, and key-value metadata can be added to entity types, properties, and relationship types. Microsoft’s semantic enrichment guide suggests adding units such as celsius or USD, sensitivity labels, and business owners.
However, there is a catch worth knowing before investing hours in it. The Fabric data agent does not use the enrichment fields today, and only entity types support synonyms. Enrichment mainly pays off for other agents and for human readers of the model.
How Data Binding Connects the Ontology to OneLake Data binding is where a Fabric ontology stops being a diagram and starts answering questions. A binding maps an entity type’s properties to columns in a real source and defines the key. It turns rows and events into governed business objects without copying the data.
Static Bindings Static data defines which instances exist, such as the list of stores and their attributes. Each entity type supports exactly one static binding, and it must come from a OneLake-backed source such as a lakehouse table.
As a result, that single-binding rule has a real design consequence. If customer attributes live in three systems, they need to be consolidated into one conformed table first. That is ordinary data engineering work, and it belongs upstream in the medallion architecture .
Time Series Bindings Time series data adds changing values over time, such as freezer temperature or machine vibration. It must be in columnar format, with one row per timestamped observation, and it can come from an eventhouse or a lakehouse.
In contrast to static data, an entity type can take several time series bindings from different sources. The static binding must exist first. A static key column has to exactly match a column in the time series data to connect the readings to the right instance.
Relationship Bindings Relationship types are bound to a mapping table that holds the keys of both entity types in each row. A table with StoreId and FreezerId is a typical example. The source and target entity types must already have keys defined, or the binding screen shows no keys to match.
Table 2: The Three Kinds of Data Binding in Fabric Ontology
Binding type Supported sources How many per entity type Key requirement Static OneLake-backed sources such as managed lakehouse tables One Defines the entity type key (string or integer) Time series Eventhouse or lakehouse, columnar with a timestamp column Several allowed A column must exactly match a bound static key Relationship A OneLake mapping table One per relationship type Both source and target keys present in each row
Binding Limitations to Check Before Starting Most failed bindings trace back to a short list of source table issues. The data binding documentation lists them, and they are cheaper to fix in the lakehouse than in the ontology.
Only managed lakehouse tables work, not external tables that show in the lakehouse but live elsewhere. Delta tables with column mapping enabled break the graph, and column mapping switches on automatically when column names contain spaces or characters such as commas and parentheses. Renaming a lakehouse table after mapping it can break access in the entity type details view. Unsupported data types need an ETL step to convert them before binding. Users need at least read access to the bound source, or the entity details view returns a 403 error. These checks fit naturally into an existing data quality framework , since they are really rules about table shape, naming, and access.
Generating an Ontology From a Power BI Semantic Model The fastest way to a first Fabric ontology is to generate it from a Power BI semantic model that the business already trusts. That approach starts from definitions people have argued about and agreed on, rather than a blank canvas. Once the semantic layer is in place, Power BI automation can handle refreshes, alerts and report delivery.
What Generation Creates According to Microsoft’s guide to generating an ontology , the process creates a new ontology item with one entity type per visible table. It adds static properties for each column with data bindings, plus relationship types that follow the model’s relationships.
The semantic model has to be published, its tables visible, and its relationships defined. Generation also does not work from My workspace, so the model needs to live in a shared workspace.
What Still Needs Hands-On Work Even so, generation gives a strong first draft, not a finished ontology. Time series properties are never created automatically, entity type keys need review, especially for multi-column keys, and relationship types still need data bound to them.
Measures and calculated columns do not come across as queryable data either. The business logic in DAX stays in the semantic model. That is one more reason the two items work side by side rather than one replacing the other.
Which Semantic Model Modes Work Mode decides how much of the generated ontology is usable. Import mode and DirectQuery mode models generate definitions but no data bindings, so the ontology comes out empty of data.
By contrast, Direct Lake models are the working path. Bindings are generated when the backing lakehouse sits in a workspace with inbound public access enabled, and relationship bindings need a primary key. Teams still on import models usually convert to Direct Lake semantic models first.
Clean the Model Before Generating Whatever is wrong in a semantic model carries straight into the ontology, and agents then repeat it at scale. Three competing definitions of an active customer become three conflicting answers delivered at machine speed.
Before generating, remove hidden helper tables that should not become entities and give tables business names. Also settle duplicate columns that share a name but not a type. Sound modeling habits from Power BI data modeling best practices and a clean star schema translate directly into a cleaner ontology.
The Ontology Graph and How Queries Reach the Data Every ontology comes with a graph built from its bindings and relationship types. The graph is what makes relationships first-class, so questions about connections do not depend on custom join logic buried in reports.
The Graph Child Item and Refresh Schedule Behind the scenes, the ontology creates a Graph in Microsoft Fabric child item in the same workspace. Nodes are entity instances, edges are relationship instances, and both keep lineage back to their source.
However, that graph only sees new source rows after a refresh. A schedule keeps it current, but every refresh uses capacity, so the schedule should follow how fast the business actually needs to see change.
GQL, KQL, and NL2Ontology Ontology queries start from entity types and can filter on properties, traverse relationships, and aggregate over time. The ontology layer routes each query to the most efficient engine, such as GQL for the graph and KQL for eventhouse data.
On top of that sits NL2Ontology, which converts a plain English question into a structured ontology query. Data agents and operations agents lean on that layer. It is what handles a question like “which stores had freezer humidity below 46 percent this week.”
Graph Versus Ontology Graph and ontology are separate items that work together. The ontology declares which things connect and why, while graph provides native storage and compute for nodes, edges, paths, and graph algorithms.
For example, teams that only need path finding or dependency analysis on connected data can use graph on its own. The ontology earns its place when those connections need shared business definitions, bindings to several sources, and grounding for agents.
Kanerika Service
Microsoft Fabric IQ and Ontology Services
Kanerika designs Fabric IQ ontologies, binds them to OneLake data, and connects them to data agents and operations agents, from a first pilot to governed production.
Explore Fabric IQ Services How AI Agents Use a Fabric Ontology The main reason to build a Fabric ontology in 2026 is to give agents a governed understanding of the business. Microsoft’s agent integration guide lists five ways to consume the same ontology, each aimed at a different audience.
Grounding in an ontology gives agents business meaning and consistency across teams. It also brings governance through the same bindings and access controls, and answers that are easier to explain. The broader case for why agents need this layer is covered in Kanerika’s look at ontology-driven AI agents .
Fabric Data Agent A Fabric data agent is the simplest path to conversational Q&A over an ontology. A team creates the agent in Fabric and adds the ontology as a data source. Users then ask questions whose answers reference entity types rather than raw tables.
Still, two setup details matter in practice. Microsoft’s tutorial adds the instruction “Support group by in GQL” to fix a known aggregation issue. The first few queries after creation can also fail while the agent initializes.
Operations Agent and Rules An operations agent watches the ontology continuously instead of waiting for a question. It is configured with natural language instructions, the ontology as its knowledge source, and optional actions. It then sends recommendations to Microsoft Teams for a person to approve or reject.
In addition, ontology rules add a lighter-weight option for alerting. Built on Fabric Activator, a rule monitors a time series property across every instance of an entity type. A typical rule flags a threshold exceeded over a time window, and each rule carries Activator costs. Both patterns pair naturally with Real-Time Intelligence in Microsoft Fabric .
Foundry IQ, Copilot Studio, and the MCP Server Developers can use the ontology as a knowledge source in Microsoft Foundry through Foundry IQ. That route suits custom agents that call tools and integrate with other systems. Makers can connect it to Copilot Studio through the Fabric IQ MCP tool for low-code agents.
Any other client can reach the ontology as a Model Context Protocol server. The ontology MCP server guide builds the endpoint from the workspace ID and ontology item ID. Tools such as VS Code in agent mode then connect to it.
Choosing the Right Agent for the Job Table 3: Which Agent Fits Which Ontology Job
Agent Best for Primary audience Practical note Fabric data agent Conversational analytics inside Fabric Analysts and business users Ignores enrichment fields today Operations agent Continuous monitoring and recommended actions Operations teams Needs Teams and a non-trial capacity Foundry IQ agent Custom agents with tool calling Developers Ontology knowledge source is in preview Copilot Studio agent Low-code conversational agents and workflows Business makers Connects through the Fabric IQ MCP tool Custom client via MCP Bringing external AI tools to the ontology Developers Requires F2 or higher, or P1 or higher
Most teams start with a data agent to prove the ontology answers real questions. They add an operations agent once one monitoring use case is clear. Building an agent on Azure AI Foundry makes sense when the answer has to trigger work in systems outside Fabric.
On-Demand Webinar
Model Context Protocol (MCP): The Key to Building Context-Aware AI Agents
An on-demand Kanerika session on how MCP connects AI agents to governed enterprise context, the same protocol a Fabric ontology exposes as an MCP server.
Watch the Webinar → Whichever agent is chosen, the quality of the answers comes back to the definitions underneath it. The same principle drives context engineering for agents more broadly, where the model is only as reliable as the context it is handed.
How to Build a Fabric Ontology Step by Step The steps below follow Microsoft’s ontology tutorial, extended with the checks that decide whether a pilot survives contact with real data. The running example is a retailer that wants to know which stores have freezers drifting out of range.
Step 1: Enable Tenant Settings and Pick a Workspace A Fabric administrator enables the ontology item setting plus the data agent settings the pilot needs. Use a shared workspace on a Fabric capacity, never My workspace, and confirm the ontology is available in the capacity’s region.
Step 2: Pick One Decision, Not One Domain Start from a business question that someone acts on, such as which freezers need a service call today. That decision points to the handful of entity types the pilot needs, instead of modeling an entire department up front.
Step 3: Generate From a Semantic Model or Build From OneLake If a trusted Direct Lake model already covers the domain, generate the ontology from it. If not, create an empty ontology item and add entity types by hand, binding them straight to lakehouse tables.
Step 4: Set Keys and Add Bindings Review every entity type key, then complete the static binding for each entity type. Add time series bindings next, such as freezer telemetry from an eventhouse, matched on the static key.
Step 5: Bind Relationship Types Create relationship types with clear, unique names such as Store operates Freezer. Bind each one to a mapping table that carries both keys, and check that the relationship shows up in the entity type configuration.
Step 6: Enrich the Model Add descriptions, synonyms, units, and owners to the entity types and properties agents will lean on. Keep descriptions to one to three sentences that start with what the thing represents.
Step 7: Refresh the Graph and Preview Instances Refresh the graph model, then open the entity type details to check that instances and relationships look right. A sparse graph almost always means a missing key or a mismatched key column.
Step 8: Connect an Agent and Test Real Questions Create a data agent, add the ontology as a source, and add the “Support group by in GQL” instruction. Test it with the actual questions from Step 2, and compare the answers against a report the business already trusts.
Step 9: Add One Rule and One Owner Add a single rule, such as an alert when freezer temperature stays above a threshold for a set window. Then name the person who owns each entity definition, because that ownership decides whether the ontology stays accurate after the pilot.
Microsoft’s open-source Ontology Playground is a useful place to sketch entity types and relationships with business stakeholders before anyone opens Fabric. It keeps the modeling conversation about the business rather than the tool.
Governance, Security, and Lifecycle for Ontology Items An ontology becomes shared infrastructure the moment a second agent depends on it. That means it needs the same access control, change management, and ownership as any other governed asset in Microsoft Fabric governance . Teams that also run Databricks face similar governance choices in a Unity Catalog migration .
Access Control and Private Link Ontology items support Fabric’s sharing and permissions experience, with granular read, edit, and reshare permissions, according to the Fabric team’s FabCon 2026 update. Azure Private Link is also supported, so traffic to ontology items can stay off the public internet at the tenant or workspace level.
Meanwhile, access to data is still enforced at the source. Users need read access to the lakehouse behind a binding, and modelers need at least Contributor rights in the workspace. Existing OneLake security design carries straight through.
Git Integration Without Native Versioning The ontology item has no version history of its own. Fabric’s Git integration lists ontology among the supported IQ items in preview. That gives teams a way to track changes, review them, and promote them across environments.
Pairing Git with Fabric deployment pipelines lets a team change definitions in development, test them against agents, and promote only what passed. Without that, a rename in production can silently break every agent that depends on it.
Teams that script their deployments can also work with the item directly. The Fabric ontology REST API includes operations to create an ontology and to get or update its definition, which makes definitions reviewable as code.
Who Owns the Definitions Tools do not decide what Customer means, people do. A workable ownership model assigns each role a clear job.
Business domain owner. Approves what each entity and relationship means and signs off changes.Data architect. Designs keys, bindings, and naming, and keeps the ontology aligned with the semantic models.Data engineer. Prepares conformed source tables and keeps bindings working as sources change.Data steward. Maintains descriptions, synonyms, sensitivity metadata, and data lineage records.Catalog and policy tooling such as Microsoft Purview still does the heavy lifting on classification and data loss prevention. The ontology adds business meaning on top of that governance, it does not replace it.
What a Fabric Ontology Costs in Capacity Ontology usage is billed against the existing Fabric capacity through meters described on the ontology capacity consumption page .
Table 4: Ontology Capacity Meters
Meter What it measures Published rate Ontology Modeling Definitions in use after any create, update, or delete, in windows of at least 30 minutes 0.0039 CU per hour per definition Ontology Logic and Operations Queries, graph exploration, and refresh compute 0.666667 CU per minute, not yet in effect (billed through graph usage today) Ontology AI Operations AI reasoning and natural language queries 400 CU seconds per 1,000 input tokens and 1,600 per 1,000 output tokens OneLake Cache Graph cache storage Same as OneLake Cache storage
Microsoft’s own worked example shows the scale. An edit to an ontology with 1,000 definitions consumes about 1.95 CU hours of modeling. An AI request with 2,000 input and 500 output tokens costs about 26.67 CU minutes, smoothed over 24 hours as a background job.
Keeping Ontology Costs Predictable In practice, the biggest lever is the graph refresh schedule, since every refresh consumes capacity. Batch modeling edits together so they fall inside the same 30-minute window, and watch the Capacity Metrics app during the pilot.
Similarly, associated items add their own costs too, including Graph, Activator for rules, and the agents themselves. Small F-SKUs can hit throttling quickly during demos, so pilots deserve a realistic capacity rather than the smallest one available.
Checklist
Microsoft Fabric Checklist
Work through capacity, security, governance, and data readiness items before switching on ontology and agents in a Fabric tenant.
Get the Checklist → When to Use Fabric Ontology Versus a Semantic Model Alone Not every Fabric estate needs an ontology yet. A skeptical thread on the r/MicrosoftFabric community questioned how many real implementations exist. The most useful reply made a fair point, that a strong star schema and semantic model go a long way.
Signs a Team Needs an Ontology An ontology earns its cost when questions cross domains and definitions. Typical signals are listed below.
The same metric returns different numbers depending on which dashboard or team runs it. Agents need to trace chains across sources, such as order to shipment to sensor. Real-time signals from an eventhouse need to be read in business terms, not device IDs. Several agents or tools need one shared definition of core entities. When Not to Build One Yet If reporting is the only goal and KPIs already agree, a well-governed semantic model is enough. Similarly, the same applies when source data is still unreliable, because an ontology amplifies whatever it sits on rather than cleaning it.
Teams in that position get more value from fixing the Microsoft Fabric architecture and semantic layer first. The ontology can then be generated from a model that deserves to become the enterprise definition.
When Databricks or Snowflake Are Also in Play Other platforms are building similar context layers, such as Databricks Genie with its business semantics and the Snowflake semantic layer . The deciding factor is usually where the governed data and the agents already live.
A Fabric ontology makes most sense when OneLake is the system of record for the domain, even if some data arrives through shortcuts or mirroring. Where the agents mostly run inside another platform, a native context layer there is usually the simpler first step.
AI Assessment
Is the Data Ready for an Ontology and AI Agents?
Kanerika’s AI maturity assessment scores data, governance, and platform readiness, so teams know whether to build an ontology now or fix the foundation first.
Start Your AI Assessment → Common Fabric Ontology Mistakes to Avoid Early Fabric ontology projects tend to stumble in the same places. Each one is avoidable with a little planning.
Modeling database tables instead of business concepts, which copies technical debt into the ontology. Generating from an import mode semantic model and wondering why no data appears. Modeling a whole department before one decision works end to end. Skipping entity type keys, which leaves the graph sparse and agents guessing. Forgetting that new source rows need a graph refresh before agents can see them. Launching without named owners, so definitions drift within a quarter. Fabric Ontology in Practice: How Kanerika Standardized 85+ KPIs for a Global Pharma Enterprise A global pharmaceutical enterprise with research, manufacturing, and commercial operations across regions had a familiar problem. Its KPI definitions and business rules lived separately inside individual Power BI dashboards. The same metric returned different numbers depending on who ran the report.
The Challenge Business users spent days on manual investigation and reconciliation to answer any question that crossed domains. The company wanted conversational AI on top of its data. Copilots had no shared business layer to draw from, so there was nothing consistent for them to answer against.
How Kanerika Delivered It Kanerika built a governed business ontology on Microsoft Fabric using the Fabric IQ ontology item. The work followed the same stages Kanerika uses on every Fabric IQ engagement.
Assess. Inventory the dashboards, KPIs, and semantic models, and find where definitions conflict.Design. Agree entity types, keys, and relationships with business owners before building anything.Bind. Connect entities, relationships, and KPI definitions to governed data in OneLake.Govern. Centralize business rules in the ontology so every report and query draws from one source.Enable. Extend the ontology into Fabric AI and Copilot so conversational analytics uses the same definitions as reporting.What Changed According to the published case study , the enterprise standardized more than 85 governed KPIs across Power BI. It also modeled over 40 entities and relationships across its main business domains. Investigation and reconciliation time fell by 70%, and cross-domain questions that took days now resolve in minutes.
The project also proved the Fabric IQ ontology could support governed analytics at enterprise scale, which gave the company a roadmap for broader adoption. The same foundation-first pattern shows up in Kanerika’s FoodPharma engagement published by Microsoft. There, unifying six systems on Fabric cut cross-functional reporting from two business days to about 90 minutes.
Case Study
70% Less Investigation Time With One Governed Ontology on Fabric
A global pharma enterprise standardized 85+ KPIs and modeled 40+ entities and relationships in a Fabric IQ ontology, so reporting and conversational AI share one set of definitions.
Read the Case Study → What Kanerika Teams Watch For The pitfalls on real engagements are rarely about the ontology editor. They are about source readiness. Typical examples are import mode models that need converting to Direct Lake, Decimal columns that need Double equivalents, and table names with spaces that trigger column mapping.
Kanerika is a Microsoft Solutions Partner for Data and AI. Its Fabric accelerators, including the Karl data insights agent that runs inside Microsoft Fabric, help teams move from a trusted OneLake foundation to agents that answer in business terms. More on that practice is on the Microsoft Fabric guide and the wider data ontology for AI agents guide.
Wrapping Up Fabric ontology gives Microsoft Fabric something it lacked, a shared, governed model of the business that agents can reason over. It binds entity types and relationships to data already in OneLake and builds a graph from them. The same definitions then serve data agents, operations agents, Foundry, Copilot Studio, and MCP clients. The item is still in preview, so the smart move is a narrow pilot built on a trusted Direct Lake semantic model. Name the owners, and record the definitions outside the tool. Get that foundation right and the ontology becomes the place every agent learns what the business means.
Frequently Asked Questions
Is the Fabric ontology item generally available? No. Fabric IQ as a workload became generally available at Microsoft Build 2026, along with graph and operations agents, but the ontology item inside it is still in preview. Microsoft said ontologies were expected to reach general availability in the coming months. Until then, expect interface changes, no built-in versioning, and manual graph refresh, and treat early ontologies as pilots that may need rebuilding.
What is the difference between Fabric ontology and Graph in Microsoft Fabric? They are separate items that work together. The ontology is a semantic layer that defines entity types, properties, relationships, and rules, and binds them to data. Graph provides native storage and compute for nodes, edges, paths, and graph algorithms. When an ontology is created, Fabric builds a graph child item from its bindings so instances and relationships can be explored and queried.
Can a Fabric ontology bind to data outside OneLake? Not directly. Static bindings must come from OneLake-backed sources such as managed lakehouse tables, and time series bindings come from an eventhouse or a lakehouse. Data held elsewhere first needs to reach OneLake, through pipelines, mirroring, or OneLake shortcuts. External tables that appear in a lakehouse but live in another location are not supported for binding.
Why do Decimal columns return null in a Fabric ontology? Graph in Microsoft Fabric does not support the Decimal type yet. When an ontology is generated from a semantic model with Decimal columns, those properties return null in every query. The workaround is to recreate the property as a Double type in the ontology and bind it to the source data, which lets the values show up in queries and agent answers.
Can a Fabric ontology be used as an MCP server? Yes. An ontology can act as a Model Context Protocol server so external AI clients and custom agents can query it. The endpoint is built from the workspace ID and the ontology item ID, then added to an MCP-compatible client such as VS Code in agent mode. It needs a paid F2 or higher Fabric capacity, or a P1 or higher Power BI Premium capacity with Fabric enabled.
Does the Fabric data agent use ontology descriptions and synonyms? Not today. Microsoft’s documentation states that the Fabric data agent does not use the semantic enrichment fields, meaning descriptions, synonyms, and key-value metadata. Those fields still help other agents that read the ontology, and they document the model for people. Clear, unique entity and relationship names matter more for data agent answer quality right now.
How much Fabric capacity does an ontology consume? Ontology usage is billed against existing Fabric capacity. The modeling meter charges 0.0039 CU per hour for each definition in use after an edit, AI operations charge 400 CU seconds per 1,000 input tokens and 1,600 per 1,000 output tokens, and the graph cache is billed as OneLake Cache storage. Graph refresh schedules are usually the biggest lever on day-to-day consumption.
Does Fabric ontology support versioning or Git? The ontology item has no built-in version history. Fabric Git integration lists ontology among its supported IQ items in preview, so teams can track changes in a repository, review them, and promote them with deployment pipelines. That combination is the practical substitute for versioning until Microsoft adds native version management to the item.
Can Eventstream data feed a Fabric ontology? Yes, indirectly. Eventstream data is landed in an eventhouse first, and that eventhouse table is then used as a time series binding source for an entity type. Microsoft’s ontology tutorial follows this pattern, binding freezer telemetry from an eventhouse to a Freezer entity type that already has a static binding and key.
How many static data bindings can an entity type have? One. Each entity type supports a single static binding, which defines its instances and its key, so attributes spread across several systems need to be consolidated into one conformed OneLake table first. An entity type can, however, take several time series bindings from different eventhouse or lakehouse sources once its static binding exists.
Do new rows in source tables appear in the ontology automatically? No. Updates in upstream sources, such as new rows, only become visible after the ontology’s graph model is refreshed. The graph child item can run on a refresh schedule, but every refresh uses capacity, so the schedule should match how quickly the business needs to see change rather than refreshing as often as possible.
