Browse Docs
Catalog
Config
Stacks
Operate
Docs

One change, dev to production, with the records to prove it

Teams ask what an approval actually looks like here. This is the recorded cycle, from the Kubara fleet work, with the receipts and screens that exist today and one honest limit named at the end. View source markdown.

The cycle

  1. A value changes in a development variant. The change is a diff against a recorded revision, not an edit to a template.
  2. The change is previewed: the exact objects that would ship, before anything ships.
  3. Production Spaces carry an approval gate. The approval binds to the exact observed revision head, so approving yesterday's revision authorizes nothing about today's. This mechanism is proven: hash-stable, head-bound, blocked-then-allowed, in the change-review receipt.
  4. Promotion moves the exact reviewed revision downstream. No rebuild from a tag, no re-render between review and delivery.
  5. Rollback restores one production target to an exact earlier recorded release while its twin keeps the newer one. The upgrade and rollback proof shows it on redis; the Kubara fleet pages show it across four clusters.

The GUI tour walks the screens with receipts behind each frame.

The honest limit

Our approval receipt does not yet record the approver's identity (approverIdentityRecordedInReceipt: false in the committed record), and the recorded apply was a dry run. The binding mechanism is proven; the named-person production claim is not, and this page will say so until the receipt exists. That gap is on the build list, not hidden under this page.

Generated from the committed markdown file docs/user/approval-story.md. The source file is the authoritative version.