Nothing Broke. That's the Problem.

The expensive warehouse incidents never announce themselves. A monthly reconciliation comes out a few cents off per row. Every pipeline ran green. Every dashboard rendered. Nobody was paged. Three weeks earlier, a table was rebuilt and an Amount column went from decimal(18,2) to float — and the database did exactly what a database is supposed to do: it stored the values, coerced the types, and answered every query without complaint.

Nothing was broken, in the only sense the engine understands. What changed was meaning. No part of the stack was watching that, because no part of the stack was ever told what the meaning was supposed to be.

This is the gap the CoreModels Microsoft Fabric connector exists to close — for Fabric Warehouses, SQL analytics endpoints, and plain SQL Server estates alike. But the problem deserves precision first, because nobody introduced it. It is a structural absence.

Three questions your schema cannot answer

"What does this column actually mean?" T-SQL's INFORMATION_SCHEMA — the surface every tool sees when it inspects a warehouse — carries names, types, ordinal positions, and nullability. It carries no descriptions. In SQL Server, documentation lives in extended properties — a mechanism most teams never populate and most extraction tooling never reads. So the schema tells you a column is nvarchar(200). It does not tell you that it holds a two-letter billing region sourced from the CRM, or that finance depends on it being present.

"How do these tables relate?" Warehouses are full of key-shaped columns — id, CustomerId, SessionId — that carry no declared PRIMARY KEY or FOREIGN KEY. Some are real keys. Some are leftovers from a migration. The difference lives in one engineer's memory and in the SQL other people copy without understanding. Every tool that reads the schema — a BI modeler, a catalog crawler, an AI assistant writing a query — sees the same undifferentiated bag of columns and has to guess. Guessing works until the day a guess is wrong in a way that still returns rows.

"Is this still what we agreed?" There is no baseline. A warehouse holds its current state and nothing else: no record of the shape the team signed off on, no diff between then and now, no distinction between a deliberate evolution and an accident that survived review because reviewers were checking syntax. The first detector of unintended change is a broken report or a reconciliation that is off by cents — the most expensive detectors money can buy.

This is not a Fabric flaw

None of the above is a criticism of Microsoft Fabric or of SQL Server. Database engines are built to store and serve data efficiently; governing what the data means has never been in their job description, and a schema surface that stayed stable for decades did so precisely by staying narrow.

If anything, modern unified analytics platforms make the absence more costly rather than less. The more consumers you connect to the same warehouse — reports, notebooks, semantic layers, downstream marts, agents — the more places a silent meaning change propagates before anyone notices. Reach multiplies whatever you point it at, including ambiguity.

What is missing is a second artifact

Not more metadata. A different kind of artifact: a model of what the estate is supposed to mean, kept outside the engine, expressed precisely enough that a machine can diff reality against it.

That is what a CoreModels project becomes for a Fabric or SQL Server estate. Getting there costs two queries. You run the documented INFORMATION_SCHEMA extract — columns joined to tables — and, optionally, a second query that flattens primary- and foreign-key constraint rows. You export the results as JSON and upload them. There is no live connection and no agent to install: CoreModels never holds your credentials, because it never connects to your warehouse at all.

From that extract, the connector (vendor key fabric) builds a governed model. Each table and view becomes a governed Type with the identity database.schema.table. Each column becomes an Element with its native T-SQL type faithfully reconstructed — varchar(200), nvarchar(max), decimal(18,2), with bit mapped to Boolean — and IS_NULLABLE = NO captured as an explicit not-null check. Declared primary keys become uniqueness checks, grouped by constraint so a composite key is recognized as one key rather than several. Foreign keys become governed references: the relationship that was implicit in a naming convention is now a queryable fact.

And because the extract genuinely carries no descriptions, the import says so once, as an estate-level fact rather than noise on every table. From then on, the governed graph is where this estate's meaning is written down.

What changes the day after

The model is only half of it. The other half is that it can now be checked.

An audit compares any fresh extract against the governed model and reports three things: coverage (what exists in the estate but is not governed yet), drift (what changed against the governed model), and conformance (vendor best-practice rules). The findings are coded and specific. A type change comes back as field-type-drift naming the governed type and the observed type side by side. A vanished column is field-removed; a vanished table is dataset-removed. Both are errors. That key-shaped SessionId with no declared key raises key-column-undeclared as a warning, with a message that states the actual consequence: relationship intent is invisible to tools.

The audit is read-only and runs at Viewer role, so it is safe to wire into a pull-request pipeline. When the error count is above zero, the build fails, and the report — machine-readable counts plus a human-readable markdown summary — explains exactly which column violated which governed fact. The latest recorded run also drives a status badge, so "is the estate still what we agreed?" becomes a color rather than an investigation.

Replay the opening incident against that setup. The decimal(18,2) to float change does not slip through as a green pipeline. It arrives as a named error, on a pull request, three weeks before finance finds it.

The point

Your warehouse was never short of information. It was short of an artifact that could be wrong — a written-down agreement precise enough to be violated, and therefore precise enough to be checked. Everything else in this story follows from that one absence.

If you own a Fabric Warehouse or a SQL Server estate, the Microsoft Fabric quickstart in our docs walks through the extract queries, the first import, and the first audit end to end.