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

# Staging and Prod

> The two-environment model used by Platinur.

Platinur has two first-class environments.

## Staging

Staging is the development and validation lane.

* Assistant development happens here.
* The first build (Models → Build) is available only here.
* Validated assistant changes are committed here before promotion.
* dbt writes to the staging output databases: `stg_staging`, `stg_dw`, `stg_marts` — fixed
  names, not configurable.
* Evidence previews show staged dashboard output.
* The staging GitHub branch defaults to `staging` (GitHub → Advanced).

## Prod

Prod is the release and runtime lane.

* The assistant is **answer-only**: it answers questions from the production marts, but
  never develops here — change requests are routed to Staging.
* Builds are not available.
* Prod runs use the configured production GitHub branch (default `main`) as source of truth.
* dbt writes to the production output databases: `prod_staging`, `prod_dw`, `prod_marts` —
  fixed names, separate from staging.
* Runtime refreshes and schedules are governed by production permissions.

## Promotion boundary

Validated Staging work is released through a dependency-aware GitHub pull request. **Prepare
release** lets you select independent changes, automatically includes anything they require,
shows what remains in Staging, validates both resulting states, and provides editable pull-request
copy. After merge, Production syncs from its
configured branch and starts dbt/Evidence refreshes. See
[Promotions](/promotions/release-flow).

## Staging release lock

Validated commits are shown in Staging order with connectors for actual dependencies. Opening the
release composer does not lock Staging. Publishing a validated plan creates a fixed release
branch/PR and locks new Staging commits until
that PR is merged or closed; one release PR may be active at a time.

Staging is locked in two situations:

* **A release PR is open.** New Assistant commits and a competing release wait until it is merged or closed.
* **A release PR is merged but not yet finalized.** New Staging work waits for reconciliation.

To resolve the lock, finish or close the release PR. When repository rules permit, Platinur
merges automatically. If review rules block it, merge or close the PR in GitHub. Platinur
reconciles automatically. A fully released Staging state resets from Production; independent
unreleased work is replayed and validated on top of the new Production state.

## Editing an already-staged model

A later assistant commit may touch or consume a model changed earlier in the batch. Validation
records that dependency. A release that selects the later change automatically includes the
required earlier change; independent work can remain for a later release.

A commit is blocked when its base is stale—for example, the same file changed after the run's
sandbox was created. Restart the request from the current Staging state.