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

# The First Build

> Platinur profiles your data, interviews you about the business, then builds and validates your warehouse.

The first build lives in **Models → Build**, runs as one guided Assistant chat, and is available
only in Staging.

## How it runs

1. **Choose coverage.** Select the raw tables to model. The compact summary and confirmation show
   selected tables, included sources, tables to add, and tables to remove.
2. **Investigation.** The Assistant profiles structure and bounded samples, checks distinctness,
   candidate keys, relationships, and the existing governed project. It answers technical
   questions from data rather than asking you to guess.
3. **Business interview.** Before generating models, the Assistant asks the context it cannot
   infer safely: what the data should improve, which decisions/KPIs matter, definitions, and
   consumers. Questions use readable labels and suggested choices—not JSON values. **Use defaults
   for all** fills unanswered questions.
4. **Generation.** Your answers guide:
   * source-aligned staging cleanup models;
   * a materially smaller conformed warehouse of dimensions and facts;
   * marts at explicit grains for the decisions surfaced in the interview;
   * useful governed metrics and descriptions, not a metric for every numeric column;
   * mart grain tests (`unique` plus `not_null` on the grain key) and column/model contracts.
5. **Validation.** Platinur builds the current project in an isolated workspace and throwaway
   validation database. Generated paths, SQL shape, dbt parsing, model dependencies, mart tests,
   semantic definitions, and any Evidence pages must pass the relevant contracts.
6. **Staging commit.** Only a fingerprint-current passing validation can commit. The result
   appears in Promotions for files, diff, ancestry, Undo, and later release.

The completed interview remains in the chat as a compact read-only Previous/Next card, so the team
can review every question and answer without reopening the form. Messages before and after it stay
in their original order. Submitting the interview continues the existing run exactly once; it does
not create a second build task or restart at question one.

## What good output looks like

* **Staging** is a clean, documented reflection of each selected source table, without business
  joins.
* **Warehouse** models durable entities and events; lookup/reference tables fold into meaningful
  dimensions rather than becoming one dimension each.
* **Marts** answer named business questions at declared grains and have built-in grain tests.
* **Metrics** define business logic, aggregation, grain/time, and meaning consistently.
* **Descriptions** explain real business meaning; generic “Generated dbt model” filler is not
  acceptable.

The build never publishes directly to Production.

## Before running

* The active environment is Staging.
* At least one selected source table has been loaded or is available as an external source.
* The warehouse is connected.
* The Assistant is ready. GitHub may be connected up front; with an organization GitHub App,
  Platinur can lazily provision the governed repository at the first Staging commit.

## Updating model coverage

After the first build, change the selected raw tables and press **Update models**. Platinur diffs
the draft against the last built coverage and gives the Assistant explicit additions/removals.

* Added tables receive the needed models; existing models change only when the new source belongs
  in a shared entity, fact, mart, or metric.
* Removed tables retire their source-aligned models and downstream models that depend solely on
  them. Models with other valid inputs are minimally rewritten.
* Raw/source schemas are never dropped. Derived Staging objects retired by the proposal are
  removed from Platinur's own output databases; Production follows only after release.

**Reset draft** and **Refresh source tables** update the Build pane without reloading the whole
page. Select all toggles back to deselect all. When the draft already matches current model
coverage, the confirmation shows a small **nothing to change** note and does not start a run.

V1 has no destructive in-place **Rebuild from scratch**, **Reset models**, or warehouse unbind.
Existing work evolves through Staging proposals. For a true clean slate, an Owner deletes the
account from Settings and creates a new paid workspace with the intended plan and warehouse.

## Confirmation and run limits

The confirmation shows only the relevant scope/counts and any no-change note. It does not claim
that a human must apply a proposal before Staging—the Assistant commits automatically only after
validation, and Promotions is the review/release surface.

Runs use the platform-supported allowance or the workspace's own provider key. A run that reaches
its configured safety budget stops without pretending to have completed; a continuation resumes
from its durable chat/sandbox where safe instead of starting duplicate work.