The Meeting That Used to Take Two Weeks

Somebody proposes changing a column. Not a dramatic change — order_total needs a different type after a rounding bug, or status needs one more allowed value.

In an ungoverned estate, that proposal starts a small archaeology project. Who consumes this table? Is anything depending on the old type? Was there a reason it was defined that way? The thread runs for a few days, three people give partial answers with different confidence levels, and eventually someone ships it and everyone watches the dashboards for a week.

Once your Unity Catalog estate is governed in CoreModels, the same proposal is a handful of calls and a decision with a name on it. That is the after-state this article is about — told through the four people who feel it, on an ordinary week, using nothing but artifacts your team already has the right to produce.

The analytics engineer opening a pull request

She changes a table definition and pushes. CI re-extracts the schema for the staging catalog and posts it to the CoreModels audit endpoint on the machine-to-machine API — the surface that accepts a user API key, at Viewer role, because the audit never writes anything.

The build goes red, and the reason is in the job summary rather than buried in a log: the audit returns a markdown report shaped for exactly this moment, alongside machine-readable counts. The finding names the column by its full catalog.schema.table identity plus field, states the governed type and the type in the artifact, and carries a stable code she can search for.

The behavioral change here is subtle and it is the whole point: a red build is not a verdict that the change is wrong. It is a statement that the change is undecided. If the retype was accidental, she fixes the PR. If it was intended, the column's meaning has moved, and that belongs to someone with the authority to move it.

The steward who changed a definition

That someone is the model steward. He reviews the proposal, agrees, and updates the governed model — tightening or widening the accepted values, retyping the governed field, adjusting the description.

Then he asks the question governance usually cannot answer: the model just moved, so does the estate as last imported still conform to it?

He does not need a fresh extract to find out. The parsed estate snapshot was stored at import time, so a single re-audit call replays the same audit engine over that last-known estate against the current governed model, and the run is recorded in the history automatically. The answer comes back in seconds: one warning, on exactly the field he touched, because the estate still carries values his tightened definition no longer allows. He opens a ticket for the loading job and pastes the finding code into it — codes are stable identifiers, not sentences that get paraphrased into ambiguity.

Two directions, one engine. The audit asks whether fresh artifacts still conform to the model. The re-audit asks whether the last-known estate still conforms to a model that changed. Most teams have never had a way to ask the second one at all.

The platform lead who just wants to know

She is not going to read audit reports. She wants a light that is on or off.

The README carries an SVG badge served straight from CoreModels, from the latest recorded run: green for clean, yellow for warnings only, red for errors, gray when nothing has been recorded yet. Gray is deliberately not green — silence is not evidence.

When she does want detail, two reads give it. The status endpoint tells her whether the vendor estate has been imported at all, when, with what fingerprint, and how many datasets are under governance. The history endpoint returns the rolling trail: each recorded run with its counts, its finding codes, its fingerprint, and what triggered it — an interactive audit, a CI run, a re-audit. "How do we know the lakehouse still matches what we agreed?" stops being a question that gets a shrug and becomes a link.

The team standing up a new mart

They need Delta tables that match the governed definitions. Before, this was a copy-paste from whatever the last person wrote, plus the small divergences that always creep in.

Now it is a generate call, which returns one artifact: a coremodels_delta_tables.sql script of CREATE TABLE IF NOT EXISTS … USING DELTA statements derived from the governed model. Not-null comes from governed checks. Each table gets one informational PRIMARY KEY constraint and FOREIGN KEY … REFERENCES declarations from governed references — the intent, declared, in a form Unity Catalog and its tooling read. Governed allowed values ride on the column COMMENTs, where every future reader finds them. Descriptions become table comments.

Two details make it trustworthy rather than merely convenient. Views are deliberately absent, and the response says so as declared lossiness — they are derived objects, and the generator does not pretend otherwise. And the script's own header states the contract: meaning changes belong in CoreModels; regenerate this script rather than editing it. The output is reviewed and deployed like any other code change.

And, quietly, one more consumer

All week, AI assistants connected over the MCP endpoint have been reading the same governed facts — types, elements, taxonomies, references, lineage — and running the same read-only audit, at the same Viewer role. They are grounded in the agreement rather than guessing from column names. Nobody had to build them a separate context pipeline; the governed model is the context.

Before and after, stated plainly

Before: schema truth lived in three places that disagreed — the catalog, the pipelines, and people's heads. Changes landed silently and surfaced at query time. New environments were rebuilt from folklore. "Are we drifting?" was, strictly speaking, unanswerable.

After: the agreement lives in one place; every pull request is checked against it; the estate is re-checked whenever the agreement itself moves; new DDL is generated from the agreement instead of reconstructed from memory; and the current state of trust is a badge, a history trail, and a set of coded findings anyone can read.

What it did not cost: any credential. The whole loop runs on JSON extracts produced in the Databricks SQL editor — one required, two optional. Adoption is one import and one CI step, and the Databricks Unity Catalog quickstart in the CoreModels docs shows both end to end.