Semantic layer

The Semantic level holds metrics: what a number means for the business, how it is calculated from the physical columns, and at which level of detail it is valid. It is where the model meets reports, dashboards and AI assistants asking "how is revenue calculated?".

Add a metric#

+ → Metric, or Add a metric on the empty Semantic level. Edit one by double-clicking its header.

FieldWhat it holds
DefinitionThe business meaning in words (Markdown is fine).
CalculationAn expression over qualified column names: table.column, schema.table.column when a table name is not unique, or the full reference. Use other metrics as {Metric name}, for example {Revenue} / {Order Count}. Bare column names are not linked. The dialog shows what it reads and what it cannot find as you type.
AggregationSum, Count, Count distinct, Average, Minimum, Maximum, or None for non-additive metrics such as ratios.
GrainThe entities or tables the metric is valid at, for example Order Line.
GovernanceOwner, steward, criticality, lifecycle, policies and tags. Classification rolls up from what the metric reads. Tag approved metrics Certified.

Example: Revenue = SUM(unit_price * quantity * (1 - discount)).

On the canvas#

Each metric card shows its aggregation, its tags, one row per input column or metric, and its grain. Dashed lines lead from each input to the column it reads. Select a metric to highlight what it reads.

Renaming follows#

Renaming a metric updates the {...} references in metrics built on it. Renaming a column, table, schema or catalog rewrites the calculations that read it, in the same version. A toast and the version message name the metrics that were updated.

Where metrics come from#

You can write them, or start from an import: dbt semantic models and metrics, and starter metrics from SQL aggregates, tagged dbt-derived or sql-derived so you can review them.

Versions#

Metric changes have their own version stream (s1, s2, ...), separate from modelling and governance. See Versions and Git.