Protocol Specification

Abstract

Elsewhere is an open protocol for creating, operating and connecting independently authoritative spatial worlds.

An Elsewhere world is divided into Regions. Each Region has its own Region Authority, publishes a small machine-readable Region Manifest, and may expose a Region MCP interface through which clients and agents discover its instructions, resources, concepts and available actions.

Regions may be games, social spaces, simulations, buildings, landscapes, tools, artworks, persistent virtual environments or forms of spatial computing not anticipated by this specification.

Elsewhere does not prescribe how a Region must be rendered, simulated or internally implemented. Instead, it standardises how independently created worlds identify themselves, describe their meaning, expose their state, advertise their capabilities, accept actions, report consequences and link to one another.

Elsewhere standardises the language through which worlds meet, not the rules governing what those worlds may become.

Contents

Appendix A — MCP reference profile Appendix B — Recommended publication artefacts

1 Scope

Elsewhere defines interoperable structures for:

• Regions;
• Region identity;
• Region Authority;
• Region discovery;
• Region Manifests;
• Region MCP interfaces;
• semantic instructions;
• entities;
• canonical state;
• catalogue terms;
• natural-language meaning;
• assets;
• capabilities;
• actions;
• behaviours;
• authoritative outcomes;
• events;
• Region links;
• permissions;
• extensions;
• client interoperability.

Elsewhere does not define a universal:

• renderer
• game engine
• physics engine
• scripting language
• asset format
• avatar format
• combat system
• inventory system
• economy
• identity provider
• world host
• AI model

Those systems may participate in Elsewhere without becoming part of its core protocol.

2 Normative language

The terms MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT and MAY indicate requirements or recommendations within this specification.

Where this specification does not constrain behaviour, implementations are free to choose their own approach.

3 Architectural model

Elsewhere consists of independently authoritative Regions connected through a common protocol.

Elsewhere itself is not the central authority over this universe. Each Region determines its own canonical reality.

                         ELSEWHERE
                          protocol
                             │
            ┌────────────────┼────────────────┐
            │                │                │
        REGION A         REGION B         REGION C
       Authority A      Authority B      Authority C
            │                │                │
         world A          world B          world C
            │                │                │
            └──────── Region links ──────────┘

4 Region

A Region is an independently addressable spatial environment participating in Elsewhere.

A Region does not need to have finite geometric bounds. The defining architectural boundary of a Region is its authority boundary.

• a room;
• a building;
• a landscape;
• a game level;
• an entire game;
• a city;
• a planet;
• a simulation;
• an abstract environment;
• a social space;
• a procedural universe;
• a collaborative workspace.

5 Region Authority

Every authoritative Region MUST have a Region Authority.

The Region Authority is the source of canonical truth for that Region.

The Region Authority does not have to be implemented by one physical server or process. It is a logical trust boundary.

• which entities exist;
• canonical Region state;
• canonical entity state;
• permitted actions;
• authoritative action outcomes;
• shared simulation outcomes;
• permissions;
• Region-specific rules;
• persistence;
• authoritative events.

6 Authority principle

The fundamental authority rule is:

Each Region is authoritative over its own canonical namespace, state and rules.

Crossing a Region boundary is crossing an authority boundary.

A source Region may link to another Region. It MUST NOT thereby become authoritative for the destination Region.

7 Elsewhere is not an authority

Elsewhere defines interoperability between authorities.

• own Regions;
• approve Region content;
• control Region state;
• dictate Region rules;
• operate a universal simulation;
• require a central Elsewhere account;
• require Regions to use common game mechanics.

8 Region identity

A persistent Region SHOULD have a stable globally distinguishable identifier.

A Region identifier identifies the Region rather than a particular server instance. Infrastructure MAY change without changing Region identity. Resolution mechanisms MAY evolve independently from Region identifiers.

elsewhere://example.com/castle

9 Region bootstrap

A client encountering an unfamiliar Region MUST be able to obtain a small machine-readable bootstrap document called the Region Manifest.

The Manifest answers:

• What Region is this?
• Who is authoritative for it?
• Which Elsewhere version does it use?
• Where is its Region MCP interface?
• Which vocabularies and profiles does it use?
• Where are realtime interfaces, if any?
• What are its entry points?
• What basic representations are available?

10 Region Manifest

The canonical interchange format for the Region Manifest SHOULD be JSON.

A Manifest MAY additionally be presented as YAML or another human-friendly representation for authoring purposes, provided that its canonical data model is equivalent.

