Connect Snowflake

Your Snowflake Schema Is Not a Contract

Picture a failure every data team has met. The revenue dashboard didn't crash. That would have been kinder. Instead it kept rendering, quietly wrong, for eleven days — because a column that had always carried a two-decimal number was rebuilt upstream as text, and everything downstream coerced, rounded, or dropped what it couldn't parse. No alert fired. No reviewer saw it coming. The warehouse did exactly what it was told, because a warehouse's job is to store structure, not to defend meaning.

Recipe: Warehouse contracts for Snowflake

A Week in the Life of a Governed Snowflake Estate

Forget the sales pitch for a moment. Here is what an ordinary week looks like for a data engineer whose Snowflake estate is governed with CoreModels — nothing heroic, just the same work with the guesswork removed.

Recipe: First governed Snowflake import

Read-Only by Design: The Trust Model Behind CoreModels for Snowflake

Governance tools lose trust in predictable ways: they demand credentials to your most valuable system, they "helpfully" rewrite things nobody asked them to touch, they paper over what they couldn't represent, and one day they act on your infrastructure without a human in the loop. We designed the CoreModels Snowflake integration against that failure list, promise by promise. This article is the trust story, stated plainly enough to be falsifiable.

One Table, Five Tools: Where Snowflake Sits in a Governed Estate

Pick one table in your warehouse — say `ANALYTICS.PUBLIC.ORDERS` — and list everything that has an opinion about it. An ingestion tool like Airbyte landed its raw ancestor. A dbt model transformed and materialized it, and dbt's manifest describes it in dbt's vocabulary. Airflow schedules the job that refreshes it. A Kafka topic with an Avro schema in a Confluent registry mirrors half its fields to another team. Snowflake's own `INFORMATION_SCHEMA` describes its physical shape. Five tools, five metadata dialects, five partial and slowly diverging descriptions of one thing.

Stop Letting Your AI Agent Guess What Your Snowflake Columns Mean

Ask a capable AI agent to "join orders to customers" in a warehouse it has never seen, and watch what it actually does: it reads column names and guesses. `CUSTOMER_ID` probably matches `ID` on the customers table. `STATUS` probably takes values like `'active'`. That JSON blob in `PAYLOAD` probably has a `user_id` inside. The SQL it writes will be syntactically flawless and semantically hopeful — and hopeful SQL in an analytics pipeline is how confident wrong answers get made at scale.

From Snowsight to First Audit: Governing a Snowflake Schema with CoreModels

You have a Snowflake schema and about thirty minutes. By the end of this tutorial you will have a governed model of that schema in CoreModels — tables as Types, columns as Elements with their native types preserved, declared keys as checks and references, object dependencies as lineage — and you will have run your first drift audit against it and read the result.

Recipe: Blank Snowflake project · First governed Snowflake import

Every Endpoint: The CoreModels HTTP Surface for Snowflake

This is the reference walk through everything you can do with the Snowflake integration over plain HTTP — every route, its role requirement, its request body, and what comes back. The Snowflake connector declares all three capabilities — Import, Audit, and Generate — so every verb below is live for it.

An Agent Runs Your Snowflake Governance: The MCP Workflow

"Is our Snowflake estate still in sync with the governed model? If not, show me exactly what drifted, and draft the DDL to fix it." That is a sentence you can now say to an AI agent, and every step it takes to answer — discovery, audit, report, generation — runs through the CoreModels MCP server as first-class tool calls. This article walks the whole flow: how an agent connects, which integration tools it gets, the exact arguments each takes, and how large metadata extracts travel via the `artifactUrls` path.

Wiring a Snowflake Drift Gate: CI, the Badge, and the Rolling Trail

Schema drift has two directions, and most teams only guard one. The warehouse can move away from the agreed model — a column retyped in a Friday migration, a table quietly dropped. But the model can also move away from the warehouse — someone tightens an allowed-value list in governance and nobody re-checks the estate. This article wires up automation for both directions against a Snowflake estate governed in CoreModels: a CI gate on the machine-to-machine API, a status badge, the rolling audit history, one-call re-audits, and the scheduled heartbeat that keeps the loop honest between changes.

Recipe: CI Drift Gate for Snowflake

Anatomy of an Import: How a Snowflake Estate Becomes a Governed Graph

Take one column — `ORDER_TOTAL NUMBER(38,2)` in `ANALYTICS.PUBLIC.ORDERS` — and follow it from an `INFORMATION_SCHEMA` row to a governed graph node. That single trace touches everything interesting about the Snowflake connector in CoreModels: how identity is minted, how native types map (and where they approximate), what rides the vendor-metadata mixin, how keys and dependencies become checks and lineage, which audit rules are Snowflake's own, and where the connector honestly declines to guess. This article is that trace, written for people who want to know exactly what the import does before pointing it at production metadata.

Recipe: Warehouse contracts for Snowflake