# Pajama Engine whitepaper · LLM reading context
Canonical source: https://engine.pajama.studio/whitepaper/en
Edition: 1.20
Published: 2026-10-01
Language: English
Historical core baseline: 026acf9fec8946f8f418c8320a4ea24e1434bb9f (2026-09-12)
This context contains the complete whitepaper, research references and runtime evidence links. Implementation references are pinned individually; core, later authoring, terrain audit and planning sources may use different revisions. September 24–25 working-tree changes have separate hashed architecture and runtime records. Historical Package recordings, live Jev sessions and deterministic native applications identify their separate scopes. Files and images are linked, with no binary data embedded.
Implementation references and revisions: https://engine.pajama.studio/whitepaper/citations.json
Research references: https://engine.pajama.studio/whitepaper/research.json
Runtime evidence and SHA-256: https://engine.pajama.studio/whitepaper/evidence.json
---
# Pajama Engine
An AI-native MMO game engine: shared physical worlds, live content creation and recoverable change.
## 01 · Vision and product direction {#overview}
### A foundation for worlds that keep evolving {#product-vision}
**Pajama Engine is the AI-native MMO game engine we are building for persistent, programmable shared worlds.** Its Rust runtime combines authoritative simulation, physics, rendering and content delivery. Structured authoring interfaces let developers and agents extend a world through explicit validation and publication. The native client uses winit and wgpu; a planned observation layer connects this foundation to learned models. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [2](https://engine.pajama.studio/whitepaper/en#source-client-manifest) [3](https://engine.pajama.studio/whitepaper/en#source-world-model-direction)
The vision is a world that continues to develop through use: players change its terrain, creators introduce new mechanics, and new visual systems give it different forms of expression. Those changes should build on a shared history. An object should remain the same object after a content update; a player's actions should retain their consequences after a server restart.
Space should also extend with exploration: players travel away and return to the structures they built and terrain they excavated. Here, an “infinite world” means **a continually extensible, revisitable world operating within finite budgets**. The implementation still has a finite terrain domain; [terrain status and intent](https://engine.pajama.studio/whitepaper/en#terrain-bounds) and [expansion acceptance](https://engine.pajama.studio/whitepaper/en#world-expansion) identify the remaining work. This extension serves the existing Package and persistent-world goal. [1](https://engine.pajama.studio/whitepaper/en#source-goal)
| Design commitment | Meaning in Pajama |
| --- | --- |
| Game engine | Explicit world state, gameplay rules, physical simulation and a native playable presentation. |
| AI-native | Discoverable, typed interfaces for inspecting capabilities, proposing content, validating changes and observing results; the complete package authoring workflow remains under development. |
| World-model-friendly | An architecture designed to expose versioned state, action and observation records for model training, evaluation and generated presentation; the bridge is a planned subsystem. |
In world-model research, learned representations support prediction and control. Pajama supplies an executable environment and proposes interfaces to such models. The first integration concerns **learned visual output conditioned on engine state**; learning the world's transition rules is a separate research capability. [R1](https://engine.pajama.studio/whitepaper/en#research-world-models)
### One world, two paths to presentation
Pajama's development combines **traditional engine systems with model-generated presentation**. The engine maintains entities, collision, gameplay and persistent state. Traditional rendering makes that state immediately playable. The planned model path turns synchronized observations of the same state into generated imagery, with candidates compared by task: Wan for adaptation and cost first, H3 for conditioning and quality, and SANA-Streaming for video transformation. [3](https://engine.pajama.studio/whitepaper/en#source-world-model-direction)
Consider a wall destroyed during play. Simulation establishes the opening and changes collision; persistence preserves the result. The renderer displays that geometry. A state-conditioned video model would receive observations of the same geometry and camera to generate its appearance. Evaluation checks whether the generated opening actually agrees with the world. This division gives evolving visual systems a stable simulation reference.
### From creation to a living world
The core unit of extension is a **versioned package**: a collection of assets, reusable objects and bounded behavior. Authors prepare a package; the server validates and activates it; clients acquire the matching resources; recovery preserves the associated world and behavior state. This lifecycle gives human and agent authoring a common path from an idea to a persistent capability. [4](https://engine.pajama.studio/whitepaper/en#source-package-contract) [5](https://engine.pajama.studio/whitepaper/en#source-admission) [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint)
The platform is designed for teams building multiplayer experiences, creators developing reusable content, and researchers working with interactive models. Its long-term value lies in connecting creation, reliable operation and visual generation through the same world representation.
The architecture below explains that foundation. The following status section identifies the implemented systems and current integration work; the development roadmap describes how they grow into a complete runtime and model output layer.
### What “AI-native MMO” means here {#product-scope}
Agents can **act in the world** through ordinary authorized player actions, and **create for the world** through typed, reviewable Package candidates. These two loops meet at one server authority. Models, tools and generators stay outside the simulation tick; their outputs gain effect only through an admitted capability or publication transaction.
MMO names the product direction: shared history, persistent objects, many participants and ongoing content delivery. The current demonstrations establish local multi-client behavior. They do not establish production MMO capacity, seamless world partitioning or a public hosting SLA. The first-party game `trenchline` is a proof environment for this runtime. World-model presentation remains a separate research track. [1](https://engine.pajama.studio/whitepaper/en#source-goal)
## 02 · System architecture {#architecture}
The architecture connects three responsibilities: **creating content, running the world and presenting its state**. A package carries a creator's changes into the server. The server applies accepted behavior and physical interactions, then produces the state clients display and checkpoints preserve. The planned model output layer connects to this same presentation boundary.
- **Authoring input** — Human · agent · build pipeline; Frozen input → exact candidate digest
- **Admission & publication** — Strict validation · realm policy · CAS; Prepared candidate → tick activation
- **Authoritative runtime** — World · typed behavior · physics; One world / one writer
- **Composite checkpoint** — World + content + script state; Durability, recovery & epoch fencing
- **Exact content delivery** — Catalog · digests · bounded cache; Verify → decode → hidden staging
- **Client presentation** — Mirror · animation · RenderSnapshot; Whole resource generation → wgpu
### Three cooperating planes
The **simulation plane** owns the live world: entity identity, gameplay decisions, physics integration and replication. The **control and content plane** coordinates admitted releases, authority leases, immutable objects and durable metadata. The **presentation plane** turns a client's replicated state and verified resources into animation and rendered frames. Rust owns simulation; the TypeScript Edge prototype provides control/content coordination. [7](https://engine.pajama.studio/whitepaper/en#source-backend-status) [8](https://engine.pajama.studio/whitepaper/en#source-tick) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation)
Server authority and client presentation are established multiplayer design choices; Unreal Engine documents this division for state, collision and visual effects. Pajama extends that separation to a prospective learned presentation service, while retaining gameplay decisions in the server. This is an architectural precedent, with Pajama's implementation evidence identified separately below. [R2](https://engine.pajama.studio/whitepaper/en#research-unreal-networking)
This division separates workloads with different lifetimes. A simulation tick needs predictable ordering. A download may be slow or retried. A content update may outlive the request that initiated it. Connecting them through exact identities and bounded handoffs lets each progress under its own scheduling constraints. The boxes describe logical ownership; thread placement is specified separately by each subsystem. [10](https://engine.pajama.studio/whitepaper/en#source-delivery-owner) [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [11](https://engine.pajama.studio/whitepaper/en#source-render-design)
| Module | Primary responsibility | Boundary presented to other modules |
| --- | --- | --- |
| `pajama-world` | Stable game-neutral documents, entity IDs and wire types | Serializable meaning and explicit versions |
| `pajama-content` | Untrusted archive staging and dependency resolution | Verified, immutable candidate content |
| `pajama-server` | Simulation, package activation, replication and persistence coordination | Authoritative commands, state and lifecycle results |
| `pajama-script` | Bounded Luau execution | Immutable frames, typed state and typed commands |
| `pajama-client` | Replicated mirror, content acquisition and local presentation | Exact resource requests and render-relevant state |
| `pajama-physics` | Solver integration | The `Physics` interface and derived poses |
| `pajama-render` | Render planning, resource lifetime and GPU execution | Compiled pipelines and render snapshots |
| `pajama-edge` | Local control-plane and content-plane prototype | Lease, publication and immutable-object protocols |
Module definitions and entry points: [12](https://engine.pajama.studio/whitepaper/en#source-workspace) [13](https://engine.pajama.studio/whitepaper/en#source-staging) [14](https://engine.pajama.studio/whitepaper/en#source-script-contract) [15](https://engine.pajama.studio/whitepaper/en#source-physics-trait) [16](https://engine.pajama.studio/whitepaper/en#source-render-snapshot).
### Two flows meet at the authoritative world
During **ordinary play**, accepted input and installed behavior advance world state; physics and other systems produce derived results; replication sends the relevant changes to each client. During **content publication**, a prepared package candidate becomes eligible for activation at a tick boundary. That changes the definitions available to subsequent gameplay and the catalog clients use to resolve presentation. Both flows participate in the same authoritative lifecycle. [8](https://engine.pajama.studio/whitepaper/en#source-tick) [17](https://engine.pajama.studio/whitepaper/en#source-publication) [18](https://engine.pajama.studio/whitepaper/en#source-replication)
### Two agent loops, one commit authority {#runtime-loops}
| Loop | Work outside the tick | Authoritative boundary | Result to observe |
| --- | --- | --- | --- |
| Acting | Read permitted observations; choose a skill or expiring driving intent. | Session, freshness, capability and world-state checks; native control and typed commands. | Accepted/rejected action, actual movement or terrain change, replicated outcome. |
| Authoring | Generate assets, solve constraints, compile behavior, prepare and inspect exact candidate bytes. | Existing cold stage, realm admission, generation CAS, composite checkpoint and tick activation. | Exact active Package, client readiness, gameplay postcondition and recoverability. |
The fast feedback loop remains native. Remote inference chooses a bounded driving maneuver; the server controller uses current physics feedback. Layout search runs in the cold compiler; the server consumes a verified prefab. A new wheel recipe can use an installed vehicle adapter. A new native physics or renderer capability requires an engine change and compatibility evidence, rather than unrestricted Package code loading.
This separates extension by **data and bounded behavior**, extension by **registered native capability**, and proposed **external model presentation**. The [dated implementation documents](https://engine.pajama.studio/whitepaper/en#evidence-architecture-update) describe each boundary. Neither an MCP tool nor an authoring agent owns a second world writer.
### Architecture priorities {#architecture-priorities}
The architecture has a clear strength: world outcomes have one authority, content has an exact identity, and models can connect through an established presentation boundary. The next engineering gains come from cross-system contracts and their validation: take one playable Package through publication and recovery, then export the same world history as trustworthy model input. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [19](https://engine.pajama.studio/whitepaper/en#source-roadmap)
| Priority | Contract to complete | Acceptance evidence |
| --- | --- | --- |
| Content continuity | Instance version policy, behavior-state migration and historical resource retention. | The same instance remains interpretable and usable through update, rollback, cleanup and restart. |
| Bounded creation | Aggregate budgets for ongoing generation and correlated publication receipts. | Sustained construction and lost-response tests show bounded growth and reconcilable outcomes. |
| Trustworthy model input | Aligned observations, durability progress and output validity. | Pass capture/read-back checks without a model before testing model conditioning. |
| Extensible world space | Global addressing, local residency, chunk persistence and geometry readiness. | Travel beyond residency, return after eviction and restart, and retain edits within declared runtime budgets. |
These are integration priorities for M1–M6 below. Runtime evidence and each milestone's completion criteria define their implementation status.
## 03 · Current progress {#status}
**Edition 1.19 · evidence reviewed September 25, 2026.** The runtime now has recorded demonstrations of physical driving, live vehicle additions, bounded constraint construction, real terrain edits, prepared-candidate publication, concurrent author conflicts and checkpoint recovery. The eight new product clips below exercise the same Package boundary with a more consistent native visual treatment.
The pinned architecture sources retain baseline **026acf9** (2026-09-12) and their later individual revisions. September 24–25 additions come from the existing uncommitted engine workspace and retain their own source/artifact hashes. This is a dated integration snapshot, not a claim that one old commit contains all current code. [19](https://engine.pajama.studio/whitepaper/en#source-roadmap) [20](https://engine.pajama.studio/whitepaper/en#source-building-rehearsal) [21](https://engine.pajama.studio/whitepaper/en#source-building-probe)
| Capability | Demonstrated now | Remaining boundary |
| --- | --- | --- |
| Jev acting | Four live model-driven vehicles and a fifth terrain-skill agent in the earlier fleet run. | Stable third-party agent sessions, durable planner handoff and fleet-scale capacity. |
| Prepared authoring | Freeze input and compiler identity; inspect candidate; publish exact digest; reconcile lost response. | Cold preparation does not preview a world or prove admission; remote production publication stays gated. |
| Dynamic vehicles | Bound body/wheel assets, materialized physical recipes, two retained cars plus two new types. | Four-wheel adapter with gameplay stabilization; no automotive-grade tire/powertrain fidelity or generic live recipe migration. |
| Constraint generation | Finite grid, independent placement checks and Package output; eight-module camp. | Terrain support, arbitrary geometry, road accessibility and general optimization remain separate solver work. |
| Live construction | Separate expansion Package; append-only construction progress survives a behavior update. | Reordering/deleting commands is not covered by that progress helper. |
| Conflicting authors | One stale generation is rejected; a new immutable request rebases. | General semantic merge and autonomous multi-agent co-design. |
| Recovery | Primitive authoring restores 24 entities; new native scene restores 15 exact instances under epoch 2. | Player/agent session recovery, production failover and arbitrary historical GLB retention. |
| Client presentation | Exact admitted old vehicle resources stay visible while successor assets load. | Catalog V2 is still an explicit experimental opt-in; normal release readiness remains open. |
Current contracts and proposal boundaries are collected in [architecture evidence](https://engine.pajama.studio/whitepaper/en#evidence-architecture-update).
### Eight practical applications {#practical-scenarios}
Each clip is a separate real native run, with an authoritative server, actual local Edge services and two native observation clients. The published view is the main camera. The scenarios use **deterministic authored recipes and ordinary client driving inputs**, not fresh live Jev calls. The earlier live-model fleet demonstration remains separately attributed below.
Videos run at **1.0× capture time**, encoded at 60 fps, for 32–42.5 seconds. Actual main-camera sampling is 59.772–60.005 fps, with maximum recorded intervals of 24–63 ms depending on the run. Missing samples hold the previous image. Recovery contains two captures and an explicitly labeled restart card. These numbers describe the local capture workload, not a production performance SLA.
#### Emergency camp
Eight connected modules are solved from adjacency, separation and exclusion constraints, then built in the authoritative world.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 39.98 s, 60 fps encoding; measured main-camera capture 60.005 fps, maximum sampled interval 26 ms. Deterministic recipes and normal inputs, not live model decisions. Capture follows wall time; missing slots hold the previous frame. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[01-emergency-camp.mp4 ↓]() — Video · 13.6 MB
Emergency camp: native product demonstration at 1.0× time.
SHA-256: `076b173894017e15ff5a0ddc659a1c4dcf2b71b570fde7324a3559dd1e30d81d`
![Emergency camp, frame from the native recording.]()
Emergency camp, frame from the native recording.
[01-emergency-camp.png ↓]() — Image · 671.9 KB
SHA-256: `9eb955b842bc2f3452dfdcec96d302d65cf2185bd1f4e0a45dc628f4c4fa138f`
[01-emergency-camp-proof.json ↓]() — Data · 30.8 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `e3ca9383f832b96b1cdf25e232c47b3c97bebb47d2ea934779876ee179472369`
[Evidence manifest]()
#### Bridge repair
A physical SUV crosses a modular bridge over excavated terrain and settles on the far bank.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 31.99 s, 60 fps encoding; measured main-camera capture 59.772 fps, maximum sampled interval 51 ms. Deterministic recipes and normal inputs, not live model decisions. Capture follows wall time; missing slots hold the previous frame. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[02-bridge-repair.mp4 ↓]() — Video · 10.8 MB
Bridge repair: native product demonstration at 1.0× time.
SHA-256: `3247ff8aee7b73a5129b1aa6175e4cfd4c52a67e814e3b5dbaf12ab4b640876c`
![Bridge repair, frame from the native recording.]()
Bridge repair, frame from the native recording.
[02-bridge-repair.png ↓]() — Image · 612.5 KB
SHA-256: `9c9ba99c51ca3fd166d07b2281d31dd6e9241d830f43213e20298f7c4ce8e67a`
[02-bridge-repair-proof.json ↓]() — Data · 145.1 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `d8b28970f829c05220f1288a211795481f0ec2a77acdd0c1cec8fdc30250ef7b`
[Evidence manifest]()
#### Convoy supply
An SUV and pickup keep moving while a live Package adds a sports car and a van.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 39.98 s, 60 fps encoding; measured main-camera capture 59.924 fps, maximum sampled interval 63 ms. Deterministic recipes and normal inputs, not live model decisions. Capture follows wall time; missing slots hold the previous frame. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[03-convoy-supply.mp4 ↓]() — Video · 7.7 MB
Convoy supply: native product demonstration at 1.0× time.
SHA-256: `59a6b7512621214fbecf40fee0571a34a91be281143576adcafc55460b2dc4c8`
![Convoy supply, frame from the native recording.]()
Convoy supply, frame from the native recording.
[03-convoy-supply.png ↓]() — Image · 576.2 KB
SHA-256: `673c1ad6d26dcfef3fa1edc33ea211cbf94797d6e46cd9fee33b3ef8be1a29fa`
[03-convoy-supply-proof.json ↓]() — Data · 575.6 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `d265991f4c62e80d6a1be2c78f3f1ecb3ab910810489dff3bf6388bffcacbe7f`
[Evidence manifest]()
#### Rewilding
Twelve saplings grow into one server-owned grove observed by two clients.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 39.98 s, 60 fps encoding; measured main-camera capture 59.999 fps, maximum sampled interval 31 ms. Deterministic recipes and normal inputs, not live model decisions. Capture follows wall time; missing slots hold the previous frame. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[04-rewilding.mp4 ↓]() — Video · 11.6 MB
Rewilding: native product demonstration at 1.0× time.
SHA-256: `61c237b23bb0d47d88d0ef7df5783a5bfce45a0689e2913e1ae224185b64738e`
![Rewilding, frame from the native recording.]()
Rewilding, frame from the native recording.
[04-rewilding.png ↓]() — Image · 519.7 KB
SHA-256: `50248b2e8f1d26a04fbb8659fd9fce25b1e86cccd796a360c92e387ff2985e14`
[04-rewilding-proof.json ↓]() — Data · 18.9 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `4d58a088391ac4e3ac7a2bbc5ff2dc5e875baa4489fae160929d8b6adb8bc88a`
[Evidence manifest]()
#### Live expansion
An unchanged core camp receives a separate expansion Package and its successor.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 39.99 s, 60 fps encoding; measured main-camera capture 59.990 fps, maximum sampled interval 25 ms. Deterministic recipes and normal inputs, not live model decisions. Capture follows wall time; missing slots hold the previous frame. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[05-live-expansion.mp4 ↓]() — Video · 13.4 MB
Live expansion: native product demonstration at 1.0× time.
SHA-256: `cb774dffb5a344aa3b3f1cef136670c70c30ddb2bef69dd79549195ee0fde88f`
![Live expansion, frame from the native recording.]()
Live expansion, frame from the native recording.
[05-live-expansion.png ↓]() — Image · 618.3 KB
SHA-256: `175b28d8fc342e46ccce25105df5657346b6f9a8acf95ab4bb4d01db9bf07683`
[05-live-expansion-proof.json ↓]() — Data · 36.6 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `c0d00cf8beeef648a090c9014272288ff3d41655b2a74667eed85835fb24678d`
[Evidence manifest]()
#### Terrain training
Five berms and three craters alter authoritative terrain and trigger fresh collision installations.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 39.98 s, 60 fps encoding; measured main-camera capture 60.001 fps, maximum sampled interval 30 ms. Deterministic recipes and normal inputs, not live model decisions. Capture follows wall time; missing slots hold the previous frame. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[06-terrain-training.mp4 ↓]() — Video · 12.3 MB
Terrain training: native product demonstration at 1.0× time.
SHA-256: `cf8bec38146a3c82413041af6b79b84c9407bf219f6cf39043643aae595023bf`
![Terrain training, frame from the native recording.]()
Terrain training, frame from the native recording.
[06-terrain-training.png ↓]() — Image · 571.0 KB
SHA-256: `043bd78b9b9cb4cf0a1b12c44fcf53d6c13d6ab7d01b4a81ff754fa81d9575d8`
[06-terrain-training-proof.json ↓]() — Data · 26.9 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `709eb3052c40eb20b31dc1e9821b49d4576ff38936467856274a0bf8bddd7b06`
[Evidence manifest]()
#### Coauthor district
Two prepared plans share one base generation. One conflicts, rebases under a new request, and completes the district.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 39.99 s, 60 fps encoding; measured main-camera capture 59.990 fps, maximum sampled interval 27 ms. Deterministic recipes and normal inputs, not live model decisions. Capture follows wall time; missing slots hold the previous frame. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[07-coauthor-district.mp4 ↓]() — Video · 12.4 MB
Coauthor district: native product demonstration at 1.0× time.
SHA-256: `4215cf080fd0356ecdbd93dff4aa26fcf33b2ddd614d24e54597615210f62d45`
![Coauthor district, frame from the native recording.]()
Coauthor district, frame from the native recording.
[07-coauthor-district.png ↓]() — Image · 607.5 KB
SHA-256: `65d6034966443ca3bad27b4ca0acabfe80a81da06a2ec3ebe0b09dd1c28ff9e1`
[07-coauthor-district-proof.json ↓]() — Data · 31.7 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `97c5e93616c41d817a6533ba26240c0e699fb75f89945df2518fdb2831281fa1`
[Evidence manifest]()
#### Durable world
After verifying the committed checkpoint, a restarted authority restores all fifteen scene instances with their identities and transforms.
**Provenance:** Recorded September 25, 2026 in an isolated local world with real Edge, native authority and two native observation clients. 42.47 s, 60 fps encoding; measured main-camera capture 59.992 fps, maximum sampled interval 24 ms. Deterministic recipes and normal inputs, not live model decisions. Two recordings separated by a labeled 2.5-second restart card; waiting is omitted. Vehicle assets: Kenney (CC0); building/utility geometry authored for this suite.
[08-durable-world.mp4 ↓]() — Video · 10.9 MB
Durable world: native product demonstration at 1.0× time.
SHA-256: `0a8a183e8cd0294a14fc190acf09adcb80ee0f04f632f5a45ed85b6502ca9958`
![Durable world, frame from the native recording.]()
Durable world, frame from the native recording.
[08-durable-world.png ↓]() — Image · 587.2 KB
SHA-256: `4aa35751b5ef4f7aa5697e593ebc7dbf55c90e7a926443544f9de2fc23bf3c33`
[08-durable-world-proof.json ↓]() — Data · 37.8 KB
Publication identities, world observations and capture cadence; curated public projection.
SHA-256: `c0d3437a28b40f111b824c4e170007621919287b482275a1b7151ef02d180ccf`
[Evidence manifest]()
### A running world, captured by the native client {#runtime-evidence}
This research station is assembled inside a running multiplayer world. A versioned Package supplies reusable structural parts, a Luau construction policy and a player skill. The native renderer presents the resulting entities, terrain, vegetation and connected players. The [case study](https://engine.pajama.studio/whitepaper/en#walkthrough) follows the same run from an empty site to construction and damage.
#### A package running inside a shared world
A native-client view from the September 21 rehearsal shows the completed building and its surrounding playable world. The next record follows the construction that produced it.
**Provenance:** Original 1920 × 1080 presented-swapchain capture, copied unchanged from construction/live-build/left\_007.png. The companion public receipt records the camera, capture time and replication tick. The on-screen FPS is a momentary diagnostic, not a benchmark.
![Native game view of a teal and orange multi-storey building with an attached tower in a grassy landscape.]()
Native client after the package construction completes: a multi-storey building, observation tower, terrain and two connected players.
[station-complete.png ↓]() — Image · 2.5 MB
SHA-256: `694d8465d5118b380758cbfbceb2509b2db839389108bba816062981f1b1c01f`
[Evidence manifest]()
### Earlier live-agent and lifecycle demonstrations {#demo-gallery}
Ten independently executed scenarios connect live Jev decisions, Package generation, player actions, construction, collaborative authoring and recovery to observable results. The four-vehicle, dual-vehicle and Jev clips preserve **1.0× real time**. The Jev clip separates model round-trip from server receipt latency. The next six clips use **1.25× speed**; the final clip is explicitly a **still-image lifecycle evidence replay**. These separate runs do not represent one uninterrupted server session. Start playback manually. Source downloads require a compatible engine checkout and dependencies; the shared guide includes narration and reproduction commands.
#### Four Jevs: expand a moving fleet through a live Package update
A green SUV and orange pickup drive while the same Package advances from V1 to V2 through admission, CAS and tick activation. A blue sports sedan and yellow van then join, with 26.2 seconds of measured simultaneous progress. Four independent native chase views retain the full vehicles and hide mounted occupants.
**Provenance:** Local four-client Edge rehearsal with live hosted OpenRouter Jev decisions. V1 vehicle IDs, drivers, recipes and physics incarnations remain unchanged; new cars use exact V2 pins. Admitted retention keeps verified V1 meshes visible while V2 assets load, fixing the temporary pink-placeholder regression. Every native capture slot and intervening driving presentation is verified, including all five old-car draw parts through publication. This demonstrates content addition with immediate rollback retention, not arbitrary history or live recipe migration. Frame performance describes this hardware and network run.
[demo-fleet-driving.mp4 ↓]() — Video · 21.8 MB
Four simultaneous chase views; live V1 to V2 update at 1.0× real time, 60 FPS.
SHA-256: `6b6a5a91473cace1ac3ce27a05869b8bcad02f98f7906779e8ee716d6fadce89`
[demo-fleet-driving-receipt.json ↓]() — Data · 2.7 MB
Package revisions, retained instance identities, driving and native frame measurements.
SHA-256: `7fb9cc1fbb5fbe392e5253bc3ec4b61c91d56a12142345f557e271c7b5825232`
[demo-fleet-driving-source.zip ↓]() — Source · 1.2 MB
Exact source excerpts and bound CC0 vehicle parts used by this run; not a complete build environment.
SHA-256: `9fc252553fd07803b9cee4dece5943b4d342bdd64588c8f9227e4760bfd03721`
[FOUR\_VEHICLE\_PACKAGE\_RECORDING.md ↓]() — Source · 5.0 KB
Recording, publication and verification procedure.
SHA-256: `ab167cdfc957d3e87bef1cb466f67c995a7c6afd065313ed9f704191db12b148`
[Evidence manifest]()
#### Two Jev drivers, one trail saboteur
Two different vehicle Packages traverse uneven terrain simultaneously. Each native client follows its own complete vehicle in third person. Mounted car drivers and their held objects are hidden, and return on dismount. A third live Jev role chooses where to excavate real terrain beside the moving cars. The original explosion stalls coupled all vehicle movement to two checkpoint barriers. Isolated terrain skills now retain the old active terrain while the existing composite CAS commits, so authoritative driving and replication continue. Up to four affected collision tiles are prepared during that wait, then terrain and collision activate together at a tick boundary after durability. Mixed entity/damage skills retain the original fence. Local terrain mesh invalidation and incremental shoreline sampling also remove avoidable client work. Visible vehicles keep the server tick cadence even when their orientation is steady and only a compact position update is needed. Camera, chassis and suspension now share one buffered presentation sample. The recording pipeline preserves fine source timestamps, correcting a separate 25 Hz image-demux quantization defect, and encodes native 60 FPS.
**Provenance:** Recorded 2026-09-24. 28.4 seconds at 1.0×, native 60.0 / 60.0 FPS; the delivered excerpt has no missing capture slots. The full driving window's longest authority observation gap is 215 ms on a nominal 200 ms sample cadence, with no sampled midroute physics stalls. Every presented frame between capture slots is also measured across the complete driving window: P99 8.39 ms, maximum 14.11 ms; camera/body pose mismatch is zero. The receive-time presentation buffer adds 100 ms and never extrapolates through an outage. Accepted and terminal skill durability still precede visibility. This is a local Edge rehearsal with hosted OpenRouter Jev decisions, not a production-network benchmark or a professional tire/drivetrain simulator. Raycast suspension and terrain collision remain authoritative. The receipt names any gaps outside the excerpt and hashes the uncommitted sources and binaries.
[demo-dual-driving.mp4 ↓]() — Video · 13.0 MB
Green SUV and orange pickup: synchronized native chase cameras, live Jev drivers and terrain sabotage. Real time, 1.0×.
SHA-256: `6b09ac2dd74ae7e4f92f0b4378e52d4e31c00a26941188b5a6fb966b3c65eb9a`
[demo-dual-driving-receipt.json ↓]() — Data · 31.8 KB
Public recording receipt: native FPS, authoritative and physics progress, checkpoint timings, crater encounters and exact artifact hashes.
SHA-256: `9a0ac0694d3ba1ddfb050b97ed6bfcbd54e87782116778c08c55bf5e5bc44cff`
[demo-dual-driving-source.zip ↓]() — Source · 867.4 KB
Exact source excerpts and authored route/tuning documents for this candidate; a dirty-tree snapshot, not a complete build environment.
SHA-256: `1737f0ce73d4b7624ddb6230c50e4b18ea3e50a567cdd50b0c864300d9d18591`
[DRIVING\_PRESENTATION\_DECISION.md ↓]() — Source · 12.4 KB
Frame-level stutter audit: coherent camera, chassis and wheels; corrected video timestamps; native 60 FPS gates and evidence.
SHA-256: `46ec7a91b36b35c1e3ac51fb20d7b50c130129473432d33a20245ecf131b4c53`
[DRIVING\_CONTINUITY\_DECISION.md ↓]() — Source · 25.3 KB
Measured checkpoint and terrain-render bottlenecks, staged terrain and collision activation, recovery checks and remaining latency limits.
SHA-256: `d559bf46f9a041264b8b2f4787f04502f80edeee7546e6200edb6e851101a924`
[Evidence manifest]()
#### Jev live decisions control an agent
Three real OpenRouter/Jev calls choose wait, advance and plant. The built-in character moves through an admitted server skill, stops, then plants a continuously growing tree. Both native cameras present the action and matching skill cues.
**Provenance:** Recorded from whitepaper-jev-live-20260922-02. Provider round trips: 280.1 / 166.5 / 246.2 ms. Advance and plant terminal receipts took 7.25 / 13.19 seconds from intent; this run does not demonstrate subsecond end-to-end action latency. The model is hosted through OpenRouter; the director runs beside the server, outside simulation ticks. Intents are operator-authored, not autonomous planning. No fixture provider or automatic retry. Three calls cost $0.000083706.
[demo-jev-agent.mp4 ↓]() — Video · 19.1 MB
50.72 seconds, 1.0x real time; top/bottom synchronized native cameras and measured timing panel. Capture target 6 Hz, no interpolation or audio. Model-result overlay is derived from measured duration within frame precision.
SHA-256: `18e7431d7e4f7732494666969d3f6beb8c92ce687dea998ffd64a2c9d63db1d2`
[demo-jev-agent-receipt.json ↓]() — Data · 237.8 KB
Real decisions, exact activation receipts, public movement traces and native recording proof.
SHA-256: `1a9f3af3bdd8b11033e0f8813f8bd4ea37239773820db10b2603da9b45523a35`
[record-jev-agent.mjs ↓]() — Source · 92 B
Opt-in reproduction entry; at most three paid calls. Requires source snapshot and engine checkout.
SHA-256: `1aa37ff1798cb09986d2ab1781587881ada38c2d112100ee030cb68fe6105222`
[JEV\_AGENT\_RECORDING.md ↓]() — Source · 3.3 KB
Setup, narration and timing/evidence boundaries.
SHA-256: `d505ee0df8de2b10317a7c258a12bfbc7dadf530013f46d0392f79b4ed0939cc`
[Evidence manifest]()
#### Earth Rise: generate and update a terrain skill
The running server admits two generated Luau revisions of one skill: a mound, followed by a three-brush earth wall. Both clients present matching terrain hashes at 0, 1 and 4 brushes. Green upward motes replace explosive cues.
**Provenance:** Recorded from whitepaper-terrain-skill-20260922-05. Agent-authored recipes generate package source during replay; no live model inference. Native captures establish visible behavior, not a latency benchmark. Tree animation is presentation-only: this adapter supplies no collider or chopping behavior, and is not a botanical simulation.
[demo-terrain-skill.mp4 ↓]() — Video · 15.1 MB
32.30 seconds, top/bottom synchronized native streams, 1.25x, no audio. Original capture target: 6 Hz; frames held without interpolation.
SHA-256: `9606ba8f8f997ad97a1190da2cfce1e5e95ca1024157a48ce5576acfc8ab1451`
[demo-terrain-skill-receipt.json ↓]() — Data · 43.6 KB
Public execution and recording receipt.
SHA-256: `0f9a8de441efdc21a4bf1fd96af7618dafd01a99702e0dc562c5eb09f8b4518d`
[record-terrain-skill.mjs ↓]() — Source · 80 B
Reproduction entry; requires the engine checkout and dependencies.
SHA-256: `acc5fb0695bb7bbf9d95ce46e8e307b1ec4a1be4fc05a7ff91f89b3ee2b9be06`
[TERRAIN\_SKILL\_RECORDING.md ↓]() — Source · 2.3 KB
Setup, narration and evidence boundaries.
SHA-256: `46d262a74c29e57a479f361913dbddaf44f7f11674af3974277358a65b8c33a0`
[Evidence manifest]()
#### Verdant seed: a procedural tree grows after casting
One cast creates one procedural oak. Replicated progress continuously extends the trunk and unfolds its branches and canopy. Both clients present monotonic intermediate progress for the same persistent entity.
**Provenance:** Recorded from whitepaper-tree-animation-20260922-02. Agent-authored recipes generate package source during replay; no live model inference. Native captures establish visible behavior, not a latency benchmark. Tree animation is presentation-only: this adapter supplies no collider or chopping behavior, and is not a botanical simulation.
[demo-tree-skill.mp4 ↓]() — Video · 8.2 MB
19.21 seconds, top/bottom synchronized native streams, 1.25x, no audio. Original capture target: 8 Hz; frames held without interpolation.
SHA-256: `3f0ae94dce1b861e72e0cad44eb421656f55a27c575b5ece8d8ab3730939da5d`
[demo-tree-skill-receipt.json ↓]() — Data · 72.7 KB
Public execution and recording receipt.
SHA-256: `9792d46f3fd311faf52006031e76d1272d5c22a91c098a825aa00e042278051a`
[record-tree-skill.mjs ↓]() — Source · 93 B
Reproduction entry; requires the engine checkout and dependencies.
SHA-256: `01780872e10f087653afdf3e96664f39d8b94c40e12e25b39ee5701b245343bc`
[TREE\_SKILL\_RECORDING.md ↓]() — Source · 2.7 KB
Setup, narration and evidence boundaries.
SHA-256: `9f48fcb184929e318fb83c310f6741ada80c6ed9f3be0d2b888ea19e79dbbe54`
[Evidence manifest]()
#### Generate a Package, then update it live
The recorder generates JSON/Luau source and publishes garden V1 through the normal admission, generation-CAS, checkpoint and tick-activation path. V1 builds 108 parts; V2 adds a 24-part tower while preserving all 108 existing entity documents exactly. Both native client processes stay connected and present 132 parts. Source generation uses saved agent-authored algorithms, not a fresh model inference or paid asset-generation call.
**Provenance:** Source run whitepaper-package-update-20260921-01. Approximately 33 seconds, two native cameras aligned by capture timestamps and edited at 1.25× speed, with no audio. Original captures contain 719/720 frames at 6 Hz; one left-camera capture slot was late before this excerpt. Full video decode passed; automatic visual-quality assessment remains review. Publication receipts and authoritative entity comparisons establish update identity and preservation separately from visual capture.
[demo-package-update.mp4 ↓]() — Video · 11.1 MB
V1 courtyard construction followed by V2 tower expansion, 1.25× speed.
SHA-256: `5b88454f6e7e800f583c77a410fe2338a9c981269bb083bbf71a974f83449ff2`
[demo-package-update-receipt.json ↓]() — Data · 1.9 KB
Public update receipt, including exact release digests and 108 preserved + 24 added parts.
SHA-256: `0124a83954f1d535d8c2822dad297cf4ddf59a331edd481e00cb234a12b3d6e2`
[record-package-update.mjs ↓]() — Source · 97 B
Update recording entry script; requires its companion modules and an engine checkout.
SHA-256: `ccdb7210bda459d745fea40309bffe801ddc6afea5d92b3c523e5686f04441c8`
[PACKAGE\_UPDATE\_RECORDING.md ↓]() — Source · 2.3 KB
Reproduction commands and narration for live update.
SHA-256: `d16e206364f64b2347f9919af9f729713ff3f7322f18009fd38a5b2e728d9885`
[demo-source-snapshot.zip ↓]() — Source · 404.7 KB
Complete demo source snapshot and guides, including lifecycle helper modules. Requires the engine checkout, binaries and dependencies; not standalone. Snapshot identified by SHA-256, with no asserted Git commit.
SHA-256: `449e1d9a2e78a034b252b7d0bf42ae4e41a4041089451e99f79fb527318cd153`
[WHITEPAPER\_DEMO\_SUITE.md ↓]() — Source · 3.9 KB
Seven-scenario guide; individual scenarios executed separately, master command preflight only.
SHA-256: `60bb7d6a77b44ec6b29dd76f8bf0ed75f4e985ca0601a527abb8378d1e61b157`
[Evidence manifest]()
#### Explosion, terrain and two clients
A player casts ground-pulse at another player’s feet. The server changes terrain and collision; the target drops 1.76 m. Both native clients present the same activation and terrain edit.
**Provenance:** Recorded September 21, 2026; source run whitepaper-duel-20260921-02. These edited videos preserve the same time transform for both cameras. Full decode checks passed; automatic visual-quality assessment remains review. Captures establish visible behavior, not a latency benchmark or recovery proof.
[demo-explosion.mp4 ↓]() — Video · 3.5 MB
8 seconds; vertically stacked cameras, 1.25× speed, no audio. The original captures sample at 8 Hz; encoded frames are held, not interpolated. The excerpt ends before the later recording gaps.
SHA-256: `4bc9bb8557ee1ba929826bb018b28bba5d45e3c30045a02b1ad4fead717b740d`
[record-rehearsal.mjs ↓]() — Source · 22.7 KB
Recording entry script; run within the engine repository with its documented dependencies.
SHA-256: `91b565c8f9f78e10cb5d1e3622073bf1c455f7fd62a48b47821af03f3c4e1b3e`
[RECORDING\_REHEARSAL.md ↓]() — Source · 7.4 KB
Reproduction commands and narration.
SHA-256: `296d9ca53fc3e23f31e5c344beeeac84eb7aad8bd6981121cc410d082e3d8d58`
[demo-explosion-receipt.json ↓]() — Data · 1.4 KB
Public recording receipt: verification status, scenario and measured event timeline.
SHA-256: `a7f7a1766ad772aaa30058681e48f496627df041ff3d18589641782063f3ef66`
[demo-source-snapshot.zip ↓]() — Source · 404.7 KB
Complete demo source snapshot and guides, including lifecycle helper modules. Requires the engine checkout, binaries and dependencies; not standalone. Snapshot identified by SHA-256, with no asserted Git commit.
SHA-256: `449e1d9a2e78a034b252b7d0bf42ae4e41a4041089451e99f79fb527318cd153`
[WHITEPAPER\_DEMO\_SUITE.md ↓]() — Source · 3.9 KB
Seven-scenario guide; individual scenarios executed separately, master command preflight only.
SHA-256: `60bb7d6a77b44ec6b29dd76f8bf0ed75f4e985ca0601a527abb8378d1e61b157`
[Evidence manifest]()
#### A program builds a research station
An existing agent-authored Luau program creates 399 Package-owned parts in bounded batches while two native clients remain connected. The video shows execution of saved source, not fresh model inference.
**Provenance:** Recorded September 21, 2026; source run whitepaper-building-20260921-01. These edited videos preserve the same time transform for both cameras. Full decode checks passed; automatic visual-quality assessment remains review. Captures establish visible behavior, not a latency benchmark or recovery proof.
[demo-building.mp4 ↓]() — Video · 6.1 MB
28.35 seconds; vertically stacked cameras, 1.25× speed, no audio. Each original stream contains 540 samples at 6 Hz with no capture drops and 39 intermediate construction counts.
SHA-256: `62d9f94f6bba2192828e21c1726e76083415d8e0c0b90a4368871a504de110c0`
[record-building.mjs ↓]() — Source · 161 B
Recording entry script; run within the engine repository with its documented dependencies.
SHA-256: `6d0db575dc88f12484a099bbc7a2a62abe84be91fb5af4a4cdc8c225eae11792`
[CONSTRUCTION\_RECORDING.md ↓]() — Source · 4.3 KB
Reproduction commands and narration.
SHA-256: `90bf506b7aab2578414a5309ab16af9c073702412521274226c7bd570615909f`
[demo-building-receipt.json ↓]() — Data · 1.0 KB
Public recording receipt: verification status, scenario and measured event timeline.
SHA-256: `fe44864bececfb069e0fc1dfef87b11b00c02a451dd65e9b5da3a4d5705264ce`
[demo-source-snapshot.zip ↓]() — Source · 404.7 KB
Complete demo source snapshot and guides, including lifecycle helper modules. Requires the engine checkout, binaries and dependencies; not standalone. Snapshot identified by SHA-256, with no asserted Git commit.
SHA-256: `449e1d9a2e78a034b252b7d0bf42ae4e41a4041089451e99f79fb527318cd153`
[WHITEPAPER\_DEMO\_SUITE.md ↓]() — Source · 3.9 KB
Seven-scenario guide; individual scenarios executed separately, master command preflight only.
SHA-256: `60bb7d6a77b44ec6b29dd76f8bf0ed75f4e985ca0601a527abb8378d1e61b157`
[Evidence manifest]()
#### Two authors, two regions, one server
Two independent agents concurrently authored a 108-part garden and a 106-part station. A coordinator published their separate Packages sequentially; the server then executed the two build policies during overlapping periods, with 32 sampled intervals in which both grew. These are two regions in one authoritative world, not isolated world instances.
**Provenance:** Recorded September 21, 2026; source run whitepaper-multi-agent-20260921-01. These edited videos preserve the same time transform for both cameras. Full decode checks passed; automatic visual-quality assessment remains review. Captures establish visible behavior, not a latency benchmark or recovery proof.
[demo-multi-agent.mp4 ↓]() — Video · 7.1 MB
28.14 seconds; vertically stacked overview cameras, 1.25× speed, no audio. Each native stream contains 720 samples without capture drops and observes 214 new entities. The footage shows server execution; the authors’ chat sessions are not filmed. Reruns reuse the saved plans.
SHA-256: `b76a173ae4745018a3bdddbd1e7c6c901bddb8b9791962240aaad00a35dfc12d`
[record-multi-agent.mjs ↓]() — Source · 94 B
Recording entry script; run within the engine repository with its documented dependencies.
SHA-256: `01cd932bc3f23d0fa905c24f76749d788427f9709c6e84f1a47866375b899442`
[MULTI\_AGENT\_RECORDING.md ↓]() — Source · 3.9 KB
Reproduction commands and narration.
SHA-256: `962d567f05aafd6e6820d2e3fec94c7c181ec95dc20cfc4a9592b531fad36c79`
[region-garden.mjs ↓]() — Source · 2.4 KB
Independent garden author’s exact saved plan and part definitions.
SHA-256: `3002ca000de1b6629fda6e3e39678e263451c885847799b2e2ef1bce0fd00324`
[region-station.mjs ↓]() — Source · 1.9 KB
Independent station author’s exact saved plan and part definitions.
SHA-256: `f103cbff5f4e48dde209ef7840b18d99868a8af790f36b17ed590c8455923f63`
[demo-multi-agent-receipt.json ↓]() — Data · 1.4 KB
Public recording receipt: verification status, scenario and measured event timeline.
SHA-256: `c50688c2da057314198ef2344aaa5556cfb4ade7fc5baf9f8082139f848a7ead`
[demo-source-snapshot.zip ↓]() — Source · 404.7 KB
Complete demo source snapshot and guides, including lifecycle helper modules. Requires the engine checkout, binaries and dependencies; not standalone. Snapshot identified by SHA-256, with no asserted Git commit.
SHA-256: `449e1d9a2e78a034b252b7d0bf42ae4e41a4041089451e99f79fb527318cd153`
[WHITEPAPER\_DEMO\_SUITE.md ↓]() — Source · 3.9 KB
Seven-scenario guide; individual scenarios executed separately, master command preflight only.
SHA-256: `60bb7d6a77b44ec6b29dd76f8bf0ed75f4e985ca0601a527abb8378d1e61b157`
[Evidence manifest]()
#### Package lifecycle: native stage evidence replay
A separate strict test passed A1 publication, B2 update, A3 rollback with the fixture CDN stopped, warm-cache rejoin and crash-style server restart. Exact catalog identities, retained terrain edits and ABI2 state were checked; the authority epoch advances from 1 to 2. Package rollback preserves committed world edits.
**Provenance:** Source run whitepaper-lifecycle-evidence-20260921-02. This is a 20-second replay of actual native screenshots, holding each stage for 4 seconds, not continuous real-time footage. During rejoin, the lower panel is explicitly an earlier A3 reference. The minimal triangular fixture proves import/publication receipts; the separate final composited prefab-pixel gate and per-resource cache-hit counts are not claimed.
[demo-lifecycle.mp4 ↓]() — Video · 502.1 KB
20-second stage replay; still images with labels, no audio. This is not a real-time synchronization recording.
SHA-256: `54137f3526ea779f12fc78c53fe5ffba969defa257a6473bec1c9184f669707c`
[demo-lifecycle-receipt.json ↓]() — Data · 9.5 KB
Public strict-test receipt: exact versions, checkpoint state, offline rejoin and server recovery.
SHA-256: `2dcb02a7bb77eb84a304cf2a2eb0a41a7e93f28acd5a892bec916133ee12e4d9`
[PACKAGE\_LIFECYCLE\_RECORDING.md ↓]() — Source · 3.6 KB
Lifecycle reproduction commands and narration; requires an engine checkout and test binaries.
SHA-256: `4ea955a53c48f0ed03b789c361a802512148403684ae4ff7843faea5a2d4330c`
[demo-source-snapshot.zip ↓]() — Source · 404.7 KB
Complete demo source snapshot and guides, including lifecycle helper modules. Requires the engine checkout, binaries and dependencies; not standalone. Snapshot identified by SHA-256, with no asserted Git commit.
SHA-256: `449e1d9a2e78a034b252b7d0bf42ae4e41a4041089451e99f79fb527318cd153`
[WHITEPAPER\_DEMO\_SUITE.md ↓]() — Source · 3.9 KB
Seven-scenario guide; individual scenarios executed separately, master command preflight only.
SHA-256: `60bb7d6a77b44ec6b29dd76f8bf0ed75f4e985ca0601a527abb8378d1e61b157`
[Evidence manifest]()
Implementation and integration references: [22](https://engine.pajama.studio/whitepaper/en#source-worlddoc) [8](https://engine.pajama.studio/whitepaper/en#source-tick) [19](https://engine.pajama.studio/whitepaper/en#source-roadmap) [23](https://engine.pajama.studio/whitepaper/en#source-native-evidence) [24](https://engine.pajama.studio/whitepaper/en#source-terrain-evidence) [25](https://engine.pajama.studio/whitepaper/en#source-skill-frontier) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation) [7](https://engine.pajama.studio/whitepaper/en#source-backend-status).
### Integrated results
The September 12 native-client records follow A1 → B2 → A3. A and B are content definitions; 1, 2 and 3 are successive deployment generations. A3 restores A's definition while preserving forward progress in deployment history. Later runs add a stopped HTTPS source, rejoin from a warm disk cache, a deliberately corrupted required asset and recovery into a new server authority epoch. The terrain variant also compares authoritative brush state with typed script state in the same checkpoint. [23](https://engine.pajama.studio/whitepaper/en#source-native-evidence) [24](https://engine.pajama.studio/whitepaper/en#source-terrain-evidence)
The useful result is continuity across several lifecycle changes: the clients agree on exact content identity, retained entities remain addressable, and recovery reconstructs the recorded world/content combination. The later construction rehearsal adds player-triggered skill execution and matching cue receipts. Completing the product gate requires combining these results with update and recovery in the supported workflow. At the architecture baseline, retained presentation covers the active and immediate rollback versions; broader historical lineage is a separate workstream. [25](https://engine.pajama.studio/whitepaper/en#source-skill-frontier) [26](https://engine.pajama.studio/whitepaper/en#source-history-frontier) [21](https://engine.pajama.studio/whitepaper/en#source-building-probe)
### The next integration focus
The immediate focus is lifetime-managed retained content, a durable observation barrier, stable agent contracts and an author-to-player handoff through the prepared publication workflow. World-model work begins at the observation boundary and develops toward generated presentation. The [development roadmap](https://engine.pajama.studio/whitepaper/en#roadmap) connects these workstreams. [19](https://engine.pajama.studio/whitepaper/en#source-roadmap) [27](https://engine.pajama.studio/whitepaper/en#source-world-model-roadmap)
### Architecture records for this edition {#current-evidence}
The prepared-authoring receipts establish a concrete workflow beyond standalone script publication. They use primitive prefabs and two protocol clients. The eight native clips add presentation and application evidence in separate worlds; combining them into one universal lifecycle proof would overstate their scope.
#### Prepared candidate: interruption, lost response and recovery
Three primitive-prefab revisions produce 8 → 16 → 24 entities. Retrying a lost real Edge response reuses the same release; a stale candidate needs a rebase. Recovery preserves all 24 entities and advances 94 ticks without duplicate construction.
**Provenance:** Local September 24 acceptance (completed September 25 UTC): Rust compiler, real Edge D1/R2/DO, native shard, separate stdio MCP process and two protocol clients. These are not native rendering or live LLM proofs. Original sanitized receipts are copied unchanged.
[prepared-publication-proof.json ↓]() — Data · 18.6 KB
Original sanitized prepared-authoring acceptance: publication-proof.json
SHA-256: `126edaf6a473841daad0300d93e636610049a7f87fe1aad88da596ada57aab53`
[prepared-recovery-proof.json ↓]() — Data · 1.2 KB
Original sanitized prepared-authoring acceptance: recovery-proof.json
SHA-256: `a6209127e40961e913c69259e93aa47b0e67cddfbdea761b0f7d29ce75901db1`
[Evidence manifest]()
#### September 25 architecture and evidence update
Current contracts for prepared authoring, dynamic vehicles, bounded constraint generation, presentation continuity and recovery.
**Provenance:** Dated source documents and SHA-256 audit from the existing dirty engine workspace. Proposed interfaces remain labeled proposals. Scenario receipts retain the source identities captured by each run; this document update does not rerun engine acceptance.
[PRACTICAL\_SCENARIO\_SUITE.md ↓]() — Source · 7.6 KB
Dated implementation or proposal document: PRACTICAL\_SCENARIO\_SUITE.md
SHA-256: `a3f647ba5f2fe2df819f63f03aeef9e96c1b3dc61d81ea12abcf7f39e4b9fe28`
[PREPARED\_PACKAGE\_AUTHORING.md ↓]() — Source · 8.9 KB
Dated implementation or proposal document: PREPARED\_PACKAGE\_AUTHORING.md
SHA-256: `06cc89a8baa6fa7700f4cc16b692e9d2b5c90f9c820d15823868f378d41b3346`
[AGENT\_NATIVE\_AUTHORING\_PLAN.md ↓]() — Source · 17.8 KB
Dated implementation or proposal document: AGENT\_NATIVE\_AUTHORING\_PLAN.md
SHA-256: `2e2b6b1a7beb8f8d6c74321b19f8917d0e8e1e5c47f5b8c576c1e5be0a966647`
[GENERATIVE\_CONTENT.md ↓]() — Source · 15.8 KB
Dated implementation or proposal document: GENERATIVE\_CONTENT.md
SHA-256: `277455365e811500198e6f7bb9e08c751c860a325b706d947243ac94b445168b`
[DRIVING.md ↓]() — Source · 9.6 KB
Dated implementation or proposal document: DRIVING.md
SHA-256: `1fd15a4233ad2a9fa602e8a3af9bdd19355899f01c354e81f20f2fdd00456618`
[DRIVING\_TERRAIN.md ↓]() — Source · 17.5 KB
Dated implementation or proposal document: DRIVING\_TERRAIN.md
SHA-256: `19f46cc28158e07a3b1141aee5c50f3d9787faf74da55e6902fc67f1b960add9`
[CAPTURE\_STAGING\_DECISION.md ↓]() — Source · 5.7 KB
Dated implementation or proposal document: CAPTURE\_STAGING\_DECISION.md
SHA-256: `a37f3692f486cc50017550d3a08f0eafb76b44f6988b3e3b7e92c898c6a905e5`
[architecture-review-20260925.json ↓]() — Data · 3.0 KB
Current source audit identities, separate from recorded runtime builds.
SHA-256: `6016e0f44488d098069b9faf0a2db4b89d321b69fa89584032fe4c43219037b0`
[practical-scenarios-index.json ↓]() — Data · 3.7 KB
Eight video hashes, durations and measured capture cadence.
SHA-256: `554476b3c1ef439b9d09091cd2a4aa1280aae47bdf9763aa5b8e89ece778838e`
[Evidence manifest]()
## 04 · Design principles {#principles}
### Preserve meaning across implementation changes
A world's durable identity consists of its documents, stable entity IDs, exact package references and authoritative state. The engine can rebuild a physics body, replace a decoded mesh or allocate a new GPU buffer while preserving that identity. This separation allows runtime optimizations to evolve independently from saved-world compatibility. [22](https://engine.pajama.studio/whitepaper/en#source-worlddoc) [1](https://engine.pajama.studio/whitepaper/en#source-goal)
### Give every authoritative change a clear owner
One simulation authority orders changes to a world. In leased operation, its epoch identifies the current writer lifetime and fences stale writers. This gives gameplay, publication and persistence a common basis for deciding whether an operation is still allowed to commit. Storage and delivery services can scale independently around that authority. [28](https://engine.pajama.studio/whitepaper/en#source-authority) [7](https://engine.pajama.studio/whitepaper/en#source-backend-status)
### Treat a release as a lifecycle
A usable content release includes validation, authorization, activation, client delivery and recovery. Each stage answers a different question: are the bytes valid, is this world allowed to use them, which definition is active, can the client present it, and can the server restore it? Keeping these states explicit makes failures diagnosable and avoids collapsing several meanings into a single “upload succeeded” result. [17](https://engine.pajama.studio/whitepaper/en#source-publication) [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [10](https://engine.pajama.studio/whitepaper/en#source-delivery-owner)
### Make resource identity explicit
A package revision and its resource hashes determine what the client needs. Delivery locations can change without changing those identities. The cache verifies bytes; the presentation coordinator publishes a complete compatible resource generation. This supports asynchronous loading while giving late or stale work an unambiguous owner. [29](https://engine.pajama.studio/whitepaper/en#source-cache) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation)
### Make extensibility observable and bounded
Human and agent authors discover the supported schema, operate within explicit scopes and receive structured results. Sandboxed behavior reads immutable input and returns typed commands. Resource budgets and validation apply at the boundary, where the engine can explain a rejection before it becomes a runtime inconsistency. [30](https://engine.pajama.studio/whitepaper/en#source-mcp-scopes) [14](https://engine.pajama.studio/whitepaper/en#source-script-contract)
## 05 · World data and object lifetime {#world}
### A document describes the world; runtime structures execute it
`WorldDoc` stores serializable world data, including entities and terrain. Runtime `World` adds indexes, change tracking and lifecycle information needed for execution. `EntityId` identifies an entity across external contracts. Internal solver, ECS and renderer handles serve the subsystem that allocated them. [31](https://engine.pajama.studio/whitepaper/en#source-entity) [22](https://engine.pajama.studio/whitepaper/en#source-worlddoc) [32](https://engine.pajama.studio/whitepaper/en#source-world-runtime)
The shared contract is semantic: a stored entity, a replicated update and an authoring operation refer to the same entity and component meaning. Their optimal memory layouts differ. Physics needs collision structures; rendering needs batches and resource handles; persistence needs stable, interpretable data. Deriving those views from explicit identities keeps the storage model independent of frame-loop optimizations. [22](https://engine.pajama.studio/whitepaper/en#source-worlddoc) [15](https://engine.pajama.studio/whitepaper/en#source-physics-trait) [16](https://engine.pajama.studio/whitepaper/en#source-render-snapshot)
| Kind of state | Example | Lifetime |
| --- | --- | --- |
| Durable identity | Entity ID; exact package revision and digest | Preserved through the supported save/recovery lifecycle |
| Authoritative mutable state | Entity data, terrain edits, recoverable script state | Captured in the appropriate coherent checkpoint |
| Execution state | World indexes, physics bodies, ECS handles | Rebuilt or reconciled by its runtime owner |
| Presentation state | Decoded assets, imported GPU generation, animation scratch | Derived from replicated state and exact resource identity |
The persistence and package contracts define these distinctions. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation)
### Change tracking connects mutation to replication
`World::touch` advances the world's mutation sequence and marks a full change. A stamp therefore gives an update a position in the world's mutation history; it is more than a per-entity edit count. Dirty-state classification then supports the replication work needed for affected clients. [33](https://engine.pajama.studio/whitepaper/en#source-world-touch) [18](https://engine.pajama.studio/whitepaper/en#source-replication)
The simulation layer uses `bevy_ecs` for storage/scheduling tasks. The server's concrete tick remains the source for cross-system execution order, allowing individual subsystems to move toward data-oriented organization without requiring a wholesale engine migration. [34](https://engine.pajama.studio/whitepaper/en#source-sim-manifest) [8](https://engine.pajama.studio/whitepaper/en#source-tick)
## 06 · Package identity and publication {#publication}
### What a package identifies
A package binds an ID, an exact authored revision and a digest. Its manifest references assets, prefabs, behavior and exact dependencies. The **dependency closure** is the complete set of packages required to interpret that release. Resolving the whole set before activation prevents a release from depending on whichever version happens to be found later. [4](https://engine.pajama.studio/whitepaper/en#source-package-contract)
Several version numbers coexist because they answer different questions. The package format determines how bytes are decoded. A package revision identifies authored content. The deployment generation records activation history. Behavior ABI and component schema define execution/data contracts. Catalog protocol defines what the client receives. Frozen document decoders and explicit adapters preserve those meanings as the engine evolves. [4](https://engine.pajama.studio/whitepaper/en#source-package-contract)
01. **Prepare** — Freeze input and seal exact candidate bytes. Bind request, compiler, expected generation and target. Cold preparation is not world admission or preview.
02. **Admit** — Check realm policy, dependencies and compatibility. Publish the reviewed digest without recompilation; conflicts require a new rebased request.
03. **Commit durably** — Use the existing composite checkpoint and fenced head CAS. Reconcile a lost response against the same candidate, not a second logical release.
04. **Activate** — Install the exact candidate at the authoritative tick. Observe exact active status. Catalogs precede dependent entities; never expose half a Package.
05. **Client readiness** — Verify, decode, stage and expose complete resources. Clients complete independently. Authorized old resident models do not wait for successor downloads.
### From reviewed bytes to a live capability
The current **prepared, fenced Package path** is: freeze source and expected generation → cold-stage exact bytes → inspect candidate digest → realm admission and semantic preflight → prepare the composite checkpoint and fenced head CAS → reconcile and activate at the authoritative tick → observe the exact Catalog and per-client readiness. The interactive lifecycle below refers to this delivery-aware path. [13](https://engine.pajama.studio/whitepaper/en#source-staging) [5](https://engine.pajama.studio/whitepaper/en#source-admission) [17](https://engine.pajama.studio/whitepaper/en#source-publication) [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [8](https://engine.pajama.studio/whitepaper/en#source-tick) [35](https://engine.pajama.studio/whitepaper/en#source-catalog-order)
`authoring_prepare_package` binds request ID, canonical input, compiler hash and target. `authoring_candidate_status` rehashes the sealed inventory. `authoring_publish_prepared_package` verifies the requested candidate digest and submits those bytes without recompilation. The compatibility one-step publisher uses the same implementation. Preparation has no live-world side effect and is **not** a world-admission dry-run or physics/visual preview. [Prepared authoring contract](https://engine.pajama.studio/whitepaper/en#evidence-prepared-authoring).
The runner has bounded, resumable attempts and an immutable submission intent. A lost reply remains unknown: reconcile or retry the same request and digest using existing release deduplication. Changing a candidate or its expected generation requires a new request. `submitted` does not mean `active`; an exact active generation does not prove every client's assets are ready.
### Handling a concurrent edit
Suppose two authors both prepare from generation 12. If one release advances the generation, the other's expected base is stale. The intended workflow is to read the new status, reconsider the candidate against that state and submit a newly authorized request. This makes collaboration explicit and prevents a delayed request from silently replacing a more recent decision. The generation check is implemented in the shared publication service. [17](https://engine.pajama.studio/whitepaper/en#source-publication)
The current local `package_put` V1 input uses the composite writer but carries no Delivery Index. Delivery-aware release inputs carry the additional exact resource-location information required for the complete client closure. The roadmap tracks those input capabilities separately from the shared commit mechanism. [36](https://engine.pajama.studio/whitepaper/en#source-local-publication-frontier)
## 07 · Persistence, recovery and rollback {#recovery}
### Recover a state that actually existed
A content definition, the script state executing it and the world effects it produced are related. Loading each subsystem's independently latest record can combine incompatible moments. Pajama's composite checkpoint provides one recovery root for the corresponding world, package/admission and recoverable script state. The coordinator owns capture, immutable preparation, head CAS and reconciliation. [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [37](https://engine.pajama.studio/whitepaper/en#source-checkpoint-backend)
The checkpoint **head** is the committed reference identifying the selected durable snapshot. Preparing or uploading another snapshot alone does not move that reference. This distinction gives restart a clear starting point and allows an interrupted writer to reason about whether its exact candidate became authoritative. [38](https://engine.pajama.studio/whitepaper/en#source-local-store) [37](https://engine.pajama.studio/whitepaper/en#source-checkpoint-backend)
### Local and leased operation
In **process-local mode**, one store owns its root and operating-system lock for the server lifetime. Immutable objects and an epoch-free local head form the recovery namespace. Existing committed state takes precedence over authored seed inputs; corruption is surfaced as a recovery error. [38](https://engine.pajama.studio/whitepaper/en#source-local-store) [39](https://engine.pajama.studio/whitepaper/en#source-local-lifetime)
In **leased mode**, authority is bound to a world/shard/server subject and an epoch. An epoch identifies a writer lifetime. A replacement authority receives a new one, allowing storage and coordination to reject operations from its predecessor. The Edge prototype serializes these lease/head decisions while the Rust server executes the simulation. [28](https://engine.pajama.studio/whitepaper/en#source-authority) [7](https://engine.pajama.studio/whitepaper/en#source-backend-status)
### Lost acknowledgements are a recoverable state
A storage operation can complete while its response is lost. The coordinator must then compare the observed head with the exact base and candidate it retained. The candidate indicates that the intended write committed; the unchanged base supports the specified retry path; a third, missing or corrupt state requires reconciliation or failure handling. Ownership of the prepared operation survives uncertainty, so callers do not have to guess from a timeout. [38](https://engine.pajama.studio/whitepaper/en#source-local-store) [37](https://engine.pajama.studio/whitepaper/en#source-checkpoint-backend)
### Rollback preserves a forward-moving history
| Deployment | Definition selected | Meaning |
| --- | --- | --- |
| A1 | A | Initial admitted definition |
| B2 | B | Successor definition under a new deployment generation |
| A3 | A | A's definition reissued under another new generation |
This example separates content revision from deployment history. Restoring A can require migrating current typed behavior state into A's contract. World effects that already committed remain part of the world: changing them requires a separately authorized migration or compensating command. That policy preserves player history while allowing the definitions governing future behavior to change. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [40](https://engine.pajama.studio/whitepaper/en#source-rollback-frontier)
Current retained presentation is bounded to the active and immediate rollback cuts. M2 addresses wider historical-instance policy, recovery-source retention and durable garbage collection. [26](https://engine.pajama.studio/whitepaper/en#source-history-frontier)
### Declare how persistent instances evolve {#instance-evolution}
M2 will apply the product contract's **pin/rebase** choice to each Package-owned instance type. Pinning retains its creation revision and resources. Rebasing adopts a new definition under a validated policy; state changes require declared source/target schemas, typed migration and rollback compatibility. Failed preflight must leave no partial migration effects. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [14](https://engine.pajama.studio/whitepaper/en#source-script-contract)
For example, changing a wall's default health requires an explicit decision about an existing damaged wall: retain its old rules or preserve damage through a specified conversion. Downloading an asset or reconstructing a physics object must not make that choice implicitly. Collection must retain revisions referenced by live instances and supported recovery points. Restart and cleanup after A1 → B2 → A3 will test this contract. [26](https://engine.pajama.studio/whitepaper/en#source-history-frontier)
### Visibility and durability are different observations {#durable-observation}
Ordinary world changes may become visible before the periodic checkpoint contains them. The new recovery fixture reads the fenced checkpoint head, verifies referenced blob hashes and lengths, and confirms all 15 scene identities and transforms before stopping the authority. Fresh clients then observe the same scene under epoch 2. A screenshot or an `active` Package receipt alone would not prove this later construction was saved.
A supported **durable observation barrier** remains a priority: callers should correlate a requested world result with a durable cut without inspecting internal storage. Temporary driving sessions and intents are not checkpointed; recovery preserves vehicle/road content pins but requires new authorization and fresh observations. The demonstration does not claim automatic driver resumption. [Recovery evidence](https://engine.pajama.studio/whitepaper/en#evidence-practical-durable-world).
## 08 · Content delivery and client readiness {#delivery}
### Three identities connect authoring to pixels
The package reference identifies the authored definition. The content digest identifies the required bytes. The presentation generation identifies the compatible set of resources currently exposed by one client. Keeping these identities separate lets the engine move bytes between delivery locations, reuse verified cache entries and rebuild GPU resources without changing the authored content. [4](https://engine.pajama.studio/whitepaper/en#source-package-contract) [29](https://engine.pajama.studio/whitepaper/en#source-cache) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation)
The client pipeline is: **catalog → Delivery Index and documents → bounded fetch → verified content-addressed cache → CPU decode → hidden GPU staging → complete presentation generation**. The Delivery Index supplies exact descriptors for the selected package closure. Only resources belonging to the current selected state may advance that state's readiness. [10](https://engine.pajama.studio/whitepaper/en#source-delivery-owner) [41](https://engine.pajama.studio/whitepaper/en#source-decoder) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation)
### Each stage has its own completion rule
| Stage | Produces | Readiness condition |
| --- | --- | --- |
| Fetch and cache | Verified immutable handles | Bytes meet identity, length and integrity checks. |
| CPU decode | A complete decoded asset set | Selected formats are supported and the generation passes decode/admission bounds. |
| GPU staging | Resources prepared for publication | All required resources for that generation are ready to expose together. |
| Presentation | Exact asset lookups used by rendering | The published resources match the selected logical content state. |
These are implemented ownership boundaries in the cache, decoder and presentation coordinator. [29](https://engine.pajama.studio/whitepaper/en#source-cache) [41](https://engine.pajama.studio/whitepaper/en#source-decoder) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation) [42](https://engine.pajama.studio/whitepaper/en#source-gpu-generation)
Byte limits, queue capacity, concurrency and time budgets keep content loading from consuming unbounded work. Late responses remain associated with the selection that requested them. Missing resources produce a bounded diagnostic placeholder, while terminal failures are observable; an imported asset miss cannot fall through to an unrelated legacy shape. [10](https://engine.pajama.studio/whitepaper/en#source-delivery-owner) [43](https://engine.pajama.studio/whitepaper/en#source-package-presentation)
Atomic publication applies to each client's resource set. Different clients can finish loading at different times and still converge on the same content identity. Server-owned physics and gameplay continue to determine the authoritative outcome independently of local mesh readiness. [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation)
The recorded warm-cache offline scenario and targeted corruption test exercise this separation. Normal Catalog V2 availability remains gated while the broader lifecycle and historical-retention work is completed. [23](https://engine.pajama.studio/whitepaper/en#source-native-evidence) [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation)
### Retained visibility is independent of successor readiness {#retained-content}
The earlier pink-car regression exposed a lifecycle coupling: old GPU resources existed, but exact retained permission was not available to the resolver until successor hydration finished. The fix allows an exact durably admitted retention grant to authorize already verified resident resources. New resource generations still require complete verification and staging. No lookup falls back to a differently versioned mesh or material. [Four-client evidence](https://engine.pajama.studio/whitepaper/en#evidence-demo-fleet-driving).
The broader lifetime problem remains. A third replacement can push an old live GLB source outside the active/previous catalog union; the engine correctly rejects that publication. An unrelated publication after that replacement can reach the same limit. The new expansion demo keeps core A1 fixed and evolves a separate B1 → B2 Package. This is a valid workload within current bounds, not a solution for arbitrary history.
The required next contract is a budgeted retained-content closure rooted in live instances, behavior state, supported recovery/rollback cuts and in-flight work, with tested reclamation. New bytes, definition activation and instance migration must remain separate decisions. [Current architecture findings](https://engine.pajama.studio/whitepaper/en#evidence-architecture-update).
## 09 · Simulation, physics and terrain {#simulation}
### Order is part of the simulation contract
The tick acquires an authority operation and revalidates it after obtaining shared world state. Pending package activation occurs at the boundary. Installed scripts run before subsequent physics/pose processing and final replication. A content transition therefore has a defined place relative to the gameplay that consumes it. [8](https://engine.pajama.studio/whitepaper/en#source-tick)
This ordering also handles waiting: a request may have been authorized when it started but become stale while waiting for a lock. Revalidation checks that permission at the point where authoritative work is about to proceed. [8](https://engine.pajama.studio/whitepaper/en#source-tick)
### Physics has a dedicated interface and timing policy
`Physics` isolates solver-specific representations. Rapier is the default implementation; Box3D remains a compatibility implementation. Box3D's world is owned by a dedicated thread, while the default Rapier path executes directly. Each implementation satisfies the interface while retaining its own numerical behavior. [15](https://engine.pajama.studio/whitepaper/en#source-physics-trait) [44](https://engine.pajama.studio/whitepaper/en#source-physics-default)
Rapier uses 4 ms internal steps, capped at 16 per call. After reaching the cap, excess accumulated time is dropped. The design bounds the amount of recovery work following a stall, trading some elapsed simulation time for continued responsiveness. Evaluating that tradeoff requires observing skipped deadlines, physics behavior and server timing together. [45](https://engine.pajama.studio/whitepaper/en#source-physics-step)
### One terrain change has several consumers
A terrain edit changes the authoritative document, invalidates collision data and produces the relevant causal/network updates through the shared terrain entry point. Rendering and collision derive their own representations from that state, so each has a separate readiness lifecycle. A visible surface alone does not establish that its collision representation has completed rebuilding. [46](https://engine.pajama.studio/whitepaper/en#source-terrain-entry)
The recorded package-terrain scenario verifies brush/state agreement across clients and checkpoint recovery. Geometric collision accuracy and player-triggered skill effects require their own acceptance cases. [24](https://engine.pajama.studio/whitepaper/en#source-terrain-evidence) [25](https://engine.pajama.studio/whitepaper/en#source-skill-frontier)
Replication classifies changes and applies interest-management budgets. Client movement prediction improves response time and reconciles against authoritative echoes. These mechanisms should be evaluated together: simulation timing determines when truth advances, replication determines when a client learns it, and prediction determines what the client shows while waiting. [18](https://engine.pajama.studio/whitepaper/en#source-replication) [47](https://engine.pajama.studio/whitepaper/en#source-client-loop)
### Dynamic vehicles and continuous driving {#dynamic-vehicles}
The four-wheel component declares chassis dimensions and mass, wheel positions/radii, suspension stiffness, damping/travel, acceleration, steering and exact body/wheel assets. A materialized recipe and Package pin belong to each instance. New definitions affect subsequent instances; a live vehicle does not silently receive new mass, collision or wheel geometry. Rapier supplies chassis physics, raycast wheels, suspension, forces and collision. Steering and stability aids target playable off-road driving, not an automotive engineering model. [Vehicle and driving contracts](https://engine.pajama.studio/whitepaper/en#evidence-architecture-update).
Jev chooses expiring maneuvers from bounded observations; native server control closes the feedback loop. Session identity includes authority epoch, driver, vehicle incarnation and relevant content pins. Stale observations, expired intents, lost control or unready collision require re-observation or braking. In the live fleet video, four Jevs drive and the fifth selects terrain-skill attacks. Package publication is orchestrated by the recording harness; the video does **not** establish that two Jevs independently authored their new cars.
### Terrain changes without freezing unrelated movement {#terrain-activation}
The explosion hitch was partly a server scheduling problem: Accepted and terminal durability cuts had held the whole simulation, so moving vehicles paused together even while clients rendered. For an isolated, terrain-only skill batch, the engine now retains active terrain while preparing a private candidate and its durable composite cut. Movement and replication continue against the active preimage; effects stay private until activation.
For at most four affected collision tiles, preparation overlaps persistence off-thread. Exact source fingerprints bind the derivatives. At the tick boundary, durable commitment and derivative readiness allow installation, terrain publication and receipt/cue release. Mixed entity/damage batches retain their broader fence, and larger terrain batches use the bounded streaming fallback. This is a specific latency fix with local-run evidence, not a guarantee that every edit is stall-free. [Implementation and measured continuity](https://engine.pajama.studio/whitepaper/en#evidence-demo-dual-driving).
The new bridge scenario joins terrain excavation, installed bridge colliders and a normally controlled vehicle crossing. Terrain training separately checks matching brushes and fresh collider acknowledgements. A particle burst alone is never evidence of a physical crater.
### Why terrain still has boundaries {#terrain-bounds}
**The engine does not yet implement a seamlessly expanding world.** Source inspection at `d96cddf` confirms that `TerrainParams.extent` defines the playable half-size on X/Z. The engine default is 250 metres, a 500 × 500 metre square domain. Validation permits half-sizes of 64–4,096 metres; that is a configuration limit, not measured capacity. Individual demo instances may use different settings. [48](https://engine.pajama.studio/whitepaper/en#source-terrain-domain) [49](https://engine.pajama.studio/whitepaper/en#source-terrain-default) [50](https://engine.pajama.studio/whitepaper/en#source-terrain-extent-validation)
Server movement paths clamp coordinates to `±extent`, and physics ground scheduling bounds tile keys using that extent. Chunk loading therefore already exists within a finite world. Increasing `extent` retains a finite domain and raises resource demand. [51](https://engine.pajama.studio/whitepaper/en#source-terrain-movement) [52](https://engine.pajama.studio/whitepaper/en#source-terrain-ground)
Three boundaries need separate diagnosis: the **world domain** determines where players may go; the **resident/visible region** determines which chunks are loaded and shown; the **persistence boundary** determines what survives leaving. A clipped horizon alone cannot identify the cause. Acceptance should record the actual camera, world parameters, render chunks and collision chunks, distinguishing hard limits, missing distant terrain and late streaming. Fog and distant scenery can improve presentation.
**October 2026 update:** The values above retain their historical source-audit date. The new [40 km terrain horizon](https://engine.pajama.studio/whitepaper/en#rendering-horizon) expands visual residency; it does not claim to remove gameplay, collision or persistence boundaries.
### Contracts for a continually expanding world {#continuous-world}
The following requirements are planned; an infinite-terrain acceptance record does not yet exist:
| Boundary | Intended design and responsibility |
| --- | --- |
| Addressing and precision | Versioned global integer chunk addresses and local coordinates, with local origins for physics and rendering. Chunk crossings, negative coordinates and origin shifts preserve entity identity; wire and save formats require explicit migration. |
| Base terrain and generation | Pin seeds, generator versions and chunk identities; generate shared boundaries independently of visit order and retain old chunks' versions. Agent/model assets and generation rules still pass Package admission. |
| Edits and recovery | Spatially index terrain edits, construction and destruction. Cross-chunk edits pass the shared authoritative entry point into one recoverable commit. Evicting derived meshes preserves durable state; checkpoints cover chunk manifests and content references. |
| Residency and distance | Load precise collision and nearby visuals around active regions, with distant LOD and prefetch. Define missing-chunk, stale-job and overload states; restrict entry before collision is ready and provide understandable loading feedback. |
| Resources and authority | Bound CPU, GPU, colliders, networking, generation queues and durable storage growth separately, including aggregate demand from dispersed players. Extend under one world authority first; cross-server partitioning requires separately verified ownership transfer. |
These requirements extend the shared terrain mutation and content recovery contracts. Saves retain accepted world facts; native distant views, generated imagery and caches derive from them. [46](https://engine.pajama.studio/whitepaper/en#source-terrain-entry) [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [53](https://engine.pajama.studio/whitepaper/en#source-distributed-roadmap)
World Labs' Spark 2.0 (2026-04-14) demonstrates view-dependent LOD, progressive streaming and a fixed GPU page pool. Its residency approach is useful design input. The source concerns 3D Gaussian Splatting rendering; it does not implement Pajama's destructible terrain, collision or persistence. [R3](https://engine.pajama.studio/whitepaper/en#research-spark-streaming)
## 10 · Rendering and animation architecture {#rendering}
### Extract only the state rendering needs
`RenderSnapshot` presents the camera, instances and other render-relevant state to the renderer. Simulation and networking keep their own ownership. The renderer can consequently change batching, resource layout or GPU execution without becoming responsible for world mutation. [16](https://engine.pajama.studio/whitepaper/en#source-render-snapshot) [11](https://engine.pajama.studio/whitepaper/en#source-render-design)
Bevy's read-only extraction from a main world into a render world provides a related architectural precedent. For Pajama, this motivates a dedicated observation extractor alongside ordinary rendering. A model adapter should consume a captured view without holding mutable simulation access. [R4](https://engine.pajama.studio/whitepaper/en#research-bevy-extract)
### Compile configuration before frame execution
The rendering architecture separates a versioned pipeline document, validation of fields and topology, compilation of typed resource dependencies, and execution of an immutable compiled pipeline. For example, a pass that consumes a resource needs a compatible producer and declared ordering; those relationships belong in validation and compilation before the frame executor uses the plan. [11](https://engine.pajama.studio/whitepaper/en#source-render-design) [54](https://engine.pajama.studio/whitepaper/en#source-render-pipeline)
Code supplies registered GPU capabilities, while data composes and configures them. That gives authoring a defined vocabulary and lets performance-sensitive execution remain specialized. Package publication continues to use its admitted content boundary; broader renderer configuration and package permissions are distinct surfaces. [11](https://engine.pajama.studio/whitepaper/en#source-render-design) [1](https://engine.pajama.studio/whitepaper/en#source-goal)
### Retire resources with their generation
Package assets cross CPU decode and GPU staging before the coordinator exposes a complete generation. Imported resources have renderer-owned identities rather than borrowed legacy names. When presentation changes, retirement follows those identities, preventing a newly selected package from accidentally resolving a resource belonging to an older allocation. [9](https://engine.pajama.studio/whitepaper/en#source-client-presentation) [42](https://engine.pajama.studio/whitepaper/en#source-gpu-generation)
### Replicate intent; evaluate poses locally
Animation separates authoritative intent from client-side skeletal evaluation. The server can determine an entity's action or animation intent, while the client samples and blends the pose required for its current frame. This preserves a gameplay decision across clients while allowing each renderer to evaluate at its own frame rate. [55](https://engine.pajama.studio/whitepaper/en#source-animation)
Together, the snapshot boundary, compiled pipeline and resource generations define a practical evolution path: add rendering capability behind stable inputs, profile its cost, and preserve the lifetime rules expected by content delivery.
### Latest rendering progress and evidence {#rendering-progress}
As of October 1, 2026, native rendering integrates clearer lake water, shoreline foam, distance-adaptive cloud detail, weather, underwater optics and a 40 km terrain horizon into the existing pipeline. Every image below is an original engine capture. Feature validation, visual comparisons and performance measurements retain their separate scopes. Implementation references are pinned to the records at `e2134b8`; runtime evidence identifies its actual builds and profiles separately, including measurements timestamped October 2 in UTC. [56](https://engine.pajama.studio/whitepaper/en#source-render-progress-performance)
| System | Implemented change | Recorded evidence |
| --- | --- | --- |
| Water and shoreline | Spectral small waves, absorption/scattering, oblique wave filtering and porous foam above reflection | Matched lake views, numerical and GPU checks |
| Sky and clouds | Shared lighting basis for visible clouds and water reflections; erosion filtered by the actual pixel footprint | Resolution consistency across three views |
| Weather | Eight presets, automatic evolution and manual control; linked wind, precipitation, wetness, snow and lightning | Native weather captures, temporal and lighting checks |
| Underwater | Distance attenuation, scattering, approximate caustics, Snell's window and total internal reflection | Six-view A/B and 1,440 GPU numerical cases |
| Terrain horizon | Multiresolution streaming out to 40 km visually | Distance sweep, asynchronous streaming and edit checks |
| Multiple clients | Correct authored profile and matching requested/applied render revisions | Complete presentation intervals from four native clients |
### Water, shoreline foam and cloud detail {#rendering-water-clouds}
Water now uses two bounded 128×128 GPU inverse-FFT slope fields. Unresolved small waves contribute variance to reflection roughness, while long waves, rivers and interaction ripples retain their established paths. Lake transport attenuates both incoming and outgoing light and uses Snell refraction and dielectric Fresnel reflection: shallow water reveals its bed and deeper water progressively absorbs light, rather than relying only on a color change. [57](https://engine.pajama.studio/whitepaper/en#source-render-progress-spectrum) [58](https://engine.pajama.studio/whitepaper/en#source-render-progress-lake)
Shoreline foam follows wave arrival, backwash and decay. Pores and larger gaps break up the bank instead of forming a uniform white outline. Foam covers the lit water surface, remains visible at grazing angles, and leaves sky reflection and sun highlights visible through gaps. It is a bounded realtime approximation, not a shoreline fluid solver. [59](https://engine.pajama.studio/whitepaper/en#source-render-progress-foam)
#### Clear water and broken shoreline foam
Matched shoreline views before and after the foam refinement.
**Provenance:** Original 1280 × 720 native renderer PNGs. Same lake, profile, camera and time; this fixture omits kitchen props and characters. It is a visual comparison, not a gameplay FPS measurement.
![Before: original shoreline foam.]()
Before: original shoreline foam.
[render-shore-before.png ↓]() — Image · 1.2 MB
SHA-256: `880ea3cbd113e0e50bc19e123c2cdae3b063896d875097457f2fb5e25fb914f6`
![After: porous foam above the water reflection, with larger gaps along the bank.]()
After: porous foam above the water reflection, with larger gaps along the bank.
[render-shore-after.png ↓]() — Image · 1.2 MB
SHA-256: `31d437f161bf70d945bc1be50ba8b94d5520949c0d68a7a416e04ad751699d91`
[render-progress-proof.json ↓]() — Data · 26.6 KB
Public measurement receipt, original image/source-record hashes and explicit scope for all six rendering records.
SHA-256: `e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739`
[Evidence manifest]()
Cloud erosion is filtered using distance, viewing angle and the pixel footprint reconstructed from the actual projection. Unresolved detail converges toward mean erosion instead of switching erosion off and filling cloud creases back in. Narrow fields of view retain detail their pixels can resolve. Across three fixed views, mean RGB disagreement between 640×360 and reduced 1280×720 captures fell by approximately 49.7%–64.2%. This measures resolution consistency, not realism or overall superiority to Tidewater; local banding and cotton-like structure remain improvement areas. [60](https://engine.pajama.studio/whitepaper/en#source-render-progress-clouds)
#### Cloud detail follows the pixel footprint
Matched narrow-field horizon captures show the change in distant cloud structure.
**Provenance:** Original native 1280 × 720 PNGs, 30-degree vertical field of view. Weather, exposure and profile are fixed. The numerical comparison measures resolution consistency, not overall realism or superiority to another renderer.
![Before: previous cloud detail filtering.]()
Before: previous cloud detail filtering.
[render-cloud-before.png ↓]() — Image · 631.3 KB
SHA-256: `08cf9436ec4419f6bf0ce9aa8dc935ccaacb3e5da543afc3fe782421b7895110`
![After: projection-aware, mean-preserving erosion filtering.]()
After: projection-aware, mean-preserving erosion filtering.
[render-cloud-after.png ↓]() — Image · 610.4 KB
SHA-256: `da303878fc7bca83ee061e6b0e5067d78ebd2876653e4cfd569d7044709137f1`
[render-progress-proof.json ↓]() — Data · 26.6 KB
Public measurement receipt, original image/source-record hashes and explicit scope for all six rendering records.
SHA-256: `e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739`
[Evidence manifest]()
### Shared weather across wind, rain, snow and lightning {#rendering-weather}
Weather supports clear, cloudy, overcast, fog, rain, thunderstorm, snow and blizzard, with automatic evolution and manual transitions from the current state. The server supplies a shared weather clock. Wind drives cloud travel, vegetation, water waves and precipitation. Rain creates ground/water impacts and wet surfaces; snow accumulates and melts, and static roofs shelter nearby precipitation. A fixed spatial lightning source illuminates clouds, fog, surfaces and water, with distance-delayed thunder. Control continues through the existing revision checks and render-publication path. [61](https://engine.pajama.studio/whitepaper/en#source-render-progress-weather)
Precipitation and lightning have explicit budgets, and refinements reuse existing passes. Puddles, shelter and cloud illumination use realtime approximations. Evidence covers environmental presentation and sound logic; it does not add lightning damage, flooding, ice collision or wind forces on authoritative bodies. [61](https://engine.pajama.studio/whitepaper/en#source-render-progress-weather)
#### Weather across the same lake
Thunderstorm and snow captures illustrate linked sky, water and precipitation presentation.
**Provenance:** Original native 960 × 540 PNGs from the recorded weather refinement. These are different presets, not a matched A/B pair. Still images do not demonstrate audio, gameplay damage or a frame-rate guarantee.
![Thunderstorm: lightning over wind-driven lake water.]()
Thunderstorm: lightning over wind-driven lake water.
[render-thunderstorm.png ↓]() — Image · 629.3 KB
SHA-256: `ce92ec45ec143f7e974504fd86837022136ae1797175dc583501250ba751eb53`
![Snow: drifting precipitation and accumulated surface snow.]()
Snow: drifting precipitation and accumulated surface snow.
[render-snow.png ↓]() — Image · 597.2 KB
SHA-256: `828e711d97f4476493ccf75598049aee7ebe291d7a8420aed46515570040d830`
[render-progress-proof.json ↓]() — Data · 26.6 KB
Public measurement receipt, original image/source-record hashes and explicit scope for all six rendering records.
SHA-256: `e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739`
[Evidence manifest]()
### Crossing the water surface {#rendering-underwater}
Underwater membership comes from published physical water triangles and local depth, excluding dry camera positions below the bed. Volume transport reuses the water node with four illumination/shadow segments, producing distance-dependent absorption and scattering, approximate caustics, Snell's window and total internal reflection when looking upward. Existing scene motion and temporal response are preserved without giving the renderer simulation authority. [62](https://engine.pajama.studio/whitepaper/en#source-render-progress-underwater)
In six-view RTX 4090 / DX12 comparisons at 960×540, the underwater increment in median water-node time was **0.115–0.180 ms**. Above-water RGB pixels were identical with the feature enabled and disabled. Separate checks cover 1,440 GPU numerical cases and the forward path. This record does not include full multiple scattering, fluid simulation, swimming or underwater audio, and is not a browser/mobile frame-rate guarantee. [62](https://engine.pajama.studio/whitepaper/en#source-render-progress-underwater)
#### Underwater transport and the water-to-air interface
Views of the bed and Snell’s window from the existing kitchen lake.
**Provenance:** Original native 960 × 540 PNGs from the six-view optical acceptance. The scene isolates water and terrain. Caustics are a realtime approximation; swimming and underwater audio were outside this change.
![Bed view: attenuation, scattering and approximate caustics.]()
Bed view: attenuation, scattering and approximate caustics.
[render-underwater-bed.png ↓]() — Image · 418.7 KB
SHA-256: `9551d647c1e534a3f3acd541682a777d93645f705ef11b15c42274b56bc0cb10`
![Upward view: refracted sky within Snell’s window and reflection beyond it.]()
Upward view: refracted sky within Snell’s window and reflection beyond it.
[render-underwater-snell.png ↓]() — Image · 412.6 KB
SHA-256: `f4e149b8decdf4950a7b98e502f7e8a78038ab5b406deea8752d5b572418c4c8`
[render-progress-proof.json ↓]() — Data · 26.6 KB
Public measurement receipt, original image/source-record hashes and explicit scope for all six rendering records.
SHA-256: `e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739`
[Evidence manifest]()
### A 40 km visual horizon within streaming budgets {#rendering-horizon}
Terrain uses fine nearby meshes, progressively coarser distant levels and asynchronous generation. LOD seams, reversed camera depth, retention of the previous layout and complete-layout publication support the horizon. **40 km describes visual terrain residency, not metre-resolution simulation, vegetation residency or a seamless MMO world across that distance.** Terrain edits retain their single authoritative entry point, with collision invalidation, spatial script events and network observation following that edit. [63](https://engine.pajama.studio/whitepaper/en#source-render-progress-horizon) [46](https://engine.pajama.studio/whitepaper/en#source-terrain-entry)
In one native renderer fixture, increasing distance from 4 km to 40 km raised the patch count from 984 to 1,202 and CPU mesh bytes by 8.4%. The near 1 m tier retained 528 patches; allocated terrain/grass GPU arenas remained approximately 704 MiB. A separate asynchronous streaming test took about 13.8 seconds for cold start and 6.25 seconds for the layout phase after a 64 m move, including roughly one second of settled sampling per phase. The horizon is visible, but cold and moving-layout generation remain optimization work; these timings do not establish seamless high-speed travel. [63](https://engine.pajama.studio/whitepaper/en#source-render-progress-horizon)
#### Terrain residency at 4 km and 40 km
The same world and elevated camera show the visual footprint of multiresolution terrain.
**Provenance:** Original native 960 × 540 PNGs from an 8 km altitude camera. The distance sweep changes only terrain distance in one executable. This is visual terrain coverage, not a claim about gameplay extent or realtime movement.
![4 km terrain distance from the elevated camera.]()
4 km terrain distance from the elevated camera.
[render-horizon-4km.png ↓]() — Image · 318.3 KB
SHA-256: `6e3a0d5b66c41c4d5eeaa8afb54be4513dea0272b847aab17370a2786a757b69`
![40 km terrain distance with coarse distant tiers.]()
40 km terrain distance with coarse distant tiers.
[render-horizon-40km.png ↓]() — Image · 606.1 KB
SHA-256: `8ee90de99f39a91e26b157de0e0b4726b027b51a557b488aec8f328deff123f5`
[render-progress-proof.json ↓]() — Data · 26.6 KB
Public measurement receipt, original image/source-record hashes and explicit scope for all six rendering records.
SHA-256: `e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739`
[Evidence manifest]()
### Four clients: verify the profile actually running {#rendering-multi-client}
A recent four-client kitchen recording ran at approximately 23 FPS per window. Logs showed the older client rejecting the 40 km profile and retaining engine-default revision 0 instead of the requested revision 35. Default grass and grass shadows substantially increased each window's workload. After rebuilding both ends, a controlled test used the same updated binaries, scene and camera to reconstruct that fallback and compare it with the existing authored revision 36. [56](https://engine.pajama.studio/whitepaper/en#source-render-progress-performance)
| Controlled experiment | Effective FPS, windows 0 / 1 / 2 / 3 | Median GPU graph span | Grass instances per window |
| --- | --- | --- | --- |
| Reconstructed fallback | 15.4 / 15.4 / 15.4 / 58.2 | 8.94 ms | 399,604 |
| Current authored profile | **57.8 / 57.7 / 57.8 / 57.6** | **1.63 ms** | **84,359** |
Conditions: RTX 4090, DX12, 960×540 per window, a 60 FPS cap, fixed camera, frozen visual time, 20-second warmup and 20-second capture. FPS uses all presented intervals over approximately 19.5 seconds, including capture frames; PNG sampling is only 2 Hz. The four authored windows yielded 4,501 audited frames, each window's p90 interval below 17.9 ms. GPU columns take the median across windows, and concurrent timestamp spans include scheduling effects. The recorded build includes concurrent uncommitted work, identically in both controls; this is separate from the earlier dynamic kitchen recording. [56](https://engine.pajama.studio/whitepaper/en#source-render-progress-performance)
The authored profile retains the 40 km horizon, current water/cloud settings and underwater support, without an additional background FPS throttle or output-resolution reduction. Capture readiness now requires **a successful application and matching requested/actual revisions**, preventing fallback imagery from being certified as ready. This establishes improvement in the fixed scene, not 60 FPS acceptance for arbitrary combat, moving terrain streams or long four-player sessions. Further gates cover movement continuity, low-memory devices, browser performance and complete gameplay workloads. [56](https://engine.pajama.studio/whitepaper/en#source-render-progress-performance)
#### Four clients with the correct authored profile
Window 0 of each four-client control: reconstructed fallback versus authored revision 36.
**Provenance:** Original 960 × 540 presented-window PNGs. Both controls use identical updated binaries, fixed camera, frozen visual time and a 60 FPS cap. Complete interval counts, build hashes and concurrent uncommitted-build provenance are retained in the public receipt. This is a short stationary experiment, not long-session gameplay acceptance.
![Reconstructed fallback: expensive default grass and shadows.]()
Reconstructed fallback: expensive default grass and shadows.
[render-four-fallback.png ↓]() — Image · 914.3 KB
SHA-256: `2ec5188857a943249defcfe52fc16c0a4b1980d00568bb5b1179bf25427a2502`
![Authored revision 36: the 40 km horizon and current water/cloud settings retained.]()
Authored revision 36: the 40 km horizon and current water/cloud settings retained.
[render-four-authored.png ↓]() — Image · 1.1 MB
SHA-256: `ce29b635406a9d8692afaec8a0fee987599f35b11a351e2e774c5bf07c112be1`
[render-progress-proof.json ↓]() — Data · 26.6 KB
Public measurement receipt, original image/source-record hashes and explicit scope for all six rendering records.
SHA-256: `e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739`
[Evidence manifest]()
## 11 · Human and agent authoring {#authoring}
### Discover the connected runtime's contract
The registry describes supported commands and components. MCP exposes scoped tools using that contract, with live discovery identifying what the connected server accepts. The default scopes are read-only `core,scripting,content`; write scopes are explicit operator choices. The compiled registry remains useful for offline inspection, while live calls require a freshly validated runtime contract. [64](https://engine.pajama.studio/whitepaper/en#source-registry) [65](https://engine.pajama.studio/whitepaper/en#source-mcp-live) [30](https://engine.pajama.studio/whitepaper/en#source-mcp-scopes)
This matters for long-running projects: an authoring tool and a world server may be upgraded at different times. Discovery gives the tool a way to select supported operations, understand limits and report a capability mismatch before attempting a change.
MCP standardizes tool discovery, input schemas and invocation. World-specific authorization, transaction semantics and resource limits remain responsibilities of the engine and its host. Pajama therefore connects tools to existing admission and publication rules. [R5](https://engine.pajama.studio/whitepaper/en#research-mcp-tools)
### Keep generated behavior inspectable
Luau receives immutable frames and returns typed commands checked by the host. The recoverable ABI2 also makes behavior state explicit: state initialization, migration and execution cross a bounded typed boundary. This allows recovery to associate behavior state with its exact artifact and world effects rather than relying on an opaque VM heap. [14](https://engine.pajama.studio/whitepaper/en#source-script-contract)
Luau's sandboxing guidance supports restricting exposed libraries and isolating scripts, while leaving memory limits, interruption and the safety of host APIs to the embedding application. Pajama's typed commands and execution budgets address that host boundary; the language sandbox alone does not establish gameplay authority. [R6](https://engine.pajama.studio/whitepaper/en#research-luau-sandbox)
An agent can therefore propose content and behavior through the same constrained interfaces used by a human-operated tool. The engine remains responsible for admission, version checks, execution budgets and authoritative effects. This is the practical meaning of AI-native authoring in the project. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [14](https://engine.pajama.studio/whitepaper/en#source-script-contract)
Per-invocation budgets bound one script execution; continuous creation also needs to bound accumulated results. M5 will add package/world accounting for live instances, persistent-state bytes and outstanding work, with reservation and validation at typed-command commit. Exhaustion should produce attributable rejections; accounting must cover deletion, migration and recovery. Acceptance tests will run slow, sustained construction to its budget boundary and verify the world-wide limit across multiple packages. [14](https://engine.pajama.studio/whitepaper/en#source-script-contract) [1](https://engine.pajama.studio/whitepaper/en#source-goal)
### Constraint generation is a compiler pipeline {#constraint-generation}
`LayoutSpecV1 → bounded search → independently verified placements → ordinary Prefab → prepared Package`. The current language uses an integer grid with hard bounds and non-overlap, plus adjacency, separation, group connectivity and excluded rectangles. Compiler identity, specification hash, seed and exact placements are part of authored provenance. Recovery restores committed results instead of rerunning the solver.
Current bounds are a 64 × 64 grid, 32 nodes/prototypes, 128 rules and at most 1,000,000 attempted placements. `BudgetExceeded` means incomplete search; `Unsatisfiable` means the finite search was exhausted. A declared footprint does not prove arbitrary mesh clearance, walkability, structural stability or live terrain support. The camp demo adds footprint-clearance checks for its own asset set. [Generation contract and native application](https://engine.pajama.studio/whitepaper/en#evidence-practical-emergency-camp).
The next domains should add typed hard constraints, soft objectives, budgets and useful diagnostics separately: terrain support, clearance, access and road grade first. World-dependent inputs need snapshot identity and authoritative precondition checks before placement. Expensive solving stays outside the simulation lock. This is an extensible compilation approach, not a claim that one universal DSL already solves every generative system.
### Observe the result as part of the operation {#publication-receipts}
The existing script author runner discovers the live ABI, intersects requested commands with operator ceilings, dry-runs, publishes with revision checks and verifies durable activation through a fresh connection. The current prepared Package runner adds cold preparation, exact-candidate publication and authoritative reconciliation; M5 still owns preview, durable orchestration and broader lifecycle qualification. [66](https://engine.pajama.studio/whitepaper/en#source-author-runner) [67](https://engine.pajama.studio/whitepaper/en#source-author-roadmap)
A lost network response produces an explicit outcome: `not_sent` is eligible for safe automatic retry; `outcome_unknown` requires observation and reconciliation. Visual capture adds another view of the result. A native headless frame can reveal a placeholder or wrong presentation, while authoritative queries verify state and recovery tests verify persistence. A useful transcript combines these observations under the same release identity. [68](https://engine.pajama.studio/whitepaper/en#source-mcp-retry) [69](https://engine.pajama.studio/whitepaper/en#source-headless)
The current prepared runner correlates candidate and release identity; the broader integration contract must also use operation identity and candidate digest to correlate authority lifetime, expected/actual deployment generation, activation tick, durable checkpoint and each client's catalog/resource readiness receipts. **Accepted, active, durable and client-ready** answer different questions; the trace will retain each result and any missing evidence. After a timeout, query the same operation's outcome; any retry must still pass the existing deduplication and version checks. Lost activation responses, interruption before durability and a delayed client will be explicit failure scenarios. Durable Package activation also does not replace recovery tests for subsequent gameplay effects. [17](https://engine.pajama.studio/whitepaper/en#source-publication) [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [67](https://engine.pajama.studio/whitepaper/en#source-author-roadmap)
### An Agent authors and activates a new behavior {#agent-trace}
In a fresh September 21 run, an AI agent inspected the live script contract and authored a bounded **three-stage rescue-platform assembly**. A recording harness used the engine's WebSocket admin API to discover capabilities, submit a dry-run, publish the same candidate with revision checks, and query the result through fresh connections. The retained trace contains actual requests and responses; the generated Luau source is also available.
The observations progress through **0, 1, 2 and 3 assembled sections**. The runtime records **3 committed batches, 6 commands, zero faults and zero host rejections**. The activated artifact matches the preflight digest; the in-memory and persisted deployment generations both reach **2**, with `disk_state: exact`. This validates the authored behavior and durable activation for this run.
#### An AI-authored mechanic, published and observed
After live contract discovery, the assistant authored a three-step rescue-platform behavior. Dry-run, revision-checked publication and fresh queries recorded three built sections, three committed batches and six commands, with no runtime faults or host rejections.
**Provenance:** Recorded on 21 September 2026 through an actual admin WebSocket harness. This is standalone ABI1 script publication, separate from the package example. Binary SHA256 values identify the retained executables; source HEAD is context only. Restart continuation was not tested. The excerpt projects fields from actual records; the download retains all records with documented path redactions.
[agent-tool-trace.jsonl ↓]() — Trace · 125.0 KB
All 93 actual admin WebSocket request/response and authorship records; local deployment paths redacted.
SHA-256: `a8cd57edf8dba1c094e486173e7613af3747d1c1451ea672b57d4186564daeac`
[agent-rescue-platform.luau.txt ↓]() — Trace · 894 B
The new bounded Luau program authored after live contract discovery.
SHA-256: `45189486651f464f7e1c8c6688a58b9f58783cd950e298ac8749abdbbd04c46f`
[agent-verification.json ↓]() — Data · 6.6 KB
Measured outcomes, binary provenance, original digests and exact public redactions.
SHA-256: `f565b074b88ebaeba93b9f0640f7d15895196fa3e59b9133eab22bfd0195172d`
**Read evidence excerpt**
```text
{"schema_version":1,"seq":5,"at":"2026-09-21T13:47:13.855Z","kind":"request","phase":"describe","request":{"cmd":"describe"}}
{"schema_version":1,"seq":6,"at":"2026-09-21T13:47:13.861Z","kind":"response","phase":"describe","response":{"ok":true,"data":{"engine":"pajama-engine","version":"0.1.0"}}}
{"schema_version":1,"seq":7,"at":"2026-09-21T13:47:13.862Z","kind":"request","phase":"script_describe","request":{"cmd":"script_describe"}}
{"schema_version":1,"seq":8,"at":"2026-09-21T13:47:13.865Z","kind":"response","phase":"script_describe","response":{"ok":true,"data":{"runtime_mode":"process_local_abi1","command_contract_v2":{"commands":[{"kind":"set_data_number","capability":"entity_data"},{"kind":"build_prefab","capability":"build"}]}}}}
{"schema_version":1,"seq":9,"at":"2026-09-21T13:47:13.866Z","kind":"request","phase":"script_status","request":{"cmd":"script_status"}}
{"schema_version":1,"seq":10,"at":"2026-09-21T13:47:13.868Z","kind":"response","phase":"script_status","response":{"ok":true,"data":{"runtime":{"active":null},"deployment":{"enabled":true,"disk_state":"exact","generation":0}}}}
{"schema_version":1,"seq":11,"at":"2026-09-21T13:47:13.869Z","kind":"request","phase":"target_discovery","request":{"cmd":"query","tag":"agent-proof-controller","limit":1}}
{"schema_version":1,"seq":12,"at":"2026-09-21T13:47:13.871Z","kind":"response","phase":"target_discovery","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"name":"rescue-assembly-controller","data":{"assembled_sections":0}}]}}}
{"schema_version":1,"seq":13,"at":"2026-09-21T13:47:13.872Z","kind":"request","phase":"prefab_discovery","request":{"cmd":"prefabs"}}
{"schema_version":1,"seq":14,"at":"2026-09-21T13:47:13.873Z","kind":"response","phase":"prefab_discovery","response":{"ok":true,"data":{"prefabs":[{"doc":"One bounded rescue-platform section.","entities":1,"name":"rescue-span"}]}}}
{"schema_version":1,"seq":15,"at":"2026-09-21T13:47:51.953Z","kind":"authored_candidate","goal":"Author and publish a new bounded Luau rescue-platform mechanic from the live runtime contract; observe three typed build steps and a controller counter.","command_ceiling":["build_prefab","set_data_number"]}
{"schema_version":1,"seq":18,"at":"2026-09-21T13:47:51.958Z","kind":"request","phase":"dry_run","request":{"name":"ai-rescue-platform","revision":1,"tick_interval":20,"capabilities":["build","entity_data"],"cmd":"script_put","expected_revision":0,"expected_active_artifact_digest":"","expected_deployment_generation":0,"dry_run":true}}
{"schema_version":1,"seq":19,"at":"2026-09-21T13:47:51.962Z","kind":"response","phase":"dry_run","response":{"ok":true,"data":{"dry_run":true,"revision":1,"source_hash":"4b0a8d45998eac26","artifact_digest":"13c449bb0780d769898656cd22a78eb4573f2501b256402f121a7bb67aef29c6","bytecode_bytes":521}}}
{"schema_version":1,"seq":20,"at":"2026-09-21T13:47:51.962Z","kind":"request","phase":"publish","request":{"name":"ai-rescue-platform","revision":1,"tick_interval":20,"capabilities":["build","entity_data"],"cmd":"script_put","expected_revision":0,"expected_active_artifact_digest":"","expected_deployment_generation":0,"dry_run":false}}
{"schema_version":1,"seq":21,"at":"2026-09-21T13:47:51.973Z","kind":"response","phase":"publish","response":{"ok":true,"data":{"dry_run":false,"revision":1,"source_hash":"4b0a8d45998eac26","artifact_digest":"13c449bb0780d769898656cd22a78eb4573f2501b256402f121a7bb67aef29c6"}}}
{"schema_version":1,"seq":23,"at":"2026-09-21T13:47:51.975Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":0}}]}}}
{"schema_version":1,"seq":47,"at":"2026-09-21T13:47:53.033Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":1}}]}}}
{"schema_version":1,"seq":65,"at":"2026-09-21T13:47:53.831Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":2}}]}}}
{"schema_version":1,"seq":89,"at":"2026-09-21T13:47:54.892Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":3}}]}}}
{"schema_version":1,"seq":93,"at":"2026-09-21T13:47:54.896Z","kind":"response","phase":"activation","response":{"ok":true,"data":{"runtime":{"active":{"artifact_digest":"13c449bb0780d769898656cd22a78eb4573f2501b256402f121a7bb67aef29c6","bytecode_bytes":521,"capabilities":["build","entity_data"],"name":"ai-rescue-platform","revision":1,"source_hash":"4b0a8d45998eac26","tick_interval":20},"metrics":{"commands":6,"committed_batches":3,"committed_commands":6,"consecutive_faults":0,"faults":0,"host_rejections":0,"last_committed_tick":820,"last_run_us":53,"max_run_us":235,"memory_bytes":649784,"runs":3}},"deployment":{"disk_state":"exact","generation":2,"persisted_generation":2}}}}
```
[Evidence manifest]()
This run exercises the standalone ABI1 script-publication surface. Its local progress cursor does not establish restart continuation. The Package case below exercises versioned content and Package-owned behavior; bringing agent creation through that complete lifecycle is the purpose of M5. [66](https://engine.pajama.studio/whitepaper/en#source-author-runner) [67](https://engine.pajama.studio/whitepaper/en#source-author-roadmap)
## 12 · System 1 and System 2: agent roles, coordination and integration {#agents}
Pajama assigns agents two kinds of work: **System 1 selects the next action from existing capabilities; System 2 plans tasks and authors new capabilities.** They cooperate through versioned Packages, bounded player intents and verifiable receipts. System 1/System 2 describe engineering roles here, not claims about a model's internal cognition or a fixed speed guarantee. The current System 1 adapter uses Jev; System 2 integration targets Codex and other planners that can call tools. [70](https://engine.pajama.studio/whitepaper/en#source-system-one-guide) [R7](https://engine.pajama.studio/whitepaper/en#research-jev-system-one)
### What each agent can do {#agent-roles}
| Dimension | System 1: acting agent | System 2: planning and authoring agent |
| --- | --- | --- |
| Question | “Which approved skill or driving maneuver should I choose now?” | “How can I complete the goal, and what code, assets and checks are needed?” |
| Input | Current intent, bounded public player/nearby-entity summaries, approved skill descriptions. | User goal, live interface contracts, authorized world queries, source files and publication results. |
| Output | The current adapter returns one approved skill, `wait` or `plan`, with probabilities and confidence. | Candidate Luau, Package documents, asset-generation jobs, validation steps and subsequent tool calls. |
| Engine example | Select `ground-pulse` when a player asks to dig underfoot; decline activation when conditions are insufficient. | Design destructible building components and construction rules; coordinate character generation, rig binding and skill assets; revise a rejected candidate. |
| Entry point | Ordinary player WebSocket and `ActivatePackageSkill`; no admin write interface. | Read-only engine MCP; explicitly enabled authoring MCP, or the Cloudflare job bridge. |
| Cadence | One decision for a discrete intent, avoiding remote inference on each tick. | Iterate on goals and check results; generation, building and publication are asynchronous. |
| Authority | Select only configured, approved and active skills; the caller supplies aim, and the server determines the actual hit. | Propose new code/content; publication still follows validation, admission, generation checks and activation. |
The Jev adapter currently supports up to eight configured skills plus `wait` and `plan`. It cannot generate Luau, invent skills or understand the complete rendered scene. Broader NPC tactics, skill ranking and target selection require separate input contracts and acceptance. System 2 is likewise limited by connected tools and authorization: generating code does not establish that it is active in the world. [71](https://engine.pajama.studio/whitepaper/en#source-system-one-director) [72](https://engine.pajama.studio/whitepaper/en#source-system-one-client) [73](https://engine.pajama.studio/whitepaper/en#source-agent-authoring-interface)
### A stable contract for future agents {#agent-contract}
The prepared tools are usable building blocks; the following **shared third-party agent contract is still proposed**. It should preserve agent/world/session identity, granted capabilities, permitted observation scope, observation time/digest, relevant exact Package references, action deadline, cancellation state and budget ownership across reconnects. Action outcomes must distinguish accepted, committed/failed, unknown and observed postcondition.
An unrelated Package addition should not cancel a still-valid pinned driving action. A revoked capability, changed relevant definition or stale observation must cause re-observation or rejection. Inference, asset generation and compilation need bounded durable jobs; they must not hold the world tick. Cancellation after a world commit cannot undo that commit.
The next integrated proof is one author agent creating a capability, publishing through the existing transaction, and a separately authorized acting agent discovering and using it. Include a conflicting candidate, lost response and coordinator restart. The live driving video and deterministic eight-scenario suite provide components of this proof, not completed autonomous creator-to-player orchestration. [Proposal and prepared implementation](https://engine.pajama.studio/whitepaper/en#evidence-architecture-update).
### Coordination through explicit handoffs {#agent-coordination}
```text
User goal
+-- Existing skill suffices -> System 1 -> type/confidence/state checks
| -> player intent -> authority
+-- New capability / multiple steps -> System 2 -> candidate Package
-> validation, admission, CAS, checkpoint, tick activation
|
Fresh Catalog + approved skill policy
|
System 1 selects an available skill
Authoritative result -> replication, cues and receipts -> observe or plan
```
This is the **target coordination flow**. Both entry points exist, but `needs_planning` remains a structured result for the caller. Automatic Codex invocation, a cross-process handoff queue and resumption of interrupted tasks are not yet connected. [70](https://engine.pajama.studio/whitepaper/en#source-system-one-guide)
For “build a destructible castle, then open an entrance,” the roles divide into five steps:
1. **Discover and plan.** System 2 reads `world_script_describe` and content contracts, establishing component counts, resource budgets, destruction behavior and completion criteria. An already approved skill can be used directly when no new capability is needed.
2. **Author and validate.** System 2 produces Luau and Package candidates, coordinates existing asset generators and verifies binding results. Luau reads immutable frames and returns typed commands; network calls and generation run outside the sandbox.
3. **Publish and confirm.** Candidates use the existing cold stage, admission, generation CAS and composite-checkpoint path, with tick-boundary activation. A `completed` job or `submitted` release does not establish an updated world: query authoritative `active` for the exact Package identity.
4. **Hand over available capabilities.** The caller refreshes the Catalog and updates the skill policy according to authorization. System 1 selects an approved entrance-breaking skill only against fresh observations; late decisions for the previous Package revision are discarded.
5. **Execute and inspect.** The server validates player intent, executes Package behavior, commits collision/terrain/entity changes and replicates them. System 1 consumes the matching execution receipt; System 2 revises plans in response to failure reasons or new user goals.
This example describes coordination design, not an already completed “Codex builds a castle, then Jev breaches it” joint acceptance. Building, character-authoring and Jev proofs come from separate run records. [73](https://engine.pajama.studio/whitepaper/en#source-agent-authoring-interface) [20](https://engine.pajama.studio/whitepaper/en#source-building-rehearsal) [74](https://engine.pajama.studio/whitepaper/en#source-system-one-proof)
A proposed handoff record should include the original goal/intent, task ID, world and player-session identity, observation timestamp/digest, exact Package references, approved action scope, remaining time/call budgets, prior request ID and authoritative result. This is a new caller-orchestration contract, **not an existing server message schema**. Model output and web/chat content cannot expand action permissions.
| Result | Caller response |
| --- | --- |
| `wait` | Wait without repeatedly paying for another decision. |
| `needs_planning` | Route by `reason`: send complex goals to System 2; refresh stale observations; stop or restore prerequisites for budget/provider failures. |
| `rejected` | Inspect the server reason, then re-observe or revise content if needed. |
| `unknown` / `unresolved_activation` | Freeze the affected action and reconcile the original request; do not assume it failed and cast again. |
| `committed` | Record the matching authoritative result; inspect client presentation when visual acceptance is required. A model's claim is insufficient. |
System 1 currently rechecks session, server identity, character, Catalog, active Package closure, terrain and the public observation digest. It rejects expired or superseded decisions. Confidence guides routing; the engine retains authority, and high confidence does not guarantee semantic correctness. [71](https://engine.pajama.studio/whitepaper/en#source-system-one-director) [72](https://engine.pajama.studio/whitepaper/en#source-system-one-client) [R8](https://engine.pajama.studio/whitepaper/en#research-jev-confidence)
### Connect System 1: OpenRouter / Jev {#system-one-connect}
**Available interface.** Run from the engine repository with Node 22+, a Catalog V2 game server and an already published, active character/skill Package. Copy `scripts/system-one/config.example.json` into an ignored run directory, set the actual `game_url`, and configure `character` and `skills`. The example uses `ground-pulse` from `studio.generated.meshy-hero`; a policy entry neither creates nor publishes that Package. [70](https://engine.pajama.studio/whitepaper/en#source-system-one-guide)
```powershell
# Supply OPENROUTER_API_KEY through the process environment, not JSON or model context.
node scripts/system-one/cli.mjs target/my-jev-demo/system-one.json target/my-jev-demo/intent.txt
```
An intent file can request “Dig a small hole beneath my feet using ground pulse once.” The CLI joins as its own player, waits for character selection to replicate, makes at most one model call and prints JSON. Remote game connections require WSS; loopback also permits WS. Reusable Node interfaces are `JevProvider`, `GameClient` and `SkillDirector.decide(intent)`. [70](https://engine.pajama.studio/whitepaper/en#source-system-one-guide)
The adapter uses OpenRouter's native `POST /api/alpha/decisions`, requests `typesafe/jev-1.13`, restricts routing to TypeSafe without fallback, and requires the accepted response version `typesafe/jev-1.13-20260917`. Chat Completions is not a substitute for this contract. Defaults are a 1.5-second timeout, a 2-second observation age, selected probability of at least 0.85 and confidence of at least 0.65. Thresholds still require task-specific calibration. [75](https://engine.pajama.studio/whitepaper/en#source-system-one-provider) [R9](https://engine.pajama.studio/whitepaper/en#research-openrouter-jev)
### Connect System 2: Codex / MCP {#system-two-connect}
**Available interface, with a client-publication acceptance gap.** Codex first discovers capabilities through read-only engine MCP, then explicitly connects authoring MCP to submit candidates. The following `config.toml` example requires actual absolute paths in place of `G:/pajama-studio/engine`, plus a running server and authoring host. [73](https://engine.pajama.studio/whitepaper/en#source-agent-authoring-interface) [R10](https://engine.pajama.studio/whitepaper/en#research-codex-mcp)
```toml
[mcp_servers.pajama-engine]
command = "cargo"
args = ["run", "-q", "-p", "pajama-mcp", "--", "--require-live", "--scope", "core,scripting,content"]
cwd = "G:/pajama-studio/engine"
[mcp_servers.pajama-authoring]
command = "node"
args = ["G:/pajama-studio/engine/scripts/authoring/mcp.mjs"]
startup_timeout_sec = 30
tool_timeout_sec = 120
[mcp_servers.pajama-authoring.env]
PAJAMA_AUTHORING_CONFIG = "G:/pajama-studio/engine/target/my-authoring-demo/config.json"
```
Build `pajama-mcp` first with `cargo build -p pajama-mcp` in the same environment so initial compilation does not consume the handshake window. Record `codex --version` and inspect connections with `/mcp`. For a non-default admin port, add `--admin` and the actual loopback URL to the read-only MCP arguments. [76](https://engine.pajama.studio/whitepaper/en#source-agent-authoring-mcp)
The current local authoring surface has seven tools: `authoring_generate_character`, `authoring_character_status`, `authoring_prepare_package`, `authoring_candidate_status`, `authoring_publish_prepared_package`, `authoring_publish_package` and `authoring_release_status`. The three prepared-candidate tools extend the historically cited four-tool interface; their current contract is in the [prepared authoring record](https://engine.pajama.studio/whitepaper/en#evidence-prepared-authoring). A planner prepares files, inspects the sealed digest, submits that exact candidate and polls activation, then inspects the world through authorized queries. Generated character artifacts enter an ordinary Package after binding validation. Behavior-bearing Packages must follow composite-checkpoint publication; separate content/script writes cannot emulate atomic publication. [73](https://engine.pajama.studio/whitepaper/en#source-agent-authoring-interface)
In the September 21 record, Codex CLI **0.155.1** completed MCP handshake and discovery; automatic approval review rejected its actual publication call. The later prepared-authoring test exercises a separate stdio MCP process and real publication; it does not retroactively establish that client's approval-path acceptance. Engine-state queries, native rendered frames and model visual input are distinct capabilities; this MCP configuration does not automatically stream live video into Codex. [73](https://engine.pajama.studio/whitepaper/en#source-agent-authoring-interface)
### Custom Cloudflare agents: orchestration outside engine authority {#cloudflare-agent-connect}
**Available remote job bridge.** `services/pajama-author-agent` uses the Agents SDK to manage durable jobs. A planner uses author credentials to submit `POST /jobs` and reads `GET /jobs/`. Local `scripts/authoring/remote-bridge.mjs` claims outbound work and calls the same AuthoringRuntime, keeping the admin listener local. Author and bridge credentials are separate; jobs use idempotent IDs and expiring claims. [77](https://engine.pajama.studio/whitepaper/en#source-agent-cloudflare)
```json
{
"id": "observe-agent-demo",
"name": "world_observe",
"args": {}
}
```
This is an existing observation-job body, without credentials. Publication jobs use `authoring_publish_package` with reviewed Package input in `args`; a completed job still requires an `authoring_release_status` check for authoritative activation. The Cloudflare job service does not run an LLM automatically or host Jev's player WebSocket decision loop. Scheduling both agent roles requires further handoff, player-identity authorization and recovery work in the orchestration layer. [77](https://engine.pajama.studio/whitepaper/en#source-agent-cloudflare) [73](https://engine.pajama.studio/whitepaper/en#source-agent-authoring-interface)
### Cost, evidence and joint acceptance {#agent-acceptance}
Reduce cost first by routing work: explicit waiting and deterministic decisions need no inference; System 1 handles simple existing skills; new capabilities, ambiguity and complex goals go to System 2. The implementation bounds observations, skill count, frequency and calls per director lifetime. Cross-process budgets, durable task queues and a general rule router still require orchestration work. Package publication and physics ticks do not wait for model inference. [71](https://engine.pajama.studio/whitepaper/en#source-system-one-director)
In the final September 21 Jev run, three real requests—wait, a Chinese complex goal returned for planning, and a Chinese skill command—took about **180–415 ms** each. Returned charges totaled **$0.000070938**. The real server executed the skill; two player connections received a matching dig brush with a 2 m radius, and the observer received matching cast/impact cues. The first English-only skill description yielded probability 0.78 and no activation. Adding a bilingual description yielded 0.99 without lowering the execution threshold. [74](https://engine.pajama.studio/whitepaper/en#source-system-one-proof)
#### Real Jev decision → authoritative skill → two-client terrain
Three real OpenRouter decisions test waiting, planning handoff and a Chinese skill intent. The last commits a 2 m dig brush and matching observer cues. The file retains earlier failed attempts and the later local-host outage.
**Provenance:** Recorded 2026-09-21; copied byte-for-byte from engine commit 382ca36, docs/evidence/jev-system-one-2026-09-21.json. The server baseline is d96cddf with a retained binary hash; Node adapter hashes are included. This is game-protocol acceptance, separate from native captures and the earlier authoring trace. Website publication reruns no inference.
[jev-system-one-2026-09-21.json ↓]() — Data · 9.8 KB
Version, decisions, latency/cost, exact Package and activation identity, matching brushes, cues and recorded limitations.
SHA-256: `364cb970a727ee87220cc62f06249ec0cbaeef3deb04905e4339827064cb582e`
[Evidence manifest]()
This proves a bounded skill loop, not sustained multi-agent autonomy. A later local Wrangler disconnect caused the server to exit after lease renewal failed; that environment failure is retained. Joint acceptance still needs actual Codex publication, automatic `needs_planning` handoff and budget control, reconciliation after orchestrator restarts, invalidation of old decisions during publication, matching frames on two native clients, and sustained operation through recovery. [70](https://engine.pajama.studio/whitepaper/en#source-system-one-guide)
## 13 · AI-assisted engine evolution {#evolution}
**Proposed architecture.** Pajama should support a durable loop from observed failure to validated change, then retain evidence that helps the next improvement. The external evolution control plane coordinates experiments and releases; the authoritative server continues to own world state. This extends the existing product boundary and does not require a new optimizer inside the tick. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution)
Duan et al.'s September 15 revision distinguishes improving an artifact from improving the process that creates its successors. Reusing a changed improver establishes structural recursion; independently better successors at comparable budgets are a further test. This survey informs our design, not a claim that unrestricted self-improvement is solved. [R11](https://engine.pajama.studio/whitepaper/en#research-recursive-improvement)
### Five targets, explicit release boundaries {#evolution-boundaries}
| Target | What AI may propose | How the change becomes active |
| --- | --- | --- |
| Content and gameplay | Luau, destructible building kits, character/rig/skill Packages. | Existing cold stage, admission, generation CAS, composite checkpoint and tick activation. Confirm the exact revision on clients. |
| Agent behavior | Skill descriptions, approved policy, routing, prompts and harness code. | Replay and shadow decisions, then replace external workers after reconciling pending actions. |
| Native engine | Rust implementation, physics/rendering algorithms and trusted shaders. | Git patch, build, correctness/lifecycle/performance checks and a compatible binary release. Server replacement uses drain/checkpoint and a new fenced epoch. |
| World models | Capture selection, datasets, adapters, weights, caching and serving configuration. | Offline comparisons and versioned provider selection; generated presentation does not decide authoritative physics. |
| Improvement process | Diagnosis, experiment selection and reusable repair recipes. | Compare old and new improvers on held-out tasks, then record which accepted version governs the next round. |
A common ledger correlates releases without turning them into one activation mechanism. **Packages do not load native Rust code.** An old binary cannot read a new persistence format without an explicit compatibility adapter. A content rollback restores definitions and validated typed state; it does not erase destruction already committed to the world. The current V1/ABI2 publication split still needs convergence. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution) [4](https://engine.pajama.studio/whitepaper/en#source-package-contract)
### Close the loop outside the simulation {#evolution-loop}
```text
World / native clients / CI / authoring receipts
|
Reproducible case + exact versions
|
System 2: hypothesis and bounded plan
|
Isolated candidate -> tests / replay / performance
|
Independent verdict -> rejected or inconclusive evidence
|
Existing release path -> staging -> scoped rollout
|
Authoritative results + retained recipe -> next case
```
System 1 executes approved skills and supplies bounded outcomes; it can also exercise a staging scene through ordinary player intents. System 2 diagnoses the failure, chooses the responsible layer and authors a candidate. Executable checks and an independently controlled evaluator decide whether to promote it. An author's model-generated verdict cannot substitute for world receipts, regression tests or native frames. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution) [70](https://engine.pajama.studio/whitepaper/en#source-system-one-guide)
The first implementation can be a repository runner with immutable artifacts and an append-only experiment journal. Cloudflare may later coordinate durable claims and budgets; native builds and GPU trials run on suitable workers. The current Cloudflare authoring bridge is not an engine-build or training executor. No new always-on microservice is required to start.
### How each role makes engineering decisions {#evolution-decisions}
**Use a versioned decision protocol.** At each round, provide the agent with the current goal, authorized scope, owner lane, exact source/runtime identities, relevant contracts, a bounded set of prior decisions and actual evidence. Distinguish hard invariants from conditional practices and untested hypotheses. Repository agents can now follow `docs/ENGINE_DECISIONS.md` through the `AGENTS.md` routing table and use its decision template. Automated enforcement remains proposed. [79](https://engine.pajama.studio/whitepaper/en#source-engineering-decisions) [80](https://engine.pajama.studio/whitepaper/en#source-decision-routing)
| Role | Required decision output | Boundary |
| --- | --- | --- |
| Router / diagnostician | Symptom, responsible lane, facts versus hypotheses and the next distinguishing measurement. | A symptom alone does not establish the root cause. |
| Architect / planner | Meaningful alternatives, applicable constraints and a chosen experiment or implementation. | A high benefit score cannot override an invariant. |
| Implementer | Small candidate with exact base/digest and relevant tests. | Return to planning when assumptions or scope change. |
| Verifier | Counterexamples, regression results and an independent measured verdict. | The author cannot attest to its own release success. |
| Release controller | Approved artifact, expected predecessor, authorized scope and activation/recovery receipts. | Use the target's existing release boundary. |
| Memory curator | Tested recipe, failures, applicability and invalidation triggers. | One successful case does not make a universal rule. |
These are responsibilities, not a requirement to run six models. One System 2 agent can perform several stages sequentially, with protected evaluation and release rights kept separate. System 1 remains a bounded skill selector. A future fast path may reuse a proven engineering recipe when its preconditions match and required checks still run; the current Jev adapter does not choose architecture or edit engine code. [79](https://engine.pajama.studio/whitepaper/en#source-engineering-decisions)
For a material choice, the proposed protocol applies this order:
1. **Identify the product outcome and owner.** Read the relevant lane rather than loading the entire repository. Mark disagreement between code, documentation and tests as a gap to investigate.
2. **Separate facts from uncertainty.** If the cause is unknown, select the cheapest bounded observation that could change the decision. Do not invent confidence percentages or precise gains.
3. **Compare plausible options.** Include the current baseline, a local change behind the existing interface and a broader alternative when meaningful. Gathering evidence is a valid choice; trivial fixes need no artificial alternatives.
4. **Filter before ranking.** Reject violations of scope, authority, compatibility, hard budgets or recovery. Compare feasible options by relevance to the product blocker, evidence, benefit, complete cost, affected surface and reversibility.
5. **Choose the next action.** Return `measure`, `experiment`, `implement`, `promote`, `defer` or `escalate`, with concise rationale and invalidation conditions. Promotion needs independent acceptance of the exact candidate.
6. **Stop or re-plan from outcomes.** Stop when the gate is met, the budget is spent or another experiment has little decision value. Re-plan after a changed baseline or a counterexample. Routine authorized choices proceed without repeated permission; escalation is for genuinely missing scope, authority or product tradeoffs.
If options trade different benefits and neither dominates, use a small discriminating experiment or obtain the missing product preference. This protocol improves accountability; it does not guarantee a globally optimal choice. Keep a reviewable explanation and evidence, not private reasoning transcripts. [79](https://engine.pajama.studio/whitepaper/en#source-engineering-decisions)
### Best practices need applicability conditions {#engineering-practices}
Epic's profiling guidance ties performance budgets to target hardware. Godot's September 15 rendering report shows why an intuitive optimization, including caching, may lose through memory traffic. Google's canary guidance couples limited rollout with controls and representative evaluation. These sources inform methods; the following applications are Pajama proposals. [R12](https://engine.pajama.studio/whitepaper/en#research-epic-performance) [R13](https://engine.pajama.studio/whitepaper/en#research-godot-render-optimization) [R14](https://engine.pajama.studio/whitepaper/en#research-sre-canary)
| Observed condition | Candidate practice | What must still be checked |
| --- | --- | --- |
| Repeated computation dominates a measured CPU stage | Cache, batch, incremental updates or compact data layout. | Invalidation, retained memory, other workloads and actual frame/tick tails. |
| Measured blocking with separable ownership | Cold preparation and bounded asynchronous jobs. | Queue bounds, cancellation, stale results and authoritative commit order. |
| Allocation churn dominates | Pool or reuse objects with clear lifetimes. | Peak retained memory, reset correctness and malformed inputs. |
| Terrain continuity or residency is the bottleneck | Spatial streaming and bounded residency. | Collision, edits/revisit, two clients, coordinate compatibility and recovery. |
| Inference cost dominates a valid task | Deterministic routing, smaller decisions, caching or a provider comparison. | State/intent changes, correct abstention, causal fidelity and cost per accepted result. |
| A candidate passes tests and rollout is authorized | Limited staging/canary with control and absolute health limits. | Representative samples and stop/recovery rules. Authority canaries use separate worlds, never competing writers in one world. |
Rules should carry an ID/version, source, owner, applicability condition, required evidence, validator and invalidation triggers. “Always cache,” “always add threads,” and “always shard” are not valid rules. Native performance continues to use the existing A/B/A and fidelity gates; changing architecture does not waive them. [79](https://engine.pajama.studio/whitepaper/en#source-engineering-decisions) [81](https://engine.pajama.studio/whitepaper/en#source-evolution-performance)
### Example: deciding what a terrain boundary requires {#engineering-decision-example}
The same symptom supports different choices depending on the actual goal. This is a proposed pre-experiment comparison, not a new measurement:
| Option | Appropriate goal | Decision for continuous traversal |
| --- | --- | --- |
| Distant visual terrain or fog | A wider-looking finite demo vista. | Insufficient for collision, traversal and edit persistence. |
| Larger accepted finite extent | Move the boundary farther away within verified budgets. | Still finite; not proof of a continuous world. |
| Streamed authoritative terrain | Traverse, edit and revisit beyond current residency. | Candidate needing coordinate, ownership, memory and lifecycle experiments. |
| Immediate renderer replacement or sharding | A demonstrated limitation in that subsystem. | Defer until measurements identify that limitation. |
For the continuous-world goal, first choose `measure`: bind the scene/source identity and observe boundary behavior, collider/terrain residency and frame/tick/memory cost. Then select the smallest streaming experiment that can test traversal, edits and recovery. If the user's goal is only presentation, the first option can be reasonable. This makes the choice responsive to the goal rather than to a fashionable technique. [79](https://engine.pajama.studio/whitepaper/en#source-engineering-decisions)
Each consequential decision should retain alternatives, rejected reasons, constraints, evidence, total budget, chosen action, stopping conditions and later outcome in a versioned record. Small fixes can keep that information in their change description. A proposed dispatcher verifies versions, budgets and permissions; protected runners bind evidence to the actual artifact and evaluator. Agent-authored `passed: true` is not a valid attestation. The new guide/template supports this process today, but the dispatcher and attestation service are not implemented. [79](https://engine.pajama.studio/whitepaper/en#source-engineering-decisions)
The AI may propose revisions to best-practice rules as a separate experiment. An authorized policy owner adopts independently validated changes for later rounds; the candidate cannot weaken its own current test. Evaluate the decision policy itself against a frozen baseline on held-out engine tasks, including invalid promotion, unnecessary escalation, inaction, regressions and total cost—not merely whether it filled in every field. [79](https://engine.pajama.studio/whitepaper/en#source-engineering-decisions)
### Persistent evidence, bounded execution and recovery {#evolution-contracts}
Two stores have different responsibilities: **world checkpoints preserve gameplay truth; the evolution ledger preserves experiments and decisions.** Link them through exact identities. The proposed coordinator records are:
| Record | What must survive the run |
| --- | --- |
| Case and plan | Failure predicate, reproduction, world/epoch/tick, source/binary/Package versions, hypothesis, allowed operations, evaluator version and total time/call/token/currency/compute budget. |
| Candidate and verdict | Immutable patch/artifact, dependencies and tool versions; assertions, raw evidence digests, regressions, paired cost/outcome results and `accept`, `reject` or `inconclusive`. |
| Release and memory | Expected predecessor, idempotent operation ID, exact activation/recovery receipts; successful and failed recipes, applicability conditions and evidence of later reuse. |
These are **proposed orchestration records**, not existing MCP tools or server messages. Persist budget reservations before dispatch. Claims and journal revisions fence stale workers. On restart, reconcile an unknown publication or skill request by its original identity before another effectful attempt; do not restore spent budgets. A changed baseline requires reevaluation. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution)
An experiment copies an authorized checkpoint into a separate world identity, storage namespace and writer lease. Retain seeds, intent/event sequences, tick policy, exact content, model responses and hardware/runtime identity. Recorded responses help reproduce a failure; separate real-provider trials measure model drift and latency. Physics and GPU results are not assumed bitwise identical across machines: compare exact document/event identities where required and declared semantic/visual tolerances elsewhere. Keep credentials and raw private conversations out of evidence exports.
### Measure improvements without rewarding regressions {#evolution-evaluation}
Freeze acceptance criteria for each round. The candidate author can propose new tests but cannot remove protected cases, lower thresholds or rewrite held-out scoring during the same evaluation. Correctness, authority, compatibility and recovery are hard gates. Compare completion, regressions, tail latency, memory and cost separately; a higher aggregate score cannot compensate for corrupted state. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution)
For native performance, reuse the existing `tools/perf/baseline.py` and `tools/perf/compare.py` workflow. Its A/B/A controls bind source, binaries, workload and presentation state, with visual-fidelity checks. Default acceptance requires at least 3% median improvement, at most 2% p95 regression and less than 8% control drift. Inconclusive results do not justify a release. General CI checks engine correctness; acceptance-grade timing requires a stable runner. Missing private fixture coverage remains unverified. [81](https://engine.pajama.studio/whitepaper/en#source-evolution-performance) [82](https://engine.pajama.studio/whitepaper/en#source-evolution-ci)
Reduce experiment cost with reproduction deduplication, cached immutable builds, small deterministic tests before expensive native/provider trials, event-triggered diagnosis and bounded candidate search. Report **total cost per validated improvement**, including failed attempts, evaluation, model calls, compute and human review. For changes to the improver itself, compare old and new versions from the same engine baseline on unseen tasks with the same model access and total budget. Confirm that retained knowledge changes a later decision; merely storing notes is insufficient. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution)
### First proofs: agent policy and continuous-world engineering {#evolution-demonstrations}
The Jev bilingual-description fix is a useful seed: its small recorded sample improved selection without lowering the execution threshold. It was human-directed, not an autonomous evolution demonstration. Build an independently labelled test family covering Chinese/English paraphrases, negation, waiting, complex plans, stale Catalogs, cancellations and uncertain activations. Compare correct actions **and correct abstentions**, then verify accepted choices through two player connections. Retain the winning policy and prove its reuse on a new case. [74](https://engine.pajama.studio/whitepaper/en#source-system-one-proof) [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution)
For an engine-level case, travel toward the terrain boundary and distinguish an intentional world limit from missing collision, missing chunks or a visual cliff. A continuous-world candidate must verify traversal, edits, revisit, two-client agreement and reconnect/restart while bounding memory and tail latency. Hiding the horizon alone cannot pass. Coordinate/extent changes require explicit compatibility work; the agent must not simply remove the movement clamp. This turns the world-expansion direction into a sequence of testable changes. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution) [48](https://engine.pajama.studio/whitepaper/en#source-terrain-domain) [51](https://engine.pajama.studio/whitepaper/en#source-terrain-movement)
The same exact-state scene can become a world-model experiment, with splits by world/scene/trajectory to avoid adjacent-frame leakage. Improve capture selection, caching or serving first where measurements justify it; training new weights remains an offline candidate with its own cost and causal-consistency checks. H3/Wan selection continues to follow the [shared-scene comparison](https://engine.pajama.studio/whitepaper/en#model-benchmark).
### Increase autonomy only after the corresponding proof {#evolution-rollout}
| Stage | Exit evidence |
| --- | --- |
| Reproducible assistance | A real failure, an isolated candidate, an honest verdict and retained artifact/cost records. |
| Retained strategy | New tasks actually use past recipes and outperform a frozen baseline at matched budgets without regressions. |
| Active task selection | Generated stress cases improve independent held-out outcomes while retaining old capabilities. |
| Governed adaptation | Durable budgets/claims, restart reconciliation, duplicate/stale-request and rollback tests pass before unattended rollout. |
| Improvement of the improver | Multiple inherited rounds produce better successors than the frozen improver under comparable resource limits. |
The engine has useful authority, Package, CI, performance and bounded-agent foundations. The unified evolution coordinator, protected evaluation service, automatic curriculum and autonomous binary rollout are **not implemented**. This chapter proposes their contracts; it adds no runtime acceptance claim. Start with a named product-gate failure or measured limit, keeping the coherent Package lifecycle as the shipping priority. [78](https://engine.pajama.studio/whitepaper/en#source-engine-evolution)
## 14 · Dynamic gameplay through a versioned Package {#walkthrough}
The research-station rehearsal makes the Package boundary tangible: **one release carries a structural kit, a construction policy, a damage rule and presentation cues into a running world.** The recorded release is `studio.generated.meshy-hero`, revision **2**, digest beginning `93d02749`. Two native observers are connected before the new construction begins. [83](https://engine.pajama.studio/whitepaper/en#source-building-package) [20](https://engine.pajama.studio/whitepaper/en#source-building-rehearsal)
### Author reusable parts and executable rules
The Package defines 17 structural part types, including floors, columns, walls, stairs and tower sections. Each part carries a primitive visual shape, static collision and a breakable-block component. The `build-fortress` Luau policy computes placement from a small set of dimensions, then emits bounded batches of typed `build_prefab` commands. Its recoverable state records construction progress. The runtime resolves every part through the admitted Package revision. [83](https://engine.pajama.studio/whitepaper/en#source-building-package) [14](https://engine.pajama.studio/whitepaper/en#source-script-contract)
This is the practical scope of dynamic gameplay authoring: an author supplies data and bounded policy, and the running engine turns them into interactive world state. A generation system can propose those same documents. The station is a recorded execution of an authored Package; the separate [Agent trace](https://engine.pajama.studio/whitepaper/en#agent-trace) demonstrates live AI authorship and script publication.
### Publish into an already running world
The rehearsal starts from the character-only release and observes an empty construction site. The authoring service submits the new Package against the expected generation. A subsequent authoritative status query records generation **2**, catalog revision **2**, and the exact revision-2 digest. The construction history records **0 → 399** Package-owned blocks, including intermediate counts. This links publication identity to an observable world change. [20](https://engine.pajama.studio/whitepaper/en#source-building-rehearsal) [17](https://engine.pajama.studio/whitepaper/en#source-publication)
#### From package behavior to constructed, damageable objects
The same native view records the open site, foundation and growing structure. The recorded package creates 399 building parts; a separate breach-wall interaction in the same run reduces a selected wall from 180 HP to removal, observed by both protocol peers.
**Provenance:** Recorded September 21, 2026 in target/complex-building-evidence/construction. Images are unchanged originals; JSON is an explicit public field projection and the Luau files are exact source strings from build-live.json. This deterministic rehearsal is distinct from an LLM tool-call transcript. Implementation reference fe4d401 is available; the artifacts do not embed the executable’s exact commit.
![The native multiplayer scene before construction, showing open grassland, trees and two player characters.]()
Before publication: the same native client shows the open site; 27 entities are present in its captured view.
[station-before.png ↓]() — Image · 2.6 MB
SHA-256: `504884b9db59939fb73929a024cbce1e0f010f460e31967b1435c76dd6d2f6ce`
![A rectangular slab foundation appears in the same native game scene.]()
Construction begins: the package behavior places the foundation while the clients remain connected.
[station-foundation.png ↓]() — Image · 2.6 MB
SHA-256: `fd94695eed81e9501c59df2f3ec0a1f687d7904b4eaafd5f1ae0c994a71a2115`
![An incomplete multi-storey building with exposed columns and floor slabs in the native client.]()
Construction in progress: floors, columns and walls appear through bounded batches of typed build commands.
[station-in-progress.png ↓]() — Image · 2.6 MB
SHA-256: `2cbe867c7653cac3e92a018d69093534b421cc7a1717d1cddd0ed8a98f012610`
[package-rehearsal.json ↓]() — Data · 21.7 KB
Public field projection of the recorded publication, construction, damage, cue and removal receipts, with capture metadata and source-file hashes.
SHA-256: `510f28691846a31a3de06cc717fa6ed07796ec0289fcff8236710fd2b18efee1`
[build-fortress.luau.txt ↓]() — Trace · 4.4 KB
Exact build-fortress Luau source from this run’s submitted package bundle: procedural layout, typed build\_prefab commands and a persisted construction cursor.
SHA-256: `892c8f84d4817844a966f04474e8207713e6c0a964923e8bfcf42222a6280e8c`
[breach-wall.luau.txt ↓]() — Trace · 1.2 KB
Exact breach-wall Luau source from the same bundle: validates the authoritative target and returns a typed 60-point damage command.
SHA-256: `15d2fb24760ce376a657fcaea7e6efe1daf627c7e3d3a87f611f0dbfa6c8b6cf`
**Read evidence excerpt**
```text
Formatted summary derived from package-rehearsal.json / 根据公开回执整理的摘要
2026-09-21 · deterministic package rehearsal / 确定性内容包演练
package: studio.generated.meshy-hero @ revision 2
publication: request build-live → generation 2 / catalog 2
construction history: 0 → 399 parts
typed behavior: build_prefab batches; persisted cursor
breach-wall requests: 91001 / 91002 / 91003
target 994 HP: 180 → 120 → 60 → removed
building parts: 399 → 398
requesting and observing protocol peers: cue events and remove 994 recorded
Not an LLM conversation or raw tool-call log / 非 LLM 对话或原始工具调用日志
```
[Evidence manifest]()
### Turn generated structure into gameplay
The same Package binds the `breach-wall` skill to bounded behavior. A player sends a skill intent; the server's targeting path selects the hit, and the behavior checks the immutable event/frame before proposing **60 damage** to the eligible block. The block's initial health is **180**. The accompanying probe sends player-protocol requests without world-edit authority. [83](https://engine.pajama.studio/whitepaper/en#source-building-package) [21](https://engine.pajama.studio/whitepaper/en#source-building-probe)
| Observed step | Authoritative result | Independent observation |
| --- | --- | --- |
| Construction complete | 399 Package blocks; target wall entity 994 has 180 HP | Native captures show the assembled station. |
| First accepted cast | Target HP 120; 399 blocks remain | Exact-package outcome and cue receipts. |
| Second accepted cast | Target HP 60; 399 blocks remain | Another accepted activation with its own identity. |
| Third accepted cast | Target removed; 398 blocks remain | Both game-protocol clients receive removal of entity 994. |
The downloadable receipt excerpt preserves the Package identity, sampled construction history, three cast outcomes and both clients' relevant messages. Cue receipts establish event delivery; the wide construction screenshots establish visible scene assembly. Pixel-level effect attribution and the full update/recovery release gate remain separate checks.
### Carry the capability through its lifecycle
A generated mechanic becomes useful beyond a demonstration when its content, behavior state and lasting effects survive publication changes, reconnect and recovery. The September 12 terrain/checkpoint run and this later construction/skill run provide different parts of that evidence. M1–M3 bring these capabilities into a repeatable supported workflow, including retained instances and exact-version presentation. [24](https://engine.pajama.studio/whitepaper/en#source-terrain-evidence) [23](https://engine.pajama.studio/whitepaper/en#source-native-evidence) [26](https://engine.pajama.studio/whitepaper/en#source-history-frontier) [40](https://engine.pajama.studio/whitepaper/en#source-rollback-frontier)
## 15 · Verification and performance methodology {#validation}
### Verify properties at the level where they matter
The release objective is one repeatable black-box scenario covering a real render asset, prefab, authoritative mechanic and matching presentation across update, reconnect, restart and rollback. Component tests establish local rules; integration and native-client tests establish that those rules cooperate under the actual lifecycle. [19](https://engine.pajama.studio/whitepaper/en#source-roadmap)
| Property | Evidence to collect | Acceptance question |
| --- | --- | --- |
| Admission correctness | Rejection reason and unchanged authoritative state | Did invalid or unauthorized input leave the world untouched? |
| Release identity | Generation, catalog fingerprint and exact asset references | Do server and clients identify the same selected content? |
| Durable gameplay | World changes, typed script state and checkpoint identity | Can recovery reconstruct the accepted result coherently? |
| Client readiness | Verification/decode results, GPU publication and visual capture | Did the expected resource set become usable and visible? |
| Retry behavior | Request identity, authoritative result and reconnect/replay trace | Can interruption produce a duplicate effect? |
| Authority fencing | Writer subject, epoch and commit/acknowledgement trace | Are operations from the old authority rejected? |
This matrix organizes the product completion criteria and the recorded native scenarios into a review method. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [23](https://engine.pajama.studio/whitepaper/en#source-native-evidence) [25](https://engine.pajama.studio/whitepaper/en#source-skill-frontier) [53](https://engine.pajama.studio/whitepaper/en#source-distributed-roadmap)
The native runner is `services/pajama-edge/test/native_catalog_v2_two_client_e2e.mjs`. Its recorded scenarios cover two independent native clients, update/rollback, offline rejoin, corruption and server recovery. Receipt counts, screenshots and manual inspection serve different purposes; the roadmap separately tracks stronger per-entity pixel attribution. [84](https://engine.pajama.studio/whitepaper/en#source-native-runner) [23](https://engine.pajama.studio/whitepaper/en#source-native-evidence)
### Build a reproducible performance baseline
Performance runs should pin the engine revision, content hashes, workload, configuration and machine/OS/GPU. Separate a first join with an empty cache from a repeat join with a warm cache. Measure steady play, publication during play and recovery as different phases, so the cost of loading or durability is visible rather than hidden in an overall average.
| Metric group | Measurements | Engineering use |
| --- | --- | --- |
| Publication | Import-to-active and active-to-durable latency | Locate staging, activation or persistence delays. |
| Simulation | Tick p95/p99, skipped deadlines, replication backlog | Identify CPU, lock or network pressure. |
| Delivery | Verified bytes, cache-hit rate, placeholder duration | Quantify first-join and update cost. |
| Presentation | Decode/upload time and frame-time distribution | Detect resource-loading stalls. |
| Recovery | Rejoin/restart success and rollback convergence time | Track lifecycle reliability and time to return to service. |
These measurement priorities follow the product goal. Capacity targets and budgets should be justified by recorded workloads; the current whitepaper does not publish a player-count or latency SLA. [1](https://engine.pajama.studio/whitepaper/en#source-goal)
### Document provenance
Core architecture descriptions reference engine **026acf9** (2026-09-12). The construction/skill rehearsal references later authoring implementation **fe4d401**; the agent integration chapter is pinned to **382ca36**; world-model architecture uses a separate planning revision. Native captures, authoring traces and Jev protocol acceptance retain their individual provenance and file digests. The references section collects source coordinates and revisions; the evidence manifest identifies downloadable artifacts. Visual world-model integration remains planned work.
This edition adds source inspection of terrain extent, validation, movement limits and ground scheduling at **d96cddf**. This bounded review neither advances the entire core baseline nor supplies new infinite-world runtime evidence. External references were checked through **2026-09-21**; their publication dates and scope are retained below.
### What the latest videos measure {#capture-evidence}
The eight main-camera recordings meet the suite's predeclared floor of 59 actual fps and ceiling of 100 ms per sampled interval. They retain frame manifests and separate measured capture cadence from the 60 fps MP4 encoding rate. Main views are 1600 × 900, except the 1440 × 810 recovery footage; a second native observer is captured at 15 Hz. Full MP4 decoding and byte identity checks passed during delivery.
The bridge video has seven unrepresented sample slots and the convoy has three; the final accepted clips are not all zero-drop recordings. Recovery has two separately validated 1,200-frame captures. Failed and superseded runs remain diagnostic evidence. The optional lossless capture staging format and render quiescence reduced recording overhead; this does not measure general multiplayer scalability.
Original beveled building/utility meshes, shared materials and daylight, reduced ground noise, deliberate cameras and story captions improve the native presentation. Vehicles retain Kenney CC0 attribution. Buildings have exterior solid colliders; this suite does not claim walkable interiors or ecological tree simulation. [Video hashes and dated records](https://engine.pajama.studio/whitepaper/en#evidence-architecture-update).
This edition reuses recorded acceptance. It validates the website and published artifacts separately; it does not rerun paid inference or relabel an edited video as a new engine benchmark. Historical citations retain their original commits, and current source inspection is explicitly hash-bound. External research remains dated to its previous review rather than being silently presented as newly verified.
## 16 · World-model integration {#tradeoffs}
### Explicit state, generated presentation {#world-model-boundary}
The proposed integration has a precise responsibility boundary: **the engine computes authoritative world transitions; the output model synthesizes a visual observation from permitted conditions.** Here, world-model-friendly describes an interface and evaluation strategy. The planned bridge aligns actions, physical outcomes, camera views and generated frames with an explicit state history. [3](https://engine.pajama.studio/whitepaper/en#source-world-model-direction)
Authoritative world (gameplay, physics, identity, content versions, persistence)
- Traditional track: RenderSnapshot → wgpu → immediate interaction and precise UI; existing foundation, continued integration.
- Model track: aligned observations → proxy → model adapter (Wan/H3/SANA comparison) → offline replay / delayed spectator; planned research, live capability unproven.
Both outputs are checked against the same world facts; models cannot rewrite collisions, damage or saves.
The intended dataflow can be written as three operations:
```text
S(t+1) = EngineStep(S(t), accepted_actions(t))
C(t) = Observe(S(t), camera(t), view_permissions, content_revision)
I(t) = Model(conditions_available_by(t), appearance, session_history)
```
`S` is authoritative state; `C` is a declared observation projection; `I` is generated imagery. The engine step also depends on pinned code, configuration and numerical behavior. Capturing its results does not imply bit-identical solver replay across platforms. The model may approximate appearance or motion; its pixels do not commit world changes. Generated gameplay proposals still pass through typed commands or package admission. [15](https://engine.pajama.studio/whitepaper/en#source-physics-trait) [4](https://engine.pajama.studio/whitepaper/en#source-package-contract) [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
The native path uses RenderSnapshot and wgpu for immediate presentation. The proposed model path consumes synchronized records in an asynchronous service. This preserves a usable engine while the visual path is evaluated. Research on video models' physical generalization motivates the boundary: controlled motion/collision tests have found gaps on unseen physical conditions. Those findings support testing against explicit state, rather than assuming that plausible video establishes physical correctness. [11](https://engine.pajama.studio/whitepaper/en#source-render-design) [R15](https://engine.pajama.studio/whitepaper/en#research-physical-generalization)
### How recent research informs the design {#hybrid-research}
The recent signed article located in this review discusses **GPT-6 Astra**, with an authorized republication dated **2026-09-16**. Yuanming Hu argues that coding/spatial understanding and detailed 3D generation complement each other: one helps organize scenes and mechanics, while the other supplies asset detail. This is the author's assessment; its model comparisons are not Pajama performance or product acceptance results. It motivates separately integrating and evaluating agent orchestration and asset generation. [R16](https://engine.pajama.studio/whitepaper/en#research-hu-astra)
The Meshy team's **Mora** article (2026-09-09) combines code, 3D control signals and video output. It also discloses early limitations in portal views, character detail and latency. We adopt the division of responsibilities as a design reference, retaining native presentation and separate acceptance gates. A public demonstration does not establish an available compatible SDK for Pajama. [R17](https://engine.pajama.studio/whitepaper/en#research-mora-architecture)
Other approaches suggest different interface choices:
| Primary source and date | Relevant mechanism | Pajama design choice and remaining verification |
| --- | --- | --- |
| World Labs functional taxonomy, 2026-06-03 | Distinguishes observation, state and action outputs—rendering, simulation and planning—which can coexist in one model. | Choose integration points by output contract; validate geometry, actions and imagery separately. The engine's runtime protocol establishes authority. [R18](https://engine.pajama.studio/whitepaper/en#research-world-model-taxonomy) |
| World Labs Atlas, 2026-09-01 | Grounds cameras, images/video and geometry in spatial context, producing views or explicit 3D. | Investigate structured camera conditioning and candidate scene import. The announcement offers early-access applications; available interfaces still require verification. [R19](https://engine.pajama.studio/whitepaper/en#research-worldlabs-atlas) |
| Google Project Genie launch, 2026-01-29 | Generates explorable environments in response to actions; the prototype announcement lists physics, control and 60-second generation limits. | Learn from interactive generation while testing exploration and persistence separately. That duration describes the launch prototype, not an upper bound on all current world models. [R20](https://engine.pajama.studio/whitepaper/en#research-project-genie) |
Pajama's model interfaces should therefore accommodate **content proposals, action proposals and generated observations**, each with its own lifecycle. Learned state prediction can initially support offline tests, planning or candidate proposals. Future authoritative execution would require explicit state formats, budgets, recovery and consistency protocols. This is a project engineering choice, not a claim that models can only ever render.
### Connecting code, assets and visual feedback {#authoring-model-loop}
The intended loop starts with an agent reading live capabilities and authorized observations, writing bounded Luau mechanics and construction rules, and preparing assets through a specialized 3D service or modeling tool. It then publishes a reviewable Package. After activation, the engine provides queryable results and native frames; the planned observation adapter supplies model presentation and evaluation inputs. The agent uses that feedback to propose another revision. This loop reuses admission and revision checks; its complete integration still requires acceptance. [14](https://engine.pajama.studio/whitepaper/en#source-script-contract) [4](https://engine.pajama.studio/whitepaper/en#source-package-contract) [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
For a destructible research station, code describes floor layouts, component relationships and skill rules; assets supply appearance, rigs, animation and collision candidates. The server accepts publication and determines construction, hits and destruction. Generated scenes or 3DGS also require supported resource formats, units, collision and budget checks: visual completeness does not establish interactive semantics. Observations bind to activated content and world identities; subsequent agent edits carry their observed revision so stale feedback cannot overwrite newer state. [5](https://engine.pajama.studio/whitepaper/en#source-admission) [83](https://engine.pajama.studio/whitepaper/en#source-building-package) [17](https://engine.pajama.studio/whitepaper/en#source-publication)
Three completion criteria remain separate: **content is accepted and executes, world outcomes survive recovery, and generated presentation is faithful and usable.** An external model upgrade can improve one stage without establishing evidence for the others.
### H3 or Wan: choose the adaptation starting point by task {#model-selection}
**As of 2026-09-21, prioritize a causal, few-step Wan 2.2 TI2V-5B route for adaptation and cost experiments, retain H3 as a conditioning/quality baseline, and include SANA-Streaming in the first presentation comparison.** This orders experiments; it is not an engine performance result. With explicit world state already available, the first task is to represent that state faithfully, rather than ask a model to infer collisions and destruction again.
| Candidate and role | Available starting point | Condition for further investment |
| --- | --- | --- |
| Wan 2.2 TI2V-5B: first adaptation candidate | Official base-model instructions support a 24 GB GPU using offloading; this does not establish real-time operation. Reproduce a causal distilled version before studying continuous state conditioning. [R21](https://engine.pajama.studio/whitepaper/en#research-wan22) | State adherence, latency and valid-output cost on the same scenes; parameter count alone is not a speed estimate. |
| SolarWM-Wan / H3: a shared research framework | All three stages have releases for Wan 5B and H3; streaming few-step H3 was released on September 13. [R22](https://engine.pajama.studio/whitepaper/en#research-solarwm-release) | The Wan Stage2 guide provides a single-GPU inference example, and the H3 guide an eight-GPU example. These are launch topologies, not minimum requirements or a measured cost ratio. [R23](https://engine.pajama.studio/whitepaper/en#research-solarwm-wan) [R24](https://engine.pajama.studio/whitepaper/en#research-solarwm-h3) |
| SANA-Streaming 2B: presentation comparison | Continuous source-video conditioning makes it relevant to an engine-RGB-to-generated-view experiment. Preservation of newly destroyed structures still requires engine-specific evaluation. [R25](https://engine.pajama.studio/whitepaper/en#research-sana-streaming) | Use the same actual state trajectory and declare supported inputs separately; do not assume depth or entity-ID support. |
The critical adaptation gap is **continuously changing geometry**. SolarWM's reported experiments use a fixed scene prompt, with camera trajectories as the time-varying external control. Camera exploration does not establish faithful rendering of a newly built floor, a fresh wall opening or an asset revision. Pajama needs adapters and paired data supporting continuous RGB/geometric conditions, or must restrict a candidate to camera-exploration research. [R26](https://engine.pajama.studio/whitepaper/en#research-solarwm-paper)
### Frontier approaches to interaction, memory and cost {#frontier-models}
These are verifiable approaches relevant to engine integration, not a cross-task leaderboard. External results retain their hardware, measurement scope and release status.
| Approach | Mechanism worth investigating | What the evidence does not establish |
| --- | --- | --- |
| SolarWM, 2026-09 | Bidirectional adaptation, causal training and few-step distillation share a data contract while retaining native backbone representations. [R26](https://engine.pajama.studio/whitepaper/en#research-solarwm-paper) | Long rollouts do not establish recoverable, precisely revisitable persistent worlds. |
| ReWorld, 2026-08/09 | A Wan 5B route combines local/global attention, bounded caches, camera-retrieved landmark memory and few-step distillation. [R27](https://engine.pajama.studio/whitepaper/en#research-reworld) | Model memory is not a save file. Destruction must invalidate old landmarks by world/content/chunk revision so they cannot visually restore a wall. |
| LingBot-World 2.0, 2026-07 | Causal models expand action interaction through 14B and 1.3B variants. Public inference examples use multiple GPUs; deployment code is not planned for release. [R28](https://engine.pajama.studio/whitepaper/en#research-lingbot-v2) | Headline throughput cannot establish single-GPU, single-player input response. |
| SANA-WM / Streaming, 2026-05/06 | Hybrid linear attention reduces long-context work. WM reports about 34 seconds of denoising for a 60-second video on RTX 5090; Streaming reports 24 FPS end to end at 1280×704 on that GPU class, versus 58 FPS for the DiT alone. [R29](https://engine.pajama.studio/whitepaper/en#research-sana-wm) [R25](https://engine.pajama.studio/whitepaper/en#research-sana-streaming) | Denoising time, full-pipeline throughput and input-to-display latency differ; NVFP4 optimizations do not transfer directly to RTX 4090. |
| fal H3 Max, 2026-09-17 | The provider reports roughly five seconds of video generated in under three seconds, using GB200 multi-node serving, weight/kernel caches and warm-capacity scheduling. [R30](https://engine.pajama.studio/whitepaper/en#research-fal-h3-max) | Faster-than-playback clip generation establishes neither immediate response to each player input nor low per-user cost. |
ReWorld and LingBot-World 2.0 currently specify CC BY-NC-SA 4.0. They are research references, not automatic additions to the platform's commercial deployment list. Each actual candidate also requires separate checks of base weights, adapted weights, data and dependencies; a code license does not cover all of them. [R27](https://engine.pajama.studio/whitepaper/en#research-reworld) [R28](https://engine.pajama.studio/whitepaper/en#research-lingbot-v2)
### MiniMax H3 as a conditioning and quality baseline {#h3-research}
**H3 remains a conditioning and quality baseline, rather than the sole first integration candidate.** Its released FL2VA and Ref2VA base checkpoints offer a starting point for conditioned video generation. The official release distinguishes local 768p base output from the full pipeline's hosted Context-IR and, at release, unavailable local Regenerate-2K checkpoint. The initial experiment must pin the exact checkpoint, license, conditioning path and deployment dependencies. The advertised 24 FPS describes output playback, not inference throughput or input response. [R31](https://engine.pajama.studio/whitepaper/en#research-minimax-h3)
Two recent preprints provide more specific evidence:
| Related work | Demonstrated mechanism | Implication for Pajama |
| --- | --- | --- |
| H3-World | Temporally aligned language represents character/camera actions; LoRA and temporal attention routing adapt H3 for action-conditioned clips. | A useful action-conditioning comparison. Its reported scope is short, fixed-length segments, with persistent state and real-time interaction left open. |
| Code World Model | Executable state produces per-frame proxies; H3 Ref2VA is adapted with depth and semantic-ID conditions paired with RGB targets. | The closest precedent for a state-conditioned output path. The prototype excludes inference latency from its qualitative comparison and does not implement autoregressive real-time generation. |
These results motivate a reproduction and adaptation experiment; they do not establish an existing Pajama integration. [R32](https://engine.pajama.studio/whitepaper/en#research-h3-world) [R33](https://engine.pajama.studio/whitepaper/en#research-code-world-model)
Those prototypes' limitations are not permanent limits of the H3 backbone: subsequent SolarWM-H3 releases provide a causal streaming route. They still do not establish continuous geometry conditioning, multi-client consistency or target deployment cost for Pajama. Selection records must distinguish base H3, H3-World, SolarWM-H3 and hosted H3 Max. [R22](https://engine.pajama.studio/whitepaper/en#research-solarwm-release)
Pajama would supply the persistent environment, accepted actions and versioned content missing from a standalone clip workflow. The adapter work includes aligned training pairs, supported conditioning channels, model adaptation and evaluation. Sending depth to an unmodified public video endpoint is insufficient unless that interface explicitly supports it.
The visual objective is specified through appearance references and aligned target imagery, with recorded rights and provenance. Engine proxies describe structure and motion; they do not by themselves supply a richer visual style. Experiments should therefore measure both adherence to state and the visual benefit over the native baseline.
The first use case is **recorded-world replay**. Full recorded trajectories can condition a clip, including information that was future at its first frame. This measures visual conditioning. A separate causal test restricts each generation request to inputs available at its declared decision time. Delayed spectator output must declare its lookahead and display delay; live evaluation must exclude future actions and state from both clip preparation and conditioning.
### A state-to-observation interface {#observation-contract}
The existing boundaries are useful starting points, with distinct timing semantics. `PhysicsFrame` publishes dynamic/vehicle poses and can return a cached frame with `fresh=false`. `OwnedRenderSnapshot` captures presentation inputs and an extraction generation, without an authoritative tick/epoch identity. The bridge must reconcile authoritative snapshots, actual physics publications and camera/presentation sampling; concatenating these structures would not establish alignment. [15](https://engine.pajama.studio/whitepaper/en#source-physics-trait) [16](https://engine.pajama.studio/whitepaper/en#source-render-snapshot) [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
| Interface layer | Responsibility |
| --- | --- |
| Identity and time | World/episode, authority epoch, tick, actual physics publication, content revision, entity incarnation and frame sequence; label authoritative, predicted and interpolated origins. |
| Geometry and camera | Coordinate units, camera projection/crop and sample time; explicit validity and alignment for each supported RGB, depth, semantic, instance or motion channel. |
| Spatial continuity | Global chunk addresses, local-origin generation, generator/chunk revisions and residency readiness. Origin shifts preserve logical identity; returning after eviction must not reuse invalid model memory. |
| Actions and events | Accepted actions and their outcomes, including collisions and lasting edits; preserve discrete events during resampling. |
| Appearance and reproducibility | Exact assets, checkpoint/adapter/decoder versions, seeds and training/evaluation provenance. |
| Output lifecycle | Consumed input range, session and epoch; bounded queues, cancellation, stale-output rejection and declared lookahead. |
**Each inference session receives only its authorized view.** Privileged reference state may be retained separately for evaluation. An observation exporter must preserve player/spectator visibility and interest rules so hidden entities and internal state do not leak through model conditions.
A feasible first deliverable is a bounded recorder and offline reader: an episode manifest, timestamped state/action/event records, and aligned reference images. An offline or headless renderer can generate additional channels without placing inference in the tick. Queue pressure, dropped samples and timing gaps are recorded explicitly. Depth and semantic-ID adaptation follow once paired capture is validated; other channels remain capabilities to negotiate, not assumptions about a candidate's inputs. [69](https://engine.pajama.studio/whitepaper/en#source-headless) [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
Observations must also distinguish **capture progress from durability progress**. Planned records carry the sampled tick, authority lifetime and the known durable checkpoint's identity and coverage. A visible effect is not automatically part of the recovery root, and a missing durability acknowledgement does not establish a failed write. Capture must not block simulation waiting for a checkpoint. Recovery starts a new episode and model session from the recovered state. Reconcile the historical tail against the checkpoint actually restored, marking records as included, outside that recovery root or still unknown. Observation records cannot become an alternate world save. [6](https://engine.pajama.studio/whitepaper/en#source-checkpoint) [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
### Admitting model output {#output-admission}
The proposed adapter binds each request to its episode/session, authority lifetime, content identity, authorized-view revision, camera conditions and input range. Output is eligible only while the receiver accepts those conditions and its declared display window remains valid. Content changes, recovery, view-permission changes or incompatible camera discontinuities require checks on pending work and cached history; ordinary camera motion follows the declared condition sequence. Cancellation does not prove that a background job has stopped, so late results must pass the same admission check.
This checks provenance and freshness; agreement between pixels and geometry still requires separate evaluation. The first test can use a mock adapter that returns delayed, reordered results, proving that obsolete output cannot enter presentation and native fallback remains available before connecting real model inference. [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
### Quality and operating efficiency {#model-economics}
Evaluation asks whether output preserves the visible facts of an interaction, and what that costs. Physion provides a precedent for scenario-based tests of physical events; VBench separates temporal, motion and appearance dimensions of video quality. Pajama needs both kinds of measurement alongside its engine reference state: neither benchmark alone establishes interactive game correctness. [R34](https://engine.pajama.studio/whitepaper/en#research-physion) [R35](https://engine.pajama.studio/whitepaper/en#research-vbench)
| Dimension | Measurements |
| --- | --- |
| World consistency | Visible position/contour error against projected reference geometry; identity after occlusion; contact and destruction-event timing; agreement of separate camera views. |
| Perceptual quality | Temporal stability, appearance continuity and reviewed failure examples, separately from state alignment. |
| Responsiveness | Causal input-to-display p50/p95/p99, queue depth, stale frames, reset time and simulation/capture overhead. |
| Efficiency | GPU time, peak memory, concurrency, failed/retried generations and cost per output minute passing the declared quality gate; adaptation/training costs separately. |
| Portability | Supported conditions, model/decoder versions, data and license provenance, local/hosted dependencies. |
Use native reference rendering as shared truth, comparing supported Wan/H3 conditioning and SANA video transformation with their input capabilities and application scopes declared separately. Keep scenes and trajectories separate between training and evaluation, avoiding adjacent-frame leakage. Use held-out interactions and multiple seeds; publish sample counts, failure rates and uncertainty. Geometric scoring needs visibility masks and calibrated extraction, with manual review where a stylized image makes automatic measurement ambiguous. Set acceptance thresholds for the intended workload before running the comparison.
Shared entity IDs and correct input receipts establish protocol identity; they do not prove that generated pixels agree. Multi-view geometry, appearance and event agreement remain measured research objectives. The inference worker has no mutable world handle. Timeouts, wrong epochs and stale sessions can trigger deterministic rejection and a native-renderer fallback; reliable automatic detection of visual mismatch requires additional research. Fallback preserves availability and authoritative play, while transition quality must also be tested. Precision-sensitive targeting and UI remain engine-rendered in the initial design. [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
This work extends the engine's established design choices: explicit versions, bounded interfaces and one simulation authority per world. Native release readiness, content continuity and distributed operation remain the foundation for the model path. [1](https://engine.pajama.studio/whitepaper/en#source-goal) [26](https://engine.pajama.studio/whitepaper/en#source-history-frontier) [86](https://engine.pajama.studio/whitepaper/en#source-platform-frontier) [53](https://engine.pajama.studio/whitepaper/en#source-distributed-roadmap) [67](https://engine.pajama.studio/whitepaper/en#source-author-roadmap) [27](https://engine.pajama.studio/whitepaper/en#source-world-model-roadmap)
### Inference cost: reduce the task before optimizing computation {#inference-cost}
Optimize in this order, rechecking state adherence and visual benefit at each step:
1. **Reuse known engine results.** Produce inexpensive reference views and supported geometry conditions from actual state; test presentation transformation first. Native systems provide collision, destruction, aiming and UI. Assets and static appearance reusable through Packages need not be generated anew for every player frame.
2. **Reduce online work.** Compare smaller backbones, lower working resolution and short generation chunks; reserve expensive refinement for replay or other non-immediate uses. Report resolution, compression and chunk size together: larger chunks can improve throughput while delaying input collection and first output. Reprojection of slower model output is a display strategy, not newly generated frames or a remedy for stale state.
3. **Use causal few-step distillation and bounded memory.** Start from released distilled weights to reduce denoising work; adding LoRA alone does not reduce backbone inference computation. Retain necessary history and retrieve by space and revision; recovery, visibility changes, destruction and content switches invalidate it. Measure step-reduction gains across the full pipeline.
4. **Optimize the whole generation pipeline.** Profile condition encoding, DiT, VAE, transport and display before selecting hardware-compatible precision, fused kernels, compilation and caches. SANA-Streaming's end-to-end versus DiT rates illustrate why denoiser optimization alone is insufficient. Recheck small structures, motion boundaries and event timing after quantization. [R25](https://engine.pajama.studio/whitepaper/en#research-sana-streaming)
5. **Schedule against latency targets.** Separate cold starts from warm requests; bound batching, concurrency and queues by deadlines, and cancel obsolete work. Warm pools trade startup delay for idle expense. Different cameras or visibility permissions cannot simply share generated frames; shared assets or encodings still require matching identity and access contracts.
Account for **cost per minute of valid, timely delivered model output**, accumulating minutes per receiving view. Also report total cost per active player-minute and model coverage:
```text
Cost per valid output minute = (all GPU billing + API + transport and other serving costs) / valid, timely delivered model-view minutes
```
GPU billing includes warm idle capacity, failures, retries and work that continues after cancellation. Do not double-count a charge as both API and self-hosted GPU expense. Exclude stale, rejected, duplicate and interpolation-filled segments from the denominator; record native fallback separately. A run with no valid output fails, rather than reporting zero cost. Report training/adaptation separately and state amortization assumptions against expected usage.
### A shared-scene experiment to decide which models proceed {#model-benchmark}
Fix a destructible-building trace covering turns, occlusion, construction, wall damage, departure and return, two cameras and content revision changes. Validate capture and a mock adapter before comparing causal Wan, conditioned/causal H3 and SANA video transformation. Candidates unable to represent live changes enter only the offline group, not the online ranking.
Retain engine/weight/adapter versions, input channels, resolution, precision, denoising steps, chunk length, cache budget, GPU type/count, concurrency and complete timestamps. Report **file playback FPS, fresh generation FPS including codecs, time to first frame, and input-to-actual-display latency** separately. The last includes capture, chunk assembly, queuing, network and presentation. Runs supplied with a whole future trajectory establish offline capability only.
Apply declared state-consistency and response gates before comparing valid-output cost. Separate single-view and concurrent-view workloads; verify native availability under timeouts, memory pressure and late output. This review establishes sources and experiment design, not Pajama H3/Wan/SANA inference measurements. No per-user price, real-time frame rate or proven winning model is claimed.
## 17 · Development roadmap {#roadmap}
### Two tracks, one foundation {#next-cycle}
Development advances along two connected tracks. The **runtime track** makes a persistent world easier to create, operate and extend. The **model track** turns that world's state into controllable generated presentation. Both build on the same identities, content versions and recovery contracts. [19](https://engine.pajama.studio/whitepaper/en#source-roadmap) [27](https://engine.pajama.studio/whitepaper/en#source-world-model-roadmap)
| Stage | Runtime development | Model development | Result |
| --- | --- | --- | --- |
| Establish the foundation | Complete playable packages, consistent effects and performance baselines. | Define synchronized observations and export aligned geometry, camera and state. | A playable world with a reliable record of what happened. |
| Connect state and presentation | Preserve content and behavior through updates and recovery. | Adapt recorded world conditions in the selected order; evaluate held-out scenes and valid-output cost. | Generated replay that can be compared with the underlying simulation. |
| Extend the experience | Consolidate native release readiness and operational reliability. | Introduce delayed spectator output, session management and rendering fallback. | A shared runtime supporting conventional play and model-generated views. |
### Next work, ordered by the new evidence {#next-contracts}
| Order | Contract and owner | Executable completion gate |
| --- | --- | --- |
| 1 | Retained content lifetimes — world/content/server/client owners. | Keep A1 instances alive through multiple replacements and unrelated publications; validate budget rejection, cleanup, rollback and cold recovery with exact old meshes. |
| 2 | Durable observation — checkpoint and authoring owners. | Wait for a named world result's durable cut, interrupt around commitment, and recover it without privileged storage inspection. |
| 3 | Agent sessions and SDK — world schema/server/external adapter. | Capability revocation, stale observations, reconnect, cancellation, lost replies and provider failure preserve authority and bounded work. |
| 4 | Rebase-aware creation — existing prepared runtime and job bridge. | An author and a player agent complete a real new-capability handoff despite a conflict and coordinator restart; preview remains isolated. |
| 5 | Domain constraint compilation — cold content compiler. | Add support/clearance/access rules with budgets, diagnostics and independent result validation; reject changed world preconditions. |
| 6 | Native/operational qualification — delivery and authority owners. | Normal client policy, corrupt/slow assets, terrain/update frame tails, remote fencing and a measured workload pass together. |
These priorities refine M1–M5; they do not replace the single-authority product goal or promise delivery dates. Expanding one qualified authority comes before speculative sharding. Model presentation remains M6 and cannot bypass these world contracts. [Architecture assessment](https://engine.pajama.studio/whitepaper/en#evidence-architecture-update).
### M1 · Playable content packages {#milestone-m1}
Consolidate demonstrated player actions, Package behavior and matching presentation into the complete release workflow. Terrain/checkpoint evidence and the construction/breach rehearsal provide the starting points. The integration gate combines request handling, durable replay/cooldown, exact-version cue playback, update and recovery in one run. [24](https://engine.pajama.studio/whitepaper/en#source-terrain-evidence) [25](https://engine.pajama.studio/whitepaper/en#source-skill-frontier) [21](https://engine.pajama.studio/whitepaper/en#source-building-probe)
**Completion criterion:** two native clients observe the same accepted action and effect through update, rollback and recovery. Repeated requests produce one world result. This becomes the reference workflow for adding further gameplay capabilities.
### M2 · Content continuity {#milestone-m2}
Extend resource retention from the active and immediate rollback versions to the lifetime requirements of persistent instances. Define which instances retain their original version, which may migrate, and how historical resources are retained and reclaimed. [26](https://engine.pajama.studio/whitepaper/en#source-history-frontier) [23](https://engine.pajama.studio/whitepaper/en#source-native-evidence)
**Completion criterion:** retained instances resolve the correct content after updates and restarts; publication and cleanup preserve every required reference.
### M3 · Native release readiness {#milestone-m3}
Bring gameplay and content continuity into the normal client/server startup path. Complete catalog ordering, compatibility handling, platform validation and workload-based performance measurements. [35](https://engine.pajama.studio/whitepaper/en#source-catalog-order) [86](https://engine.pajama.studio/whitepaper/en#source-platform-frontier) [19](https://engine.pajama.studio/whitepaper/en#source-roadmap)
**Completion criterion:** the normal application flow passes the two-client publication, update, reconnect, restart and rollback scenario, including missing or corrupt resources. This establishes a repeatable native release baseline.
### M4 · Persistent world operations {#milestone-m4}
Build on the leased authority and checkpoint foundation to connect player identity, world discovery, admission and recovery. Complete persistent-write fencing and the profile-effect outbox, then exercise replacement of a failed authority. [7](https://engine.pajama.studio/whitepaper/en#source-backend-status) [53](https://engine.pajama.studio/whitepaper/en#source-distributed-roadmap) [40](https://engine.pajama.studio/whitepaper/en#source-rollback-frontier)
**Completion criterion:** a replacement authority restores a coherent world and admits reconnecting players while rejecting late writes from the previous authority. Capacity measurements guide subsequent scaling decisions.
### World expansion: acceptance across M3 and M4 {#world-expansion}
Implement the [spatial contracts](https://engine.pajama.studio/whitepaper/en#continuous-world) under one authority before deciding whether cross-server partitioning is needed. All stages below are new acceptance work still to complete:
| Stage | Reproducible evidence |
| --- | --- |
| Addressing and chunks | Exercise positive/negative coordinates, seams and local-origin shifts; cross the old `extent` and verify agreement among entity, camera and collision coordinates. |
| Travel and return | Follow a route beyond the resident radius that causes actual eviction. Two players observe separate regions, then revisit the same excavation and building destruction, retaining chunk/entity identities and content versions. |
| Durable recovery | Restart and revisit after a cross-chunk edit. Inject interrupted commits, late old generation jobs, missing resources and generator upgrades; restore a coherent version from the checkpoint. |
| Bounded operation | Declare route, duration, speed, player distribution and budgets before measuring memory, GPU/collision residency, queues, networking and storage growth. Unready collision must not allow falling through; inspect native horizons and LOD seams. |
| Model presentation | Pass the native path first, then test the same revisits, paired views and origin shifts with a model, checking that destroyed structures are not visually restored. Native play continues when the model is unavailable. |
These gates separately establish spatial expansion, persistence and visual continuity. Until they pass, demonstrations should identify their current map extent. Expansion remains subject to address-space limits, storage quotas and operational capacity; it does not promise to load or permanently retain infinite resources.
### M5 · Human and agent creation {#milestone-m5}
Build on the implemented prepared-candidate workflow: add isolated preview, persistent job/cancellation budgets, stable third-party contracts and an author-to-player handoff. Exact-digest publication, lost-response reconciliation and conflicting-generation rejection already have local evidence. Generation services supply candidate assets and behavior through the same admission process. [66](https://engine.pajama.studio/whitepaper/en#source-author-runner) [67](https://engine.pajama.studio/whitepaper/en#source-author-roadmap) [1](https://engine.pajama.studio/whitepaper/en#source-goal)
**Completion criterion:** an author can introduce a playable capability, inspect its result and manage its lifecycle through one documented workflow; receipts correlate publication stages, sustained generation stays within aggregate budgets, and lost responses remain reconcilable.
### M6 · Model-generated world presentation {#milestone-m6}
Develop a provider-neutral observation and presentation layer, prioritizing **Wan adaptation, H3 quality comparisons and SANA video transformation experiments**. Synchronized capture can advance alongside core-runtime integration; production presentation depends on reliable content and recovery lifecycles. Distributed model sessions build on M4. [3](https://engine.pajama.studio/whitepaper/en#source-world-model-direction) [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
| Workstream | Deliverable | Validation |
| --- | --- | --- |
| M6.1 · Observation | Bounded recorder, episode manifest and offline reader with state/action/camera alignment and permitted-view projection. | Read captures without a model; check reference projections, discrete events and durability progress; reject mixed epochs, stale physics publications and invalid channels, accounting for gaps. |
| M6.2 · Adaptation | Native reference, Wan/H3 conditioning baselines, SANA video transformation and supported geometry-conditioned adaptation. | Compare held-out scenes/trajectories and multiple seeds; report geometry/event error separately from perceptual quality. |
| M6.3 · Presentation | Asynchronous sessions, cancellation, bounded queues, restart handling and native fallback. | Inject reordering, disconnects, delays and identity changes with a mock adapter before testing real inference; exclude obsolete output and invalid view history, and measure transition behavior. |
| M6.4 · Consistency | Separate full-trajectory replay and causal-prefix evaluation, including two views of one event. | Exclude future information from causal runs; measure longer-sequence drift, cross-view error, latency and cost against predeclared gates. |
| M6.5 · Portability | Versioned episode format, capability contracts and reproducible adapter run records. | Validate each adapter's supported channels, permissions, provenance and reset behavior against the same captures. |
The initial scenario set covers a falling body reaching rest, a character returning from occlusion, a persistent terrain or wall opening, and two cameras observing one interaction. These exercises connect visual quality to the facts that make a world playable. [27](https://engine.pajama.studio/whitepaper/en#source-world-model-roadmap)
The planned executable evidence is an observation round-trip validator, an offline comparison runner and a session fault-injection suite, extending the native lifecycle runner. A replay result permits a replay application. Spectator and live applications require their own causal, latency and consistency gates. If an adapter misses them, it remains a replay/creative-output option while the native game path continues to develop.
### Validation across the lifecycle
Each milestone is reviewed through its delivered capability and reproducible integration results. The existing native package runner provides the lifecycle baseline; planned capture, model-comparison and session-failure tooling extends it with synchronized observations and real-model measurements. The path progresses from replay to spectator presentation, then toward live output as control quality, latency and operating efficiency meet the needs of the experience. [84](https://engine.pajama.studio/whitepaper/en#source-native-runner) [85](https://engine.pajama.studio/whitepaper/en#source-world-model-bridge)
## 18 · Terminology and reading guide {#glossary}
| Term | Meaning |
| --- | --- |
| AI-native | Structured, inspectable authoring and observation interfaces with engine-enforced permissions and lifecycle rules. |
| World-model-friendly | Designed to exchange versioned actions, state and observations with learned models; does not assert that the engine itself is a trained world model. |
| Output model | A model synthesizing presentation from supplied conditions, without authority to commit gameplay state. |
| Causal evaluation | Generation uses only information available at the declared decision time. |
| Package revision | An exact authored content version, identified with its digest. |
| Deployment generation | A forward-moving activation sequence, including rollback releases. |
| Catalog | The exact client-facing content description for a selected release state. |
| Dependency closure | All exact package dependencies required by a release. |
| Cut | A coherent snapshot of related state, captured or published together. |
| Checkpoint head | The committed reference selecting a durable recovery snapshot. |
| CAS: compare-and-swap | Advance only when the expected base still matches. |
| CAS: content-addressed storage | Store and retrieve bytes by digest; a separate use of the acronym. |
| Authority epoch | A leased writer lifetime used to reject stale operations. |
| Realm / admission | An administrative policy context and its permission to use a package. |
| Hydration | Reconstruct executable state from verified durable objects. |
| Presentation generation | A compatible set of client resources exposed together. |
| Prefab | A reusable entity definition instantiated under the world's authority. |
| Cue | A named presentation event associated with a gameplay action or state. |
For a project overview, read **vision → architecture → progress → roadmap**. For the architecture, read **execution flows → world data → publication → recovery**. For authoring or client integration, continue through **delivery → rendering → authoring → worked example**. The references below identify the source and design records behind the implementation statements.
## 19 · References and evidence {#sources}
Implementation evidence and planning documents are pinned to their respective source revisions. Section 15 explains their scope; external research and its design relevance are listed separately below.
1. **Product goal and durable boundary** — `docs/PRODUCT_GOAL.md:10` @ `026acf9`
2. **Native client dependencies** — `crates/pajama-client/Cargo.toml:21` @ `026acf9`
3. **Planned direction: world-model interoperability** — `docs/PRODUCT_GOAL.md:28` @ `bf13e81`
4. **Permanent package formats and identity** — `docs/CONTENT_PACKAGES.md:15` @ `026acf9`
5. **Realm-owned package admission** — `docs/CONTENT_PACKAGES.md:595` @ `026acf9`
6. **Composite checkpoint coordinator** — `crates/pajama-server/src/authority_checkpoint_coordinator.rs:1` @ `026acf9`
7. **Backend scope and production gates** — `docs/BACKEND_ARCHITECTURE.md:3` @ `026acf9`
8. **Real authoritative tick ordering** — `crates/pajama-server/src/lib.rs:4025` @ `026acf9`
9. **Atomic client presentation coordinator** — `crates/pajama-client/src/content_presentation.rs:1` @ `026acf9`
10. **Bounded client delivery owner** — `crates/pajama-client/src/content_runtime.rs:1` @ `026acf9`
11. **Render layers and execution ownership** — `docs/RENDERING_ARCHITECTURE.md:41` @ `026acf9`
12. **Workspace ownership map** — `Cargo.toml:3` @ `026acf9`
13. **Bounded package archive staging** — `crates/pajama-content/src/lib.rs:323` @ `026acf9`
14. **Immutable frames, typed commands and budgets** — `crates/pajama-script/README.md:17` @ `026acf9`
15. **Solver interface** — `crates/pajama-physics/src/lib.rs:297` @ `026acf9`
16. **RenderSnapshot boundary** — `crates/pajama-render/src/snapshot.rs:246` @ `026acf9`
17. **Package publication service** — `crates/pajama-server/src/package_publication.rs:1` @ `026acf9`
18. **Interest-managed replication** — `crates/pajama-server/src/replication.rs:1` @ `026acf9`
19. **Completion gate and implementation frontier** — `docs/ROADMAP.md:8` @ `026acf9`
20. **Native observers and live Package construction rehearsal** — `scripts/authoring/building-rehearsal.mjs:1` @ `fe4d401`
21. **Player-intent breach test, authoritative damage and replicated removal** — `scripts/authoring/building-probe.mjs:1` @ `fe4d401`
22. **WorldDoc persistence schema** — `crates/pajama-world/src/lib.rs:489` @ `026acf9`
23. **Recorded native update, rollback and recovery evidence** — `docs/ROADMAP.md:294` @ `026acf9`
24. **Recorded durable package terrain evidence** — `docs/ROADMAP.md:371` @ `026acf9`
25. **Skill binding and remaining playable gate** — `docs/ROADMAP.md:419` @ `026acf9`
26. **Historical instance policy and V5 boundary** — `docs/ROADMAP.md:437` @ `026acf9`
27. **Planned P6 stages and evidence gates** — `docs/ROADMAP.md:476` @ `bf13e81`
28. **Authority lifecycle and fencing** — `crates/pajama-server/src/authority.rs:24` @ `026acf9`
29. **Verified content-addressed cache** — `crates/pajama-client/src/content_cache.rs:1` @ `026acf9`
30. **Read-only defaults and explicit write scopes** — `crates/pajama-mcp/README.md:32` @ `026acf9`
31. **Entity document** — `crates/pajama-world/src/lib.rs:384` @ `026acf9`
32. **Runtime world and change tracking** — `crates/pajama-world/src/lib.rs:533` @ `026acf9`
33. **World mutation stamp** — `crates/pajama-world/src/lib.rs:796` @ `026acf9`
34. **Standalone ECS dependency** — `crates/pajama-sim/Cargo.toml:10` @ `026acf9`
35. **Catalog ordering evidence and open gates** — `docs/ROADMAP.md:173` @ `026acf9`
36. **Local V1 input and composite publication** — `docs/ROADMAP.md:104` @ `026acf9`
37. **Closed checkpoint backend ownership** — `crates/pajama-server/src/authority_checkpoint_backend.rs:1` @ `026acf9`
38. **Local immutable store and head CAS** — `crates/pajama-server/src/local_checkpoint_store.rs:1` @ `026acf9`
39. **Process-local checkpoint lifetime** — `crates/pajama-server/src/process_local_checkpoint.rs:1` @ `026acf9`
40. **Rollback integration and production boundary** — `docs/ROADMAP.md:135` @ `026acf9`
41. **Generation-bound CPU decoder** — `crates/pajama-client/src/content_decode.rs:1` @ `026acf9`
42. **Imported GPU resource generations** — `crates/pajama-render/src/skinned/asset_generation.rs:1` @ `026acf9`
43. **Exact asset extraction and placeholders** — `crates/pajama-client/src/package_asset_presentation.rs:1` @ `026acf9`
44. **Rapier default and Box3D compatibility** — `crates/pajama-physics/src/lib.rs:402` @ `026acf9`
45. **Fixed substeps and bounded catch-up** — `crates/pajama-physics/src/rapier_backend.rs:60` @ `026acf9`
46. **Authoritative causal terrain edit** — `crates/pajama-server/src/terrain_sync.rs:232` @ `026acf9`
47. **Client movement prediction and echo reconciliation** — `crates/pajama-client/src/app_runtime.rs:541` @ `026acf9`
48. **Finite terrain domain contract** — `crates/pajama-world/src/terrain.rs:35` @ `d96cddf`
49. **Default terrain half-size: 250 metres** — `crates/pajama-world/src/terrain.rs:310` @ `d96cddf`
50. **Accepted finite extent range** — `crates/pajama-world/src/terrain.rs:362` @ `d96cddf`
51. **Authoritative movement clamps to terrain extent** — `crates/pajama-server/src/lib.rs:4556` @ `d96cddf`
52. **Extent-bounded physics ground tile scheduling** — `crates/pajama-server/src/ground_schedule.rs:214` @ `d96cddf`
53. **Distributed authority roadmap** — `docs/ROADMAP.md:452` @ `026acf9`
54. **Compiled render pipeline** — `crates/pajama-render/src/pipeline.rs:389` @ `026acf9`
55. **Animation architecture** — `docs/ANIMATION.md:1` @ `026acf9`
56. **Four-client render profile regression and controlled measurements** — `docs/evidence/four-client-render-profile/README.md:1` @ `e2134b8`
57. **Spectral water and consistent cloud radiance** — `docs/TIDEWATER_ROUND3.md:1` @ `e2134b8`
58. **Lake transport and oblique wave filtering** — `docs/LAKE_REALISM.md:1` @ `e2134b8`
59. **Shoreline foam implementation and acceptance** — `docs/SHORE_FOAM.md:1` @ `e2134b8`
60. **Cloud detail footprint filtering and evidence** — `docs/CLOUD_DISTANCE.md:1` @ `e2134b8`
61. **Native weather implementation and limits** — `docs/WEATHER_SYSTEM.md:1` @ `e2134b8`
62. **Underwater optics numerical and native acceptance** — `docs/evidence/underwater-optics/README.md:1` @ `e2134b8`
63. **Native 40 km terrain horizon and streaming acceptance** — `docs/evidence/terrain-horizon-lod/README.md:1` @ `e2134b8`
64. **Command/component registry** — `crates/pajama-world/src/registry.rs:1` @ `026acf9`
65. **Live registry discovery and authorization** — `crates/pajama-mcp/README.md:3` @ `026acf9`
66. **Existing audited script runner** — `crates/pajama-mcp/README.md:61` @ `026acf9`
67. **Package authoring and generation roadmap** — `docs/ROADMAP.md:465` @ `026acf9`
68. **At-most-once send and uncertain outcomes** — `crates/pajama-mcp/README.md:52` @ `026acf9`
69. **Native headless rendering path** — `crates/pajama-client/src/headless.rs:951` @ `026acf9`
70. **Jev integration scope, controls and acceptance** — `docs/SYSTEM_ONE_AGENT.md:7` @ `382ca36`
71. **Approved skill choice, budget, freshness and receipt policy** — `scripts/system-one/skill-director.mjs:35` @ `382ca36`
72. **Ordinary player observation and authoritative skill receipts** — `scripts/system-one/game-client.mjs:46` @ `382ca36`
73. **Authoring tools, Codex client acceptance limit and remote integration** — `docs/AGENT_AUTHORING_DEMO.md:118` @ `382ca36`
74. **Real Jev decisions and bilateral authoritative terrain evidence** — `docs/evidence/jev-system-one-2026-09-21.json:82` @ `382ca36`
75. **Jev native Decisions transport and version validation** — `scripts/system-one/jev.mjs:98` @ `382ca36`
76. **Explicit authoring MCP adapter to the existing runtime** — `scripts/authoring/mcp.mjs:1` @ `382ca36`
77. **Durable Cloudflare job queue, bounded tools and claims** — `services/pajama-author-agent/src/index.ts:31` @ `382ca36`
78. **Proposed engine evolution control plane, contracts and acceptance gates** — `docs/ENGINE_EVOLUTION.md:7` @ `bb964ad`
79. **Engineering decision roles, conditional practices and proposed enforcement** — `docs/ENGINE_DECISIONS.md:9` @ `e1dc2c0`
80. **Repository agent routing to the engineering decision guide** — `AGENTS.md:33` @ `e1dc2c0`
81. **Existing controlled performance comparison and retained verdicts** — `docs/PERFORMANCE_LOOP.md:156` @ `bb964ad`
82. **Engine correctness CI and stable-runner performance boundary** — `.github/workflows/ci.yml:10` @ `bb964ad`
83. **Versioned building kit, procedural behavior and player skill binding** — `scripts/authoring/complex-building.mjs:7` @ `fe4d401`
84. **Native two-client test runner** — `services/pajama-edge/test/native_catalog_v2_two_client_e2e.mjs:9` @ `026acf9`
85. **Planned observation, provider and presentation contracts** — `docs/WORLD_MODEL_BRIDGE.md:8` @ `bf13e81`
86. **Platform cleanup and CI scope** — `docs/ROADMAP.md:70` @ `026acf9`
### External research and design references {#research-references}
These publications inform the proposed design. Their results describe the cited systems, not capabilities already demonstrated by Pajama Engine.
References checked: 2026-09-21.
**[R1] [World Models]()** — David Ha and Jürgen Schmidhuber · 2018 · Research paper
Learns compressed spatial and temporal representations of environments for prediction and policy training. It grounds the distinction between a learned environment model and its execution environment; a physics engine or observation export alone does not constitute a trained world model.
**[R2] [Networking Overview]()** — Epic Games · Accessed 2026 · Official engine documentation
Documents the separation between authoritative server gameplay, replicated client state, and visual presentation. This established multiplayer pattern informs Pajama's authority boundary; it does not validate Pajama's implementation, network performance, or a learned renderer's consistency.
**[R3] [Streaming 3DGS worlds on the web]()** — World Labs · 2026-04-14 · Official renderer engineering article
Explains view-dependent LOD, progressive streaming and fixed-pool GPU paging for 3DGS. Informs bounded residency, without supplying destructible terrain, authoritative collision or persistence.
**[R4] [Extract in bevy::render]()** — Bevy contributors · Accessed 2026 · Bevy 0.19.1 API documentation
Documents read-only extraction from the simulation world into a separate render world, allowing simulation and rendering work to overlap. This is an engineering precedent for observation boundaries; it does not establish serialized replay, model conditioning, or cross-machine determinism.
**[R5] [Model Context Protocol — Tools]()** — Model Context Protocol contributors · 2025 · Protocol specification, 2025-06-18
Defines discoverable tools, JSON Schema inputs, optional output schemas, structured results, and server validation requirements. It supports a typed authoring interface; domain authorization, resource budgets, revision checks, and atomic world activation remain responsibilities of the engine implementation.
**[R6] [Embedding a sandboxed Luau virtual machine]()** — Luau contributors · Accessed 2026 · Official language documentation
Describes restricted libraries, protected environments, and host-controlled interrupts for sandboxing. It informs bounded script execution; embedders must configure memory limits and exposed APIs, and the documented sandbox is not a formal proof of isolation or safety for arbitrary host bindings.
**[R7] [System One introduction]()** — TypeSafe AI · 2026 · Official model documentation
Describes typed decision models. Supports the narrow decision role; it does not establish Pajama latency, autonomy or full visual understanding.
**[R8] [Confidence]()** — TypeSafe AI · 2026 · Official confidence documentation
Explains confidence and decision distributions. Thresholds need task evaluation; confidence is neither permission nor proof of correctness.
**[R9] [Jev 1.13 API]()** — OpenRouter · 2026 · Official provider API documentation
Documents Jev availability through OpenRouter. The engine adapter pins the native Decisions contract and verifies the actual returned version; measured costs belong to the linked run receipt.
**[R10] [Model Context Protocol]()** — OpenAI · 2026 · Official Codex MCP documentation
Documents config.toml MCP entries, stdio command/args/cwd/environment and timeouts. Correct configuration does not establish successful Pajama publication or bypass client approval.
**[R11] [The Last AI Built by Humans: Toward Genuine Recursive Self-Improvement]()** — Yi Duan et al. · 2026-09-15 (v2) · Survey preprint
Motivates distinguishing artifact gains from inherited improvements to the improver. Pajama's control-plane design is a proposal, with no autonomous-evolution result claimed.
**[R12] [Introduction to Performance Profiling and Configuration]()** — Epic Games · 2026 (accessed) · Official engine documentation
Connects frame timing and performance budgets to target hardware. It informs measurement practice, not Pajama performance claims.
**[R13] [Optimizing CPU-side Rendering Code]()** — Clay John / Godot Engine · 2026-09-15 · Official engine engineering report
Demonstrates profiling, diagnosis and remeasurement, including counterexamples to intuitive caching optimizations. Reported gains belong to Godot's test scenes.
**[R14] [Canarying Releases]()** — Alec Warner and Štěpán Davidovič / Google SRE · 2018 · Primary release-engineering guidance
Supports limited rollout with control comparisons, representative samples and absolute health measures. Pajama must apply this without concurrent writers in one world.
**[R15] [How Far is Video Generation from World Model: A Physical Law Perspective]()** — Bingyi Kang et al. · 2025 · ICML 2025 research paper
Finds out-of-distribution physical generalization failures in controlled two-dimensional video prediction experiments. It motivates testing against explicit physical state and unseen conditions; its findings concern the tested models and setup, rather than proving a universal limitation of video generation.
**[R16] [GPT-6 Astra and the value of 3D generation]()** — Yuanming Hu (Ethan); authorized republication via Founder Park / BAAI · 2026-09-16 · Signed commentary, authorized republication
Argues for complementary coding/spatial understanding and detailed asset generation. This is the author’s assessment, not an independent model benchmark or Pajama acceptance result.
**[R17] [Mora: Beyond the “World Model”]()** — Meshy Research Team · 2026-09-09 · Official architecture and prototype report
Combines coding, 3D control signals and generated audiovisual output; discloses early visual and latency limitations. It motivates modular integration without establishing a compatible Pajama SDK.
**[R18] [A Functional Taxonomy of World Models]()** — World Labs · 2026-06-03 · Official research perspective
Classifies renderers, simulators and planners by observation, state and action outputs, while discussing convergence. Informs output-specific contracts; generated geometry still needs validation.
**[R19] [Atlas: A World Model for Spatial Intelligence]()** — World Labs · 2026-09-01 · Official model announcement
Describes spatially grounded multimodal context, camera control and explicit 3D outputs. The early-access announcement motivates interface research, not a claim of Pajama integration or measured performance.
**[R20] [Project Genie: Experimenting with infinite, interactive worlds]()** — Diego Rivas, Elliott Breece and Suz Chambers (Google) · 2026-01-29 · Official prototype launch report
Reports action-responsive exploration and the launch prototype’s physics, control and 60-second generation limits. Supports separating exploration from durable world acceptance; these are dated prototype limits.
**[R21] [Wan2.2: Open and Advanced Large-Scale Video Generative Models]()** — Wan team · Accessed 2026-09-21 · Official model repository
Documents the 5B base and offloaded 24 GB inference. This is a feasibility starting point, not evidence for interactive latency or a continuous state-conditioned adapter.
**[R22] [SolarWM: release status and model family]()** — Junchao Huang et al. · 2026-09-13; checked 2026-09-21 · Official research repository
Records three-stage Wan 5B and H3 releases, including September 13 streaming H3. Release availability does not establish live engine integration.
**[R23] [SolarWM Wan2.2 TI2V-5B backend guide]()** — SolarWM contributors · Accessed 2026-09-21 · Official inference guide
Provides a single-GPU Stage2 inference example. An example launch is neither a hardware minimum nor a same-workload cost comparison.
**[R24] [SolarWM MiniMax-H3 backend guide]()** — SolarWM contributors · Accessed 2026-09-21 · Official inference guide
Documents H3 stage checkpoints and eight-GPU inference examples. No eightfold cost ratio or minimum configuration is inferred.
**[R25] [SANA-Streaming: Real-time Streaming Video Editing with Hybrid Diffusion Transformer]()** — Yuyang Zhao et al. · 2026-05; released 2026-06 · Research preprint, v1
Studies source-video-conditioned streaming editing and separates whole-pipeline from denoiser throughput. Engine geometry fidelity and input-response latency require separate tests.
**[R26] [SolarWM: Open Data and Scalable Training for Long-Horizon Video World Models]()** — Junchao Huang et al. · 2026-09-02 · Research preprint, v1
Describes causal adaptation and distillation across backbones. Section 7.1 uses fixed prompts and time-varying camera control, not arbitrary live geometry updates.
**[R27] [ReWorld: An Interactive World Model with Long-Horizon Memory]()** — ReWorld authors · 2026-08/09; checked 2026-09-21 · Official research repository
Documents bounded caches, landmark retrieval and few-step generation. The current repository specifies non-commercial terms; model memory does not replace versioned engine persistence.
**[R28] [LingBot-World 2.0: Infinite Worlds with Versatile Interactions]()** — Robbyant / LingBot-World team · 2026-07; checked 2026-09-21 · Official model repository
Provides causal model variants and multi-GPU examples. Non-commercial terms and unreleased deployment code constrain reuse; headline throughput is not single-player latency.
**[R29] [SANA-WM: Efficient Minute-Scale World Modeling with Hybrid Linear Diffusion Transformer]()** — Haoyi Zhu et al. · 2026-05-14 · Research preprint, v1
Studies efficient camera-conditioned generation with hybrid attention. The RTX 5090 minute-video result measures denoising, not input-to-display latency.
**[R30] [H3 Max: Built with fal Inference and Training]()** — fal · 2026-09-17 · Provider engineering report
Describes fast clip generation and multi-node serving with startup optimizations. Provider-reported speed does not establish continuous control or per-player cost.
**[R31] [Open General Intelligence: MiniMax H3 Is Now Open Source]()** — MiniMax · 2026 · Official model release documentation
Describes released FL2VA and Ref2VA base checkpoints and multimodal conditioning. The documented full 2K workflow also uses hosted components; its 24 FPS output specification is a playback rate, not a measurement of generation throughput or interactive latency.
**[R32] [H3-World: Turning Language Understanding into World Control]()** — Danze Chen et al. · 2026 · Research preprint
Adapts H3 using temporally aligned language instructions for character and camera control. The study supports short-horizon controllability; it explicitly leaves persistent state, real-time interaction, planning, and policy learning outside the demonstrated capabilities and calls for broader reliability evaluation.
**[R33] [Code World Model: Coding Agent as World Brain]()** — Yiwen Chen, Guosheng Lin, and Chi Zhang · 2026 · Research preprint
Separates executable world evolution from video synthesis and adapts H3 Ref2VA to depth and semantic proxy conditions. Qualitative results support investigating this interface; the prototype omits autoregressive real-time generation, and its control comparisons exclude inference latency.
**[R34] [Physion: Evaluating Physical Prediction from Vision in Humans and Machines]()** — Daniel M. Bear et al. · 2021 · Research paper and benchmark
Introduces reproducible physical prediction scenarios covering contact, stability, rolling, and other dynamics. It motivates scenario-based physical evaluation; it evaluates prediction from observations, so generated game footage still needs separate tests against authoritative geometry, event timing, and gameplay state.
**[R35] [VBench: Comprehensive Benchmark Suite for Video Generative Models]()** — Ziqi Huang et al. · 2023 · Research paper and benchmark
Separates video quality into dimensions including identity consistency, motion smoothness, flicker, and spatial relationships. It informs visual evaluation alongside state-based checks; high perceptual scores alone do not establish collision accuracy, event fidelity, multiplayer agreement, or acceptable interaction latency.