Fabric IQ Ontology V2: A Preview Briefing, Fact-Checked

On 25 September 2026, I watched a two-hour, 45-minute Microsoft product briefing on the next Fabric IQ Ontology experience.

The session called it Ontology V2. It showed a virtual semantic layer that can answer questions before a physical graph exists, direct reuse of Power BI semantic models, keyless entity types, inheritance, versioning, an ontology Copilot, and a wide set of downstream integrations.

Microsoft Learn does not describe all of that yet.

As of 26 September, the public docs still label the ontology item preview and describe the current graph-backed experience. The briefing said most of the new experience was planned for public preview the following week, with several capabilities arriving later. That leaves a short but important gap between the product team’s preview and the public contract customers can verify.

I kept two evidence ledgers while writing this:

Status	Meaning in this article
Documented	Available in current Microsoft Learn documentation
Previewed	Demonstrated or stated in the 25 September briefing, but not yet confirmed in public docs
Announced	Named in a Microsoft announcement without a current implementation guide
Roadmap	Planned; timing and scope can change

This article is a field report from that gap. It records what the team showed, checks the current documentation, and turns both into design guidance.

Preview briefing screenshot, 25 September 2026. Product names, scope, and release timing may change.

The architectural change: graph becomes a choice

The current ontology documentation says Fabric creates a managed Graph item when an ontology is created. Static source updates need a manual or scheduled refresh before the graph reflects them.

The V2 briefing showed a different execution model.

Under that model, an author defines the ontology, binds data, and can query it immediately through the built-in agent or MCP. Physical graph generation is configurable and off by default. When no graph exists, the agent federates queries to the native source engine. Lakehouse queries use SQL, Eventhouse queries use KQL, and semantic-model queries use DAX. When a materialized graph exists and suits the question, the agent can use it for graph traversal or multi-hop optimization.

Previewed capability. Current Learn documentation still describes an automatically created managed Graph item.

This addresses a real V1 constraint. Large fact and event datasets are poor candidates for mandatory graph indexing. A billion-row event table should not need full materialization before an agent can ask a useful question.

Configurable materialization also creates a query-planning problem that belongs in evaluation:

• Which source did the agent query?
• Did it choose federation or graph traversal?
• How many source calls did it make?
• What was the freshness point for each source?
• Did the answer change when graph materialization was enabled?

The product can hide that complexity from a casual user. A production team still needs the trace.

Power BI becomes a source, not only a starting template

Current Learn documentation supports generating an ontology from a Power BI semantic model. Tables become entity types, columns become properties, and modeled relationships become ontology relationships.

That generation path has sharp limits. Import and DirectQuery models can generate structure but not usable ontology data bindings. Direct Lake can generate bindings under documented network and source conditions. Measures and calculated columns are not queryable through those generated bindings.

The V2 briefing went further. It showed the ontology definition built as an extension of the semantic-model language, described in the session as TMSL/TMDL with ontology-specific additions. The stated goal was direct semantic-model binding, so DAX measures remain executable by the DAX engine while the ontology adds entities, relationships, rules, and metadata around them.

Previewed capability. The current public ontology documentation does not yet describe TMDL-based ontology authoring or first-class DAX measures inside ontology.

If this ships as demonstrated, teams will no longer need to choose between their analytical semantic model and a separate ontology model for the same domain. The ontology can reuse the Power BI investment and add operational semantics.

That still does not make the two models interchangeable.

Power BI measures encode analytical logic under filter context. Ontology relationships encode navigable business meaning. A Gross Margin measure and a Shipment delayedBy Carrier relationship solve different problems. A good enterprise model lets each engine keep its native job while exposing a shared vocabulary to the agent.

The acceptance test should include both:

1. Ask an analytical question whose answer depends on a governed DAX measure.
2. Ask an operational question that crosses from the measured entity into another source.
3. Inspect the generated queries and security context for every hop.

A fluent answer is not enough. The engine routing must be correct.

V2 loosens the model where operational data is messy

The current public experience expects entity keys for bound static data and uses a OneLake mapping table to bind relationships.

The briefing showed three changes aimed at operational domains:

• entity types that can be queried without a primary key;
• relationships across entities bound to different data sources;
• inheritance within an ontology, with cross-ontology reuse planned later.

Previewed capability. Keyless entities, inheritance, namespaces, and polymorphic query behavior are not in the current public Learn documentation.