{
  "elsewhere": "1.0",
  "region": {
    "id": "elsewhere://example.com/castle",
    "name": "Castle of Glass"
  },
  "authority": {
    "origin": "https://example.com"
  },
  "interfaces": {
    "mcp": "https://example.com/castle/mcp",
    "events": "wss://example.com/castle/events"
  },
  "instructions": {
    "resource": "elsewhere://region/instructions"
  },
  "vocabularies": [
    "elsewhere:core/v1",
    "castle:vocabulary/v3"
  ],
  "profiles": [
    "elsewhere:interactive-region/v1"
  ],
  "entryPoints": {
    "default": "outer-gate"
  }
}

11 Manifest stability

The Manifest SHOULD contain information necessary to begin communication. It SHOULD NOT become a large repository of lore, entity data, detailed rules, world history, full catalogues or complete behavioural descriptions. Those belong behind discoverable Region resources.

This allows the Manifest to remain fast to retrieve, cacheable, inspectable, stable and useful to non-AI clients.

12 Region MCP

An interactive Region SHOULD expose a logical MCP interface associated with that Region.

This does not require one physical MCP server process for every Region. A provider MAY host many Regions on shared infrastructure. Each Region nevertheless SHOULD present its own logical MCP context, because each Region may have different authority, instructions, vocabulary, resources, tools, permissions and rules.

Region
   │
   ├── Manifest
   │
   └── Region MCP
          ├── instructions
          ├── resources
          ├── tools/actions
          └── deeper discovery

13 Role of MCP

MCP is the preferred initial interface for machine discovery, agent discovery, Region instructions, semantic documentation, Region resources and structured action invocation.

Elsewhere does not redefine MCP. Elsewhere defines conventions for using MCP to expose spatial Regions. A conforming Region MAY additionally expose other interfaces.

14 MCP does not contain the whole runtime

A Region MUST NOT assume that all high-frequency world communication must pass through MCP. The Manifest MAY advertise additional interfaces for these purposes. MCP remains the principal discoverable interface through which an unfamiliar client or agent can understand what those interfaces mean.

• continuous avatar transforms;
• realtime multiplayer replication;
• high-frequency physics state;
• large asset delivery;
• voice;
• video;
• spatial media streams.

15 Region instructions

An interactive Region SHOULD expose authoritative Region Instructions through its Region MCP interface. Region Instructions explain how to understand and operate within that Region. Markdown SHOULD be the preferred representation for these instructions.

# Castle of Glass

The Castle of Glass is a fortress built around an artificial star.

## Important concepts

Gravity becomes weaker toward the central chamber.

Entities tagged `castle:memory-door` do not respond to ordinary physical force.

Reflections inside the Mirror Hall may be persistent entities rather than visual effects.

## Interaction

Inspect unfamiliar entities before invoking capabilities on them.
Read the relevant vocabulary resource when encountering an unknown namespaced term.

16 Babel-tablet principle

The Region Instructions act as the Region’s introductory semantic guide. They may be thought of as a Babel tablet: enough information for an unfamiliar intelligent participant to begin understanding the place on its own terms.

The instructions SHOULD explain unusual assumptions, important concepts, Region conventions, how important resources relate, and how to discover further information. They SHOULD NOT attempt to describe every entity or rule in the Region.

Memory doors open when a visitor presents a memory associated
with the place beyond them.

17 Instructions and execution

Region Instructions MAY describe how a Region works in natural language.

Memory doors open when a visitor presents a memory associated
with the place beyond them.

These instructions help humans, agents and clients understand the intended meaning of the Region.

When an interaction changes shared or persistent Region state, the change SHOULD be performed through a structured action and confirmed by the Region Authority.

For example, an interactive memory door might expose a capability such as:

capabilities:
- castle:present-memory

A participant may invoke that capability with structured input. The Region Authority evaluates the request and determines the authoritative result.

Instructions explain how the world works. The Region Authority determines what actually happens.

18 Layered Region knowledge

Region knowledge SHOULD be progressively discoverable. A participant SHOULD NOT need to ingest all Region documentation merely to enter the Region.

Region Manifest
      ↓
Region Instructions
      ↓
Relevant catalogue/resources
      ↓
Relevant entities
      ↓
Actions and state

19 Region resources

A Region MCP interface MAY expose semantic and structured resources. Semantic resources SHOULD generally use human- and AI-readable formats such as Markdown where appropriate. Structured resources SHOULD use an appropriate machine-readable representation.

elsewhere://region/instructions
elsewhere://region/about
elsewhere://region/rules/movement
elsewhere://region/vocabulary/memory-door
elsewhere://region/areas/mirror-hall
elsewhere://region/lore/history

20 Hypertext Region documentation

Markdown Region resources MAY link to other Region resources. This allows a Region’s knowledge to form a discoverable internal hypertext rather than one monolithic instruction document.

This Region uses persistent reflections.

