Standout Builder Studio · planning Index / Flow / 06 · Promote / Handoff draft Updated 12 Jun 2026

Proposal 06 · Promote / Handoff

This proposal covers pipeline step 8 — Promote toward handoff. Today promotion stages exist only as submissionState strings in mock data with no gate definitions, no per-stage blockers surfaced to the builder, and no mechanism to export a certification-ready package. This stub captures the problem, sketches one wireframe, and lists the open questions that must be resolved before a full proposal can be written.

1 Choose build path 2 Define the game package 3 Configure mechanics 4 Attach assets & theme 5 Run validation 6 Generate playable sandbox 7 Iterate 8 Promote toward handoff

Draft stub — structure and problem statement only.

Copy the full-depth anatomy of Proposal 01 / Proposal 04 when writing this proposal.

User problem

The submissionState field in apps/web/src/lib/builderMockData.ts holds strings such as "prototype", "review_candidate", and "operator_demo", but these strings are displayed as labels only — there are no gate definitions attached to each stage, no list of blockers a builder must resolve before promoting, and no UI that presents the promotion ladder as a series of rungs with explicit pass/fail criteria.

A builder who believes their game is ready for an operator demo has no tool to confirm which gates they have and have not cleared, no export path for a certification package, and no visibility into what a certification body will expect to receive. The GameWorkspace.tsx component renders the current submissionState as a status badge but provides no actionable path forward — a builder must rely on out-of-band communication (email, Slack) to understand the next step.

Proposed UI

The workspace gains a Promotion stage ladder: five named rungs (Prototype playable → Internal playable → Review candidate → Operator demo → Certification package) each with gate chips showing which criteria are met and which are blocking, plus an "Export package" panel that becomes active at the Certification package rung.

Promote / Handoff — stage ladder with gate chips and export panel CONCEPT · proposed

Promotion ladder

✓

Prototype playable

Config saved · sandbox generated · internal team access

cleared

✓

Internal playable

Validation passing · Math-Sim run logged · assets complete for internal

cleared

Review candidate ← current stage

✓ Reviewer notes submitted

✗ Jurisdiction matrix confirmed blocker

1 blocker

Operator demo

Signed demo URL · all assets at handoff quality · NDA scope confirmed

locked

Certification package

Cert-Pack agent output · jurisdiction-specific bundle · export available

locked

Export package

Available at Certification package stage — jurisdiction-specific bundle generated by the Cert-Pack agent.

State variants

State variants to be designed in the full proposal

gated — the current rung has one or more blockers; the rung is highlighted in amber; each blocker item is listed with its category and (where known) an owner; the "Promote" CTA for that rung is disabled.
ready-to-promote — all gate criteria for the current rung are met; the "Promote to next stage" CTA becomes active; the next rung in the ladder animates into a non-locked state.
package-exported — the build has reached the Certification package rung and the Cert-Pack agent has generated the jurisdiction bundle; the Export CTA is active and a download link is shown with the bundle's file size, jurisdiction scope, and agent run timestamp.

Affected current files

File	Change
`apps/web/src/components/builder/GameWorkspace.tsx`	Replace the `submissionState` badge with a full promotion stage ladder component; each rung renders its gate criteria as chips with passed/blocked states; the Export package panel is gated on reaching the Certification package rung.
`apps/web/src/lib/builderMockData.ts`	Extend the `submissionState` model (or replace it) with a structured promotion record: current rung, per-rung gate results, and export bundle metadata once the Cert-Pack agent has run.
Cert-Pack agent output	The Certification package rung and Export panel depend on the Cert-Pack agent producing a jurisdiction-specific bundle. The agent's output contract (bundle format, jurisdiction scope fields, file naming) must be defined before this rung can be fully specced.

What changes in the build flow

Today promotion is invisible — a string label on a card with no gates, no actionable blockers, and no export path; after this proposal it becomes a structured five-rung ladder where each rung has explicit criteria, the builder can see exactly what is blocking the next promotion, and the final rung produces a real exportable certification package rather than a manual email handoff.

Open questions

Decisions needed before implementation

Who can promote externally-built games? For games built by external studio partners, promotion beyond the Operator demo rung may require an internal Standout staff approval step — the builder alone should not be able to self-promote a game into certification without review. The proposal needs to decide whether promotion actions at certain rungs trigger an approval workflow, and which roles hold the promote permission at each rung.
What are the cert-package contents per jurisdiction? Different regulated markets (e.g. Malta, Great Britain, Isle of Man) have different certification submission requirements — the file list, RNG audit attachments, and math documentation differ. Until the Cert-Pack agent's jurisdiction-specific output contract is defined, the Export package panel's contents cannot be accurately specced and the "Certification package" rung gate criteria will remain a placeholder.

What to tackle next

Once the open questions above are resolved, the promotion ladder and Cert-Pack agent output contract can be specced in full. The next document in this planning suite is the Mechanics library, which catalogues the mechanic archetypes available as starting points for new game builds.