Five Questions a Governed Warehouse Answers Without a Meeting

Every team that owns a Fabric Warehouse or a SQL Server estate fields the same handful of questions. They arrive in stand-ups, in review threads, in messages from someone who needs an answer before lunch. Individually they look small. Collectively they are where warehouse ownership goes: a day tracing a type, an afternoon explaining a join, a standing meeting whose only purpose is to reconstruct what everyone used to know.

This article is about what happens to those questions once the estate's meaning is governed in CoreModels — not the capability list, but the change in how they get answered.

"Is the estate still the way we agreed?"

Before: you answer from vibes. No alerts fired, so presumably nothing changed. Confirming it properly means comparing today's DDL against a mental model living in three people's heads — so nobody confirms it.

After: it is a color. Every audit run you choose to record lands in a rolling history, and the latest recorded run drives an SVG status badge — green when the run was clean, yellow when only warnings appeared, red when there were errors, gray when nothing has been recorded yet. The badge is served on the machine-to-machine surface too, so it renders in a README with a user API key. The rest of the trail is one call away: the history endpoint returns recent runs with their counts, codes, timestamps, and artifact fingerprints, and the status endpoint reports the last-import state and how many governed datasets exist.

The question becomes a glance, with the investigation available underneath when the glance is not green.

"Will this pull request change what our data means?"

Before: a reviewer reads a migration script. They can check syntax, naming, and plausibility. They cannot check it against an agreement, because the agreement was never written down in a form anything can compare against.

After: the pipeline re-extracts INFORMATION_SCHEMA, posts it to the audit endpoint on the API-key surface, and gets back a verdict. Errors fail the build. The report is designed for both parties: machine-readable counts and coded findings for the gate, and a markdown summary that drops into the job summary or a PR comment for the humans.

What lands in that summary is specific enough to act on. Metrics like datasets governed and fields governed show coverage at a glance. A retyped column arrives as field-type-drift with the governed type and the artifact type side by side. A new table with a key-shaped column and no declared constraint arrives as key-column-undeclared — a warning, not an error, because the build should not fail on a modeling suggestion, but it is now a five-minute fix during review instead of a mystery join two years later. Review changes character: reviewers stop guessing at consequences and start reading a diff of meaning.

"We just changed the model — does the estate still fit?"

Before: this check does not exist. Documentation and databases drift apart in both directions, and only one direction is ever watched, if any.

After: it is a single call with an empty body. The re-audit verb replays the estate snapshot stored at import time against the current governed model. No fresh extract, no warehouse access, no credentials. If tightening a status column's definition would put twelve existing tables out of conformance, you learn that in seconds, before the change is announced as policy.

Re-audit always records its run into the same history the CI gate feeds, which means model changes and estate changes appear in one dated trail rather than in two systems that never meet.

"Can the new environment have these tables?"

Before: somebody copies DDL out of production and hand-edits it — the exact moment environments begin to diverge, invisibly, until it matters.

After: the generate verb emits coremodels_fabric_tables.sql from the governed model itself — T-SQL CREATE TABLE statements with bracketed identifiers, NOT NULL or NULL derived from governed checks, one PRIMARY KEY per table, and FOREIGN KEY declarations derived from governed references. The file's own header states the rule the team ends up living by: meaning changes belong in CoreModels; regenerate the script rather than editing it.

Views are skipped deliberately, with an explicit note saying so, because emitting a CREATE TABLE for a derived object would be a confident lie. CoreModels does not apply the script — it hands you an artifact for your normal review and deployment process.

"What does this column mean, and can the assistant be trusted about it?"

Before: the answer is a person. Sometimes a wiki page from two reorganizations ago. When an AI assistant is in the loop, the answer is whatever the assistant inferred from column names, delivered with unearned confidence.

After: the governed graph is the documentation home for the estate — which the connector states outright, since the T-SQL extract carries no descriptions of its own. Tools and agents read it over the Model Context Protocol at an OAuth-protected endpoint (https://coremodels.example.com/mcp), where they can pull the project summary, search the governed nodes, ask for the last-import state of the fabric vendor to judge how current that picture is, and run an audit against a fresh extract when currency matters. "These columns probably join" becomes "the governed model declares this reference."

What it costs, honestly

Two documented queries and an upload. The required extract is the INFORMATION_SCHEMA columns-and-tables query; the optional second one flattens PK/FK constraint rows into checks and references. Because that shape is ANSI T-SQL, a plain SQL Server estate rides the same connector as a Fabric Warehouse.

Re-importing after the estate grows is additive: new tables and columns are added, and anything already governed is left exactly as it is. Growth does not overwrite decisions.

The compressed before and after

Before: health was assumed. Reviews checked syntax. Model and database drifted independently. Environment DDL was copied by hand. Agents guessed at structure. Each question cost a person part of a day.

After: health is a recorded badge with a trail behind it. Reviews check meaning, with coded findings. Drift is watched in both directions. DDL is generated from the agreed model. Agents read declared facts. The questions are answered by the system, and the people who used to answer them are doing something else.

That is the whole outcome. Not a governance program — a set of questions that stopped needing a meeting.

The Microsoft Fabric quickstart in our docs has the exact extract queries, endpoints, and CI snippet if you want to reproduce this on your own estate.