A Catalog That Agrees With Everything Can Warn You About Nothing

Here is a design flaw hiding inside a lot of metadata tooling. Point it at your Fabric Warehouse and it crawls the schema, recording what it finds. Point it again next week and it records what it finds now. The tool is always current, always accurate, and useless for the one job that matters: telling you something changed that should not have.

A system that silently rewrites itself to match the database can never disagree with the database. And a system that can never disagree can never warn you.

Everything about how the CoreModels Microsoft Fabric / SQL Server connector handles trust follows from that. The governed model is not a mirror of your warehouse; it is a separate, human-owned statement of what the warehouse is supposed to mean. Five properties keep it that way.

1. Import is additive, not authoritative

When you import an estate — tables and views becoming governed Types keyed database.schema.table, columns becoming Elements with reconstructed native types, key constraints becoming checks and references — existing governed nodes are never mutated or deleted. If the warehouse now says something different from the governed model, the import does not resolve the disagreement in the warehouse's favor. It does not resolve it at all — that is the audit's job, and the resolution is a human decision.

The one thing an import refreshes is vendor bookkeeping: the record of what the extract natively said — native type, checks, materialization, physical name — which rides in a per-vendor metadata mixin alongside the governed node. That is estate observation, not governed meaning, and the distinction is enforced in code, not in a policy document.

Re-importing a grown estate is therefore a safe, boring operation: new tables and columns arrive; every decision you already made stays as you made it.

2. Meaning changes are gated on people, and the gate is a role

The verbs have postures, enforced per project. Import requires Admin, because it writes to the graph. Audit, re-audit, generate, history, badge, and status run at Viewer and are read-only. Recording an audit run into the rolling history is opt-in: a read-only verb should stay read-only unless asked. Re-audit is the deliberate exception: it always records its run, because an unrecorded drift check is a drift check that never happened.

The same split governs machine access: on the Model Context Protocol surface, the read-only tools are served at Viewer role on the public endpoint, while the tools that write live only on the separate admin endpoint and require Admin membership in the project.

3. Lossiness is a success channel

A result that says "succeeded" while quietly dropping something is worse than a failure: it teaches you to trust it. CoreModels treats lossiness as a normal part of a successful response, and this connector is honest in four specific places.

T-SQL's INFORMATION_SCHEMA carries no descriptions — in SQL Server they live in extended properties, which this connector does not extract. Rather than implying coverage that does not exist, the import records the fact once, at estate level, and every audit reports it as a single Info finding, descriptions-not-extracted: the governed graph is where this estate's meaning is documented.

When a native type has to be approximated in the neutral model, the import says so and names the type — instead of presenting an approximation as an exact translation.

Import stores a snapshot of the parsed estate so later re-audits can run without fresh artifacts. If the encoded snapshot exceeds the storage cap, the response reports snapshotStored: false with a record explaining why, and states the consequence: fresh-artifact audits still work; re-audit has nothing stored to run against.

And when generating DDL, views are skipped with an explicit note, because a CREATE TABLE for a derived object would be a different kind of dishonesty.

4. Drift is evidence, not opinion

An audit does not produce a health score. It produces evidence with a chain of custody.

Every run returns counts by severity, findings with stable codes and subjects resolved down to database.schema.table.column, the drifted objects, a fingerprint of the artifact content behind the verdict, coverage metrics, and a markdown report for humans. field-type-drift names the governed type and the observed type. field-removed and dataset-removed name what disappeared. key-column-undeclared names the column whose relationship intent is invisible to tools. Recorded runs accumulate into a dated trail, and the latest one drives the badge.

The consequence is social as much as technical: when a build fails because the error count is above zero, nobody debates a feeling — the finding says which column, what the governed model expects, and what the artifact contains.

Drift is watched in both directions: the audit asks whether fresh artifacts still conform to the governed model; the re-audit asks whether the last-known estate still conforms to a model you just changed. Neither fixes anything automatically, because an automatic fix is unreviewed change with better branding.

5. Review and deploy, in that order

Nothing in this connector writes to your warehouse. There is no live connection to a Fabric Warehouse, SQL analytics endpoint, or SQL Server, and CoreModels never holds those credentials — you upload extracts you produced.

When the loop closes in the other direction, it closes as an artifact, not an action: generation produces coremodels_fabric_tables.sql — bracketed identifiers, nullability from governed checks, one primary key per table, foreign keys from governed references — and hands it to you. You review and deploy it like any other schema change. The file's own header states the rule: meaning changes belong in CoreModels; regenerate the script rather than editing it.

The same shape applies to proposals: fresh estate facts can be classified against both the stored snapshot and the governed model into a reviewable, replayable plan, whose only writes are the plan itself and a ledger entry noting it exists. Nothing about what your data means changes because a plan was produced.

Why this adds up to trust

Each property is the same principle in different clothing: the governed model is authoritative precisely because no machine can change its meaning unreviewed, no verb exceeds its stated posture, and no result claims more fidelity than the source provided. A catalog that agrees with your database is a mirror. A model that can disagree with it, and show its work when it does, is a control.

The Microsoft Fabric quickstart in our docs lays out each verb, role, and response shape if you want to check these postures yourself — which is rather the point.