See [Reflection](elsewhere://region/vocabulary/reflection)
for its semantic definition.

See [Mirror Hall](elsewhere://region/areas/mirror-hall)
for location-specific behaviour.

21 Entities

A Region MAY expose persistent identifiable entities. An entity SHOULD have stable identity within its authoritative scope where persistence or interaction requires it.

• objects;
• avatars;
• creatures;
• vehicles;
• lights;
• sounds;
• zones;
• systems;
• controllers;
• interfaces;
• abstract concepts.

{
  "id": "station-door-01"
}

22 Three-layer meaning model

Elsewhere represents meaning using three complementary layers: canonical structured facts, catalogued concepts and natural semantic description. These layers SHOULD be read together. They are not alternatives.

23 Canonical facts

Canonical facts are explicit structured information. Canonical facts constrain interpretation. An implementation MUST NOT contradict an explicit canonical fact merely because another interpretation appears more plausible.

transform:
  position: [2.0, 0.0, -4.5]

dimensions:
  width: 1.1
  height: 2.0

state:
  locked: true

24 Catalogue concepts

An entity MAY reference stable semantic terms. Terms provide reusable concepts that can be recognised across implementations.

semantic_type: elsewhere:door

terms:
  - elsewhere:hinged
  - elsewhere:openable
  - elsewhere:metal

25 Natural semantic description

An entity MAY additionally contain unrestricted natural-language meaning. Natural semantic description preserves nuance that would be undesirable or premature to formalise.

semantic: >
  A massive circular steel pressure door. Its surface is
  scratched and oxidised around the locking wheel. It initially
  resists movement before swinging outward with a deep metallic
  groan.

26 Descriptiveness principle

Elsewhere distinguishes authority from descriptiveness. Structured data is not automatically more descriptive because it is structured. Natural language is not automatically authoritative because it is detailed. Implementations SHOULD use the richest compatible information available.

Authority determines what may be contradicted. Descriptiveness determines how compatible gaps should be filled.

27 Meaning precedence

Where information genuinely conflicts, readers SHOULD apply the following order. Compatible information SHOULD be combined rather than discarded.

1. authoritative canonical facts;

2. explicit structured authored semantics;

3. explicit natural-language authored semantics;

4. inferred or generated interpretation.

28 Catalogue evolution

Elsewhere does not attempt to define a complete ontology of possible worlds. The preferred process is: describe, recognise, name, reuse, standardise when useful.

Describe first. Standardise later.

29 Progressive formalisation

A concept may evolve through progressively more formal representations. Not every concept SHOULD progress through every stage. Formalisation should occur when interoperability benefits from it.

natural-language description
        ↓
recurring concept
        ↓
namespaced term
        ↓
shared catalogue term
        ↓
capability or structured property
        ↓
deterministic contract

30 Term namespaces

Custom terms SHOULD be namespaced. The same namespace principle SHOULD apply to extensible capabilities, events, state fields, behaviours, profiles and properties.

terms:
  - elsewhere:door
  - museum:restricted-object
  - mygame:memory-gateway

31 Unknown concepts

A reader MUST tolerate unknown optional vocabulary. An unfamiliar term MUST NOT invalidate an otherwise understandable entity. Readers SHOULD preserve unknown information where practical. AI-capable readers MAY use natural semantic description to make a best-effort interpretation.

32 Catalogue promotion

Concepts SHOULD be considered for wider standardisation when demonstrated use shows recurring interoperability value. Core vocabulary SHOULD grow from actual usage rather than speculative completeness.

• repeated use across unrelated Regions;
• repeated queries;
• common interactions;
• common accessibility requirements;
• common simulation semantics;
• recurring agent interpretation.

33 Representation standards

Elsewhere is representation-independent. A Region MAY choose any representation that satisfies its requirements, and a conforming client MUST NOT require one scene or asset format unless a Region profile explicitly requires it.

Where established open standards already solve a representation problem, Elsewhere SHOULD reuse them rather than define competing Elsewhere-specific formats.

Elsewhere defines what must interoperate. External standards define how particular kinds of content may be represented.

33.1 OpenUSD

OpenUSD SHOULD be the recommended representation for large, composed or high-fidelity Region scenes where its scene graph, layering, references, variants and composition model are useful.

OpenUSD is a representation of scene content; it is not the Region Authority. Region identity, permissions, actions, canonical state, semantic adjudication and authoritative outcomes remain Elsewhere concerns.

33.2 glTF

glTF SHOULD be the recommended portable runtime representation for 3D assets and scenes where efficient transmission and broad runtime support are more important than large-scale scene composition.

A Region MAY expose OpenUSD, glTF, both, or neither. Multiple representations MAY describe the same canonical Elsewhere entity.

33.3 Khronos and OMI extensions

Elsewhere SHOULD adopt or reference established Khronos and Open Metaverse Interoperability Group (OMI) extensions when they adequately describe common spatial concepts such as audio, physics metadata, seats, spawn points or other portable runtime features.

Elsewhere SHOULD NOT create a duplicate core concept merely because the same information could be represented inside Elsewhere. A new Elsewhere construct is justified when authority, federation, semantic interpretation or interactive interoperability requires semantics that an existing representation standard does not provide.

33.4 Region implementations and OpenSimulator

Elsewhere does not require a particular Region implementation. A Region Authority MAY be implemented using OpenSimulator, Unreal Engine, Unity, Godot, a custom server, an AI-native runtime, a text world or another system.

OpenSimulator is a useful reference and test implementation because it already provides persistent interactive Regions, world state and multi-user simulation. It MUST NOT define the Elsewhere architecture or constrain other Region implementations.

34 Assets

Elsewhere SHOULD support authored assets as first-class representations. Complex objects SHOULD NOT need to be approximated from basic primitives solely because they participate in Elsewhere.

• meshes;
• materials;
• textures;
• images;
• animations;
• audio;
• procedural representations;
• point clouds;
• volumetric data;
• neural representations;
• future formats.

35 Representational independence

An entity’s canonical identity MUST NOT depend upon a particular rendering representation. One entity may have high-fidelity geometry, lightweight geometry, an image impostor, procedural geometry, a textual representation or no visual representation. These may all represent the same canonical entity.

36 Appearance

Explicitly specified appearance is canonical where provided. A renderer MAY enrich unspecified details. It MUST NOT silently contradict authored appearance.

37 Spatial facts

Explicit spatial information is canonical. AI or procedural interpretation MAY fill gaps. It MUST NOT rewrite explicit spatial facts without an authorised state change.

• position;
• orientation;
• scale;
• dimensions;
• geometry;
• attachment points;
• spatial relationships.

38 State

Shared facts affecting authoritative interaction SHOULD be represented explicitly. Important shared state SHOULD NOT rely solely upon interpretation of prose.

state:
  open_fraction: 0.0
  locked: false

39 Capabilities

Capabilities describe operations that participants may request from an entity. A capability SHOULD normally identify an interoperable affordance without prescribing its complete implementation. elsewhere:open does not imply a specific animation, duration or physical mechanism.

capabilities:
  - elsewhere:open
  - elsewhere:close

40 Creative freedom of capabilities

Two entities may expose the same capability while behaving very differently. The common capability communicates the broad interaction. The Region defines the actual behaviour.

• swing;
• slide;
• fold;
• dissolve;
• transform;
• ask a question;
• require several participants;
• open into another Region.

41 Actions

A participant interacts with authoritative Region state by requesting an action. An action is a request. It is not itself proof that the requested change occurred.

action:
  actor: player-17
  target: door-3
  capability: elsewhere:open
  parameters: {}

42 Region Authority evaluates actions

The Region Authority determines whether an action is recognised, permitted, satisfies Region rules, succeeds, fails or produces another result. The Region then communicates the authoritative consequence.

43 Runtime loop

The core interactive model allows games and interactive worlds to run directly on Elsewhere without making Elsewhere itself a game engine.

43.1 Intuition: the Region Authority as dungeon master

A useful mental model is to think of the Region Authority as the dungeon master for its Region. This analogy is explanatory rather than normative: a Region Authority may be implemented entirely through conventional software, AI, game-engine logic, human moderation, or any combination of these.

The client represents the participant’s intent. The Region Authority knows the Region’s canonical state, rules, permissions, capabilities and instructions, and determines the authoritative outcome of an attempted action.

For example, when a participant attempts to open a door:

• the client identifies the target entity and the participant’s intent;
• if the door exposes an explicit open capability, the client requests that capability directly;
• the Region Authority checks the door’s state, permissions and any Region-specific rules;
• if the action is valid, the Region Authority commits the canonical state change and reports the outcome;
• clients then render or otherwise present that authoritative result.

AI reasoning is most useful when intent or meaning is not already fully structured. An AI-capable participant may interpret natural-language instructions, catalogue terms or semantic descriptions to understand what action is appropriate. Where an explicit capability and structured state already exist, no AI inference is required simply to invoke them.

The Region Authority may itself use AI to adjudicate intentionally open-ended rules, much as a dungeon master interprets an unusual player action. However, once an outcome affects shared or persistent reality, the Region Authority is responsible for committing one authoritative result.

Client = participant interface and intent interpreter. Region Instructions = campaign guide and local rules. Catalogue = shared dictionary. Structured state and capabilities = facts and explicit affordances. Region Authority = the final arbiter of what happens in that Region.

43.2 Worked example: semantic adjudication

A participant says: “I pick up the axe.”

The axe may combine structured and semantic information:

semantic_type: elsewhere:axe

terms:
- elsewhere:pickupable
- magic:cursed

semantic: >
A magical axe that burns anyone who picks it up
unless they first speak the word "ember".

The Region Authority evaluates the attempted pickup using all relevant information available to it. It may determine that:

• the axe can be picked up;
• the curse applies when it is picked up;
• the participant did not satisfy the stated condition;
• the pickup succeeds; and
• the participant receives the Region-defined burn consequence.

The Region Authority then commits any shared consequences as canonical state or authoritative events.

This illustrates an important Elsewhere principle:

A Region may define novel rules in semantic language before those rules have been formalised into a universal schema. The Region Authority adjudicates them, while structured state records the resulting shared reality.

If the mechanic becomes important, widely reused or requires stronger interoperability, the Region MAY progressively formalise it into dedicated capabilities, conditions, behaviours or catalogue terms.

participant intent
       ↓
structured action request
       ↓
Region Authority
       ↓
permissions + Region rules
       ↓
behaviour
       ↓
authoritative state transition
       ↓
event / outcome
       ↓
clients and agents

44 Behaviour

A Region MAY expose behaviour definitions or references. Behaviour describes how inputs may produce authoritative consequences. Elsewhere does not prescribe how behaviour is internally implemented.

• native code;
• scripts;
• game-engine logic;
• deterministic simulation;
• databases;
• AI;
• remote services;
• procedural systems;
• combinations of these.

45 Behaviour principle

This is a central protection against unnecessary constraints on creativity.

Standardise requests and observable consequences before standardising internal implementation.

46 Events

Authoritative changes SHOULD be observable. Regions MAY define namespaced custom events.

event:
  id: event-82914
  type: elsewhere:state-changed
  entity: door-3

  changes:
    open_fraction:
      from: 0.0
      to: 1.0

47 Event ordering

Where event order affects shared reality, the Region Authority MUST expose sufficient ordering information. Elsewhere SHOULD NOT require stronger ordering than a Region needs.

• sequence numbers;
• transaction identifiers;
• authoritative timestamps;
• causal identifiers.

48 Realtime interfaces

Regions MAY advertise realtime state transports separately from MCP. The semantics of those interfaces SHOULD remain discoverable through the Region.

{
  "interfaces": {
    "mcp": "https://game.example/forest/mcp",
    "events": "wss://game.example/forest/events",
    "realtime": "wss://game.example/forest/state"
  }
}

49 Games

Games are a first-class Elsewhere use case. A game may exist directly as one or more Regions. A Region Authority may implement game logic, multiplayer state, puzzles, scoring, NPCs, progression, combat, inventory, economies and procedural systems. Those mechanics do not automatically belong in the Elsewhere core.

50 Game-specific concepts

A game may define namespaced state and capabilities. Clients that understand those concepts can interact richly with them. Other clients may preserve them or interpret accompanying semantics.

state:
  mygame:suspicion: 0.72
  mygame:dream_depth: 4

capabilities:
  - mygame:whisper-to
  - mygame:enter-memory

51 Profiles

Reusable families of conventions SHOULD be defined as optional profiles rather than universal core requirements.

profiles:
  - elsewhere:interactive-region/v1
  - rpg:inventory/v2
  - mygame:combat/v3

52 Progressive determinism

Elsewhere SHOULD formalise only what needs shared agreement.

If divergent interpretations would break shared reality, formalise it. If divergence merely creates compatible presentation differences, leave it open.

• subtle vegetation motion may be client-local;
• possession of a key may be authoritative state;
• whether the key opens a door may be authoritative behaviour;
• the precise door sound may remain presentational.

53 Simulation

A Region MAY expose simulation expectations or profiles, including gravity, atmosphere, collision conventions, locomotion assumptions and environmental constants. Elsewhere does not itself execute simulation. Where simulation affects shared canonical reality, the Region Authority determines the authoritative result.

54 Simulation authority

Simulation is a responsibility beneath Region Authority. Elsewhere does not define a competing universal Simulation Authority. A Region Authority MAY internally delegate simulation while retaining a clear authoritative trust chain.

55 Delegation

A Region Authority MAY delegate responsibilities such as assets, simulation, identity, media and storage. Delegation MUST NOT make the authoritative source ambiguous to clients.

one Region → one primary Region Authority

56 Identity

Elsewhere SHOULD NOT require one universal user account. A Region Authority MAY accept local identities, federated identities, anonymous sessions, cryptographic identities, external identity providers or other mechanisms. The Region determines which identities it trusts and what they may do.

57 Permissions

Regions MAY control permission to observe, enter, inspect, interact, invoke capabilities, create, modify, delete, administer and subscribe to events. Permission decisions belong to the Region Authority.

58 Region links

A Region MAY link to another Region. The source Region is authoritative for the existence of the link. The destination Region is authoritative for the place to which the link leads.

destination:
  region: elsewhere://moon.example/base
  entry: arrival-hall

59 Portals

A portal is one possible spatial presentation of a Region link. Linked Regions do not need to share owners, servers, engines, physics, coordinate systems, catalogues or game rules. A portal is therefore conceptually closer to a spatial hyperlink than an opening between partitions of one central simulation.

60 Region transition

A client following a Region link may need to:

1. resolve the destination Region;

2. retrieve its Manifest;

3. identify its Authority;

4. connect to its Region MCP;

5. read relevant instructions;

6. negotiate identity and permissions;

7. resolve the requested entry point;

8. obtain required state and representations;

9. establish event or realtime connections;

10. enter.

61 Cross-Region objects

Moving an object between Region Authorities raises separate questions of reference, representation, copying, custody, ownership and authority transfer. Elsewhere SHOULD distinguish these concepts rather than treating them as equivalent. Early implementations MAY support external references without supporting arbitrary authority transfer.

62 AI

AI is a valid Elsewhere implementation mechanism. It is not required. AI does not possess authority merely because it performs reasoning. Authority comes from the Region Authority.

• authoring;
• interpretation;
• asset selection;
• procedural detail;
• NPC behaviour;
• semantic querying;
• accessibility;
• catalogue development.

63 Authoring AI

An AI authoring system MAY convert human intent into structured Elsewhere information. Once that information is explicitly committed by an authorised authoring process, it becomes canonical until changed through an authorised edit.

64 Runtime AI

Runtime AI MAY interpret unspecified details. It MUST respect canonical facts and authoritative state. AI interpretation MAY enrich a Region. It MUST NOT silently rewrite its canonical reality.

65 Semantic caching

Semantic interpretation MAY be cached. Natural-language description does not imply continuous model inference. Clients MAY resolve descriptions into cached assets, materials, render plans, behavioural interpretations and accessibility representations. Caches SHOULD be invalidated when relevant authoritative information changes.

66 Agents

Agents are Elsewhere participants. Agents SHOULD operate against the same canonical Region model as other clients.

• inspect a Region;
• read its instructions;
• read its vocabulary;
• query entities;
• invoke capabilities;
• receive events;
• navigate;
• modify authorised state.

67 MCP and agents

The Region MCP interface provides a natural way for an unfamiliar agent to learn a Region.

connect
   ↓
read Region instructions
   ↓
discover relevant resources
   ↓
understand unfamiliar vocabulary
   ↓
inspect current entities/state
   ↓
discover available tools/actions
   ↓
participate

68 Client freedom

A client MAY choose its own renderer, engine, interface, control scheme, accessibility representation, local effects, audio implementation, level of detail and caching strategy. Local presentation MUST remain distinguishable from authoritative Region state.

69 Different forms of client

A Region may be experienced through realtime 3D, VR, AR, mobile rendering, a web interface, a text interface, an accessibility interface, an AI-generated renderer, a game engine or an autonomous agent. These clients may perceive different representations of the same canonical Region.

70 Privacy

Region Authorities SHOULD expose only information a participant is authorised to receive. Semantic and AI-capable clients MUST NOT be relied upon to conceal private data after it has already been exposed. Privacy SHOULD be enforced at the authoritative data boundary.

71 Extensibility

Elsewhere MUST remain extensible. Unknown optional fields and namespaced concepts SHOULD be tolerated. A Region MUST NOT require every client to understand every extension before basic interoperability is possible.

72 Backwards evolution

Stable meanings SHOULD NOT silently change. Where a catalogue term, profile or structured contract changes incompatibly, implementations SHOULD use explicit versioning, replacement identifiers, deprecation or compatibility declarations. Previously authored Regions SHOULD remain interpretable.

73 Minimum Region Manifest

A minimal Manifest SHOULD communicate the Elsewhere version, Region identity, Region Authority, Region MCP endpoint where interactive, and entry information. Optional features may then be discovered progressively.

74 Minimum interactive Region

A minimally useful interactive Region SHOULD expose a Manifest, Region Authority, Region Instructions, entities or resources, canonical state, available actions and authoritative outcomes. Realtime transports are optional.

75 Minimum Elsewhere client

A basic client SHOULD be able to:

1. resolve a Region;

2. retrieve its Manifest;

3. identify its Authority;

4. discover supported interfaces;

5. read canonical information it supports;

6. tolerate unknown optional concepts;

7. connect to Region MCP where supported;

8. discover available interactions;

9. request supported actions;

10. receive authoritative outcomes.

76 Example Region

The following example shows a Region Manifest and its Markdown instruction resource.

{
  "elsewhere": "1.0",
  "region": {
    "id": "elsewhere://game.example/castle",
    "name": "The Drowned Castle"
  },
  "authority": {
    "origin": "https://game.example"
  },
  "interfaces": {
    "mcp": "https://game.example/castle/mcp",
    "events": "wss://game.example/castle/events"
  },
  "instructions": {
    "resource": "elsewhere://region/instructions"
  },
  "vocabularies": [
    "elsewhere:core/v1",
    "drowned:vocabulary/v2"
  ],
  "profiles": [
    "elsewhere:interactive-region/v1"
  ],
  "entryPoints": {
    "default": "harbour-gate"
  }
}

# The Drowned Castle

The lower half of this Region is permanently flooded.
Water level is authoritative Region state.

## Unusual concepts

`drowned:breathing-water` is water that can be breathed but
cannot support ordinary combustion.

`drowned:memory-lock` is a locking mechanism whose valid input
is semantic rather than physical.

Its instruction resource might begin with Markdown describing the flooded state and unusual concepts such as drowned:breathing-water and drowned:memory-lock.

77 Example interactive entity

A client may request elsewhere:open. The Region Authority determines the outcome.

entity:
  id: vault-door-01

  semantic_type: elsewhere:door

  terms:
    - elsewhere:hinged
    - elsewhere:openable
    - elsewhere:metal
    - industrial:pressure-door

  semantic: >
    A massive circular steel pressure door. Its surface is
    scratched and oxidised around the locking wheel. It initially
    feels almost immovable before swinging outward slowly.

  transform:
    position: [8.4, 0.0, -11.2]
    rotation: [0, 180, 0]

  dimensions:
    width: 1.45
    height: 1.95
    depth: 0.24

  state:
    open_fraction: 0.0
    locked: false

  capabilities:
    - elsewhere:open
    - elsewhere:close

  behaviour_ref:
    elsewhere://behaviours/heavy-hinged-door/v1

78 Example custom game mechanic

Elsewhere does not need a universal concept of manifestation, awareness or enter-memory. The Region defines those mechanics.

entity:
  id: dream-guardian-6

  semantic_type: mygame:dream-guardian

  terms:
    - elsewhere:agent
    - mygame:hostile-when-observed

  semantic: >
    A figure that becomes more physically real as the visitor
    notices it, but loses awareness of the visitor when directly
    illuminated.

  state:
    mygame:manifestation: 0.63
    mygame:awareness: 0.27

  capabilities:
    - mygame:observe
    - mygame:enter-memory

79 What belongs in the core

The Elsewhere core SHOULD concentrate on interoperability primitives such as:

• Region identity;
• Authority discovery;
• Manifest structure;
• MCP discovery;
• entity identity;
• canonical state;
• references;
• capability discovery;
• action invocation;
• outcomes;
• events;
• permissions envelope;
• Region links;
• vocabulary discovery;
• profiles;
• extension rules.

80 What should usually remain outside the core

The core SHOULD be cautious about universalising concepts such as:

• health;
• damage;
• weapons;
• inventories;
• XP;
• quests;
• currency;
• teams;
• magic;
• NPC architectures;
• one locomotion model;
• one avatar model;
• one economy;
• one combat model;
• one physics implementation.

81 Core design test

Before adding a new universal Elsewhere concept, ask whether independent interoperability actually requires it; whether divergent interpretation would break shared reality; whether the proposal standardises communication or dictates world design; whether real Regions can experiment with it first; and whether actual usage has demonstrated the need.

Does independent interoperability actually require it? If not, it may not belong in the core.

Would divergent interpretation break shared reality? If not, it may remain semantic or presentational.

Is it standardising communication or dictating world design? If it dictates world design, it probably belongs in a profile or namespace.

Can real Regions experiment with it first? If yes, namespaced experimentation SHOULD precede universalisation.

Has actual usage demonstrated the need? Core growth SHOULD be driven by demonstrated interoperability requirements.

82 Architectural summary

The Region Manifest bootstraps identity and interfaces; the Region MCP exposes Markdown instructions, semantic and structured resources, and structured tools/actions; the Region Authority applies Region rules and owns canonical state and outcomes.

REGION URI
    │
    ▼
REGION MANIFEST
    │
    ├── Region identity
    ├── Region Authority
    ├── Elsewhere version
    ├── Region MCP endpoint
    ├── vocabularies
    ├── profiles
    ├── entry points
    └── optional realtime interfaces
             │
             ▼
         REGION MCP
             │
             ├── Markdown instructions
             ├── semantic resources
             ├── structured resources
             └── structured tools/actions
                      │
                      ▼
               REGION AUTHORITY
                      │
                 Region rules
                      │
                      ▼
              canonical state
                      │
                      ▼
              events / outcomes

83 Meaning summary

CANONICAL FACTS
       +
CATALOGUED CONCEPTS
       +
NATURAL SEMANTIC DESCRIPTION
       ↓
RICHEST COMPATIBLE UNDERSTANDING
       ↓
CLIENT-SPECIFIC REALISATION

84 Runtime summary

PARTICIPANT
     │
   intent
     ▼
STRUCTURED ACTION
     │
     ▼
REGION AUTHORITY
     │
 permissions + rules + behaviour
     ▼
CANONICAL CONSEQUENCE
     │
     ▼
STATE + EVENT
     │
     ▼
CLIENTS / AGENTS

85 Federation summary

The source owns the link. The destination owns itself.

REGION A
Authority A
    │
    │ spatial hyperlink
    ▼
REGION B
Authority B

86 Foundational rules

The following principles define Elsewhere:

• Elsewhere is the protocol; Regions are the authorities.
• Every Region has its own authoritative boundary.
• Crossing a Region boundary means crossing an authority boundary.
• Every Region begins with a small structured Manifest.
• Interactive Regions should expose a logical MCP interface of their own.
• The Region Manifest tells a participant how to begin.
• Region Markdown teaches a participant how the place should be understood.
• Structured state and actions determine shared reality.
• Markdown explains the world; it does not replace deterministic contracts where deterministic agreement matters.
• Canonical facts, catalogue concepts and natural semantic meaning should be interpreted together.
• Authority determines what may be contradicted; descriptiveness determines how compatible gaps should be filled.
• Use the richest compatible description available.
• Describe first. Standardise when recurring interoperability makes standardisation useful.
• Unknown concepts must not prevent the universe from evolving.
• Standardise requests and consequences before internal implementation.
• Standardise the grammar, not the game design.
• Games can run directly as Elsewhere Regions.
• A Region may invent rules Elsewhere has never encountered before.
• Clients may be engines, browsers, tools, accessibility interfaces or agents.
• The source Region describes the link; the destination Region describes itself.

Elsewhere reuses established open standards where they already solve the representation problem; it defines new protocol structures where world authority and interoperability require them.

87 Philosophy

Elsewhere exists to allow independently created worlds to become part of a connected universe without requiring them to surrender their individuality.

A complete ontology of reality cannot be designed in advance. A single game engine cannot anticipate every future interaction. Natural language alone cannot guarantee deterministic shared state. Rigid schemas alone cannot express the long tail of human imagination.

Elsewhere therefore combines structure where agreement matters; vocabulary where shared meaning is useful; natural language where expression should remain open; and independent authority so that no single system needs to own the universe.

A Region can be handcrafted or generated. It can be a game or a museum. It can obey ordinary physics or invent entirely new rules. It can be experienced visually, textually, through VR, through accessibility technology or by an autonomous agent. It can introduce concepts that have never previously existed.

Its Manifest tells visitors where they have arrived. Its Markdown teaches them how to begin understanding the place. Its catalogue gives recurring concepts stable names. Its MCP interface exposes what can be discovered and done. Its structured state records what is actually true. Its Authority decides what happens. Its links connect it to worlds controlled by others.

Elsewhere does not need to decide what every world should contain. It needs to make it possible for those worlds to understand one another.

Elsewhere provides the language through which worlds meet. It does not tell those worlds what they are allowed to become.

Appendix A — MCP reference profile

The initial Elsewhere reference profile targets the contemporary Model Context Protocol server model for Region discovery, resources and tools.

An Elsewhere implementation SHOULD avoid depending on incidental MCP implementation behaviour where the same requirement can be represented explicitly in the Region Manifest or Elsewhere profile.

Future Elsewhere versions MAY update the recommended MCP profile independently from the conceptual Region model.

The following separation SHOULD remain stable:

Elsewhere
    defines spatial/world semantics and authority

MCP
    provides discoverable resources and structured actions

Markdown
    communicates semantic instructions and documentation

Realtime transports
    carry communication whose frequency or delivery model
    is unsuitable for ordinary MCP interaction

Appendix B — Recommended publication artefacts

A basic hosted Region may conceptually contain:

/.well-known/elsewhere
        Region Manifest

Region MCP endpoint
        Region instructions
        resources
        vocabulary
        tools/actions

Optional realtime endpoint
        events / state replication

Optional asset endpoints
        meshes / media / other representations

A source project might be authored as:

castle/
    manifest.json
    region.md

    vocabulary/
        memory-door.md
        reflection.md

    rules/
        movement.md
        magic.md

    lore/
        history.md

    region-data/
        entities/
        state/

The hosting implementation is responsible for exposing those source materials through the appropriate Elsewhere interfaces. The on-disk authoring layout itself is not normative.