Fabric IQ: the same graph as an ontology

Fabric IQ's ontology (preview) item describes a business as entity types with properties and a key, relationship types between them, and data bindings to tables. That is the information Krusgraph already infers for a source, with the rule behind every key and relationship. ontology_draft writes the plan in the ontology item's own shape, nothing deployed:

• a summary with what needs a hand (keyless tables, composite keys, composite-column relationships);
• a binding checklist: entity type → table, key column, property → column, relationship → columns, each with its rule;
• a Turtle file the portal's Import ontology accepts into an empty ontology item, using the mappings Microsoft documents for import (owl:Class → entity type, owl:DatatypeProperty → property, owl:ObjectProperty → relationship type, rdfs:label, rdfs:comment, skos:altLabel → display name, description, synonym); bindings are then done in the portal following the checklist;
• the item definition (generation 2, TMDL parts) that POST /workspaces/{id}/ontologies and Git integration take, with tables bound DirectLake-style to the source, entities with keys and properties, and the relationships.

Creating the item through the API needs the delegated scope Item.ReadWrite.All and Contributor on the workspace, and the workspace on a Fabric capacity (POST /workspaces/{id}/ontologies, updateDefinition; Microsoft's REST specification, read 26 October 2026). create_ontology does that with a dry run by default (creating the item: created live; reviewed in Fabric); without the permission it answers consent naming the scope when asked to create. The portal route (Import ontology with the Turtle file) needs nothing beyond what you already have. Once an ontology exists, Fabric IQ's own pieces take over: the ontology agent and data agents use it as context, and the built-in graph can be materialised from its entity and relationship types. Ontology is in preview and its definition format can change; the draft follows the item's own definition as of 2026, checked against recorded definitions and, through create_ontology, against Fabric itself (created live; reviewed in Fabric).

Why not just Fabric IQ / the Fabric ontology? The ontology (preview) item is where the plan lands. Microsoft Learn describes three ways to fill one: by hand, generated from an existing Power BI semantic model (which then already carries the relationships), or with the ontology agent, which "explores the workspace items you point it to", "samples a few rows per table", drafts entity types, relationships and bindings "grounded in the discovered evidence" and "runs structural and grounding checks on the draft" (What is Fabric IQ?, What is ontology (preview)?, Use the ontology agent (preview); read from the documentation's source repository on 1 November 2026). Krusgraph creates the ontology item; the evidence step comes before it: plan_backend names the rule behind every key and relationship, validate_plan counts duplicate key values, references with no matching row and the total that doubles against the rows, suggest_relationships checks candidates against the data, and you decide with keys= and confirmed=; /check does the plan and the counting in the browser, with no account and no capacity. The same reviewed plan then becomes the ontology item (create_ontology: created live; reviewed in Fabric) and, from one plan, the API for GraphQL, the semantic model and the notebooks. Krusgraph does not replace the ontology item, its agent, its rules or its metrics, and the ontology agent's checks have not been compared with validate_plan on the same data: no such measurement exists.