Skip to main content
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.