Snowflake’s semantic contract can now ship through the same deployment gate as the database

Snowflake has made DEFINE SEMANTIC VIEW generally available in DCM Projects. The change lets teams manage a semantic view’s tables, relationships, facts, dimensions, metrics, AI instructions and verified queries as a declarative definition rather than treating the agent-facing model as a separately edited artifact. Snowflake’s release note is short, but the operational consequence is larger: the contract that grounds Cortex Analyst and Cortex Agents can now move through a plan-and-deploy workflow.

The semantic layer enters the deployment pipeline

DCM Projects stores desired state in SQL and YAML files, supports Git-backed workflows, previews changes with PLAN, and applies them with DEPLOY. Snowflake describes the system as a version-controlled, repeatable route across development, staging and production environments. Its DCM overview also says deployment artifacts and definition files are retained by the DCM project object.

That matters because a Snowflake semantic view is not just documentation. It holds the logical tables, joins, facts, dimensions and metrics that translate business language into warehouse logic. Snowflake says Cortex Agents read the semantic-view definition and generate SQL against the physical tables, while BI tools and analysts can reuse the same metric definitions. The semantic-view documentation positions the object as the shared business abstraction for both AI and conventional analytics.

A team can therefore review a metric formula, relationship or verified query in the same change process as the underlying warehouse objects. DCM reconciles the full semantic-view definition on each definition change. The supported-entities guide also makes an important limitation explicit: constraints and relationships must be named, and tags on a semantic view or its members cannot be added or changed through CREATE OR ALTER SEMANTIC VIEW; existing tags are preserved. Those constraints are documented here.

Governance is moving into code, but not all at once

Snowflake also released ATTACH MASKING POLICY for DCM Projects in public preview. It can declaratively attach a masking policy to columns in tables, Iceberg tables, views and dynamic tables, with DCM managing that attachment through the deployment lifecycle. The masking-policy release note does not list semantic-view members as attachment targets.

The practical rollout is therefore two tracks: semantic definitions are GA, while this new policy-attachment mechanism remains preview. Teams should promote semantic-view changes through PLAN and environment-specific tests, but keep separate checks for the policies on the physical objects those views reference. The new release makes the agent’s vocabulary deployable as code; it does not make every governance control part of one atomic semantic-view definition.