---
title: "Explanation: Playability Proofs"
description: "Why proof gates exist, why renderability is not playability, and how the v1 readiness ledger keeps every capability claim honest before launch."
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/explanation/playability-proofs/
---

# 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](project-graph.md), 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](../../../cycles/v1-engine-readiness-loop/PROOF_REGISTRY.json) 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](../../../spec/generated/world-build-contract.md) 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](../../../cycles/v1-engine-readiness-loop/PROOF_REGISTRY.json) 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](backend-authority.md)).
- **`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](../../../cycles/v1-engine-readiness-loop/PROOF_REGISTRY.json) 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](../../../cycles/v1-engine-readiness-loop/FEATURE_LEDGER.json). 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`.

{% proof class="runtime" registry="docs/cycles/v1-engine-readiness-loop/PROOF_REGISTRY.json" status="unaccepted" %}
The minimum runtime playability proof is camera, spawn, and possession under a live session, demonstrated by runtime room/session/snapshot receipts, not by graph presence or renderer pixels. The governing runtime/playability ledger rows are `unaccepted`; the playability contract is the bar the engine is closing toward, not a capability proven today.
{% /proof %}

## The World Build Contract acceptance barrier

For AI-built worlds, the [World Build Contract](../../../spec/generated/world-build-contract.md) 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.

{% warning severity="critical" title="not_run is not pass" %}
A capability with no current proof receipt is `not_run`. The engine never treats absence of evidence as a pass, never accepts a "playable" claim without runtime proof, and never accepts a visual-quality claim without a final-state capture taken after all content and repair mutations. Stale or fake proof artifacts are launch-blocking anti-patterns.
{% /warning %}

## 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/`](../../../cycles/v1-engine-readiness-loop/PROOF_REGISTRY.json):

- `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](../../../architecture/v1-engine-readiness-master-closure-contract.md), 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](../reference/runtime-playability.md): the runtime/readiness registries this page draws on.
- [Tutorial: Create a Playable Game](../tutorials/create-a-playable-game.md): extending a world into a game that ends in a Play proof.
- [Explanation: The Project Graph](project-graph.md): why graph presence is not runtime execution.
- [Explanation: Backend Authority](backend-authority.md): 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.