> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platinur.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Models

> Inspect model layers, governed metrics, lineage, data, schedules, and warehouse coverage.

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](/operations/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](/operations/initial-run).

## 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.