AI-generated content. This lesson was produced from model knowledge plus the cited public sources; its claims have not yet passed Fabric Codex human verification. Fabric IQ is a new and fast-moving product — verify against current Microsoft documentation.
Fabric IQ shipped in preview in late 2025, and Microsoft has published very little about its internals. This lesson covers only what is publicly documented or independently field-reported, and then names the open questions explicitly. It is deliberately short: at L4/L5, the honest material is thin.
What is documented about the execution architecture#
The ontology graph is materialized, not virtual. The queryable instance graph — nodes as entity instances, edges as asserted or derived links with metadata — is built on top of the separate Graph in Microsoft Fabric item, which must be enabled as a tenant setting before graph features work [S1]. Microsoft's entity-type-details documentation adds that creating an ontology item creates a Graph child item in the workspace, which stores and serves the instance data. So an ontology is not a view over your lakehouse: it is a second, dependent store whose contents are ingested from your bindings.
Query execution is federated and engine-routed. Ontology queries start from an entity type and let the caller filter by property, traverse relationships, and aggregate over time in business terminology; the ontology layer then routes execution to whichever backend holds the data — GQL against Graph in Microsoft Fabric, KQL against Eventhouse [S1]. The caller never addresses a storage engine directly. How that router plans a query spanning both engines is not documented (see the open-questions list below).
Refresh is explicit, full, and billable. Upstream data source changes — new, updated, or deleted rows — are not automatically reflected in the bound data or graph; they require a manual or scheduled refresh of the graph model before they become visible [S1]. Microsoft's refresh documentation (the "View entity type details" how-to) states two further mechanics worth internalizing: schema changes within the ontology (adding/editing/removing properties, types, relationships) automatically trigger re-ingestion of all currently bound data; and each graph refresh is a full refresh, with Microsoft explicitly recommending you batch updates rather than refresh per change because of the cost implications on the Graph item. Incremental refresh of the instance graph is not documented as existing. For capacity planning, this means refresh cost scales with total bound volume, not with delta size — an unusual profile for anyone calibrated on Delta/warehouse incremental patterns.
Field-reported failure modes (community, not Microsoft)#
These come from practitioner write-ups, not official docs — treat them as reproducible observations, not contracts.
- Asynchronous rebuild timing. One field report on building a data agent against a graph-backed ontology found that graph rebuilds complete asynchronously, so an agent can query the graph before a rebuild has landed [S2].
- Name-resolution sharp edges in generated GQL. The same report found the agent must use binding property names rather than display names in generated GQL, and hit a hidden requirement to prefix SQL objects with
dbo.that the agent otherwise omits [S2]. Both are the kind of impedance mismatch you should test for explicitly before trusting agent output. - Evaluation-layer artifacts. A community author inspecting the
evaluate_data_agentSDK found that part of an apparent agent accuracy weakness originated in the evaluation critic prompt itself — substituting a stricter custom critic prompt materially changed measured results with no change to the agent [S2]. At this depth, benchmark your benchmark: a community-built 72-question multilingual suite initially scored poorly, but a row-level audit traced many failures to faulty ground truth and ambiguous phrasing; after fixing the benchmark and tightening instructions, accuracy measured about 97.2% [S2].
One documented governance fact matters operationally here: Graph and the operations agent are shared with the Real-Time Intelligence workload [S3], so the Graph item your ontology depends on is not exclusively "yours" — its settings, cost, and lifecycle sit at a workload intersection.
What Microsoft hasn't documented yet#
The following are open questions as of this writing. Nothing below should be assumed, estimated, or extrapolated — these are the gaps to watch the docs for, and to raise with Microsoft if they gate your design.
- Graph storage internals. How Graph in Microsoft Fabric physically stores, partitions, and indexes nodes and edges; whether it is backed by OneLake Delta or a separate engine format.
- Scale limits and quotas. Maximum entity types, instances, edges, or bindings per ontology; graph size limits; concurrent query limits. No published numbers.
- Refresh performance. Expected duration or throughput of a full graph refresh at any scale, and whether incremental refresh is planned. Only the full-refresh behavior and its cost warning are documented.
- Capacity consumption. CU rates for ontology operations, graph refresh, GQL queries, or NL2Ontology calls. The docs warn refresh "has cost implications" without quantifying them.
- NL2Ontology internals. Which model powers it, how questions are planned into structured queries, how ambiguity is resolved, and what its failure modes are.
- Federated query planning. How the router optimizes a query that spans Graph and Eventhouse backends — pushdown rules, join placement, latency characteristics.
- Security propagation. Whether and how row-level or object-level security on bound sources (lakehouse tables, semantic models) carries through bindings into graph query results.
- Programmatic surface. A full REST/SDK story for ontology CRUD and refresh orchestration beyond the portal experience.
- GA timeline and preview constraints. What changes at general availability; Microsoft publishes no roadmap commitments here, and none should be inferred.
The practical L5 posture: design so that these unknowns are replaceable assumptions — isolate the ontology behind the data agent or query layer, benchmark refresh and query behavior on your own data, and re-verify against the docs each time you upgrade a design from experiment to dependency.
Sources