How-To: Publish and Play

Publish a world, enter Play, and handle the normal lifecycle: reconnecting after a dropped session and reloading after an edit. The thread running through every step is that the frontend is a non-authoritative projection, the runtime owns the session, and the client re-derives from authoritative state. You trust the backend receipt, never the client's local picture.

This page describes the canonical publish-and-Play flow for v1. The engine is pre-launch: its readiness rows are all unaccepted, and "publishable" or "playable" is a contract model here, not a guarantee that a given world runs end-to-end today. Status tracks the v1 readiness ledger.

Publishing is gated, not automatic

Publishing promotes a project graph to a deployment that a Play session can run against. It is not a copy step, it passes a gate first. The relevant surfaces:

• Script publish gate. script_publish_gate runs the script publish-gate checks for a game and surfaces blockers before a deployment is created. Run it first; a script blocker should stop the publish, not the Play session.
• Create the deployment. runtime_create_deployment publishes a project graph as a deployment (action surfaces include deployment.redeploy to redeploy a content version and deployment.rollback to revert). These are mcp:admin / publish-domain operations: they are deliberately not in the everyday mcp:write set.
• Open a room. runtime_create_room creates a Runtime room for a deployment; a Play session connects to that room.

The publish-and-Play recipe

The frontend is non-authoritative, trust the receipt

None of these steps let the client become a second source of truth. Publish, Play, reconnect, and reload all re-derive from backend authority:

• Publish promotes authoritative state; the client does not "own" the published version.
• Play is runtime-driven; the client renders a projection.
• Reconnect re-syncs to the authoritative snapshot rather than reconstructing from local memory.
• Reload re-projects from the latest published content.

This is the same backend-authority discipline that governs editing, see Explanation: Backend Authority. The runtime, the publish gate, and the deployment lifecycle are owned by the server runtime modules (server/src/modules/runtime); there is no single generator for runtime playability, so its source of truth is those modules plus the readiness registries.

What "playable" formally means

In v1, a world is playable only when runtime evidence holds under a live session, and that evidence is recorded as a proof, not asserted in prose. The minimum runtime proof is camera, spawn, and possession under a live session, runnable via the runtime.proof.run action.

The readiness registries are the source of truth for what is proven: FEATURE_LEDGER.json, PROOF_REGISTRY.json, and the others under docs/cycles/v1-engine-readiness-loop/.

Related

• Reference: Runtime Playability: the playability criteria and the registries that gate them.
• Explanation: Playability Proofs: why proof, not prose, decides "playable".
• Explanation: Backend Authority: why reconnect and reload re-derive from authority.
• How-To: Use MCP Tools: the deployment and room tools used above.

Status: this page documents the canonical publish-and-Play flow for v1. The engine is pre-launch; "publishable" and "playable" are contract models whose end-to-end runnable status tracks the v1 readiness ledger.