These features matter because event and fact data often resist tidy entity modeling. A sensor observation may have a timestamp, device identifier, and reading but no single business key. A shipment may live in a Lakehouse while telemetry lives in an Eventhouse. A perishable product may inherit the common properties of a product while adding temperature rules.

The flexibility also raises questions the demo cannot answer:

• How does the runtime prevent duplicate or unstable instances for keyless types?
• Which join strategies are allowed across sources?
• How does inheritance affect security and query planning?
• Does a query for Product include every derived type?
• How are incompatible property definitions handled across namespaces?

The briefing said polymorphic query support and cross-ontology inheritance would come later. Until those semantics are documented, model inheritance as a preview experiment rather than a durable enterprise contract.

The ontology Copilot could change authoring more than querying

The current public integration story is already broad. Microsoft documents ontology consumption through Data Agent, Operations Agent, Foundry IQ, Copilot Studio, and the ontology MCP endpoint. The MCP path also supports GitHub Copilot and VS Code Agent Mode.

The briefing previewed a built-in ontology Copilot with a larger job:

• inspect semantic models, Lakehouses, and Eventhouses;
• draft an ontology from their schemas and metadata;
• apply requested naming, description, and relationship changes;
• update the ontology after source-schema changes;
• answer broad operational questions over the resulting model.

This could remove blank-page friction. It does not remove ontology design.

Source schemas reveal tables, columns, and joins. They rarely settle whether two departments mean the same thing by Customer, whether a shipment delay is observed or inferred, who owns a business rule, or when two similar concepts must remain separate.

The Copilot can propose structure. Domain owners still need to ratify meaning.

I would evaluate authoring in two passes:

Pass	Test
Structural	Did the Copilot bind the right sources, keys, types, and relationships?
Semantic	Did domain experts agree with the names, definitions, rules, and boundaries?

Then test whether the edited ontology improves downstream answers. A cleaner diagram that does not improve retrieval, reasoning, or abstention is cosmetic success.

The integration surface is becoming the product

The briefing positioned ontology as shared context for Data Agent, Operations Agent, Microsoft 365 Copilot, Microsoft 365 Copilot Cowork, GitHub Copilot, Foundry IQ, Copilot Studio, real-time dashboards, and custom applications.

Preview briefing screenshot. Data Agent, Operations Agent, Foundry IQ, Copilot Studio, and MCP have public documentation; the dashboard and Microsoft 365 experiences should be treated as previewed or announced until their implementation guidance is public.

MCP makes this more than a list of integrations. It gives custom agents a standard connection to the business model. The ontology can outlive any one agent host or model.

That is where the investment starts to compound. The first agent pays the modeling cost. The second agent reuses the vocabulary and bindings. The third agent exposes inconsistencies that the first project never found.

An enterprise ontology that serves one dashboard is an application model. An ontology that survives reuse across operations, analytics, development tools, and knowledge work is shared infrastructure.

Governance is still the uncomfortable gap

The briefing showed version history, restoration, ontology health, RDF interoperability, namespaces, and a V1-to-V2 migration experience. Current public documentation says versioning is not available, and I found no current Learn guidance for RDF import/export, namespaces, or V1 migration.

These may arrive with the new preview. Until they do, teams need an external release discipline:

1. Export or record the ontology definition before a material change.
2. Review source-binding changes separately from naming changes.
3. keep a regression set of representative business questions.
4. Re-run permission, freshness, latency, and answer-quality checks.
5. Record who approved the change and which evidence they reviewed.
6. Keep a tested rollback path.

Ontology health was described as a future loop that detects schema drift and quality problems, then hands them to Copilot for remediation. The first version would still require a user to trigger the check.

That sequencing is sensible. Automated repair without an approval boundary could allow a source-schema change to rewrite business meaning. A closed loop should propose and test a repair before a named owner publishes it.

The release status needs two clocks

Microsoft’s Build 2026 announcement said Fabric IQ reached general availability while ontology remained in preview. The 25 September briefing said the V2 experience was targeted for public preview the following week and ontology GA around the November Ignite timeframe.

Those statements can both be true.

The public documentation describes what customers can use under the current product contract. The briefing describes the team’s near-term release intent. Dates given in a preview session can move, so this article does not treat them as commitments.

The safest status summary on 26 September 2026 is:

