Metrics get their own section, and tell you whether they work
Metrics no longer hide in a tab on one table's page. Every connection now has a Metrics section in Settings → Admin → Data, and each metric has a page of its own — with a Check card that compiles the definition while you write it.
One list for the whole connection
Metrics span tables, so they now live beside the tables rather than inside one. Selecting Metrics turns the rail into the connection's metric list, grouped into From dbt and Custom, each row showing the metric's type and a blue dot while it has unsaved edits. Search it, or hit New metric.
A metric is still stored on one table's model, but you no longer have to know which: the Stored on field says where it lives, picking a measure from another table moves it there, and Save saves the right model.
The Check card
Beside the definition, Check dry-runs the metric against your live schema before you save it:
- whether it compiles on your warehouse — and, when it doesn't, the exact reason;
- the tables it can be grouped and filtered by, with the chain of joins the query would walk;
- the time axis it aggregates along and the grains it offers;
- the SQL Axiome would run.
Nothing touches your warehouse — the check compiles, it does not query. A metric pointing at a measure someone deleted now shows up here, not on a dashboard.