Metrics layer vs. semantic layer: model metrics apart from the data model
The metric estate, how metrics are calculated from each other and which metrics drive which, belongs in its own model, abstracted from the data model. Duodata keeps that metrics model, links it deterministically to the data model, and bakes the result into the semantic layers of Snowflake, Databricks and Microsoft Fabric.
Two models, one correct link
- The metrics model (business world): the metric estate with approved definitions, owners and valid variants; calculation lineage, meaning how metrics derive from other metrics (gross margin from revenue and cost of goods sold); and value driver lineage, meaning which metrics move which (activation drives churn, churn drives net revenue retention).
- The data model (platform world): tables, columns, joins, grain and filters in Snowflake, Databricks, Fabric and dbt.
- Duodata links the two: every approved metric is mapped to its implementation through an explicit, versioned Implementation Mapping. The same question always resolves to the same approved metric and the same implementation, instead of an AI inferring the link at query time.
- The semantic layer runs the result: Duodata deploys the linked definitions as Snowflake Semantic Views, Databricks Metric Views and Fabric semantic models, backed by Apache Ossie / MetricFlow YAML in Git.
Why the metrics model must sit above the data model
- Value driver lineage exists in no data model. Tables record transactions, not which KPI moves which. Without it, AI can say where a number came from but not why it moved.
- Data models change, metric meaning should not. Migrations, new platforms and refactored tables would otherwise rewrite what "revenue" means.
- One metric has many implementations. Gross margin can live in a Snowflake view, a Power BI measure and a dbt model at once. Only a model above them can say they are the same metric.
| Metrics layer (Duodata) | Semantic layer (Snowflake, Databricks, dbt, Fabric) | Data catalog | |
|---|---|---|---|
| Models | The metric estate: definitions, variants, owners | Measures, joins and dimensions on one platform | Datasets, owners and data lineage. |
| Lineage | Calculation lineage and value driver lineage between metrics | How one measure is computed from tables | How data flows between systems. |
| Link to data | Deterministic, versioned mapping to every implementation | Is the implementation | Descriptions attached to tables. |
| Main users | Business owners, Metric Stewards, data teams | Analytics engineers, BI developers | Data engineers, technical stewards. |
| What AI gets | One approved metric, its drivers and how to retrieve it | Queryable logic for that platform | A list of candidate tables. |
Governing agents, not just data
Data governance controls the data: who may access which tables, data quality, classification and lineage. Duodata governs what AI agents mean when they answer: which approved metric, variant and implementation an agent uses, and a clear stop when a requested metric is not approved. It complements data governance and runtime agent controls (permissions, identity, guardrails) rather than replacing them.
How it fits together
- Business and data teams model the metric estate in Duodata and approve each definition.
- Data teams map each approved metric to its implementation in the data model.
- Duodata deploys the linked definitions into the semantic layers, and the AI Connector serves agents the approved context.
When you need a metrics layer above the semantic layer
- More than one data platform or BI tool holds the same KPI.
- AI assistants answer metric questions and contradict the dashboards.
- A migration or new platform is coming and metric meaning must survive it.
- Leaders ask why a number moved, not only what it is.