Semantic Layer as AI Interface: Governed Metrics (2026)

Q: What is a semantic layer and why does it matter for AI analytics?

A semantic layer is a governed set of business definitions, entities or logical tables, dimensions, measures or metrics, and the relationships between them, that sits between raw tables and the tools that query them. It matters for AI analytics because a model that writes SQL against a raw schema has to re-derive the formula, join path, grain and filters for every question, and it will sometimes get them differently. With a semantic layer the model selects a defined metric and dimensions, and a deterministic compiler generates the SQL, so the same question yields the same query whichever model or tool asked. That consistency is what lets an agent answer match the dashboard, and it is the property that determines whether business users keep trusting the agent after the first disagreement.

Q: What is Apache Ossie and how does it relate to Open Semantic Interchange?

Apache Ossie is the new name of the Open Semantic Interchange specification, announced on 10 July 2026 as the project entered the Apache Incubator. The rename avoided confusion with other open-source projects that share the OSI acronym. It is an open, vendor-neutral, YAML-based specification for expressing business metrics, dimensions, relationships and broader business concepts so that different tools can produce and consume semantic definitions without losing meaning. The project reports contributions from Snowflake, Dremio, Salesforce, Databricks, dbt Labs and others, and converters to the dbt Semantic Layer and Apache Polaris have already been merged. It is a specification rather than an engine, and the Apache incubation notice states that incubating status is not necessarily a reflection of the completeness or stability of the code.

Q: What is MetricFlow and did dbt really open-source it?

MetricFlow is the engine behind the dbt Semantic Layer: it takes semantic model and metric definitions written in YAML, builds a query plan and compiles it into warehouse-specific SQL. dbt Labs announced at Coalesce on 14 October 2025 that it was open-sourcing MetricFlow under the Apache 2.0 licence, and framed it as a way for AI agents to use trusted, governed metric definitions for conversational analytics instead of relying on opaque text-to-SQL. The engine being open does not mean every surrounding capability is free of platform dependencies: managed APIs and some MCP server tools depend on your dbt platform plan. Check what you actually need against the plan you have before assuming the open-source engine covers your deployment.

Q: How do Snowflake semantic views and Databricks metric views compare?

Both are native, platform-governed objects that store business definitions where the data lives, and both are read by the vendor's own agents. Snowflake semantic views are schema-level objects made of logical tables, facts, dimensions, metrics and relationships, created with CREATE SEMANTIC VIEW, and Snowflake's agents read the definitions to generate SQL against the physical tables. Databricks metric views live in Unity Catalog, define sources, joins, filters, dimensions and measures once, and can be queried from SQL editors, notebooks, dashboards, Genie and alerts, with agent metadata such as synonyms and display names to improve accuracy. The practical difference is less about features than about lock-in: in both cases your metric definitions become platform objects, so keep an exportable source of truth if portability matters to you.

Q: Should the AI agent query the semantic layer or generate SQL directly?

Query the semantic layer for every question you have predefined, and use generated SQL only as a governed fallback. The layer constrains the model to a menu of defined metrics and dimensions, so the failure mode shrinks from any SQL that parses to a valid query over defined objects, access control can be applied at the metric level, and the answer can carry the definition it used. Direct SQL generation is still needed for the long tail of ad hoc questions, but it should sit behind a query firewall with a read-only role, row limits and a timeout, and the agent should tell the user which path produced the answer so lower-confidence results are visible. Silent fallback to free-form SQL erodes the consistency the layer was built to give you.

Q: What should I write in each metric so an agent uses it correctly?

Five things beyond the formula. A one-sentence business definition in plain language. The synonyms people actually type, and an explicit statement of which of those map to this metric, since sales, turnover and GMV may not all mean net revenue. The grain and the default time dimension so a phrase like last quarter resolves without the model picking a column. The filters that always apply, such as excluding test accounts. And a status of canonical, deprecated or experimental so the agent does not surface a metric you are retiring. Databricks documents agent metadata such as synonyms, display names and formats in metric views specifically to improve agent accuracy, which is the same idea. A human analyst asks a colleague when a name is ambiguous; the agent has only what you wrote down.

Q: When should a team not build a semantic layer?

When the layer would encode an unresolved argument, or when a simpler structure already serves the need. If finance and sales genuinely disagree on what counts as revenue, writing one definition into YAML moves the dispute into a pull request instead of resolving it; settle it with the business first. A single team with a handful of dashboards, stable definitions and no agent on the roadmap gets little beyond what well-named views already provide. The layer earns its cost when several tools or consumers need the same definition, or when an agent is about to answer to non-analysts. Also avoid a year-long project to model the whole warehouse before any agent uses a metric; start with the twenty questions leadership asks every week and expand from the log of questions that miss the menu.

Q: How do I keep semantic layer definitions from becoming a vendor lock-in?

Treat a Git repository in a convertible format as the system of record and treat any native platform object as a deployment target. Native layers from warehouse vendors are governed and fast, but a definition that exists only as a platform object cannot be audited, ported or reused in the next tool. The Apache Ossie specification exists to make definitions a portable artefact, and its converters to the dbt Semantic Layer and Apache Polaris show interchange is possible, but the project is incubating, so plan on having to translate. Keep names, descriptions and owners in the exportable source, add a question-to-metric regression suite that runs against whichever engine serves production, and review the portability posture whenever you evaluate a new platform or agent tool.