Skip to main content
Models is the primary surface for the governed dbt project. It has five line-style tabs— Models, Metrics, Data, Schedule, Build—and the selected tab is deep-linkable through ?view=models&tab=<key>.

​
Models

The default tab shows the current environment’s dbt assets directly on the page, grouped under Model layers rather than inside one large container card.
  • Staging: source-aligned cleanup models, normally one per selected source table.
  • Warehouse: conformed dimensions and facts. Reference and history tables may fold into a smaller set of durable business entities/events.
  • Marts: purpose-built serving models at explicit reporting grains.
The Lineage section follows the model layers and tests on this tab. It renders the dependency graph for the current environment; select a model to open the same accurate model detail used by the layer lists. Production lineage remains read-only. Open a model to inspect its real columns, descriptions, SQL, tests, and last-run state. Explain shows a short Assistant-generated explanation below the trigger after a minimal loading state; it does not open a second oversized detail box. Tests have their own Tests heading, are collapsed by default, and use the page-level Run all action. A test or dbt failure stays in Monitoring; the Models page does not duplicate the complete run ledger.

​
Metrics

Metrics is a searchable, read-only catalog of governed metric definitions currently available in the active environment. Each card exposes the business definition, model, aggregation, grain, dimensions, and current status where present. If there are none, the page simply says No governed metrics yet. Create or change governed metrics by asking the Assistant in Staging. The definition is validated as part of an ordinary staged proposal and reaches Production through a validated release plan; the catalog does not hand-edit semantic YAML or write directly to both environments. See Governed Metrics.

​
Data

Data is a full-width warehouse explorer at the same content width as the other tabs.
  • The Warehouse explorer is visible by default, but no database/schema connection is expanded automatically.
  • Expand a connection and choose a governed relation to inspect it.
  • Sample data displays a bounded, scrollable row preview.
  • Columns switches to a vertical, scrollable column catalog with type and available metadata; columns are not forced into one horizontal strip.
The explorer is environment-aware and read-only. It does not expose validation scratch databases as durable product data.

​
Schedule

Schedule manages dbt refresh cadence for the active environment. Choose the build scope and cadence in the workspace timezone, save it, and inspect its executions in Monitoring. Production schedules operate on production code and output databases; Staging schedules stay isolated.

​
Build

Build is available only in Staging. Its Change model coverage section selects which discovered raw tables the governed dbt project should model. The compact summary above the source list shows:
  • selected table count;
  • included source count;
  • number of tables to add;
  • number of tables to remove;
  • a minimal Draft mode tag when the selection differs from the saved baseline;
  • an Assistant-logo Update models action of the same visual size as the summary cards.
Source-specific controls—search, add schema/source, refresh source tables, and select/deselect all—stay with the source list. Refreshing source tables and resetting the draft update the panel without reloading the whole page. Selecting all a second time deselects all. Pressing Update models opens a confirmation summary with source/table/add/remove counts. When the selected coverage is already modeled, that fact appears as a small note in the confirmation and the action explains that there is nothing to change. The Assistant then prepares, validates, and commits the model update to Staging; review its files and diff in Promotions. The initial build additionally runs the persisted business interview before generation. See The First Build.

​
Environment awareness

Staging reads the staging workspace/branch and permits governed changes. Production reads the configured production branch and runtime. It does not show Change model coverage or Build actions; production development always begins in Staging.