Skip to content
Embabel Worlds

Execution hosts

Forward-looking contract. The portable Docker capability boundary, fail-closed unknown-host behavior, and atomic artifact-set publication below require host changes. Until implemented and tested, current Docker/source-validation behavior is not a marketplace security boundary.

A realm ships logic and declarations. The platform supplies the sandbox, identity binding, resource limits, triggers, and observability. Data enters through declared surfaces and leaves through gateway calls. A portable realm never reaches around that boundary: no ambient credentials, direct infrastructure, or mutable runtime shared with another realm.

Two consequences are normative:

  • Isolation. Each dispatch runs in a sandbox with exactly the capability set its host defines. One realm’s dispatches cannot observe or interfere with another’s mutable runtime state, and no realm can change the host-bound world, context, principal, or execution. Realms deliberately share declared types inside a world; graph data is readable only through the current context/access policy or an explicit policy-authorized bridge. An implementation may pool processes and immutable content-addressed code, but every mutable object and gateway call remains world-, context-, and where principal-dependent, principal-scoped.

  • Statelessness between dispatches. A handler must assume nothing survives from one dispatch to the next — no globals, no accumulated caches, no in-memory session. Durable state lives in the graph, written and read through the gateway. This is what lets a host run one instance or a thousand: any dispatch can land on any instance, so a realm scales independently of every other realm and of the platform itself.

  • A binding the runner was not given is NOT DECLARED. Referencing it throws a ReferenceError rather than yielding undefined, so if (violation) does not guard it and neither does violation ?? null. Only typeof does, and it holds whether the identifier was never declared or declared without a value:

    const row = typeof violation === 'undefined' ? null : violation
    if (!row) { console.log('run by the duty that binds a row; nothing to do alone'); return { done: null } }

    Guard every binding a handler does not always get, and especially one supplied by a single caller — a duty’s violating row, a signal’s payload. autonomous: false and a comment saying “run by the duty, never on its own” do not prevent the handler being invoked; only the guard does. A host may surface a failed handler to the user, so an unguarded read is a stack trace in somebody’s chat: a realm shipped exactly this, was reached on a chat turn, and answered a user who had just said their wife had died with a ReferenceError and ten frames of Node.

    Prefer a fallback where one is obvious — the current time for now, doing the work for real for an absent dryRun — and a no-op that says why where one is not. A handler should not depend on being invoked the way its author expected.

The Realm Function contract is independent of placement. Each host declares which executable and declarative surfaces it supports, and admits them against the captured Realm and resource grants. Parsing a producer, lens, API or event declaration does not authorize its execution. A handler that needs npm does not become a Wasm function by relabeling it. Two hosts exist:

Host What runs Choose it when
docker the compiled dist/ JS modules, in the host’s Node code sandbox Default. Handlers need npm dependencies or the full TS project layout. Portable realm code still has no raw network or ambient credential access.
wasm dist/handlers.wasm, in-process inside the host runtime Functions are small and dependency-free, per-dispatch latency matters, or the deployment has no container runtime.

The portable contract is capability-based on both hosts: no sockets, DNS, arbitrary fetch, process environment, inherited file descriptors, or ambient credentials. External access goes through the host gateway, which applies world/context scope, policy, receipts, quotas, and audit. A deployment may define a privileged container extension with raw network access, but that is organization-reviewed host code outside the portable/marketplace realm contract and must not be selected merely by declaring host: docker.

Adding a host that consumes an existing artifact class changes nothing for a Realm author except the host: value. Functions keep their names and schemas, signals keep their identity, gateway calls keep their envelope, and the audit format stays the same. A candidate host that needs more than that from authors is not a host.