Runtime Principles

Five principles that govern all Elonn runtime development. The Runtime Contract is the implementation contract; this page explains the reasoning behind it.

The Runtime Contract standard is practical: a new runtime team should be able to build for a new device from the Runtime Contract, service contracts, examples, and conformance checks without asking project-specific questions or reading existing runtime code to infer behavior.

World is the only runtime-facing service

Runtimes consume World. Runtimes do not consume services.

All platform data reaches a runtime through world.elonn.local. Find, Maps, Social, Calendar, Messaging, and any future services are implementation details hidden behind World. A runtime should function correctly without knowing where any piece of data originated.

This is the most important boundary rule in the platform. If a runtime requires service knowledge to function, the architecture is wrong.

Runtimes are consumers, not owners, of platform state

A runtime does not own identity, social, messages, calendar, maps, workspace, or find state. It receives the canonical runtime dataset from World, renders it, and writes mutations back through World.

State ownership belongs to services and World. Services own domain truth. World owns the canonical runtime dataset and command authority. Runtimes project that dataset into platform-native scene structures without interpreting service or product structure.

World is the runtime data boundary

Runtimes render the canonical runtime dataset. The runtime does not decide what objects exist, how workspace state is ordered, what service backs an object, or what actions mean. World defines the dataset; runtimes decide how to display it.

A runtime that adds its own product structure, service interpretation, or workspace rules is building a fork, not a runtime adapter.

Platform behavior is defined once and projected everywhere

The workspace model, field model, find model, action model, and authority model are specified once in the runtime dataset. Existing Web, Android, iPad, and Cardboard implementations are not design references; they are migration targets and evidence of where the old model was ambiguous.

Capability differences are declared to World and handled by runtimes through projection and fallback behavior. They change presentation shape, not object identity, action meaning, permissions, or authority.

New runtimes are adapters, not independent applications

Each new runtime is an adapter of the canonical runtime dataset to a new environment. The adapter handles device capabilities, sensor integration, platform rendering, input, accessibility implementation, projection, and local lifecycle.

A runtime that reimplements platform architecture rather than adapting it creates maintenance debt that compounds across every future platform change.