Where generative AI does the work

The zero-engineering promise is mostly a generative-AI promise. This page maps every point in game creation where a model acts — what it consumes, what it produces, and the gate that keeps a human accountable for the result. Almost everything here is CONCEPT · proposed: none of these models are wired yet. The rails they would run on — audited writes, comments-as-handoff, the certified RNG they must never touch — are real today, and are marked GROUNDED · matches main where cited. The audience includes external Game Builders; terms are glossed on first use.

The map

Generative AI is not one feature bolted onto Builder Studio — it is a layer of touchpoints, each attached to a specific step of the eight-step build flow. The honest version of the picture is that the model does a great deal of the creative and drafting work (steps 1–5) and almost none of the deterministic work (steps 6–7): generating a playable sandbox and iterating on versions are mechanical operations the platform performs, not things a model invents. The diagram below places each touchpoint against the step it serves, in flame colour; the master matrix beneath names every one with its inputs, outputs, owning agent, and autonomy level.

Read the flame nodes as "a model acts here." Steps 6 and 7 are deliberately drawn dashed and grey: generating a signed sandbox URL and diffing two versions are deterministic platform jobs (see vision · step 6 and step 7), and dressing them up as "AI" would be dishonest. The violet node is the one genuinely open direction — telemetry-driven tuning — consistent with the mind map's open branches.

The master matrix

One row per touchpoint. Where links the step or stage; Agent links the owning agent in the agent roster; Autonomy is one of three rungs — assistive (model proposes, human does the committing), autonomous · gated (model produces and a named human approves before it counts), autonomous (model acts without a per-artefact gate). Everything in Today is CONCEPT unless a manual equivalent already ships.

Thirteen touchpoints, eleven of them creative/drafting/code-side and gated by a named human; two deterministic steps (6, 7) deliberately have none; one is an open direction. The pattern is consistent: the model proposes, a human or a deterministic check disposes. Notice the matrix never lets a model own a number that affects player outcomes — config drafting hands off to the simulator, and extraction flags anything it is unsure of.

The creative cluster

Step 4 — attach assets and theme — is the generative-AI-heaviest zone in the whole flow. It is where the largest share of human hours goes today (a reskin is "hours of hand-editing assets.ts and Tailwind", per variant → live · gaps), and therefore where models have the most to give back. Each artefact family below follows the same shape: a concrete prompt seeded from the spec, N candidates the builder picks or iterates on, an explicit human gate, and a clear answer to where the artefact physically lands.

The physical-landing story matters because it is the difference between a demo and a system. Today the creative output of a reskin is hand-written into client/src/assets.ts and hardcoded Tailwind styles, duplicated per variant — see the gaps table. The target the suite proposes is a shared client shell driven by theme tokens (build-changes #1), so a generated theme is read at runtime rather than baked into a forked client. Generative theme application only becomes clean once that shell exists.

The technical cluster

The code-side touchpoints are where generative AI meets the engine repo. They are higher-stakes than the creative cluster — output is code that ships — so they sit behind the one structurally-required engineering gate in the whole pipeline.

Variant codegen (Scaffolder). An approved GameSpec becomes a new games/<slug> folder and a PR into vhslab/standout-games. Crucially, the deterministic part of this already exists as a real CLI: scaffold-game copies the base game, rewrites package identities, re-IDs the manifest, and splices config overrides — the twelve banded steps traced in variant → live · the walkthrough. The Scaffolder agent wraps and triggers that CLI rather than free-styling source; the human gate is an engineer merging the PR (agent workforce), and the proposed scaffold-game v2 (build-changes #3) makes it audited and MCP-triggerable. This touchpoint surfaces in the flow at 01 · Build Path Picker.

Theme-application codegen. Generated theme tokens become client skin code. This is the code-side companion to the creative cluster's theme tokens, and it depends on the shared client shell (build-changes #1) for the same reason: without a shell that reads tokens at runtime, "apply the theme" means hand-editing a forked client, which no model should be trusted to do silently. With the shell, theme application is a small, reviewable token-file write.

Config drafting — the propose → simulate → prove loop. This is the single most important guardrail in the technical cluster, so it gets its own inline flow. A model may draft config deltas from intent, but it never asserts the resulting RTP. The number is established by the Math-Sim simulator replaying the certified RNG against the config; only the math owner's approval of that proof lets the RTP-sim gate pass. The model's role ends at "here is a config that might hit your target"; proof is the simulator's job. See 02 · Mechanic setup for the config-intent surface and 04 · Launch Lab for where proofs are exercised.

The 10M-round figure is illustrative of a proof-grade simulation run. The point is structural: a generated number is never a certified number — a simulation is. Note the open compliance question on whether simulating against the certified RNG carries recertification implications (architecture · open questions); the simulation harness itself does not exist yet (build-changes #5).

Validation explainers. On a failing gate, the model can produce a plain-language explanation of why it failed and what would fix it — the "Explain" half of the step-5 affordance. This is read-only: the Validation agent surfaces and explains, then dispatches a specialist for the actual fix (vision · step 5).

Info-sheet generation, both directions. The Info-Sheet agent runs forwards and backwards. Forwards (step 8): spec + sim proof + approved assets → a generated game info sheet and the cert-pack evidence narrative. Backwards (step 1): an uploaded PDF or screenshot set → extracted manifest fields with confidence, prefilling the spec for correction. Both directions are gated — compliance on generation, the builder on extraction — and neither is silently authoritative. The extraction direction has a full worked example at Import · Golden Galleon.

Guardrails — where generative AI must not act

• The certified RNG. Randomness comes from packages/game-rng — a SHA-256 hash-counter CSPRNG certified under GLI-19, with src/provably-fair.ts locked by CERTIFICATION.md and a BUILD_HASH verified at deploy. No model touches randomness. Config drafting changes the parameters around the RNG; it does not, and cannot, alter the RNG itself. The recertification question around even simulating against it is flagged open at architecture · open questions.
• Wallet and money movement. Bet authorisation, debit, credit, and rollback flow through the wallet adapter (HMAC-signed both directions, bet state machine in Postgres). No generated code participates in money movement; this is integration code with a certified contract, not a drafting surface.
• Final jurisdiction and compliance judgements. A model may draft a jurisdiction matrix or compliance narrative, but the judgement that a build is fit for a jurisdiction is a compliance-owner decision. The model assists the paperwork; it does not make the call.
• RTP claims. Only the simulator proves maths. A model never states an RTP as fact — it proposes a config and hands the number-finding to the propose → simulate → prove loop above. This is worth repeating because it is the most tempting line to cross.
• Provenance is mandatory. Every generated artefact is logged with its prompt, the model and version that produced it, and the human who approved it, in the audit trail. There is no un-attributed generation.

The autonomy ladder

Autonomy is not a property a touchpoint is born with — it is earned, per-touchpoint, by track record. A model starts assistive, and only climbs as its outputs prove reliable against the gate they sit behind. Promotion up the ladder is never assumed.

The principle: a touchpoint moves from assistive to autonomous · gated to autonomous only by demonstrating a clean track record behind its gate — and a touchpoint that affects money, randomness, or a certification claim never reaches the top rung regardless of record.

Where it surfaces in the Builder

This section is a directory, not new design — it maps each generative-AI touchpoint to the place it appears in the Builder UI. Every entry is described in full on the page it links to.