Enterprise data often describes the same customer, product, order, asset, location, or service differently across systems. A report can hide that fragmentation behind one curated model. An AI agent answering cross-domain questions must resolve identity, terminology, properties, and relationships across a wider operational context. Without governed semantics, fluent answers can connect the wrong things.
Datrick treats Fabric IQ Ontology as a controlled semantic product, not a diagramming exercise. AI can accelerate candidate entity discovery, terminology mapping, relationship extraction, source profiling, question generation, and failure classification. Domain owners approve meaning and authority; engineers bind the model to tested data; evaluation proves whether the ontology improves the intended agent use case.
Do multiple teams and agents use different meanings for the same business entity? Start with one domain and the questions that require connected context.
Select a use case that needs an ontology
Choose questions that span entities, relationships, time, and multiple governed data products: customer exposure across contracts and service incidents, asset dependencies and maintenance risk, supplier orders and delivery disruption, product inventory and demand, or account relationships across sales and support. Define user, decision, source systems, expected graph traversal, business value, risk, and deterministic answer.
Compare the ontology approach with simpler alternatives. A single semantic model, governed view, Data Agent source instruction, or explicit API may solve a bounded question with less complexity. The pilot should prove that cross-domain consistency, relationship reasoning, reuse, or agent grounding creates material value beyond those options.
Build an accountable ontology design contract
| Design domain | Evidence | Decision |
|---|---|---|
| Business vocabulary | Terms, definitions, synonyms, prohibited conflations, source terminology, owners, and examples. | What does each concept mean, and who can approve that meaning? |
| Entity identity | Keys, natural identifiers, survivorship, duplicates, history, source authority, and lifecycle. | When are two records the same business thing? |
| Properties | Type, unit, allowed values, derivation, quality, sensitivity, temporality, and source field. | Which attributes are stable, calculated, sensitive, or context-dependent? |
| Relationships | Direction, cardinality, validity period, business rule, source evidence, confidence, and owner. | How are entities connected, and when is that connection valid? |
| Source binding | Fabric items, tables, semantic models, joins, refresh, lineage, permissions, and reconciliation. | Which governed data proves each entity, property, and relationship? |
| Consumption | Data Agents, graph exploration, Copilot Studio, Foundry, MCP tools, users, questions, and service levels. | Which supported experience consumes the ontology, under what identity and limitation? |
| Governance | Versions, environments, review, change impact, testing, deployment, monitoring, incidents, and retirement. | How does semantic change reach production without breaking consumers? |
Start narrow. Define only entities and relationships needed by the selected decisions. An enterprise-wide model created before real questions often becomes abstract, disputed, and unmaintained. Establish naming conventions, modeling principles, ownership, acceptance tests, and a process for unresolved semantic conflict.
Bind business meaning to governed data
Profile candidate OneLake sources and Power BI semantic models for keys, duplicates, nulls, relationships, historical behavior, quality, latency, sensitivity, and ownership. Map ontology entity types and properties to authoritative fields. Test relationship cardinality and orphan behavior. Record transformations and avoid binding the same concept to conflicting sources without an explicit authority rule.
Microsoft provides paths to begin from an existing semantic model or OneLake data. Treat generated or inferred structure as a draft. A technical relationship does not automatically represent the business relationship an agent should use. Domain experts must approve identity, meaning, temporal validity, and exceptions.
Design security and preview boundaries
Fabric IQ Ontology capabilities are currently preview and can change. Record region, capacity, item, integration, deployment, API, permission, and support assumptions. Define a production decision gate and an exit path that preserves source models, definitions, tests, and business documentation if preview behavior changes or does not meet requirements.
Test ontology and connected-agent access with representative personas. The ontology must not become a path around source security, RLS, CLS, sensitivity, restricted access, or Purview policy. Document how identities flow through Fabric Data Agents, Copilot Studio, Foundry, or MCP integrations, and verify negative access outcomes end to end.
Prove agent improvement with matched evaluation
| Evaluation dimension | Matched test | Failure example |
|---|---|---|
| Entity resolution | Ask questions using identifiers, synonyms, partial names, duplicate records, and historical identities. | Agent merges two customers or treats one renamed asset as two entities. |
| Relationship traversal | Test approved paths, direction, cardinality, multi-hop questions, missing links, and temporal validity. | Current supplier relationship is applied to a historical order before the contract existed. |
| Source and metric correctness | Compare selected sources, queries, measures, filters, periods, and results with deterministic controls. | Ontology context is correct but the agent uses a non-authoritative revenue source. |
| Security | Run the same graph questions across permitted, restricted, external, and application identities. | A relationship reveals existence of a restricted account even when properties are hidden. |
| Ambiguity and scope | Test conflicting definitions, missing time, unsupported actions, incomplete relationships, and expected clarification. | Agent chooses one regional definition of active customer without asking for scope. |
| Comparative value | Run matched questions against ontology grounding and the simpler baseline. | Ontology adds latency and maintenance but does not improve correctness or supported coverage. |
| Change resilience | Repeat after source schema, semantic model, relationship, instruction, permission, or product changes. | Binding silently breaks and the agent falls back to an incorrect source. |
Version question, persona, expected entities, traversal, source, query, result, data snapshot, narrative, prohibited content, and score. Include positive, negative, ambiguity, missing-data, stale-data, and malicious-data tests. Require a measurable improvement in correctness, coverage, or user effort before expanding the ontology.
Govern semantic change as production change
Every entity, property, relationship, binding, and definition change can alter agent answers. Require an owner, reason, impact analysis, review, test, deployment record, rollback, and communication. Monitor binding failures, orphan rates, source freshness, entity duplication, agent errors, low-confidence questions, access failures, and user corrections.
Establish a domain steward and technical owner. Review the ontology with data-product owners rather than creating a central team that changes business meaning alone. Expand to adjacent domains only when ownership, reuse, quality, evaluation, and maintenance cost support it.
Run a four-to-six-week ontology pilot
- Select one domain, high-value questions, users, sources, accountable experts, agent consumer, baseline, and measurable success criteria.
- Assess whether an ontology is justified compared with a semantic model, governed view, source instructions, or explicit application logic.
- Define business vocabulary, entity identity, properties, relationships, temporal rules, sensitivity, owners, and unresolved conflicts.
- Profile and prepare authoritative Fabric sources, then bind the ontology and reconcile representative entity and relationship data.
- Connect a Fabric Data Agent or supported pilot consumer under representative user permissions and documented preview constraints.
- Create matched baseline and ontology-grounded evaluation suites for correctness, security, ambiguity, latency, and utility.
- Run the pilot, classify failures, improve the durable semantic or source layer, and repeat the tests.
- Deliver the ontology, glossary, binding map, source controls, evaluation suite, security model, governance workflow, limitations, backlog, and scale/hold/stop recommendation.
Frequently asked questions
What is an ontology in Microsoft Fabric IQ?
A Fabric IQ Ontology is a business-semantic model that defines domain entities, their properties, relationships, and source bindings. It provides a shared vocabulary and connected business context over data in Fabric. Ontologies can support graph exploration and serve as a grounding source for supported Fabric and Copilot agent experiences.
When should an organization use a Fabric IQ Ontology?
Use an ontology when important questions require consistent business entities and relationships across multiple data products or processes, and when agents or users need more context than a single table or semantic model provides. Do not create one merely to rename columns. Start with a bounded domain, measurable questions, accountable subject-matter experts, and suitable governed data.
Can Fabric IQ create an ontology from a Power BI semantic model?
Microsoft provides paths to shape an initial ontology from an existing Power BI semantic model or OneLake data. This can accelerate entity and relationship discovery, but generated structure still needs business review. The ontology must represent approved business identity, meaning, relationships, source authority, cardinality, quality, security, and lifecycle rather than simply mirror technical metadata.
How do you evaluate whether a Fabric IQ Ontology improves an AI agent?
Build matched question sets with and without ontology grounding. Measure entity resolution, relationship traversal, source selection, query correctness, calculation accuracy, security, explanation, ambiguity handling, reproducibility, latency, and user utility against deterministic expected results. Inspect failures and require a material improvement over a simpler semantic model or data-agent baseline.
How long does a Fabric IQ Ontology pilot take?
A bounded discovery, ontology design, source binding, and Data Agent evaluation pilot can often be completed in four to six weeks for one domain when owners, business vocabulary, representative sources, permissions, and target questions are available. Broader enterprise ontology work takes longer and should expand only after the first domain demonstrates maintainable value.
Official implementation references
- Microsoft Fabric IQ overview
- Microsoft Fabric IQ learning path
- Microsoft Fabric IQ product overview
- Microsoft Fabric IQ Ontology and Copilot Studio integration
- Microsoft Fabric Data Agent concepts
Start with one domain where agents need connected business context that current models cannot provide consistently. Datrick can design the ontology, bind governed data, evaluate the agent, and define a defensible expansion decision.