One plan, five Fabric pieces

Everything Krusgraph creates comes from one plan: the keys and relationships inferred from a source, with the rule behind each one, checked against the rows and corrected by you through keys and confirmed. From that plan: create_backend makes the API for GraphQL with nested relationships (no dry run; plan_drift shows what an update would change); create_views the wide T-SQL views on the SQL analytics endpoint; and, once the operator has enabled the permission, create_semantic_model the Power BI semantic model in Direct Lake mode with the same relationships, create_ontology the Fabric IQ ontology with entity types, keys, relationship types and bindings, and create_data_agent the data agent with the plan as instructions and examples. Those four answer with a dry run first; how far each has created live, in the words of the tool reference: the views (draft; deployment not yet verified), the semantic model (created live; reviewed in Fabric), the ontology (created live; reviewed in Fabric) and the data agent (draft; deployment not yet verified). Change the plan once (a confirmed relationship, a key) and every piece is rebuilt from it; plan_drift and lineage tell you what a change reaches. The pieces agree with each other because none of them was modelled by hand.

From the same plan, further down the lakehouse: silver_notebook_draft writes de-duplicated silver tables with every reference checked, and gold_views_draft the gold views on top of them, as materialized lake views (generally available in Fabric since September 2026) whose data quality rules are the plan's keys and relationships. A model you already have is checked against the plan with compare_semantic_model. And when changes go through Git rather than straight into the workspace, export_item_definitions gives every piece as the files Fabric's Git integration reads.