Status: draft 0.3. This specification describes .world packages at manifest schema version 3, package format 2 (head-first). The normative definitions are:

1. schema/world.schema.json — the world document’s data model, machine-readable. Where prose and schema disagree, the schema wins and the prose gets fixed.
2. The conformance worlds — behavior is specified by what these render to. An implementation claiming a profile renders its worlds.
3. These documents — the rules the schema cannot express (identity, folding, versioning, must-ignore).

Reading order

1. The world document — L0: what a world is.
2. The package — L2/L3: the folder, assets by hash, metadata, integrity.
3. The session log — L1: the ops that build a world and the history around them.
4. The state document — L0: where the game is.
5. Profiles and extensions — what an implementation must, may and must-ignore.
6. Versioning policy — the compatibility contract.
7. Security and Privacy — parsing robustness and user data.

The one invariant

State at any tip is a pure fold of the path from base to tip.

fold(base, path from base to tip) == state at tip

Everything the format offers is a consequence: rendering (read manifest.json, the fold at the tip of main, already written down), editing (send edit ops to the one authority), multiplayer (one authority orders the ops), undo (append inverses), save games (base + a player’s log), replays (fold with a clock, or walk the keyframes), mods (patches against a pinned base revision), forking (base + log prefix).

The fold is total — its state is a whole manifest, and every field is reachable by an edit — so the head can always be written down, and an agent working from outside the app can change anything a person can.

What this format is not

Not a game engine, not a physics solver, not a renderer, not glTF’s job (meshes are glTF leaves), not a content-management system. The spec describes what a world is; what an engine does with it stays the engine’s.

Open items (before 1.0)

Next, in order:

1. Merges that agree — done (2026-10-09): the merge rules are exact in the session log (“The merge rules, exactly”), and conformance/merge/ pins them in all five references.
2. Cameras and shots — done (2026-10-09): ext-cinematography 0.2 is experimental: cameras as entities with a filmback and a lens, shots as ordered setups on the clock, outcome assertions in three references, and the JS renderer’s letterboxed shot view.
3. A schema marker on entity-reference fields — done (2026-10-09): x-entity-ref marks the reference fields in the schema, schema/entity-refs.json is the generated list, and name binding, merge rewriting and ingestion validation in all five references read it (each embeds a copy and drift-tests it against the canonical file).
4. Aim and focus by entity — done (2026-10-11): ext-cinematography 0.3 adds aim_entity and focus_entity as marked references — the generated list now carries extension schemas’ markers, so the five references bind, rewrite and validate them like parent — with origins composed through parents, centred and focus assertions, a Swift reference (the fourth), and every authority committing ids for the deeper references, as the log always promised.
5. A globe producer’s export — done (2026-10-20), three generic additions from one brief: the Prism shape with its geometry stated in prose (the world document, “The geometry of the shapes”; conformance/prism.json), experimental until LocalGPT’s Bevy renderer and the worldwalk viewers built it from the table beside the JS one, and a core shape since (2026-10-25); ext-h3, a geo frame extension carrying an entity’s H3 cell and integer transform beside the derived core transform, proposed with a schema, a conformance world with outcome assertions and two references; and the export contract — author.source (hand, library, ai), day-coarse time, no prompt by default (the session log “The entry”, the package “Exports from other systems”). RFCs: rfcs/ext-h3.md, rfcs/history-exports.md.

Deferred until a producer needs them: collision-free ids, an id and parent on every entry, and timed input samples (a breaking bundle, for git merges and gameplay replay); a semantic merge driver for git; a runtime that re-runs triggers over recorded input (semantic replay); a side count on Cylinder and Cone — when the producer behind Prism ships sides on its cylinders and cones, decide whether sides becomes a parameter of those shapes rather than more shapes, so the prism is not a one-off.

• The geometry of every shape is now stated in prose (the world document, “The geometry of the shapes”) and pinned by conformance/geometry/shapes.json: exact bounds, the box, and landmark vertices, run by the JS renderer and the Rust reference in CI. The table settled three disagreements between shipping renderers — the torus plane, the wedge’s facing, the icosahedron’s orientation — in favour of the majority each time.

• Pivots, phases and the swing (2026-11-06): spin and pulse act about a pivot and start at a phase, and swing is a pendulum — a wheel about its base, a block that breathes on the ground, a sign that hangs from its top (the world document, “Behavior and triggers”; rfcs/pivots-and-swing.md); the Rust reference carries a behavior kind it does not know instead of refusing the world. A colour’s alpha below 1 with no alpha_mode draws blended (“Conventions”), pinned by conformance/materials.json — the two shipping renderers had read it two ways.

• The state document is now pinned with its own schema/state.schema.json; it joins world.schema.json in the generated core.

• The extension registry holds two experimental extensions, ext-physics and ext-cinematography, and five proposed ones: ext-strict-determinism, ext-visibility, ext-provenance, ext-h3 and ext-game, which makes a board or tick game a log of moves under named rule sets (rfcs/ext-game.md). A proposed extension reserves its name; it becomes experimental with a reference implementation and conformance cases, and leaves experimental when a producer ships a package using it.

• Branching histories are specified and implemented in the reference fold (rfcs/branching-histories.md); examples/speedrun-fork is the first package to write them (a challenge chain: two runs, one fork each). No app writes branches yet, and the viewer has no branch rail.

• More prose around replay determinism as implementers arrive.

• Live authoring is accepted (rfcs/live-authoring.md) and normative in the package and the session log: agents outside the app submit ops to one authority, manifest.json is the head, ModifyWorld makes the fold total, and git may carry the history. Still open: a semantic merge driver for git, and the Authoring profile in the Python, Swift and Kotlin references (they read everything it writes).

• The world document (L0) — A world document — `manifest.json`, or a snapshot — is a self-contained description of a world: its entities, their shapes and materials, the lights, the environment, the sound, an
• The package (L2/L3) — A `.world` is a directory. A zip of that directory is the transport form for finished, published worlds; the directory is canonical because the log appends.
• The session log (L1) — `ops.jsonl` is the one history: one JSON entry per line, each entry a committed batch of ops by one author. It holds what changed the world (edits) and what happened around the cha
• The state document (L0) — A world's *document* says what the scene is. Its *state* says where the game is: score, inventory, quests, doors opened. Without a state document those live in engine memory and di
• Profiles and extensions — Cover use cases through a small mandatory core plus profiles — never through maximalism. An implementation implements a profile; a package declares which profiles it uses.
• Versioning policy — The compatibility contract, written as policy from lessons already paid for in the format's lineage.
• Security and Privacy Considerations — The Open World Format is code-adjacent by design. Behaviors run from load, triggers fire on `click` and `proximity`, and third-party packages ship meshes, textures, and audio by ha