Microsoft Fabric

Your warehouse already publishes a complete, machine-readable description of itself. Every Fabric Warehouse and SQL analytics endpoint answers `SELECT ... FROM INFORMATION_SCHEMA.COLUMNS` with the tables, the columns, the types, the nullability. Every one of them answers `INFORMATION_SCHEMA.TABLE_CONSTRAINTS` with the keys. That description is the whole input CoreModels needs to build a governed model of the estate and then guard it.

CoreModels exposes vendor integrations over two HTTP surfaces, and the split is not decoration. The interactive surface under `graph/integrations/...` is what a person or a notebook calls with a normal CoreModels login token. The machine-to-machine surface under `v1/...` accepts user API keys and is what a build pipeline calls. Both require authentication; both then enforce a per-project role on top of it.

An agent has a context window, not a file system. That single constraint shapes how AI-driven governance of a Microsoft Fabric warehouse actually works: the model cannot paste a forty-megabyte INFORMATION_SCHEMA extract into a tool call, cannot hold your SQL credentials, and should not be trusted to invent a schema comparison in its head. What it *can* do is call a small set of typed tools that run the real audit engine server-side and hand back a verdict.

Schema governance that lives in a document is not governance. It is a document. The version that actually holds is the one a pipeline can fail on - a single number, checked on every change, with a trail behind it that shows whether the estate is getting better or worse.

Governance starts with a question that sounds trivial and is not: what *is* a table, once it stops being a table?