---
title: "Reference: Runtime Playability"
description: "Reference for what counts as runtime playability in v1, the playability gate checks, the proof classes that back them, and the netcode refresh/rejoin contract."
engineVersion: v1.0.234
date: 2026-09-28
license: "(c) Gessa, proprietary. Cite with attribution to https://gessa.ai/docs/. Terms: https://gessa.ai/terms/."
canonical: https://gessa.ai/docs/reference/runtime-playability/
---

# 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/`](../../../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.

{% proof class="runtime" registry="docs/cycles/v1-engine-readiness-loop/PROOF_REGISTRY.json" status="unaccepted" %}
A playable claim requires the `runtime` proof class ("Runtime authority executes the behavior, not just persisted graph presence") backed by room/session/snapshot/proof receipts, plus the `browser`, `integration`, `performance`, and `guardrail` classes for runtime.playability.admission. A markdown description is explicitly insufficient evidence. The runtime.playability.admission ledger row is currently unaccepted.
{% /proof %}

{% warning severity="critical" title="Rendering is not playability" %}
A world that renders may still fail the gate: it can lack an active camera, declare no possessable entity, or update transforms without runtime authority. Never claim a world is playable on the strength of a screenshot, claim it only against passing gate checks and an accepting ledger row.
{% /warning %}

## 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](../explanation/backend-authority.md).

## 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](../explanation/versioning-policy.md).

## Related

- [Explanation: Playability Proofs](../explanation/playability-proofs.md): why these gates exist and what "proof, not prose" means.
- [Tutorial: Create a Playable Game](../tutorials/create-a-playable-game.md): reaching a playability proof in practice.
- [Explanation: Backend Authority](../explanation/backend-authority.md): 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.