Capability	Status
Current Fabric ontology item	Public preview
OneLake and Eventhouse bindings	Documented
Managed Graph in current experience	Documented and automatically created
Data Agent, Operations Agent, Foundry IQ, Copilot Studio, MCP	Documented
V2 virtual execution without graph materialization	Previewed for the next public update
Direct semantic-model binding through extended TMDL	Previewed
Keyless types, inheritance, namespaces, built-in versioning	Previewed
Microsoft 365 Copilot and Cowork scenarios	Previewed or announced
Ontology health automation, SDK, broader unstructured data	Later roadmap

This table will age quickly. Check the linked Microsoft Learn pages and Fabric roadmap before using it in a customer design.

What I learned

1. The graph should earn its cost

V1 treated graph generation as the path to ontology queries. V2 proposes federation first and graph materialization when traversal adds value. That is a better default for large event and fact data, provided the runtime exposes how it answered each question.

2. Power BI is part of the ontology strategy

Enterprises already hold valuable semantics in Power BI. Direct semantic-model reuse reduces duplication and keeps DAX in the engine designed to execute it. Ontology adds business relationships and operational context around that analytical core.

3. Flexible modeling increases the burden on evaluation

Keyless entities and cross-source relationships remove modeling blockers. They also make identity, duplication, join behavior, latency, and access control harder to reason about. Every new modeling freedom needs a corresponding test.

4. Authoring quality and answer quality are separate

An ontology can look coherent and still fail to improve an agent. Evaluate the model itself, then measure whether it improves context relevance, answer correctness, grounding, response time, and tool usage.

Microsoft reported a controlled internal study in which ontology-grounded agents produced more highly rated responses with fewer tool calls. That is useful evidence for running a customer benchmark, not evidence that a specific customer workload will improve.

5. Metadata only matters when the consumer reads it

Descriptions, synonyms, and custom metadata can sharpen the model, but current documentation says Data Agent does not use those enrichment fields. Test the exact agent and connector instead of assuming every consumer sees the same context.

6. Shared context needs source evidence

An ontology tells an agent what Shipment, Carrier, and TemperatureExcursion mean and how they relate. The answer still needs the records, timestamps, and source permissions that support the conclusion.

The useful contract is:

The ontology constrains meaning. The source data proves the claim.

7. Treat meeting transcripts as leads

The AI-generated notes were good enough to map the session. They were not good enough to publish unchanged. Some claims described future functionality, some mixed current and planned behavior, and some lost the distinction between a product announcement and a documented capability.

The same rule applies to AI research summaries. During this work, one search result cited a dead Learn URL and a learning repository as proof of shipped RDF and inheritance support. Opening the sources exposed the error.

I now use a three-step check for product claims:

1. Find the source that owns the capability.
2. Confirm the source says what the summary claims.
3. Record whether the claim is shipped, previewed, announced, or planned.

What I would test when the V2 preview appears

I would migrate a representative ontology rather than a showcase model. It should include a large fact table, Eventhouse telemetry, a Direct Lake semantic model with DAX measures, a cross-source relationship, unequal user permissions, and one schema change introduced after the first evaluation run.

The acceptance set should measure:

• answer correctness against expected results;
• source and query-engine selection;
• graph-on versus graph-off latency;
• tool calls and retries;
• security behavior for partial access;
• schema-drift handling;
• ontology changes proposed by Copilot;
• regression after a version restore;
• evidence attached to operational recommendations.

If V2 passes that test, Fabric ontology stops being a promising semantic diagram and becomes a credible shared context layer for enterprise agents.

Sources

1. Microsoft Learn: What is Fabric IQ?
2. Microsoft Learn: What is ontology (preview)?
3. Microsoft Fabric Blog: Fabric IQ, the shared context layer for AI agents and real-time applications
4. Microsoft Learn: Bind data to an ontology
5. Microsoft Learn: Generate an ontology from a semantic model
6. Microsoft Learn: Ontology glossary
7. Microsoft Learn: Ontology troubleshooting
8. Microsoft Learn: Add relationship types
9. Microsoft Learn: Add semantic enrichment with metadata
10. Microsoft Learn: Use rules with Fabric Activator
11. Microsoft Learn: Agent integration options
12. Microsoft Learn: Consume ontology as an MCP server
13. Microsoft Learn: Build a Foundry IQ agent grounded in an ontology
14. Microsoft Learn: Build a Copilot Studio agent grounded in an ontology
15. Microsoft Learn: Ontology frequently asked questions
16. Microsoft Fabric IQ Ontology product briefing and recording, 25 September 2026. Screenshots are cropped to remove attendee identities.