Reference: Runtime Playability

Runtime playability is the contract for when a Gessa world is playable — provably driven by runtime authority, not merely rendered. Unlike the component, action, or script references, playability has no single generated file; its source of truth is the runtime code plus the v1 readiness registries. This page explains where that truth lives, what counts as playability proof, and the netcode refresh/rejoin contract. It frames the contract and the canonical flow; whether the flow runs end to end today tracks the readiness ledger, every row of which is currently unaccepted.

Source of truth

Playability is owned in two places:

• The runtime modules in server/src/modules/runtime — the authoritative simulation, admission, and session lifecycle. The playability contract is enforced by server/src/modules/runtime/playabilityGate.ts, and admission is owned by server/src/modules/runtime/admissionService.ts.
• The v1 readiness registries under docs/cycles/v1-engine-readiness-loop/ — in particular FEATURE_LEDGER.json (what is being closed), PROOF_REGISTRY.json (the proof classes and their acceptance standards), GUARDRAIL_REGISTRY.json, VERSION_REGISTRY.json, and MUTATION_AUTHORITY_REGISTRY.json.

The ledger row that governs this contract is runtime.playability.admission ("Runtime Playability And Admission"), whose claim is that published/play worlds admit users, bind the requested world, and prove camera/player/control/runtime diagnostics for a playable claim. Its required proof classes are runtime, browser, integration, performance, guardrail, version-coverage, and mutation-authority.

What counts as playability proof

A scene that draws on screen is not a game. The runtime playability gate (playabilityGate.ts) demands that runtime authority — not persisted Project Graph presence — demonstrates the claimed behavior under a live session. The gate runs a set of named checks; a world is playable only when the required checks pass. The current check keys include:

• admission — a session is actually admitted into the running world.
• first_snapshot — the runtime emits an initial authoritative snapshot.
• camera — the authored scene declares an active, runtime-driven camera.
• possession — an entity declares a player/controllable/input-action candidate and input binds to it, so a player can move and act.
• movement_input and movement_collision_participation — input drives motion and the controlled entity participates in collision (a collision proxy: proof that movement interacts with the world, not just transforms in isolation).
• physics_public_surface_parity and physics_dynamic_transform_authority — the physics public surface (for example ctx.physics.occupancyQuery, the nav/query proxy) matches the contract, and dynamic transforms are runtime-authoritative.
• start_transition and reconnect_resume — the start action transitions the world into play and a reconnect resumes the existing session.
• always_relevant_scene, renderer_nonblank, and hud_projection — the scene has always-relevant content, renders non-blank, and HUD/UI projects correctly.

These map onto the conceptual proof families a playable claim must satisfy: a collision proxy (movement participates in collision), a nav/query proxy (the physics/occupancy query surface is contract-faithful), and a semantic anchor (the world binds the requested content and an entity is genuinely possessable). A playability.accepted claim is admissible only when these gate checks pass under runtime authority and the evidence is recorded against an accepting runtime.playability.admission ledger row.

The netcode refresh/rejoin contract

Admission and re-admission are owned by admissionService.ts. The contract distinguishes a fresh join from a resume:

• Admission intents. A request carries an intent — play_session for a fresh join, reconnect for a resume — and admission is serialized per session so concurrent attempts cannot race.
• World binding. Admission binds the session to the requested world and content version; a playable claim must prove the runtime bound the right world, not just any world.
• Resume lease. An admitted session receives a lease with a resumeUntil deadline (governed by a resume TTL). On a page refresh or transient disconnect, a reconnect intent inside the resume window restores the existing session and resumes from the authoritative snapshot rather than starting over; outside the window, the session must be re-established. This is the behavior the reconnect_resume gate check exercises.

The frontend is a non-authoritative projection: it requests admission, renders the runtime's authoritative snapshots, and resumes via the lease — it never owns world state. See Explanation: Backend Authority.

Version pinning

Playability has no single hash-pinned generated file; instead it is pinned by the registry coordinates. PROOF_REGISTRY.json carries registryVersion v1-engine-readiness-proof-registry.v1, and FEATURE_LEDGER.json carries its own ledgerVersion; the runtime.playability.admission row records its versionCoordinates, sourceOfTruth files, and requiredProofClasses. Cite the ledger row id and the registry versions for an exact contract snapshot. These align to packages/engine-version and the generated docs export manifest; see Versioning Policy.

Related

• Explanation: Playability Proofs — why these gates exist and what "proof, not prose" means.
• Tutorial: Create a Playable Game — reaching a playability proof in practice.
• Explanation: Backend Authority — the frontend as a non-authoritative projection.

Status: stable orientation page. Playability is gated by runtime code and the readiness registries; trust the gate (server/src/modules/runtime/playabilityGate.ts) and the registries over any prose here. Every readiness-ledger row is currently unaccepted, so this page describes the contract and canonical flow, not a guarantee that the flow runs end to end today.