Semantic context is becoming portable—but governance still breaks at the handoff

Portability is arriving before uniform control

Enterprise analytics stacks are starting to move semantic context across product boundaries instead of rebuilding it inside every assistant. Google says Knowledge Catalog can now ingest semantic models from LookML, BigQuery Graph, dbt MetricFlow, Snowflake Semantic Views, Databricks Metric Views and SAP CSN, while retaining overlapping definitions side by side with their provenance. That is a meaningful interoperability step: an agent can discover business definitions without forcing the organization to translate every model into one new language.

But importing context is not the same as proving that the context is correct. Google’s design makes conflicts visible rather than silently overwriting one definition with another. The operational consequence is that a steward still has to reconcile competing definitions before an agent should treat one as authoritative. Portability moves the disagreement into a shared catalog; it does not resolve it.

Join metadata is guidance, not a constraint

Databricks’ Beta relationships between metric views show the second boundary. A relationship records direction, declared cardinality and a join condition so AI assistants and BI tools do not have to infer joins from column names. Yet Databricks explicitly describes those relationships as metadata only. They do not enforce the declared cardinality, and tools remain free to choose joins for each analysis.

That flexibility is useful, but it creates a validation obligation. A declared MANY TO ONE relationship can guide an assistant while the underlying data violates that assumption. Production teams therefore need a separate test for uniqueness and fan-out risk; catalog metadata alone cannot prevent a duplicated aggregate.

Verified examples also need lifecycle controls

Snowflake’s Cortex Analyst Verified Query Repository adds a third layer: approved question-and-SQL pairs that can influence answers to similar questions. Snowflake exposes which verified query influenced a response, which provides useful runtime provenance. Its schema can also record verified_by and verified_at—but both fields are optional, and Snowflake warns that inaccurate verified queries can reduce performance and accuracy.

The pattern across the three systems is clear. Google transports definitions and preserves provenance. Databricks publishes reusable join intent without enforcement. Snowflake reuses approved SQL and exposes its influence at runtime, but leaves review metadata optional. None of those are defects by themselves; they are different parts of the control plane.

For practitioners, the deployment checklist should match those layers:

1. Import: preserve source and ownership when semantic definitions cross catalogs.
2. Validate: test cardinality, freshness and metric assumptions against the underlying data rather than trusting declarations.
3. Review: give verified queries owners, verification dates and expiry or reapproval rules.
4. Observe: retain the semantic definition, relationship or verified query that influenced each generated answer.

The emerging semantic layer is becoming portable enough for agents to share context. The harder work is now making provenance, validation and review travel with it.