World execution and isolation boundary

Forward-looking contract. Current Me commonly derives worldId from user.id and accepts legacy user/workspace scope alternatives. The guarantees below are release gates for multi-world and shared-store deployment, not a description of current isolation.

Canonical terminology is defined in the Realm domain glossary.

The portable rule is simple: isolate by world and context; authorize every execution as exactly one principal. A world may admit several human and service principals. Concurrent executions of the same Realm in the same world may therefore run as different principals without changing their data boundary.

Field	Contract role
worldId	Opaque, durable identity that partitions all private data, configuration, credentials, routes, receipts, caches, execution state, and canonical entities.
contextId	Explicit confidentiality boundary within a world. It never replaces worldId.
principalId	Human or service identity whose authority the execution uses. It authorizes and attributes the operation; it is not a data-partition substitute for worldId.
executionId	Identity of one durably admitted logical execution, stable across recovery and worker attempts.

userId is not a portable Realm scope. A host may use it for a human account that is a principal or may map it to a principalId, but Realm manifests, guest inputs, persisted scope stamps, and cache keys never use userId as an alias for worldId or as the general runtime authority. Administration, billing, and ownership are host management-plane concerns, not portable execution identities.

principalId is an opaque, stable identifier in the host security domain and is never recycled. For federated authentication the host derives it from a verified issuer and subject, not from an email address, display name, or unqualified provider-local id. Membership and access to each world and context are separate policy and are rechecked at admission and every privileged handoff.

worldId is globally unique, persisted with the world, and independent of its administrative account, name, and filesystem or deployment location. Renaming, moving, restoring, or transferring the same world preserves its id. A copy intended to become an independent world receives a new id. Administrative transfer does not rewrite world data or silently transfer authority: existing adoptions and credentials pause until an explicit transfer policy revalidates them.

A host may subdivide a world into named knowledge or memory contexts. Such a context is identified by (worldId, contextId) and is a confidentiality boundary with a versioned access policy. Every context-owned node, edge, vector record, materialization, and positive or negative cache entry includes contextId and the applicable access-policy revision. The default context is explicit; an absent context fails closed. A context may narrow which principals can read within a world; it never replaces worldId as the isolation boundary or authorizes a cross-world read.

The host binds immutable worldId, contextId, principalId, and executionId on every execution. Realm code and request payloads cannot choose or override them. On-demand work uses the authenticated caller as principalId. Autonomous work uses the run-as human or service principal selected by its adoption. A signal, webhook sender, or channel author is input data, never the principal merely because it caused an execution.

An adoption records who created or approved it for audit, separately from its run-as principal. Those audit identities grant no execution authority. A platform may record workerId for the process handling an attempt, but it is operational telemetry only: it grants no authority and enters no data, credential, cache, cursor, route, or receipt key. Credential resolution is keyed by world, context, principal, connection, and grant revision. Audit records include world, context, principal, adoption when present, execution, trigger or sender data, observed world epoch, and optionally the worker.

Realms in one world intentionally compose over that world’s typed graph and gateway surfaces. Realms in different worlds do not share data, credentials, routes, receipts, canonical entities, or mutable caches, even when the same person owns both. Deployment-approved Public/reference datasets are the only exception.

A host may share immutable code only when the canonical full-package realmDigest addresses it. Sharing a worker never relaxes world scoping. Local and single-tenant deployments run the same path with one world; deployment topology is not an authorization control.

The default identity of a world-visible persisted Person, Organization, mirror, bridge, or other canonical entity is consequently (worldId, WORLD, type, merge key). Context-private identity is (worldId, contextId, type, merge key): it cannot add properties or edges to a world-visible spine until an explicit, policy-checked promotion makes that information world-visible. Cross-world or organization-wide identity is a separate host capability: it needs an orgId, verified membership, an adoption-visible grant, and an organization-scoped merge key. A bare email or domain must never merge canonical data between contexts or worlds.

Restore, transfer, and fork

At most one world incarnation may be active. Activation allocates a monotonically increasing worldEpoch; every lease, dispatch, gateway call, token, and delivery handoff proves the current epoch. Restore or migration preserves worldId only through an exclusive handoff that fences the old incarnation before the new one runs. Restoring a copy while the original remains active is rejected.

Restore preserves effect receipts so their idempotency identity survives recovery. It invalidates leases, sessions, tokens, and captured routes. Any IN_FLIGHT or OUTCOME_UNKNOWN effect is reconciled or surfaced for a decision, never automatically replayed. worldEpoch is a fencing value, not part of an effect receipt key; incrementing it must not make the same logical effect spend again.

Administrative transfer is an atomic suspended state. Before the world resumes, host policy revalidates or revokes principal membership, context ACLs, service principals, grants/adoptions, credentials, sessions, tokens, routes, and queued work. Data, receipts, and audit retain worldId; authority does not silently transfer with them. The world resumes under a new worldEpoch.

A fork is a new world, not a second incarnation. It receives a new worldId, new context ids, and rekeys every private/context/canonical identity. It copies no adoptions, credentials, service principals, routes, sessions, tokens, leases, queued work, or effect receipts. Those capabilities require adoption in the fork.