Skip to main content
Platinur has two first-class environments.

​
Staging

Staging is the development and validation lane.
  • Assistant development happens here.
  • Initial Run is available only here.
  • Proposals are applied here before promotion.
  • dbt writes to staging output schemas.
  • Evidence previews show staged dashboard output.

​
Prod

Prod is the release and runtime lane.
  • Assistant development is disabled.
  • Initial Run is not available.
  • Prod runs use the configured production GitHub branch as source of truth.
  • Production output schemas are separate from staging output schemas.
  • Runtime refreshes and schedules are governed by production permissions.

​
Promotion boundary

Validated staging work is promoted through a GitHub PR from the staging branch to the production branch. After merge, production runs sync from the configured production branch.

​
Staging release lock

Proposals applied to Staging form one promotion batch on the staging branch. Once a promotion PR exists for that batch, the staging lane is locked: no further proposals can be applied until the release completes. Staging is locked in two situations:
  • A promotion PR is open. Applying another proposal is rejected with: “A promotion PR is open. Merge or close it in GitHub before applying more staging changes.”
  • A promotion PR is merged but not yet finalized. Applying another proposal is rejected with: “A merged promotion is being finalized from GitHub main. Sync Promotions before applying another staging change.”
While locked, unstaged proposal cards in Promotions show “Waiting for open PR” or “Waiting for main sync” instead of “Ready to apply to Staging”, and their apply actions are disabled with the same reason. To resolve the lock, finish the release: merge (or close) the PR in GitHub, then sync Promotions. On sync after a merge, Platinur marks the staged proposals as deployed, resets the staging branch and workspace to the production branch, and unlocks Staging for the next batch.

​
File overlap between staged proposals

Two proposals in the same staging batch may not change the same file. Staging commits apply sequentially, so an overlap would mean the later proposal silently overwrites the earlier one. When a second proposal touches a file that an already-staged proposal also changes, applying it is rejected with an error of the form:
Proposal ‘<staged proposal title>’ is already staged and also changes <file path> and N more file(s). Promote or discard the staged batch before staging this proposal.
Proposals that change disjoint files can be staged into the same batch freely. To resolve an overlap, do one of the following, then apply the conflicting proposal:
  • Promote the staged batch: create the promotion PR, merge it, and sync Promotions so Staging resets.
  • Unapply the staged proposal from Staging (available until a promotion PR exists).