Explanation: Playability Proofs

A scene that renders is not a game. The discipline that keeps "playable" meaning something a runtime can demonstrate — rather than something a description asserts — is the engine's system of playability proofs. This page explains why those proof gates exist, what classes of proof the engine recognizes, how the v1 readiness ledger's acceptance states work, and why every row is currently unaccepted because the engine has never launched.

This is the page where Gessa's honest pre-launch stance is stated most directly. It is also the contract behind the rule that these docs describe the canonical flow and link to generated reference, but never claim a capability is finished, proven, or guaranteed today.

Renderability is not playability

It is easy to claim a world is "playable" because it draws on screen. But a world is a persistent stateful environment, not a scene, and the renderer is only one projection of it. A world can render beautifully while a player cannot spawn, cannot possess an entity, cannot move under a runtime-driven camera, and no typed score or win state ever changes. Pixels prove the renderer ran; they do not prove the game runs.

The proof registry encodes this distinction precisely. The renderer proof class explicitly rejects "nonblank canvas only" as evidence for a cinematic-quality claim, and the runtime proof class explicitly rejects "renderer pixels without runtime state proof for gameplay claims" and "a project graph resource exists." Graph presence is not runtime execution; a screenshot is not a play session.

For a playable spatial world specifically, the World Build Contract names the minimum: a playable spatial world requires a collision proxy, a nav/query proxy, a semantic anchor, and a playability.accepted receipt — and states outright that renderability alone is not playable proof. The minimum runtime evidence for the gameplay loop is camera, spawn, and possession under a live session.

Proof, not prose

In the v1 readiness model, a claim is accepted only when it is backed by evidence against code truth. A markdown description of a behavior is explicitly insufficient evidence. Each proof class in the registry defines its acceptance standard, what counts as insufficient evidence, the artifacts it must reference, and a freshness policy — proof must be re-run after relevant changes, so a stale receipt does not keep a claim alive.

This is why these docs link down to generated references and registries instead of restating capability claims: the prose is a map, the registries are the territory, and acceptance lives in the territory.

Proof classes

The proof registry defines the full set of proof classes a ledger row may require. A row lists exactly the classes its claim needs; acceptance requires all of them (or an explicit, reviewed residual-risk acceptance). A representative selection, in the registry's own terms:

• schema — the owned contract parses, validates, rejects invalid examples, and exposes a version coordinate.
• runtime — runtime authority executes the behavior; a graph resource existing is not enough.
• renderer — final-state capture from a supported lane matches the claimed visual tier; software/WebGL output cannot stand in for a WebGPU claim.
• browser — a real browser/Playwright run proves user-visible behavior with no ignored console/page/API errors.
• factory-proof — a real factory/demo runs end to end through canonical authoring, runtime, renderer, and provenance checks.
• mutation-authority — the row's mutable concepts have one canonical authority and forbidden bypasses are tested (the rule behind Backend Authority).
• version-coverage and compatibility — owned contracts carry version coordinates and a migration/rollback stance.
• idempotency — retry-sensitive mutations have replay protection and mismatch detection.
• independent-audit — a read-only reviewer attempts to falsify the row against code, artifacts, and checks; implementer self-attestation alone is insufficient.

The registry also defines migration, typecheck, unit, integration, frontend, db, ai-mcp-sdk, tool-ergonomics, visual-qa, performance, security, guardrail, and generated-docs. Read the proof registry for each class's exact acceptance standard; this page does not restate the table.

The readiness ledger and its acceptance states

The acceptance authority is the v1 feature ledger. Each row is a launch-critical (or explicitly non-critical) capability with a claim, a sourceOfTruth file list, versionCoordinates, a canonicalMutationAuthority, requiredProofClasses, and a status drawn from a fixed acceptance vocabulary:

• accepted — accepted with proof and guardrails; required proof classes satisfied.
• accepted_with_risk — accepted with explicit, reviewed residual risk and a recorded rationale.
• blocked — blocked with evidence of the blocker.
• deferred — explicitly out of v1 launch scope, with rationale.
• in_progress — an active row being worked.
• unaccepted — work not yet accepted.

A capability claim is permissible in docs only when its ledger row is accepted or accepted_with_risk. A row that is blocked, deferred, in_progress, or unaccepted must be described as a contract model or scaffold — never as a guarantee. That is the rule the future "public docs do not claim unaccepted capabilities" validation check will enforce against these pages.

Every row is currently unaccepted

The engine has never launched. All thirty-one rows in the current feature ledger are unaccepted. That includes the platform control plane, the ECS contract surface, the authoring transaction kernel, Script Semantic Patch, script source/visual parity, and typed gameplay state. Nothing in v1 is yet proven end to end against the new harness gates.

This is not a hedge; it is the contract. It means:

• These docs describe the canonical flow — the path a capability takes through canonical authoring, runtime, and proof — whose end-to-end runnable status tracks the ledger.
• No page asserts the engine is finished, fully proven, guaranteed, or ready for general use; capability claims wait on accepting ledger rows.
• Where a {% contract %} or {% proof %} block appears, its status reflects the ledger: unaccepted, in_progress, or planned — never accepted.

The World Build Contract acceptance barrier

For AI-built worlds, the World Build Contract is the acceptance barrier between "a world was generated" and "a world is accepted." Its policy is explicit and worth reading in full; the load-bearing rules:

• world.build.from_prompt and world.build.from_spatial_asset are the canonical build actions.
• An accepted build requires a semantic contract proof, Project Graph validation, visible unsupported requirements, passing QA receipts, and a timeline receipt — not merely a rendered result.
• Workbench product claims use explicit terminal states and a proof tri-state: missing proof is not_run, not pass. A claim with no proof has not passed; it has simply not been run.
• The most demanding claim, playable_game_factory, requires the full proof lane set — project_graph, script_behavior, typed_state, hud, player_control, observer_visual_qa, renderer_visual_qa, runtime_play, and factory_acceptance — before it may be accepted.

Why the gates exist

The proof gates exist so the engine does not ship the failure modes the closure work was created to prevent: a world accepted while Play opens stale ambient state, visual QA run before final content exists, "playable" claimed while Play diagnostics show missing camera/spawn/possession, or a renderer proof built from a pre-content receipt. Each such historical symptom becomes a deterministic guardrail or an explicit accepted risk rather than being waived because a prior cycle passed. The point is not "no bugs ever" — that is not real — but no unclassified partial systems and no unproven launch claims.

Where the gates live

The readiness registries are the source of truth for what is proven, all under docs/cycles/v1-engine-readiness-loop/:

• FEATURE_LEDGER.json — the rows being closed, their claims, required proof classes, and acceptance status.
• PROOF_REGISTRY.json — the proof classes, acceptance standards, insufficient-evidence rules, and freshness policies.
• GUARDRAIL_REGISTRY.json, VERSION_REGISTRY.json, and MUTATION_AUTHORITY_REGISTRY.json — the guardrail, version-coordinate, and single-authority bindings.

The governing run-book is the v1 engine readiness master closure contract, which defines the row-by-row loop and the global acceptance conditions the engine must clear before any v1-ready claim is permitted.

Related

• Reference: Runtime Playability — the runtime/readiness registries this page draws on.
• Tutorial: Create a Playable Game — extending a world into a game that ends in a Play proof.
• Explanation: The Project Graph — why graph presence is not runtime execution.
• Explanation: Backend Authority — the single-authority rule the mutation-authority proof class enforces.

Status: stable explanation page for engine v1. It states the engine's honest pre-launch stance: every readiness-ledger row is currently unaccepted, and no capability described here is claimed as finished or proven today.