The Entity System

A Computational Information Substrate

1. Introduction

This paper examines six primitives for distributed information systems — Entity, Identity, Tree, Emit, Execution, Peer — and asks whether they are irreducible. The primitives surfaced from working on The Entity Core Protocol; the next section sketches the protocol briefly, and the rest of the paper turns to the primitives themselves.

The approach is combinatorial. We examine what properties emerge at each composition level — from single primitives through the full six. Self-description and fixed-point types emerge at three primitives. Mutability — and the structural potential for versioning, audit, and convergence — emerges at four. Computation, which actualizes these latent properties, emerges at five. Distribution at six. At each step, properties appear that could not exist at the previous step.

We test irreducibility by removing each primitive in turn and showing what is lost. We do not claim this is the only possible decomposition, but we have not found a way to simplify it further.

Existing systems — Git, IPFS, gRPC, Plan 9, AT Protocol, Nostr, Holochain, Urbit — map to subsets of two to four primitives. The gaps in each correspond to the primitives they lack. We have not found a system that implements five or more of the six.

Three independent implementations (Go, Python, Rust) validate cross-platform conformance, and peers generated from the specification into dozens of further languages reach the same bytes. A system-extension set — messaging, reactive computation, version coordination with peer sync, subscriptions, content distribution, history, time, and query — composes through the same six primitives without modifying the core protocol.

The Entity Core Protocol specifies the protocol itself. The Entity Church Architecture develops the computational model that arises from these primitives.

2. The Entity Core Protocol

The Entity Core Protocol is a working specification for distributed information systems. Its surface is small:

• Content-addressed typed data as the basic unit. Every value is {type, data}; the unit’s identity is the hash of its canonical encoding.
• A mutable named tree over an immutable content store. The content store maps hash $\to$ entity; the tree maps path $\to$ hash. Paths are mutable; content is not.
• Universal addressing. Every entity has a name, a location, and an address: peer/path resolves to a content hash in some peer’s tree. The namespace is peer-isolated by construction, so trees from different peers compose without conflict; identical content shared across peers deduplicates automatically. Whether a given entity is reachable from where you sit is a separate question — capability-gated, network-dependent — but addressability itself is unconditional.
• Two message types. EXECUTE carries a typed operation against a path; EXECUTE_RESPONSE returns the result. There is no separate query, subscribe, or update message — they are all EXECUTE against handlers registered in the tree.
• Four-dimensional capability grants (handlers, operations, resources, peers) with cryptographic attenuation. Capabilities are themselves entities, content-addressed and verifiable independently of session.
• Peer-to-peer communication. Each peer has content-derived identity, hosts its own tree, and exchanges entities with other peers under capability constraints.

Three independent implementations (Go, Python, Rust) speak the protocol on the wire. The Entity Core Protocol specifies the protocol in full; the sketch above is only enough to motivate what follows.

2.1. What surfaced

Working on the protocol returned six concerns that everything else rests on:

• Entity — the typed data unit
• Identity — content-derived hash
• Tree — mutable namespace over immutable content
• Emit — atomic state change
• Execution — typed dispatch
• Peer — the participant

The rest of this paper examines these six directly: what each one is, what they depend on, what properties emerge as they compose, and where existing distributed systems sit relative to them.

2.2. The substrate, the protocol, and the implementations

The entity system in this paper’s title refers to the abstract information substrate the six primitives produce when they compose — not to any specific implementation. The Entity Core Protocol is one instantiation of the substrate: a specific wire format, dispatch model, and capability scheme that realizes the six primitives concretely. The Go, Python, and Rust codebases are three implementations of that protocol. Substrate, protocol, and implementations are different things at different levels. When this paper says “the system,” it means the substrate; the protocol is the concrete reference we point at when specificity helps.

3. The Six Primitives

Each primitive is defined by what it is, what it provides, and what depends on it. The six divide into three domains:

• Informational (E, I, T): structure, identity, naming — no time, no space, no agency
• Temporal (M, X): change and directed action enter
• Spatial (P): position and perspective enter

This division is not merely a classification. It reflects a dependency structure: the temporal primitives depend on the informational ones, and the spatial primitive depends on both.

3.1. Entity

The fundamental data unit: {type: string, data: any}. Type is constitutive — an entity without a type is not an entity. This distinguishes the entity from a byte blob (Git), a codec-tagged block (IPFS), or an untyped record. The type is part of the thing, not metadata about it.

3.2. Identity

$$\text{content\_hash} = \text{format\_code} \mathbin\| \text{SHA256}(\text{ECF\_encode}(\text{type}, \text{data}))$$

Same {type, data} produces the same hash, everywhere, always. Different type produces a different hash even with identical data. Identity is intrinsic — derived from what something is, not assigned by an authority.

ECF (Entity Canonical Form) is a deterministic CBOR encoding that ensures identical bytes for identical data. This makes the hash function a true content-derived identity: two independent implementations that encode the same entity will produce the same hash.

3.3. Tree

Path $\to$ hash: named organization over immutable content. The tree is “what things are called” — a mapping from paths to content hashes. The content store (hash $\to$ entity) is “what things are.”

A given tree state is itself a set of bindings — a snapshot. The tree as a structural concept is informational. What makes it appear mutable is Emit (M) — the act of replacing one set of bindings with another. Mutability belongs to M, not to T.

The tree is a logical namespace (a flat path $\to$ hash mapping), not a filesystem. All paths are scoped to a peer identity.

The tree also functions as a relation space. Path segments can contain content hashes — signatures/{content_hash}, diff/{A}/{B}, merge/{A}/{B}/{base} — where the number of hash segments determines the arity of the relation. This allows the tree to express arbitrary n-ary relations over content, including content that does not yet exist (the hash space is larger than any concrete content store).

3.4. Emit

The atomic state crossing. Two operations on distinct primitives, each independently observable:

1. Store: entity enters the content store (hash $\to$ entity, immutable — the Identity axis).
2. Bind: tree binding updates (path $\to$ hash, mutable — the Tree axis).

Both happen atomically; each produces an event when it does real work. Re-putting identical content is a no-op at the Identity axis; re-binding to the same hash is a no-op at the Tree axis. Emit is the temporal coupling of Identity and Tree — the point where both primitives extend into time.

Every state change is a sequence of emit crossings. This is where content (which persists by hash) meets naming (which changes over time). Emit introduces events, change, before-and-after.

3.5. Execution

Execution represents the evaluator — the mechanism that reads typed structures from the tree and produces new structures. At the protocol level, this takes the form of two message types: EXECUTE and EXECUTE_RESPONSE.

• EXECUTE: dispatch typed parameters to a handler at a URI
• EXECUTE_RESPONSE: return a typed result

Execution introduces agency — directed transformation, not merely the change M already provides. An agent reads the tree, transforms entities, and emits new state. The evaluator is what makes information active.

The evaluator has two activation modes. In directed mode, an EXECUTE message invokes a handler explicitly — an agent requests a specific transformation. In reactive mode, an emit event triggers re-evaluation — the evaluator responds automatically to state changes (as in the compute extension’s reactive cascades). Both modes are aspects of the same primitive: the mechanism that reads typed structures and produces results.

Every interaction is an EXECUTE: queries, mutations, subscriptions, connection setup. The operation vocabulary is unbounded — any handler defines any operation. The message structure is fixed. Handlers are entities registered at tree paths. Dispatch is a tree walk: the longest matching prefix determines the handler. The tree is the dispatch table.

3.6. Peer

$$\text{PeerID} = \text{Base58}(\text{key\_type} \mathbin\| \text{hash\_type} \mathbin\| \text{SHA256}(\text{public\_key}))$$

Ed25519 key pairs. Peer identity is itself content-addressed.

Capabilities are four-dimensional grants covering handler scope, resource scope, operation scope, and peer scope, with cryptographic attenuation chains. Each EXECUTE carries its own capability token — per-message authorization rather than session-based access.

Connection is a handshake of EXECUTE messages — a hello, then authenticate, whose response carries the initial capability grant. It uses the same dispatch mechanism as everything else — there is no separate connection protocol.

3.7. Dependency Structure

The informational primitives have a strict partial order:

• Entity $\to$ Identity: the hash function takes {type, data} as input
• Identity $\to$ Tree: the tree binds paths to content hashes

The temporal primitives depend on the informational:

• Tree $\to$ Emit: the bind step of emit updates a tree binding
• Tree $\to$ Execution: dispatch is a tree walk

The spatial primitive depends on both:

• Identity $\to$ Peer: peer ID is a hash of the public key
• Execution $\to$ Peer: connection establishment uses EXECUTE

This dependency structure is not imposed — it follows from what each primitive needs as input.

4. The Pair-Relationship Structure

Primitives do not only exist as independent constructs. They interact pairwise whenever both are present. Each pair of primitives forms a pair-relationship — a structural coupling with observable content. Six primitives produce $\binom{6}{2} = 15$ pair-relationships. The distribution of structural load across these 15 pairs is uneven and informative: most of the system’s engineering sits at pair boundaries, not inside individual primitives.

4.1. The 15 Pair-Relationships

Grouping by the 3+2+1 domain split:

By structural load:

• Heavy (11 of 15): EI, IT, ET, IM, TM, EX, IX, TX, MX, TP, XP. These carry the bulk of engineering surface — extensions, SYSTEM-COMPOSITION, capability and dispatch systems concentrate here.
• Medium (1): IP.
• Light (2): EM, MP.
• Negligible (1): EP — entities do not carry peer identity, by design.

The emit primitive M, from the previous section, is best understood in pair terms: M is the temporal coupling of I and T. The Store event is the IM pair in action (content enters the I-indexed store); the Bind event is the TM pair (tree binding updates). Together with IT as the static substrate, they form the emit triangle — one of several structural triangles that recur across the system.

4.2. The Dependency-Coherent Sub-Lattice

The dependency constraints above partition the $2^6 = 64$ binary subsets: exactly 9 subsets satisfy all dependencies strictly. These 9 form a sub-lattice:

                EITMXP
               /     \
            EITMX   EITXP
           /    \   /
        EITM   EITX
                 |
               EIT
                 |
                EI
                 |
                 E
                 |
                 ∅

The dependency-coherent sub-lattice is the skeleton of internally-coherent system configurations. Other subsets — those containing M without T, or P without I, for example — are structurally incomplete: they violate at least one dependency and cannot form a working system without external compensation.

Three monotone paths run through this sub-lattice from $\emptyset$ to E+I+T+M+X+P:

• Path A: $$ E $\to$ EI $\to$ EIT $\to$ EITM $\to$ EITMX $\to$ EITMXP. Narrative: information $\to$ time $\to$ computation $\to$ space.
• Path B: via EITX before EITM. Narrative: computation before time.
• Path C: via EITXP before EITMXP. Narrative: space before time.

The build-up sequence in the next section follows Path A because it tells the cleanest story. The other paths are also valid; the narrative choice is editorial, the lattice is structural.

4.3. Five Structural Triangles

Three-primitive subsets that recur across the system as recognizable units:

• EIT — self-description triangle. The type fixed point: system/type of type system/type lives here.
• ITM — emit triangle. IT is the static substrate; IM extends I into time; TM extends T into time. The two-axis structure of emit is the triangle’s structural content.
• TMX — reactive dispatch triangle. The cascade loop (M triggers X; X emits M) closes here. The compute extension’s substrate.
• IXP — cryptographic capability triangle. Capability tokens are content-addressed entities (IX) transferred between peers (XP) verified by identity (IP).
• TXP — distributed dispatch triangle. Tree-walk routing across peer-namespaced paths. The structural shape of REST and HTTP.

These triangles are where engineering concentrates. Extensions actualize specific pair-bundles over them; system composition coordinates multiple actualizers where triangles are over-subscribed.

5. The Build-Up Sequence

Properties emerge as primitives compose. Each step adds properties that could not exist at the previous step. The build-up traces a progression through domains: the first three steps are purely informational, the fourth introduces time, the fifth introduces agency, and the sixth introduces space.

5.1. Step 1: Entity (E)

Typed data. A unit that carries its type. Nothing else — no identity, no address, no persistence.

Pair-relationships: none yet (pairs require two primitives).

5.2. Step 2: Entity + Identity (E+I)

Typed data with intrinsic identity. Content-derived hashing gives:

• Immutability: changing content changes identity (it becomes a new entity)
• Deduplication: same content is stored once
• Verification: anyone can check content against its hash

Known analog: typed IPFS blocks — content-addressed but without named organization.

Pair-relationships: EI activates. Heavy pairs: 1/11.

5.3. Step 3: Entity + Identity + Tree (E+I+T)

Typed, content-addressed, named data. The tree organizes entities into a namespace. This is where self-description emerges.

Types are entities (E). Types have content-derived identity (I). Types are stored at system/type/* in the tree (T). system/type is itself of type system/type. This is a fixed point — the type system describes itself in its own terms.

The recursion bottoms out at bootstrap types — a small set of primitives and meta-types that seed the type system. Self-description requires all three of E, I, and T: the entity carries its type, the type entity has verifiable identity, and the type entity lives at a known path where it can be discovered and where it describes itself.

E+I+T is the complete informational structure. It could, in principle, contain every structure, every relationship, every truth. You could navigate it, verify references, follow links between entities. It contains structural truth (the shapes of things) and referential truth (how things relate). Self-description is a structural fact — it holds without any computation.

But nothing happens. No state changes, no dispatch, no computation. It is pure information.

Known analog: a typed Git, if Git carried structural types rather than treating data as blobs.

Pair-relationships: IT and ET activate (both heavy). Heavy pairs: 3/11. The EIT self-description triangle is complete.

5.4. Step 4: Entity + Identity + Tree + Emit (E+I+T+M)

Adding emit introduces time. The tree can change — a path can be rebound to a new hash. The old entity still exists in the content store (content addressing preserves it), but the binding has changed. Before and after now exist.

This creates structural potential for several properties:

• Versioning: rebinding a path does not destroy the previous entity. It persists by hash. Every emit is structurally a version.
• Audit trail: the content store is append-only. Emit events form a sequence. Hash chains connect versions.
• MVCC: content addressing functions as a version column. Concurrent readers see consistent snapshots. Concurrent writers produce distinct versions (different hashes).
• Convergence detection: peers with the same hash at the same path have provably the same content, without needing a coordination protocol.

We say potential because these properties are latent in the structure. Without an evaluator, nothing tracks versions, maintains audit logs, or processes events. The content store grows as entities accumulate, but no agent reads, compares, or reacts to the changes. E+I+T+M is a mutable content-addressed store where time exists but nothing acts on it.

The potential matters because it constrains what evaluators can do when they arrive. Even fixed evaluators — like Git’s hash, merge, and diff — operating on E+I+T+M get versioning and audit structurally. The properties are latent in the data model; the evaluator actualizes them. This is why we say information precedes computation: the ground exists before any agent computes on it.

Known analog: no widely-deployed system exists at exactly this composition. Systems that reach E+I+T+M typically also have at least fixed evaluators.

Pair-relationships: EM (light), IM and TM (both heavy) activate. Heavy pairs: 5/11. The ITM emit triangle is complete — IT static substrate plus IM and TM extending into time.

5.5. Step 5: Entity + Identity + Tree + Emit + Execution (E+I+T+M+X)

Adding the evaluator actualizes the temporal properties that were potential at E+I+T+M. The raw materials were present — old entities preserved by content addressing, emit events forming a sequence — but organizing them into useful properties requires something that reads, compares, and acts:

• Versioning: the evaluator tracks, compares, and retrieves previous versions — the old entities were always there by hash; now something reads them
• Audit trails: the evaluator processes the emit event stream into a verifiable history log
• Reactive cascades: emit events trigger the evaluator, which processes changes and may emit further results — subscriptions, derived values, reactive computation
• MVCC: concurrent evaluators see consistent snapshots through content-addressed versions

Even fixed evaluators suffice for many of these. Git’s evaluators — hash, merge, diff, pack — are fixed operations on content-addressed data, yet Git has versioning, audit, and merge. The compute extension demonstrates a more expressive fixed evaluator: one that reads typed expressions (lambda, apply, if, let, lookup, literal) from the tree and reduces them reactively when dependencies change. This is Turing-complete computation without open dispatch — the evaluator is fixed, but its expression language is general.¹

Open dispatch adds extensibility and agency beyond fixed evaluation:

• Handlers: entities registered at tree paths with typed interfaces
• Dispatch: tree walk from URI to handler, longest prefix match
• Operations: unbounded operation vocabulary per handler
• Self-extension: the system can modify its own behavior through the same mechanism it uses for data — handler registration is itself an EXECUTE operation

The transition from fixed to open evaluation is from tool to platform — from a system that does specific things to one whose capabilities are open-ended.

This is a complete local entity system. It computes, self-describes, versions, and audits. But it operates on a single machine.

Known analog with fixed evaluators: Git. Known analogs with open dispatch (individually): actor systems (Erlang/OTP), plugin architectures, application servers. But none combine open dispatch with full E+I+T+M — typed, content-addressed, self-describing, versioned data as the substrate for computation. Existing open-dispatch systems operate on untyped messages (Erlang), external schemas (gRPC), or assigned identity (databases). We have not found a system that combines all five.

Pair-relationships: EX, IX, TX, and MX activate (all heavy). Heavy pairs: 9/11. Four new heavy pairs in one step — the largest single-step unlock. The TMX reactive dispatch triangle is complete.

5.6. Step 6: All Six (E+I+T+M+X+P)

Adding Peer introduces space — position, perspective, and boundaries.

• Multi-peer coordination: peers exchange entities via EXECUTE across connections
• Per-message authorization: capability tokens carried with each request
• Trust boundaries: capabilities attenuate (narrow, never amplify)
• Convergence detection: same hash at same path means converged, without coordination overhead
• Cryptographic delegation: content-addressed capability chains

Capability tokens are themselves entities — subject to the same identity, type, and addressing mechanisms as all other data. Authorization is not a separate system layered on top; it uses the same primitives.

Connection is a handshake of EXECUTE messages — hello, then authenticate, whose response carries the initial capability grant. The grant communicates the peer’s namespace layout. It uses the same dispatch mechanism as everything else.

Known analog: we have not found a system that integrates all six.

Pair-relationships: EP (negligible), IP (medium), TP (heavy), MP (light), XP (heavy) activate. Heavy pairs: 11/11 — full coverage. The IXP capability triangle and TXP distributed dispatch triangle are complete.

5.7. Observations on the Sequence

The informational primitives (E, I, T) require no universe, no time, no agents. Self-description emerges here as a structural fact. The fixed point (system/type describes system/type) holds as a property of the structure, not as a result of computation.

Time enters at M. The evaluator enters at X. Space enters at P. The build-up traces a progression through domains of physicality: from pure information, through time and computation, to distributed space.

A notable observation: the temporal properties (versioning, audit, MVCC) do not require open dispatch or extensibility. Even fixed evaluators — like Git’s hash, merge, and diff — operating on E+I+T+M are sufficient to actualize them. What open dispatch adds is extensibility and agency: the ability to register new handlers, define new operations, and extend the system’s behavior. The transition from fixed to open evaluation is from tool to platform, but even tools actualize the structural potential.

This observation — that information precedes computation in the build-up — is explored further in the Discussion.

Heavy-pair coverage per step. Tracking how many of the 11 heavy pair-relationships are active at each step:

Step 5 is the largest unlock — adding X activates four heavy pairs simultaneously, which is why computation, dispatch, convergence, and reactivity all emerge together at five primitives. Step 6 adds two heavy pairs (TP, XP), confirming that the spatial cluster contributes less structural load than the informational or temporal clusters — one reason removing P leaves a complete local system.

6. The Type System and Self-Description

Self-description emerges at E+I+T and is foundational to everything that follows. It warrants separate treatment.

6.1. Types as Entities

Every type is an entity of type system/type. Types are stored at system/type/{type_name} in the entity tree. Types have content-derived identity (their hash). Types describe entities. Types are entities. Therefore types describe themselves.

This circularity is not vicious — it bottoms out at a small set of bootstrap types that seed the type system itself.

6.2. The Fixed Point

system/type is itself of type system/type. The type that defines all types is defined by itself. This is a fixed point of the type-description function.

The recursion bottoms out at a small set of bootstrap types: primitive value types (string, bytes, integers, bool, null, any), the two meta-types needed for self-description (system/type and system/type/field-spec), and a few structural types for content hashes, paths, and type names. These bootstrap the type system. The protocol’s own structures — execute, execute_response, handler, capability token, grant entry, envelope, and others — are then defined as ordinary type entities using this bootstrap set. The type system describes the protocol; the bootstrap types describe the type system.

6.3. Structural Typing

Types describe shape: fields, field types, optionality. Validation is structural — does this entity match its type definition? — rather than nominal. The type system supports single inheritance, generics, and open types that preserve unknown fields for forward compatibility.

6.4. Types Cross the Wire

Entity types travel with the data. Unlike Protobuf (where schemas are compiled from .proto files, separate from the wire data) or Plan 9 (where data is untyped bytes), the entity protocol is typed end-to-end. There is no type gap at protocol boundaries.

6.5. Why E+I+T

Self-description needs all three informational primitives:

• E: types are entities — they carry a type field
• I: type entities have verifiable identity — their content hash
• T: type entities live at known paths (system/type/*) where they can be discovered and referenced

Remove E and types are not entities — they cannot self-describe. Remove I and type entities have no verifiable identity — you cannot confirm that two peers have the same type definition. Remove T and types exist but have no address — they cannot be discovered or referenced by path.

7. Irreducibility: The Remove-One Test

For each primitive, we remove it and document what the system loses.

7.1. Without Entity (I+T+M+X+P)

An untyped content-addressed system. Data is blobs. No structural validation, no self-description, no typed interfaces. Handlers receive untyped bytes. The system cannot describe itself — there are no type entities because there is no type field.

Known analog: Git with dispatch. Lost: self-description, type safety, structural validation.

Heavy pairs lost: 3 (EI, ET, EX).

7.2. Without Identity (E+T+M+X+P)

A typed namespace system with assigned identity. Identity is a UUID or sequence number, not derived from content. This loses:

• Deduplication (same content, different IDs)
• Verification (cannot check content against ID)
• Convergence detection (same content does not produce same ID)
• Immutability guarantees (IDs persist, but content behind them could change)
• Cryptographic audit (no hash chains)

Known analog: a typed Plan 9 with mutable records. Lost: content integrity, convergence, deduplication, audit.

Heavy pairs lost: 4 (EI, IT, IM, IX) plus 1 medium (IP).

7.3. Without Tree (E+I+M+X+P)

Typed content-addressed dispatch with no persistent namespace. Where do handlers register? Where does state live? Content-addressed entities exist and can be dispatched, but there is no system/handler/* path to organize them, no system/type/* to store type definitions. The bind step of emit requires a tree — without it, emit reduces to “store + ??? + event.”

Known analog: stateless typed RPC with content-addressed parameters. Lost: namespace, organization, handler registration, persistent state.

Heavy pairs lost: 5 (IT, ET, TM, TX, TP) — maximum among removals.

7.4. Without Emit (E+I+T+X+P)

Typed content-addressed namespace with dispatch, but no atomic state crossing. What is lost is the structural guarantee that Store and Bind happen atomically, each producing independently observable events. Without this:

• No versioning by construction (state changes are not atomically tracked)
• No event stream (no events to react to)
• No reactive cascades (extensions that respond to state changes have no integration point)

This is the softest removal among the first five. With execution still present, a handler could implement Store-then-Bind-then-notify as a sequence of operations — reconstructing much of what emit provides, but as a convention rather than a structural guarantee. The loss is not that state cannot change, but that the system no longer guarantees the atomic two-axis crossing with observable events on each axis. Versioning and audit become implementation responsibilities rather than structural properties.

Known analog: typed content-addressed RPC with a namespace but no state guarantees. Lost: atomic state crossing, structural versioning, event integration.

Heavy pairs lost: 3 (IM, TM, MX) plus 1 light (MP).

7.5. Without Execution (E+I+T+M+P)

Typed content-addressed namespace with state changes and peers, but no evaluator. A distributed database where data accumulates but nothing acts on it — no handlers, no reactive cascades, no directed operations. The tree can change (emit still works), but no agent reads the changes, processes them, or produces derived results. Versioning, audit trails, and MVCC remain structural potential that nothing actualizes.

Known analog: a distributed content-addressed typed object store. Lost: computation, reactive evaluation, handlers, operations — the evaluator and everything it provides.

Heavy pairs lost: 5 (EX, IX, TX, MX, XP) — tied with T for maximum among removals.

7.6. Without Peer (E+I+T+M+X)

The full system on a single machine. No distribution, no capabilities, no connection, no multi-agent coordination. Still useful — a complete local entity system with computation, self-description, versioning, and audit. But no trust boundaries, no convergence across machines, no delegation.

Known analog: a local entity system (this exists as single-peer mode in the implementations). Lost: distribution, capabilities, trust, multi-agent coordination.

Heavy pairs lost: 2 (TP, XP) plus 1 medium (IP) — minimum among removals, which is why P’s removal leaves a complete local system.

7.7. Summary

Removing any of the first five primitives (E, I, T, M, X) produces a qualitatively different and lesser system. Removing Peer produces a complete local system — useful, but not distributed. This suggests a natural separation: E+I+T+M+X form the computational core; P extends it to distribution.

The remove-one test also reveals that M and X are deeply interdependent. Without M, the evaluator (X) can still dispatch and compute, and could reconstruct state-crossing behavior through handler operations — but loses the structural guarantee of atomicity. Without X, emit (M) can still change state, but nothing reads, processes, or acts on the changes. Each can partially compensate for the other’s absence, but each contributes something the other cannot fully reconstruct: M contributes the atomic state crossing as a structural guarantee; X contributes the evaluator that actualizes what the state crossings make possible. They are, in a sense, two facets of temporality — M is the mechanism of change, X is the mechanism that gives change computational structure.

P is always physically present. Every running system operates on a device, in a process, with a position and perspective. A system with no peer modeling does not lack a peer — it lacks peer awareness. The device is a peer in the physical sense; the partial levels (described below) measure how much the system recognizes this fact.

8. Partial Primitives

Systems do not simply “have” or “lack” a primitive. Each primitive has internal structure that can be implemented to varying degrees. The gradients below are not formal decompositions — other segmentations are possible, and companion papers develop more detailed analyses (see Dimensional Completeness; Convergent Evolution). We present them here as an exploratory tool: a shorthand vocabulary for describing where systems sit along each primitive’s spectrum, which we use throughout this paper and the extended series.

Entity (E): E0 (raw bytes) $\to$ E1 (hardcoded type tags) $\to$ E2 (integer/string kinds) $\to$ E3 (external schemas) $\to$ Full E (types as first-class entities)

Identity (I): I0 (no identity) $\to$ I1 (assigned identity) $\to$ Full I (content-derived hash)

Tree (T): T0 (flat keys) $\to$ T1 (single-level paths) $\to$ T2 (hierarchical paths) $\to$ Full T (path $\to$ hash with two address spaces)

Emit (M): M0 (no state crossing) $\to$ M1 (non-atomic writes) $\to$ M2 (atomic, no events) $\to$ Full M (atomic Store + Bind with independently observable events on each axis)

Execution (X): X0 (fixed evaluators) $\to$ X1 (fixed verbs, fixed paths) $\to$ X2 (fixed verbs, open paths) $\to$ X3 (open dispatch, no registration) $\to$ Full X (typed open dispatch with handler registration)

Peer (P): P0 (no peer awareness) $\to$ P1 (client/server) $\to$ P2 (authenticated endpoints) $\to$ P3 (symmetric peers) $\to$ P4 (role-based access) $\to$ Full P (entity-native capabilities)

The most consequential transitions appear to be:

• X0 $\to$ X2: tool to platform. HTTP crossed this threshold; Git did not.
• E2 $\to$ Full E: types as first-class data. We have not found a widely-deployed system that has crossed this independently.
• I1 $\to$ Full I: assigned to content-derived identity. This reverses the identity model — identity becomes intrinsic rather than assigned.
• P3 $\to$ Full P: symmetric peers to capability-bearing peers. This appears to require E+I+T as substrate for the capability tokens.

Partial levels predict properties. A system with E1 can store typed data but cannot self-describe. A system with X2 can dispatch to any path but cannot discover handlers. A system with P3 has symmetric peers but no trust management. Full dimensional analysis of primitive substructure is developed in Dimensional Completeness; full landscape application with partial scoring in Convergent Evolution.

9. Where Known Systems Stop

Existing systems implement subsets of the six primitives. The gaps correspond to properties they lack. We organize the landscape by primitive count.

The systems named in this section are anchor cases — those we found most informative for the structural argument, each chosen because it stabilizes at a recognizable point in the primitive space. Each mapping is an analyst-interpreted scoring of the system at a particular point in time; primitive levels and partial forms are documented judgments rather than automated measurements of running code. A broader survey — the named anchors plus additional infrastructure, databases, federated protocols, and editor tooling — informs the patterns described here: the landscape figure below plots thirty-four entity-arrangement systems, drawn from a full cross-corpus analysis of roughly fifty manifestations developed in Convergent Evolution. We keep the treatment here narrative and refer to the named anchors only where they sharpen a structural claim.

9.1. Two-Primitive Systems

Git (I+T, with E1, X0, P3): Content-addressed tree. Hardcoded types (blob, tree, commit, tag), fixed evaluators (hash, merge, pack, diff), symmetric remotes. Git became a platform for content-addressed state management (GitOps, CI/CD, infrastructure-as-code) — evidence that even two full primitives with partial forms of the others create significant value.

IPFS (I+T, with E1, P3): Content-addressed distribution. Codec-tagged blocks (E1 — type tags, but not structural types), peer-to-peer distribution. Compared to Git, IPFS trades fixed evaluators for broader content distribution. Neither has structural types or dispatch.

gRPC (E+X, with E3, P1): Typed dispatch with external schemas via .proto files and client/server topology. No content addressing, no namespace. A typed RPC platform.

Plan 9 (T+X, with X2, P1–P2): Namespace with dispatch — “everything is a file.” Read/write/walk over an open namespace. Untyped bytes, no content addressing.

9.2. Three-Primitive Systems

Nix store (I+T+X, with E1–E2, X0): Content-addressed namespace with fixed evaluators. Domain-specific derivation types, build/hash/store operations. Domain-locked to builds, like Git is domain-locked to version control.

Datomic (E+T+M, with I1, P1): Typed namespace with state events. Assigned entity IDs (not content-derived), client/server. Rich query and temporal model, but no content addressing.

9.3. High-Primitive Systems

These are the systems closest to the entity system, each reaching three to four primitives. Each is instructive because each stops at a different point and for different reasons.

AT Protocol (E+I+T+P, with P4): Content-addressed typed data across peers. Per-user Merkle Search Trees. Federation with moderation. But no dispatch — computation happens in application code, not in the protocol. No atomic emit. This is the closest structural match we have found. Notably, all of AT Protocol’s gaps appear to be additive rather than requiring destructive changes to existing architecture.

Nostr (E+I+X+P, with E2, X3, T0, P3): Content-addressed signed events with integer kinds. NIP-90 provides ad-hoc dispatch. Flat — no tree, no structural types, no handler registration. Nostr independently arrived at {type: kind, data: content} with content-addressing, a convergence worth noting.

Holochain (E+I+X+P, with P4): Closest overall by dimensional count. But DNA determinism locks application logic at deploy time, and types are defined in Rust rather than as protocol-level data. The security model (“trust the code” — all peers must run identical validation) is architecturally incompatible with capability-based authorization.

Urbit (T+X+P, with P4): Closest in vision — a personal computing environment built on a typed namespace. Independently discovered {type, data} (vases). But no content addressing — the seed crystal that triggers structural cascading in other systems is absent. The Nock/Hoon language layer creates a significant barrier to architectural evolution.

9.4. Summary Table

9.5. Attractor Compositions

Most systems stabilize at two to three full primitives, with partial forms of one or two more. The four closest systems each reach three to four primitives. No system we have examined implements five or more.

Systems appear to stabilize at what we call attractor compositions — natural resting points where the current primitive set is sufficient for the domain:

• Content-addressed VCS: I+T+E1+X0 (Git — a platform for state management)
• Typed RPC: E3+X+P1 (gRPC — a platform for typed dispatch)
• REST-like dispatch: X2+T1+P1 (HTTP — a platform for open dispatch)
• File-as-interface: T+X2 (Plan 9 — a platform for namespace)

The modern technology stack integrates these partial-primitive platforms: Git manages state (I+T), HTTP handles dispatch (X2), Kafka handles events (partial M), PostgreSQL handles typed data (E+T+M). The integration layer — CI/CD pipelines, REST APIs, webhooks, service meshes — wires them together. This integration work is, in a sense, the cost of not having the primitives unified: each platform covers its slice, and the gaps between slices are filled by infrastructure.

The four attractor compositions named here are illustrative anchors — the platforms whose stabilization point is sharpest. The broader corpus survey surfaces additional structural regions (content-infrastructure tooling, consensus-KV substrates, peer-federation messaging, editor-and-knowledge tooling, relational-server DBMS, and a commercial-SaaS region, among others) where multiple systems cluster around shared primitive-level signatures. These regions are inductive centroids of the surveyed corpus rather than canonical categories; the full inventory is developed in Convergent Evolution and the underlying structural methodology, which generalizes the per-domain analysis applied here, is developed in A Structural Methodology for Information System Domains.

10. The Reduction

The system did not begin as architecture. It began as the distributed-substrate piece of an earlier entity-centric tool whose local entity model needed cross-peer coherence. The realization that this required a protocol, not just a refactor, was the leap into the architectural work; everything since has been alternating construction and reduction over the substrate that leap produced. The structural foundation revealed itself through that alternation.

10.1. Architectural Methodology

The methodology is a construct-and-reduce cycle guided by a small set of design values that hold at the system level:

• Simplicity — every primitive must justify its presence; a mechanism that another already covers does not stay.
• Convergence as the stopping rule — construction stops introducing new mechanisms and reduction stops removing them.
• Math where it reaches; considered convention where it does not — the spec follows the math where structure is mathematically determined (content addressing, deterministic encoding, hash-derived identity, the dispatch primitive) and records the convention elsewhere.
• The substrate settles so layers above it can — extensions, application architecture, and user-space rest on the converged substrate; if it kept shifting, they could not stabilise.

The cycle that assembled the protocol — its structurally significant named moves (the substrate leap, the relay insight, the wire reduction, the capability invariant), the representative reductions, and the cost-asymmetry argument that drove pre-release intensity — is developed in The Entity Core Protocol §The Reduction.

10.2. The Pattern

The reductive passes have a consistent shape: removals are structural (a mechanism is replaced by the entity model) and additions are types (the type system grows to cover what the mechanism previously did). The protocol shrank while the type system grew.

This is what we would expect from reduction toward a single substrate. If the entity model is expressive enough, mechanisms that were once separate can be expressed as typed data within the model. This pattern — structural removal, typed addition — is what other papers in this corpus refer to when they describe the system as having a small protocol surface and a large type-level evolution space (see The Entity Core Protocol; The Universal Computational Genome; Convergent Evolution).

11. The Extension Architecture

The extension architecture provides evidence that the six primitives compose well — that a broad range of distributed system concerns can be expressed through them without modification.

11.1. How Extensions Work

An extension registers a handler at a system/* path, defines its types, and optionally consumes emit events. It uses the same EXECUTE dispatch, the same capabilities, the same tree. There is no separate extension API.

This means extensions are not a separate mechanism. They are handler registrations that follow the same protocol as any other handler. The distinction between “core” and “extension” is a matter of which handlers are defined in the specification versus which are registered at runtime.

In pair-relationship terms, each extension is an actualizer: it pushes a specific pair-bundle — some subset of the 15 pair-relationships — from latent structural potential into fully expressive behavior. A subscription extension actualizes MX and XP (reactive cross-peer dispatch). A compute extension actualizes MX, IX, and TX (reactive dispatch with convergence). A history extension actualizes IM, TM, and TX (observing both emit events and dispatching queries over the log).

11.2. The System-Extension Layer

The system-extension layer above the core protocol is itself stratified. The architecture team’s working classification distinguishes a substrate-bridge tier (core extensions that bridge substrate primitives to application-architecture surface), an operational tier (extensions that any deployed multi-peer system needs but that do not contribute structural bridge edges), and exploratory and first-pass-grounding tiers (extensions held loosely or kept as reference designs).

The substrate-bridge extensions the architecture ships are:

Each is a structural actualizer in the sense developed above: each pushes a specific pair-bundle from latent potential into expressive behavior. The set is empirically what a peer needs to host the canonical application-architecture concerns; the broader analysis of how these extensions map to a twelve-primitive application-architecture surface is developed in Application Architecture.

Beyond these substrate-bridge extensions, the system distinguishes three further extension categories that any deployed system encounters but that play different structural roles:

• Operational extensions — identity management (peers, controllers, K-of-N quorums, certs, rotation), peer attestation, role-based authority, group membership, network connectivity, peer discovery, and (gap-flagged) relay routing. These provide the operational semantics needed to run a deployed multi-peer system. They do not contribute substrate-to-application bridge edges in the structural sense above; they sit alongside the substrate-bridge extensions as a separate concern.
• First-pass-grounding extensions — currently system/transaction, a draft that frames multi-binding atomic writes with an observation boundary. Held loosely; anti-fragmentation work, not yet load-bearing for the substrate argument.
• Exploratory extensions — currently system/durability, marked optional and not actively developed, preserved as a reference design after a scope-overreach retraction.

11.3. Composability as Evidence

That the substrate-bridge extensions all compose through the same six primitives without modifying the core protocol suggests something about the primitive set.

The framework provides a sharper explanation: extensions compose because their pair-bundles are mostly orthogonal. When two extensions actualize disjoint pair-bundles, they do not interfere. When pair-bundles overlap, coordination becomes necessary — and this is what the SYSTEM-COMPOSITION layer specifies, particularly at the two over-subscribed triangles (ITM, where history, query, and revision all observe emit events; TMX, where compute, subscription, and clock all exercise reactive dispatch) and at the XP boundary (where inbox, continuation, network, and subscription all cross peer connections).

When extension design violates orthogonality, the spec process catches it. The clearest example is the retraction of the durability extension: an apparatus that pattern-matched on log-system conventions without a concrete deployment driver was lifted out of the normative spec and preserved as an exploratory reference. This orthogonality discipline — and the willingness to retract — is an active structural property of the system, not a passive design claim.

11.4. Four Document Layers

The extension architecture occupies a specific position in the spec architecture:

• Core protocol — the primitive substrate, the specification of the $K_6$ graph with its 11 heavy pair-relationships.
• SYSTEM-COMPOSITION — coordination rules for how multiple extensions interact over shared pair-surfaces (consumer ordering, cascade depth, convergence classes).
• Extensions — individual actualizers, each specified as its own document.
• Guides — composition patterns that combine multiple existing actualizers without adding new structure. (Each guide can be formalized into a reusable SDK function once the pattern is common.)

Features route to the appropriate layer: a new pair-bundle → extension; a coordination rule for shared surfaces → SYSTEM-COMPOSITION; a composition of existing actualizers → guide. This four-layer structure is where ergonomics lives — the primitives are universal but minimal; extensions provide common capabilities; guides and SDK helpers provide the practical developer experience.

We note composability as suggestive rather than conclusive. It is possible that the extensions simply have not yet reached the boundary of what the primitives can express. But across the substrate-bridge extension set spanning a broad range of distributed system concerns, the primitive set has been sufficient, and the orthogonality discipline that keeps extensions from cross-cutting has been empirically enforceable.

12. Implementation and Evaluation

12.1. Three Implementations

• Go — hosts validate-peer, the cross-implementation validation harness; the other two run against it. Go’s tooling discipline keeps the reference behavior clean.
• Python — at parity on the conformance surface; an independent stack reading the same spec, useful at surfacing ambiguities the other two would miss.
• Rust — at parity on the conformance surface; targets performance and portability.

The three implementations are not independent attempts at the same target — they are the operational loop through which the specification itself is refined: the spec is the language-agnostic invariant, the implementations are its validators, and divergence between them is feedback to the spec. The full development methodology — the loop’s stages, why three implementations rather than two, why this is faster rather than slower, what it requires of the spec, and what it does not claim — is developed in The Entity Core Protocol §The Development Loop.

12.2. No Privileged Language

If the substrate is what we claim — a structure that information takes, rather than a design someone chose — then no language should be privileged in expressing it. The six primitives say nothing about runtimes, memory models, or type disciplines, so a peer ought to be writable in any of them.

This is testable, and it has been tested more aggressively than three implementations can test it. A generator derives a complete core peer from the specification for a target language, and the resulting peers are run as a cohort against the same conformance gate. The cohort spans dozens of languages and deliberately includes substrates with nothing in common: garbage-collected and manually managed, compiled and interpreted, a stack machine, an array language, an image-based system. They reach the same bytes.

The caveat matters as much as the result, and it points the other way from the enthusiasm: generated peers share a generation lineage, so they are not independent implementations and must never be summed with the three bespoke ones into a single count. What the cohort shows is that the specification is precise enough to be realized mechanically across substrates that share no idiom — evidence about the specification’s precision, not about independent discovery. The independent evidence is the three implementations; the cohort evidence is the absence of a language wall. They are different claims and this paper keeps them apart. The Entity Core Protocol develops both.

The relevance here is what it says about the substrate rather than about the tooling. A system whose realization depends on a particular language has, somewhere in it, a commitment that is the language’s rather than the structure’s. Nothing in the primitives has yet turned out to be such a commitment — which is weak evidence for the discovery framing, and worth stating as weak.

12.3. Normative Algorithms

Five normative algorithms are specified precisely enough that all implementations must produce identical results:

1. Content hash: SHA-256 of ECF-encoded {type, data}
2. Signature: Ed25519 sign/verify
3. Peer ID derivation: hash of public key with type prefixes
4. ECF encoding: deterministic CBOR subset ensuring identical bytes
5. URI normalization: canonical path representation

12.4. Cross-Implementation Validation

Same entity $\to$ same hash in Go, Python, and Rust. Same delegation chain $\to$ same accept/reject decision. The normative algorithms are unambiguous — implementations either agree or one has a bug.

12.5. Stability Under Evolution

The wire format has remained stable throughout the protocol’s evolution. Entity structure has remained unchanged. The two-message model has remained unchanged. What has changed: type definitions, handler conventions, and capability fields. The protocol is the primitives; the type system is extensible within them.

This stability is consistent with the reduction narrative. If the protocol were over-specified, evolution would require breaking changes. If it were under-specified, evolution would require additions. The pattern of type-system growth within a stable protocol structure suggests the primitives are at an appropriate level of abstraction.

12.6. Limitations of Current Evaluation

• No production-scale deployment data
• Performance measurements not yet systematic
• Formal verification (e.g., TLA+ model checking) has not been attempted

13. Discussion

13.1. Irreducibility vs. Minimality

Irreducibility — the property that no primitive can be removed without losing the system — is not the same as minimality — the property that no simpler equivalent exists. We present evidence for irreducibility through the reduction history and the remove-one analysis. We do not claim minimality in a formal sense.

A different decomposition into six different primitives might exist. The claim is narrower: these six resist further reduction, and the combinatorial analysis shows what each contributes. Whether a formal proof of irreducibility can be constructed is an open question.

13.2. The 3+2+1 Structure

The division into informational (E, I, T), temporal (M, X), and spatial (P) primitives is not merely a classification. It explains the dependency structure and suggests something about the nature of the primitives.

The informational primitives exist as pure structure. A complete E+I+T tree could, in principle, contain every structure and every relationship — it is a static, timeless space of typed, addressable, content-verified data. Self-description holds as a structural fact within it.

The temporal primitives introduce change and agency. They operate on the informational structure but do not create it. Emit introduces time (before/after). Execution introduces directed action.

The spatial primitive introduces position and perspective. Every running system operates somewhere, on some device, with some view of the network. P measures how much of this physical reality the system models.

Each domain transition adds something that the previous domain lacked. Whether this three-domain structure is a deep property of information systems or an artifact of this particular decomposition is a question we leave open.

13.3. Information Before Computation

The observation that E+I+T precedes E+I+T+M+X in the build-up — that information structure exists before computation — is worth examining.

Content-addressed entities exist independently of the processes that create or consume them. An entity’s identity is derived from its content, not from when or how it was produced. The structural truths of E+I+T — self-description, the fixed point, verifiable references — hold without any computation being performed.

This goes further than the familiar observation that data exists before programs act on it. Computation itself, viewed as a mathematical structure — a mapping from inputs to outputs — is information. Such a mapping is a set of (input, output) pairs, a mathematical object rather than a process. In E+I+T, every such mapping could in principle exist as structure. A pure function is a lookup in an (infinite) table.

Computation-as-activity — the temporal process of evaluating a function — exists because the complete table is infinite. We must construct specific entries on demand, and this construction requires time (M) and agency (X).

The purity boundary in the protocol makes this structural: hash references point to content that exists eternally (by content address), while path references point to state that depends on when you look. This distinction arises from content addressing, not from language design.

This observation is explored further in The Entity Church Architecture and Information as Substrate.

13.4. Identity as the Architectural Divide

The choice of how identity is derived is the fundamental architectural axis separating distributed information systems into two qualitatively different camps. The choice has only two stable settings: identity is assigned (a sequence number, UUID, surrogate key, or other externally-issued token) or identity is content-derived (a hash of the entity’s bytes or canonical form).

The database tradition — relational stores, document stores, key-value stores — almost universally selects assigned identity. Rows have keys issued by the system; documents have IDs assigned by the application; records have surrogate primary keys. The identity-assignment authority is internal to the system. Two databases storing the same content produce different identities; the same database can replace a row’s content while preserving its identity.

The content-addressed tradition — Git, IPFS, the entity system — selects content-derived identity. The same bytes produce the same identity, everywhere, always; different bytes produce a different identity, always. There is no identity-assignment authority; identity is a fact about content. Replacing a row’s content produces a different entity, with a different identity; the original is unchanged because it cannot be changed.

This choice is architectural rather than incremental. It cannot be made gradually or partially: a system either commits to content-derived identity and accepts the consequences (immutability, deduplication, verifiability, cross-peer agreement, the cascade catalogued in Convergent Evolution), or it commits to assigned identity and accepts the opposite consequences (mutable rows in place, external deduplication, authority-bound verification, assignment coordination as the path to cross-system agreement). Hybrid designs that assign identity for some entities and derive identity for others exist (most object stores do this), but the database’s mutable-rows-with-assigned-keys is a deliberate structural commitment, not an oversight.

The remove-one analysis (§Without Identity above) catalogs the technical losses when content-derived identity is removed: deduplication, verification, convergence detection, immutability, cryptographic audit. The architectural reading is that these are not five independent properties that happen to all depend on content-derived identity — they are the characteristic consequences of one design choice. The entity system’s identity is structurally constitutive: every primitive downstream of I (Tree binding, Emit, Execution dispatch, Peer trust) inherits assumptions that hold because identity is content-derived. A system that adopts assigned identity is making the opposite commitment everywhere it propagates.

This does not mean content-derived identity is “better.” Assigned identity has real benefits — the data-management tradition is one of the most successful in computing precisely because assigned identity supports mutable rows, denormalization, indexed scans over external fields, and human-readable keys. The architectural-divide claim is only that the choice is binary at the substrate level and reshapes everything above it; mixing the two requires a bridge (the integration layer between an object store and a relational database, for example) that is itself non-trivial design. The companion paper Convergent Evolution catalogs sixteen prominent systems sitting one move off the entity-system substrate, all on the Identity axis specifically — the data-management tradition arriving at this boundary by deliberate design.

13.5. Universal Substrate

A consequence of covering all six primitives: the entity system functions as an intermediate representation across multiple dimensions simultaneously.

The pattern: the six primitives define a boundary. Everything inside the boundary — typed data, content-addressed, in the tree — inherits all architectural properties: versioning, identity, self-description, audit, convergence, authorization. Everything outside — handler internals, native code — is opaque. The boundary is the EXECUTE interface: typed parameters in, typed result out, capability verified, emit pathway available.

Systems with fewer primitives have narrower boundaries. Git (I+T) bridges content-addressed data but not typed dispatch. gRPC (E+X) bridges typed operations but not content-addressed state. The full six defines a boundary broad enough for everything to cross it.

Whether this is a designed feature or a structural consequence of covering the full primitive space is itself an interesting question. We lean toward the latter — it appears to follow from the primitives rather than from intentional engineering — but this is an observation, not a proof.

13.6. Substrate Floor, Feature Space Above

The six primitives are the substrate of the entity system: the floor a participating peer cannot get below without losing the system. They are not the feature space a developer or application designer works within. The application-architecture level — where one would inventory features, build applications, or compare what two deployments can do — sits above the substrate, populated by extensions.

The extension architecture described earlier is what populates that feature space. The substrate-bridge extensions add reactive computation, version coordination with peer sync, subscriptions, durable workflow, queries, content distribution, transition history, time, and value-level type constraints by registering handlers, types, and emit consumers without modifying the core protocol. An application configures which extensions it relies on (substrate-bridge plus the operational extensions it needs for its deployment), which handlers it installs, and which types it exchanges; another application carrying a different selection looks different at the feature level while sharing the same substrate.

This distinction matters for reading the irreducibility argument correctly. Remove-one is a substrate claim: removing any one of the six leaves a substrate that cannot host the rest. It is not a feature-completeness claim. A working application’s effective feature set is the substrate plus the specific extensions it carries. The six primitives constrain what is possible above them; they do not exhaust it. Conflating the substrate with the feature space — treating six primitives as either over-claimed maximality or under-claimed scaffolding — misreads what each level is doing.

13.7. Particular Instantiation and Interoperability

An important clarification: the $K_6$ pair-relationship graph is a mathematical object, and our core protocol is our particular specification of it. The graph is universal (any distributed information system must contain it); the specification includes specific concrete choices — Ed25519 for signatures, SHA-256 for content hashes, a CBOR subset for deterministic encoding, a specific connection handshake, a specific capability-token structure. These are not additional primitives but instantiations: any implementation could in principle choose differently and satisfy the same structural claims, but two implementations that make different concrete choices would not be interoperable.

This distinction matters for what the framework claims. Mathematical structural coherence — the fact that a system reduces to the six primitives and their pair-relationships — is analytically valuable. It explains why properties emerge, where engineering concentrates, and what changes have large blast radius. It is not, however, a free interoperability mechanism. Two systems that both reduce to the same $K_6$ are not thereby able to exchange entities; they may differ on hash function, encoding, signature scheme, or connection protocol. Interoperability emerges from agreement on concrete choices, not from shared mathematical structure. The Go, Python, and Rust implementations of the entity system interoperate because they conform to identical concrete choices, not because they share a reduction.

This is why the core protocol specification is not minimal. Pure minimalism — “six primitives, agree on a hash function and encoding and signing algorithm, done” — would be unimplementable. The specification includes structural requirements (what the primitives are and how they depend on each other), structural instantiation (the specific concrete choices that make the primitives usable), and some operational conventions (common vocabulary for system handlers and type definitions). All three kinds of content live in the core; the distinction between them is pedagogical and useful for spec work but does not mean “instantiation” or “convention” content could be moved outside without loss.

13.8. Self-Bootstrap and Transferable Functionality

The core protocol exhibits a self-bootstrapping property common to universal substrate designs: the mechanism for acquiring new functionality is itself built from the same primitives that define the core. Handlers are entities at tree paths; installing a handler is ordinary emit (Store the entity, Bind the path); dispatching to a new handler is an ordinary tree walk. Nothing in the extension-acquisition mechanism sits outside the primitive substrate.

This puts the entity system in a family of self-bootstrapping architectures: Lisp is self-extensible because macros and eval make code first-class data; DNA is self-replicating because the replication machinery is encoded in DNA; the metacircular evaluator (Abelson and Sussman 1985) implements a Lisp interpreter in Lisp. In each case, the substrate is sufficient to describe its own evolution mechanism. The entity system’s core protocol is sufficient to describe its own extension mechanism.

A practical consequence: the native platform code required to participate in the system is small. A peer needs to natively implement the bootstrap evaluator (for entity-native computation), primitive I/O operations (read/write, send/receive), and a minimum set of spec-fixed natives (one hash function, one canonical encoding). Estimated at a few hundred lines of platform code per language. Everything else — type definitions, handler implementations expressed as computation, extension logic, domain code — is structurally expressible as entity-native computation and therefore transferable between peers as data. Entity-native computation is Turing-complete, so any computable function (including hash functions, validators, encoders, and domain handlers) can in principle be received as data and evaluated locally, with JIT compilation bridging the performance gap.

This does not mean everything is in practice transferred over the wire: current implementations ship many functions natively for performance. But the structural claim is significant: the entity system is a small native bootstrap plus an arbitrarily large transferable genome of entities and entity-native expressions. The peer-to-peer exchange of extensions and domain code is thus not a bolted-on feature but a direct consequence of the substrate’s design.

The Transferability Classification

The native-bootstrap-plus-transferable-genome split divides system content into four structural classes. Companion papers reference these as the transferability classification:

• Class N (platform-native). Code that each peer must implement natively for the architecture it runs on: the bootstrap evaluator, primitive I/O, OS interfaces. Not transferable between peers with different native architectures. Approximately a few hundred lines per language.
• Class S (spec-fixed natives). Standardized algorithms each peer implements identically per platform: the hash function, the canonical encoding, the signature scheme. Implemented natively for performance but specified to produce identical outputs everywhere. The interoperability surface.
• Class T (transferable data). Everything expressible as entity-native data and computation: type definitions, handler implementations expressed as compute expressions, capability tokens, extension logic, domain content. Transferable between any two peers that agree on the evaluator specification.
• Class B (bridge). The compute extension’s evaluator is the structurally privileged native implementation that makes Class T transferability work. Each peer needs a native Class B implementation; once present, Class T data is executable. Class B sits between Class N (native) and Class T (transferable) and is the structural reason the genome can be exchanged at all.

The classification is descriptive, not normative: where a given function sits on the gradient depends on implementation choices. The Class N / Class B footprint is small by design; the Class T surface is intended to be the bulk of system content. The classification appears in The Entity Church Architecture (computational substrate), The Entity Machine Boundary (the compilation gradient as the path from Class T to Class N), The Universal Computational Genome (the biological analog: ribosome plays the Class B role), DEOS (peer-deployment implications), and Information as Substrate (the philosophical reading).

13.9. Language Agnosticism

A related and distinctive property: the entity system is language-agnostic at the host level. The protocol defines wire format (CBOR-encoded entities), dispatch semantics (EXECUTE in, typed result out), and capability mechanics — all as data, not as code in any particular language. Handlers sit on the far side of the EXECUTE boundary; their internals are opaque to the protocol. A handler can be written in Go, Rust, Python, or any language whose runtime can process entity-typed parameters and return entity-typed results.

This distinguishes the entity system from designs that embed themselves in a specific language or language ecosystem. Lisp defines itself in Lisp. Urbit defines applications in Hoon over Nock. Holochain expresses validation logic as Rust embedded in DNA. Erlang/OTP is an Erlang runtime; the BEAM VM is Erlang-specific. Even the JVM, which hosts multiple source languages, requires JVM bytecode at its core. In each case, participation in the system requires adopting the system’s language substrate.

The entity system’s host-level language agnosticism comes from three structural features combined:

• Protocol is data. Entities are CBOR-encoded; handlers receive typed parameters, not function calls in a specific language.
• Handlers are opaque. The protocol sees only the EXECUTE surface — the interface — not the code behind it.
• Transferable computation is expression data. When computation is expressed as entity-native expressions (the compute extension’s bootstrap types), any peer implementing the agreed evaluator produces identical results.

The three implementations (Go, Python, Rust) exist because nothing in the protocol requires them to share a runtime. Each is an independent native bootstrap; they interoperate because they conform to identical concrete choices (hash function, encoding, signature scheme), not because they share infrastructure. The SDK layer provides language-idiomatic ergonomics per language (builders in Rust, functional options in Go, context managers in Python) over the same underlying protocol operations.

A qualification: the agnosticism is at the host level, not at the computational-substrate level. Entity-native computation — the bootstrap expression types (lambda, apply, if, let, lookup, literal) and their reduction semantics — is itself a particular design choice. It happens to be a lambda-calculus-shaped substrate; other designs (tree calculus, combinator calculus, a different set of primitive forms) could fill the same structural role. Two peers that both implement the core protocol but choose different evaluator designs would share wire format and dispatch but not share transferable computation. The transferable genome is transferable only to peers that agree on the evaluator’s specification, just as the core protocol is interoperable only between peers that agree on hash function and encoding.

In framework terms, the evaluator’s bootstrap-type design is another category (b) structural instantiation: a concrete choice made to realize a structural role (in this case, “a universal computational substrate over content-addressed data”). It is no more universal than SHA-256 is the only hash function; it is the specific evaluator we have settled on. What is universal is the structural role — any distributed information system with all six primitives must settle some universal evaluator to have a transferable computational layer. Our choice is one workable settlement.

Language agnosticism is therefore a practical consequence of the transferability claim given agreed concrete choices: if two peers agree on the core protocol’s instantiation (category b) and on the evaluator’s design, then the genome is transferable between them regardless of host language. The entity system does not have a “native host language” because it does not need one. It does have a “native computational substrate” because computation across peers requires a shared evaluator. Both these commitments — concrete protocol choices and a specific evaluator — make interoperability possible; neither is structurally forced by the six primitives.

13.10. Limitations

Several limitations should be noted:

• No formal verification. The irreducibility analysis is structural and combinatorial, not a mathematical proof. TLA+ model checking or other formal methods are natural next steps.
• No production-scale evaluation. The implementations validate correctness but have not been tested at scale.
• Streaming data. Content addressing requires fixed content for hashing. Continuous streams require discretization into entities — a genuine tension that the current framework does not fully resolve.
• Combinatorial analysis is empirical. The build-up sequence and remove-one test are systematic but not exhaustive. There are $2^6 = 64$ subsets; we examine the build-up path and six removal cases.
• Landscape claims rest on analyst-interpreted scoring. The mapping of existing systems onto the six primitives and their partial levels is documented judgment, not automated measurement. The cross-corpus survey informs the pattern claims here, but the named anchor cases are illustrative rather than statistical evidence. Corpus expansion would refine specific cluster boundaries without altering the structural decomposition; the full landscape application is developed in Convergent Evolution and the underlying structural methodology in A Structural Methodology for Information System Domains.
• Generated under prompt-and-review. This paper, like the rest of the corpus, the supporting implementations, and the architectural specifications, is LLM-generated under direction from the author. The author provides prompts, evaluates outputs, redirects, and approves — the text, code, and design refinements are generated rather than directly authored. This shapes the methodology described in The Entity Core Protocol (particularly the patience for refactoring and the multi-implementation tempo it makes tractable) and is a real factor readers should weigh when evaluating the work.

14. Conclusion

We have described six primitives for distributed information systems — Entity, Identity, Tree, Emit, Execution, and Peer — and examined what properties emerge as they compose.

The build-up sequence reveals a progression:

Existing systems map to subsets of two to four primitives. The gaps correspond to properties they lack. We have not found a system that implements five or more.

The protocol was found by alternating construction and reduction: each cycle built mechanisms to handle the next concern, then removed what the entity model could absorb. The substrate revealed itself when further reduction stopped finding anything to remove.

The substrate-bridge system extensions compose through the same six primitives, covering messaging, reactive computation, version coordination with peer sync, subscriptions, durable workflow, queries, content, history, time, and value-level type constraints. Operational, first-pass-grounding, and exploratory extension tiers sit alongside them at distinct structural roles. No extension required modifying the core.

Several questions remain open:

• Can a primitive be removed without losing the system? Our remove-one analysis says no, but a more creative restructuring might find a way.
• Can a seventh primitive be shown to be independently necessary? We have not found one, but absence of evidence is not evidence of absence.
• Can the irreducibility be formally proved? The structural analysis is suggestive but not a proof.
• What are the performance characteristics at scale? The implementations validate correctness but have not been stress-tested.

Companion papers examine the protocol specification (see The Entity Core Protocol), the computational architecture (see The Entity Church Architecture), and the convergent evolution of existing systems toward these primitives (see Convergent Evolution).

Convergent Evolution of Information Systems on Content-Addressed Typed Data

1. Introduction

Independent distributed information systems keep building fragments of the same structure. Git builds content-addressed trees. IPFS builds content-addressed distribution. gRPC builds typed dispatch. Plan 9 builds namespace-as-interface. Nostr builds content-addressed signed events. AT Protocol builds content-addressed typed repositories. Holochain builds agent-centric validated state. Urbit builds a typed personal server. Each solves its problem and stops.

The fragments are not random. A companion paper identifies six primitives for distributed information systems — Entity (E), Identity (I), Tree (T), Emit (M), Execution (X), and Peer (P) — together with fifteen pair-relationships between them and five structural triangles (EIT self-description, ITM emit, TMX reactive dispatch, IXP cryptographic capability, TXP distributed dispatch) that recur across the system as structural units (see The Entity System). Properties emerge at specific compositions: self-description at the EIT triangle, mutability through the ITM triangle, computation when TMX activates, distribution at all six primitives with the IXP and TXP triangles complete.

This paper applies the primitive-and-pair-relationship framework to the landscape. We score fifteen systems along two axes: which primitives they implement and to what partial level (coarse), and which pair-relationships their implementations activate into full expressiveness (fine). The two axes together produce a richer picture than either alone: two systems at the same primitive count can have very different pair-coverage profiles, and the pair-coverage profile is what actually determines which emergent properties the system supports.

The analysis produces several findings: a taxonomy of stopping points (walls versus fences, grounded in whether a system is positioned on the dependency-coherent ridge of the lattice), three forces that explain why no system reaches all six, a theory of attractor states that explains clustering at specific pair-coverage configurations, and a layering trap that explains why systems add partial primitives without gaining the emergent properties associated with their full pair-bundles.

The pattern is not convergent evolution — systems moving toward the same design. It is incomplete reduction: every system encounters fragments of a structure that is in the information itself, but each stops excavating when its immediate problem is solved. The entity system reached the full structure by alternating construction and reduction: building mechanisms to face each next concern, then removing what the entity model could absorb. Its pair-coverage is the unique complete case in our survey.

1.1. A note on corpus and method

The analysis here is interpretive, not statistical. The three system counts in this paper nest: fifteen anchor systems carry the per-system structural argument and appear in the landscape table below; a figure widens the view to thirty-four systems spanning four chain levels; and the cluster patterns draw on the full corpus of roughly fifty manifestations. Anchors $\subset$ figure $\subset$ corpus — the same nesting (see The Entity System) uses for its named examples. We score roughly fifty manifestations across the six primitives and their bridges. Each manifestation is an analyst-authored interpretation of a system at a particular point in time — the primitive levels and pair-coverage values are documented judgments, not measured properties of the running code. The corpus is also deliberately constructed: we selected systems we judged most informative for the structural-pattern argument, weighted toward back-end distributed-systems infrastructure. A broader sample of end-user software, embedded systems, or proprietary platforms would shift specific cluster boundaries.

We have built analytical tooling around this corpus — per-primitive heatmaps, pairwise structural similarity, multi-scope decomposition, and cluster-centroid topology — and we cite specific cluster patterns where they illustrate or sharpen a structural argument. These should be read as illustrative quantitative supplements to the structural claims, not as independent statistical evidence. With ~50 carefully-positioned manifestations the boundaries we surface are real but not definitive; corpus expansion would refine them. The framework’s primary contribution is the structural decomposition itself; the patterns that recur across this sample support the argument without standing on their own as a numerical finding.

2. The Primitive Combinatorial Space

2.1. Six Primitives as Analytical Basis

The companion paper The Entity System identifies six primitives: Entity ({type, data}), Identity (content-derived hash), Tree (path $\to$ hash), Emit (atomic state crossing), Execution (typed dispatch), and Peer (identity, capabilities, connection). These divide into three domains — informational (E, I, T), temporal (M, X), and spatial (P) — with a dependency structure: E $\to$ I $\to$ T, T $\to$ M, T $\to$ X, and Full P requires E+I+T for capability tokens.

We use these primitives as an analytical lens. Any information system can be decomposed into which of the six it implements and to what degree.

2.2. Partial Primitive Levels

Systems do not simply “have” or “lack” a primitive. Each has internal structure that can be implemented to varying degrees (see The Entity System). The internal-dimension decomposition we use here (§“Internal Substructure” below, with three to four dimensions per primitive) is what the structural methodology of A Structural Methodology for Information System Domains calls Layer 3 (internal partial levels of a primitive); the per-primitive partial levels enumerated in this section are positions in that internal-dimension space:

Entity (E): E0 (raw bytes) $\to$ E1 (hardcoded type tags) $\to$ E2 (integer/string kinds) $\to$ E3 (external schemas) $\to$ Full E (types as first-class entities, self-describing)

Identity (I): I0 (no identity) $\to$ I1 (assigned identity) $\to$ Full I (content-derived hash of complete {type, data})

Tree (T): T0 (flat keys) $\to$ T1 (single-level paths) $\to$ T2 (hierarchical paths) $\to$ Full T (path $\to$ hash with content-addressed bindings)

Emit (M): M0 (no state crossing) $\to$ M1 (non-atomic writes) $\to$ M2 (atomic without event) $\to$ Full M (atomic store + bind + event)

Execution (X): X0 (fixed evaluators) $\to$ X1 (fixed verbs, fixed paths) $\to$ X2 (fixed verbs, open paths) $\to$ X3 (open dispatch, no registration) $\to$ Full X (typed open dispatch with handler registration)

Peer (P): P0 (no peer awareness) $\to$ P1 (client/server) $\to$ P2 (authenticated endpoints) $\to$ P3 (symmetric peers) $\to$ P4 (role-based access) $\to$ Full P (entity-native capabilities)

These levels predict properties. A system with E1 can store typed data but cannot self-describe. A system with X2 can dispatch to any path but cannot discover handlers. A system with P3 has symmetric peers but no trust management.

2.3. Coverage Properties

Fourteen system-level properties emerge from specific primitive compositions:

These properties are not independent of the primitives — they are what the primitives produce when they compose. A system’s coverage is predicted by which primitives it implements, at what level, and which pair-relationships its implementation activates. This is the analytical core: decompose a system into its primitive levels, identify which pair-relationships are in regime 3 (fully expressive), and the coverage properties follow.

Three composition thresholds mark qualitative transitions:

• Information threshold (E+I+T): self-description, fixed-point types
• Temporal threshold (E+T+M+X): reactive computation, versioning actualized
• Spatial threshold (+P): distribution, capabilities, trust boundaries

2.4. Pair-Coverage as a Second Analytical Axis

Primitive count is a coarse metric. Two systems at the same primitive count can have very different coverage profiles, because the 15 pair-relationships between primitives (see The Entity System) carry the structural load, not the primitives individually. Tracking which pair-relationships a system has in regime 3 gives a sharper score than counting primitives.

Heavy pair-coverage across sample systems:

Several patterns emerge from this scoring:

• HTTP’s structural shape is the TXP triangle at minimum strength. Three pairs, all weak, forming a coherent triangle. This explains why HTTP is universally used despite being structurally minimal: it occupies a complete small triangle, enough to be useful for many applications.
• Git’s value is concentrated in one triangle (EIT). The three informational pairs fully active; everything else absent. Git does one thing structurally well.
• gRPC is concentrated in one pair (EX). The typed-dispatch pair at full strength; nothing else. This matches the single-purpose RPC framework shape.
• AT Protocol covers the entire EITP cluster — five pairs fully active. No other system (except the entity system) achieves this.
• Holochain’s missing T-cluster is visible in pair-coverage: none of IT, ET, TM, TX, TP are active. This is the structural reason T is Holochain’s most serious gap, beyond “it doesn’t have a tree.”
• Urbit covers the TXP triangle plus ET but lacks EI entirely. This is the seed crystal gap (absence of content addressing) visible at pair level.

The pair-coverage view makes these gaps precise. A system with “E+I+X+P” primitive-count description hides whether it covers the IXP capability triangle (Holochain does, substantially) or the EIT self-description triangle (Holochain does partially through Rust types, but not as EIT in the entity-system sense). Pair-coverage disambiguates what “has E” or “has X” actually means in terms of structural capabilities.

2.5. The Coherent Sub-Lattice and the Ridge

Among the $2^6 = 64$ binary subsets of primitives, exactly 9 satisfy all dependency constraints strictly (see The Entity System). These form a sub-lattice: $\emptyset$, E, EI, EIT, EITM, EITX, EITMX, EITXP, EITMXP. Real-world systems can be positioned relative to this sub-lattice:

• On-ridge systems implement primitives in a pattern that satisfies dependencies (e.g., EITP is a strict-coherent quad). Moves toward fuller configurations are additive.
• Off-ridge systems violate at least one dependency (e.g., a system with Full M but partial T, or with P but weak I). Moves toward fuller configurations require undoing commitments before adding.

AT Protocol is the only non-entity-system we have identified that sits at a strict-coherent quad (EITP). This is the structural reason why all AT Protocol’s gaps are additive (Section 6 below) — every primitive it lacks (M, X, and full P) can be added without violating any existing dependency.

Off-ridge systems pay what we call the integration tax: they use external mechanisms to compensate for missing or incoherent primitives. gRPC uses .proto files (external schemas) to substitute for structural types-as-data. IPFS uses IPNS (external naming) to substitute for a tree with mutation. Holochain uses DNA + compiled Rust to substitute for typed-data-in-tree. Each external mechanism is real engineering effort that the system must maintain alongside the primitive substrate. Summed across the ecosystem, the integration tax is the cost of being off-ridge.

3. Internal Substructure

Each primitive has internal dimensions that measure how thoroughly it is implemented. The total count across all six primitives is nineteen internal dimensions. These are the Layer 3 partial-level axes per A Structural Methodology for Information System Domains’s four-layer framework; Dimensional Completeness uses the same count when grounding type and capability surface primitives back into the substrate.

3.1. Entity: Three Dimensions

1. Type expressiveness — how rich the type language is (bits $\to$ records $\to$ structural types $\to$ self-describing types)
2. Type modifiability — whether types can change at runtime (hardcoded $\to$ schema migration $\to$ live evolution)
3. Type-data coupling — how tightly types bind to data (external schema $\to$ tagged union $\to$ intrinsic {type, data})

The partial E levels are positions in this three-dimensional space. E0 (raw bytes) is minimal on all three. E3 (external schemas) has high expressiveness but external coupling. Full E maximizes all three.

3.2. Identity: Two Dimensions

1. Derivation scope — what is hashed (nothing $\to$ some fields $\to$ complete {type, data})
2. Verification universality — who can verify (no one $\to$ issuing authority $\to$ anyone, anywhere, offline)

Full I hashes the complete entity and is verifiable by anyone. This is why content-derived identity is “intrinsic” — it requires nothing external to verify.

3.3. Tree: Three Dimensions

1. Path depth — flat $\to$ single-level $\to$ hierarchical $\to$ recursive
2. Binding type — name $\to$ pointer $\to$ hash-based binding (two address spaces)
3. Namespace scope — fixed $\to$ configurable $\to$ composable (mount points)

Plan 9 achieved depth and scope but not hash-based bindings. Git achieved depth and bindings but fixed namespace scope.

3.4. Emit: Three Dimensions

1. Atomicity — non-atomic $\to$ atomic write $\to$ atomic store + bind + event
2. Scope — single field $\to$ single entity $\to$ subtree
3. Observability — silent $\to$ polling $\to$ typed event with provenance

3.5. Execution: Four Dimensions

1. Dispatch openness — fixed operations $\to$ fixed verbs + open paths $\to$ typed open dispatch
2. Handler registration — none $\to$ configuration $\to$ entity-level (handlers as entities in the tree)
3. Evaluation model — none $\to$ fixed evaluator $\to$ self-describing evaluator
4. Composition — none $\to$ pipeline $\to$ recursive (handlers triggering handlers via emission)

The X0 $\to$ X2 transition primarily advances dispatch openness. The X2 $\to$ Full X transition advances the other three dimensions.

3.6. Peer: Four Dimensions

1. Symmetry — asymmetric (client/server) $\to$ symmetric $\to$ role-flexible
2. Identity model — anonymous $\to$ authenticated $\to$ entity-identity (peer IS an entity)
3. Trust model — all-or-nothing $\to$ role-based $\to$ attenuatable capabilities as entities
4. Connection model — point-to-point $\to$ hub-and-spoke $\to$ protocol-defined topology

Full P requires E+I+T because capabilities must be typed (E), content-addressed (I), and stored in the tree (T) to be verifiable and attenuatable. This is why P sits at the top of the dependency structure — not because peers are complex, but because peer trust requires the full information stack.

Later primitives have more internal dimensions because they can vary along axes defined by earlier ones. P’s trust model dimension exists only because E+I+T exists. X’s handler registration dimension exists only because T exists. Later primitives inherit dimensional axes from earlier ones.

4. Phase Transitions and Thresholds

Not all transitions between partial levels are equal. Some are incremental (adding a feature); others are phase transitions that qualitatively change what the system can do.

4.1. Tier 1: Phase Transitions

X0 $\to$ X2: Fixed evaluators to open dispatch. The most consequential partial-primitive transition in computing history. Below X2, operations are finite and known at compile time. At X2, the operation set is open-ended — any computation can be expressed as POST-to-a-path. HTTP crossed this threshold and became the universal dispatch platform. Git did not; it remained a platform for what its other primitives (I+T) provide: content-addressed state management. The transition determines whether a system becomes a platform for dispatch (HTTP) or for its data primitives (Git). Both are platforms. The difference is which primitives they are a platform for.

E2 $\to$ Full E: Integer kinds to types-as-entities. The “types-as-data activation energy.” Below this threshold, types are metadata about the system. Above it, types are data within the system — hashable, addressable, modifiable, self-describing. This enables the fixed-point structure (system/type describes system/type) and makes the system extensible without code changes. No widely-deployed system has crossed this threshold independently. External schemas (E3) feel “good enough” — Protobuf, JSON Schema, GraphQL all work. The payoff (self-description, convergent types, types-that-cross-the-wire) only manifests past the threshold.

I1 $\to$ Full I: Assigned identity to content-derived identity. Reverses the arrow of identity. In assigned-identity systems, data is created and then assigned an ID. In content-derived identity, the data IS its identity. Deduplication becomes automatic, verification universal, convergence detectable, audit cryptographic. Assigned identity requires a central authority or coordination protocol to ensure uniqueness. Content-derived identity is authority-free.

4.2. Tier 2: Significant Transitions

P1 $\to$ P3: Client/server to symmetric peers. Breaks the asymmetry assumption. Git, BitTorrent, and Nostr crossed this threshold. HTTP did not, and has spent decades building workarounds (CDNs, WebSocket, WebRTC).

P3 $\to$ Full P: Symmetric peers to capability-bearing peers. Adds trust management to peer symmetry. Without this, symmetric systems face “everyone or no one” — either all peers can do everything (BitTorrent) or authorization is out-of-band (SSH keys for Git remotes). Full P depends structurally on E+I+T.

T0 $\to$ T2: Flat keys to hierarchical paths. Adds organizational structure. Flat key-value stores can store anything but cannot organize it. Nostr is the clearest case: everything is flat events, so organization must be imposed by convention (NIP-defined event kinds, tags-as-structure). The community repeatedly hits the ceiling of flat namespace.

5. Attractor States

Systems do not distribute randomly across the primitive space. They cluster at natural resting points — compositions that solve a domain’s core challenge and resist movement toward higher compositions.

Applied to the broader corpus, the same pattern surfaces at a finer grain. Cluster analysis over the ~50-system sample produces roughly eight recurring structural regions: the content-addressed VCS group (git, mercurial, jujutsu), the OS-substrate group (Linux/POSIX, Plan 9, Inferno), the peer-federation-messaging group (bitcoin, matrix, nostr, scuttlebutt, holochain), the relational-server-DBMS pair (mysql, postgres), the consensus-KV / distributed-data-store group (etcd, consul, zookeeper, couchdb, plus mongodb and cassandra under expanded sampling), the editor-and-knowledge-tools group (vscode, claude-code, obsidian), a commercial SaaS region (slack, discord, figma, github, instagram, notion), and a broad content-infrastructure region (at-protocol, ipfs, docker, kubernetes, nix, wikipedia, erlang-otp). These are inductive centroids of the present corpus rather than canonical categories; their boundaries shift modestly as the corpus grows, but the regions themselves recur across method and signature choices. They concretize the qualitative attractor framing above with named members rather than competing with it.

Each attractor becomes a platform for its primitive composition. Git is a platform for I+T: GitOps, CI/CD, infrastructure-as-code, security audit trails. HTTP is a platform for X2: universal dispatch. Kafka is a platform for partial M: event streaming. PostgreSQL is a platform for E+T+M: typed mutable state. Each covers its slice. The modern technology stack is an integration of these partial-primitive platforms wired together by CI/CD pipelines, REST APIs, webhooks, and service meshes.

Why attractors are stable:

1. The current composition works and becomes infrastructure that other systems depend on
2. The next threshold is expensive — adding Full E, Full I, or Full P requires restructuring
3. Layering is easier than integrating
4. The ecosystem wires platforms together rather than integrating primitives

Inferno sat at the file-as-interface attractor for thirty years (1996–2026). Plan 9 before it. Both achieved Full T + X2, both provided namespace-as-interface, and neither crossed to the next basin. Content addressing (the seed crystal) was within reach — Plan 9’s Venti archive was content-addressed — but it was treated as an archival tool, not a foundational primitive.

5.1. The Layering Trap

When a system at an attractor needs capabilities from a higher composition, it layers partial primitives on top rather than integrating them:

• HTTP needs types $\to$ JSON Schema (layered E3)
• HTTP needs content addressing $\to$ ETags, Content-MD5 (layered partial I)
• HTTP needs state $\to$ Cookies, sessions (layered partial M)
• HTTP needs peer symmetry $\to$ WebSocket, WebRTC (layered partial P3)

Each layer adds the symptom of the missing primitive without integrating the structure. JSON Schema gives external types (E3) but not types-as-entities (Full E). ETags give partial content addressing but not content-derived identity (Full I). Cookies give partial state but not atomic state crossing (Full M). The layers are individually correct but do not compose as cleanly as integrated primitives.

The layering trap applies at ecosystem scale. The modern stack layers Git (state) + HTTP (dispatch) + Kafka (events) + PostgreSQL (typed data) + Kubernetes (namespace + auth). The integration layer between them — service meshes, API contracts, CI/CD pipelines, data sync — is the cost of not having the primitives unified.

Is HTTP asymptotically approaching the full primitive set through thirty years of layering? The evidence suggests not. Layered primitives cannot produce the emergent properties — self-description, convergence detection, versioning-by-construction — that require structural integration. HTTP crossed X0 $\to$ X2 once and jumped from document retrieval to universal platform. No system at an attractor has crossed E2 $\to$ Full E.

6. The Landscape: Where Systems Stop

6.1. Two-Primitive Systems

Git (Full I + Full T, with E1, X0, P3): Content-addressed tree with hardcoded types (blob, tree, commit, tag), fixed evaluators (hash, merge, pack, diff), and symmetric remotes. Git became a platform for content-addressed state management — evidence that even two full primitives with partial forms of others create significant value. Stuck at the content-addressed VCS attractor.

IPFS (Full I, with E1, P3): Content-addressed distribution. Codec-tagged blocks but not structural types. Peer-to-peer but no trust management. No namespace, no dispatch, no state changes. Stuck at the content-addressed store / distributed data attractor.

gRPC (E3 + Full X, with P1): Typed dispatch with external schemas (.proto files) and client/server topology (gRPC Authors 2015). No content addressing, no namespace. Stuck at the typed RPC attractor.

Plan 9 (Full T + X2, with P1–P2): Namespace with dispatch — “everything is a file” (Pike et al. 1990). Untyped bytes, no content addressing. Stuck at the file-as-interface attractor.

HTTP (X2 + T1 + P1): The accidental universal dispatch protocol. POST plus path routing provides enough X to build anything. But locked into client/server asymmetry, no types, no content addressing. Stuck at the REST-like dispatch attractor, layering everything else on top.

6.2. Three-Primitive Systems

Nix store (Full I + Full T, with E1–E2, X0): Content-addressed namespace with fixed evaluators (Dolstra et al. 2004). Domain-specific derivation types, build/hash/store operations. Content-addressed VCS attractor specialized for builds.

Datomic (Full E + Full T + Full M, with I1, P1): Typed namespace with state events (Hickey 2012). Assigned entity IDs (not content-derived), client/server. Rich query and temporal model, but no content addressing and no dispatch.

Inferno (Full T + X2, with P1–P2): Plan 9’s successor (Dorward et al. 1997). Everything is a file; any Limbo program can be a file server. Fourteen Styx message types map to two entity operations (GET and EXECUTE). Same single-abstraction commitment, different starting point. Three of fourteen coverage properties (namespace, user-space servers, peer management). The other eleven require the missing primitives: Identity, Entity, and Emit.

6.3. The Pattern

Most systems stabilize at two to three full primitives with partial forms of one or two more. Coverage gaps correspond precisely to missing or partial primitives. The following table summarizes the landscape:

A note about the “—” rows in the attractor column: across the broader corpus, systems like Datomic, Kafka, Memcached, MongoDB, Redis, Smalltalk, SMTP/email, SQLite, Spreadsheets, and Urbit do not co-cluster strongly with any other system at strict similarity thresholds. Within the small-corpus framing this is sometimes read as evidence of a distinct attractor, but at our sample size it is more honestly described as sparse-sampling: each occupies a structurally coherent region whose other occupants have not been included in the corpus. Adding a structural twin invariably resolves the apparent isolation — adding Valkey (a Redis fork) places it at maximum-similarity to Redis; adding Cassandra brings MongoDB into a broader replicated-data cluster; adding XMPP brings SMTP into a federated-protocol pair; adding a word-processor brings Spreadsheets into a broader interactive-content cluster. We treat these “no attractor listed” rows as boundary cases of the present corpus rather than as evidence for unique structural classes.

6.4. The Composite: What the Standard Stack Leaves Out

The preceding sections describe where individual systems stop. The complementary question is constructive: what does the standard software stack reach when its components are composed, and what remains? Consider the canonical web application: an HTTP transport, a relational store (Postgres), a versioned object store (Git), and a general-purpose language (Smalltalk as the corpus exemplar — a language is the Execution primitive made concrete, X5). Composing these under the natural capability-union rule (each primitive at the maximum partial level any component supplies) yields:

The composite reaches the full set on Entity, Identity, and Execution for free: object structure, hash identity, and computation fall out of composing parts the ecosystem already provides. The residual is exactly Tree +2, Emit +2, Peer +4.

That residual is not an abstract gap — it is the integration code hand-written in every web application. The Tree shortfall is the structural impedance mismatch between URL paths, the in-memory object graph, and the relational schema: the router, the object-relational mapper, the serializer. The Emit shortfall is the reactive wiring: cache invalidation, job queues, change notification, websocket fan-out. The Peer shortfall is the distribution layer: replication, load balancing, deployment, and synchronization. None of the composed systems supplies this glue; each application rebuilds it, and the rebuild is where most accidental complexity accumulates.

The glue is therefore the structurally interesting object, and it is precisely what the full primitive set internalizes. The gap between “the standard stack bolted together” and the full set is the same Tree/Emit/Peer deficit catalogued for individual systems in the preceding tables — here arrived at constructively rather than by elimination. Stated as a falsifiable claim: a system that provides Tree, Emit, and Peer as native primitives should absorb the integration glue the composed stack externalizes, leaving no per-application counterpart. A web application whose router, object-relational mapping, reactive propagation, or replication is not expressible as Tree, Emit, and Peer structure would refute that.

7. High-Primitive Systems

Four systems reach three to four primitives. Each stops at a different boundary and for different reasons. These are the systems that test the primitive framework at its limits.

7.1. Holochain: E+I+X+P — Closest Overall by Primitive Count, Fragmented in Pair-Coverage

Holochain shares the entity system’s agent-centric architecture: content-addressed DHT, typed entries, capability tokens, no global consensus, immutable entries with mutable links (Brock and Harris-Braun 2018). By dimensional count (four primitives), it is the closest existing system. By pair-coverage, the picture is more nuanced.

Holochain’s active pairs are EI, IX, EX, IP, XP: it has content-addressed entries (EI), convergence-via-hash (IX), typed dispatch (EX), content-addressed peer ID (IP), and cross-peer dispatch (XP). Its inactive pairs are the entire T-cluster: IT, ET, TM, TX, TP are all null. Holochain’s DHT is not a tree; there is no path-to-hash binding space, no hierarchical namespace, no tree-walk dispatch, no peer-scoped path hierarchy. The missing T-cluster — five heavy pairs — is the precise structural content of what the primitive-count view flattens into “no T.”

This framing makes the seven engineering walls precise:

1. DNA = network identity = frozen types. New entry types require a new DNA, a new network. This is the absence of ET — types cannot live at tree paths because there is no tree.
2. Entries are not self-describing. Entry type is an integer index into a Rust enum compiled into WASM. EI is active but not Full E; the EIT triangle is incomplete.
3. The DHT is a shared global space, not a per-agent namespace. The missing TP pair: no peer-scoped path structure.
4. Links are metadata, not content. Mutable operations outside the content-addressed store. Partial TM without the IT substrate.
5. Capability tokens are per-function, non-delegatable, secret-based. IXP is partial: IX and XP active, but the capability-as-entity structure is undercut because Full E and structural Ts are absent.
6. No subscription mechanism. The MX pair is null; reactive cascade is not available.
7. Coordinator zomes are hot-swappable; integrity zomes are not. Partial Full X — open dispatch is limited to a subset of the handler surface.

Commitments 1 and 3 are the load-bearing walls: they block activation of the entire T-cluster (five heavy pairs). Activating them would require redesigning DNA-as-network, which is Holochain’s core architectural invariant. These are pair-dependency violations, not missing features. T’s dependencies (T requires I; TP requires I+P) are not violated by Holochain — it has I and P. But Holochain’s existing commitments to DNA-determinism-as-validation prevent adding T without undoing those commitments. The pair-coverage framework makes this visible: Holochain sits off-ridge because activating T-cluster pairs requires first deconstructing existing architecture.

The security philosophies diverge structurally. Holochain trusts the code (everyone runs identical validation, so results must converge by replay); the entity system trusts the identity (capability tokens prove authorization, validated via the IXP triangle). Moving from one to the other is not incremental because the two philosophies ground in different pair-bundles: Holochain’s validation-by-replay exercises IX + EX but not the full IXP capability triangle; the entity system’s capability model needs Full I + Full X + full XP and all three active together.

What Holochain proves: agent-centric architecture works at scale; developers build tree structures on top of its flat DHT, confirming hierarchical namespace as a recurring need even when the substrate provides no T-cluster pairs; hot-swappable coordinators validate the need for dynamic handler installation (partial Full X); fine-grained capability is useful even when limited to the sub-triangle Holochain can reach.

7.2. Urbit: T+X+P — Closest in Vision, Missing the Seed Crystal

Urbit independently discovered seven structural parallels to the entity system (Yarvin et al. 2016):

1. Vases = {type, data}. Literally [type noun] in Hoon. Independently discovered from runtime metaprogramming needs.
2. Watch/fact = subscription. Gall’s %watch/%fact/%kick maps almost exactly onto entity subscription.
3. Poke = EXECUTE. Sends a cage ([mark vase]) to a named target.
4. Clay = typed revision-controlled tree. Stores typed data at paths with revision history and per-type diff/patch/merge.
5. Scry = content-addressed reads. Immutable referentially transparent namespace.
6. Ducts = chain_id. Tracks causal chains, as entity system’s chain_id + parent_chain_id does.
7. Marks = types + handlers. Type validation, conversion, revision control.

Urbit was designed from scratch, by different people, at different times, with different motivations, and still arrives at {type, data} as the universal atom, path-based typed dispatch, pub/sub on typed paths, typed revision control, and deterministic event processing. The seven independent convergences are the strongest evidence that the architecture is structural — not designed but inherent in the problem.

Urbit’s active pairs are ET, TX, TP, XP (plus partial aspects of MX via Gall subscriptions). Its missing pair is the one that activates the entire content-addressed cascade: EI. Urbit has vases ({type, data}), so E is present; it has identity in the namespace-position sense; but it does not have content-derived identity. Without EI, the IT pair cannot activate (T’s value space cannot be I’s hash space if I is not content-derived). Without IT, the IM and TM pairs cannot carry content-addressed temporal semantics. Without IX, convergence detection is unavailable. Without IP, peer identity is not content-addressed.

The missing seed crystal is precisely the EI pair. Urbit stops its structural cascade before EI activates, and every downstream pair that would depend on EI’s content-addressed identity also stays inactive. The “seed crystal” metaphor is literal at the pair level: activating EI triggers the IT, IM, TM, IX, IP cascade that produces the entity system’s distinctive properties. Urbit cannot reach these without backtracking to install content-addressed identity, which in turn requires a type system that can be hashed independently of Hoon’s type nouns.

The language wall makes this backtrack costly. Nock is designed for deterministic, complete replay. Urbit’s type is a Hoon type noun, meaningful only to the Hoon compiler. Language-independent types would mean abandoning Hoon’s type system as the universal type description mechanism — the same way Holochain’s wall is abandoning DNA-determinism. In pair-coverage terms, Urbit’s wall is at EI: activating EI requires a type system whose hash is stable across implementations, which Hoon’s nouns are not.

What Urbit proves: {type, data} is independently discoverable (strongest single convergence proof for E); the personal server vision is architecturally coherent at the TXP triangle; deterministic event replay is production-possible; vision alignment at the T, X, P level does not guarantee structural convergence when the EI seed crystal is absent.

7.3. Nostr: E+I+X(partial)+P — Simplest at High Primitive Count, Fragmented Pair-Coverage

Nostr’s event model is {type: kind, data: content} with content-derived identity (fiatjaf 2021):

{
  id:         SHA-256(serialized([0, pubkey, created_at, kind, tags, content]))
  pubkey:     secp256k1 public key
  kind:       integer (0-65535)
  tags:       [[string, ...], ...]
  content:    string
  sig:        Schnorr signature
}

Nostr has reinvented the entity’s core structure. The event ID is a content hash (partial EI — the kind-as-integer limits E’s expressiveness). The public key is the peer identity, content-addressed (IP active). NIP-90 (Data Vending Machines) reserves kind ranges for job requests and results — structurally parallel to EXECUTE/EXECUTE_RESPONSE but ad-hoc (partial EX, unstandardized).

Nostr’s active pairs are partial EI, partial IX, IP, partial EX, XP (all at varying strength). Its inactive pairs are the entire T-cluster (IT, ET, TM, TX, TP all null) and MX. The missing T-cluster is structural: Nostr has no tree, so no pair involving T can activate. The missing MX is a consequence: without a tree for subscription patterns to live in, reactive cascade has no substrate.

The gaps are technically addressable — adding structural types would complete EI, adding a tree would activate the T-cluster, adding handler registration would complete EX. But the protocol is released with users and implementations. NIP proliferation shows the E2 ceiling in practice: the integer kind space requires external coordination because there is no EI structural identity to anchor types, and people build hierarchy in tags (a partial-T workaround) because the T primitive itself is absent. This is a textbook layering trap: symptoms of missing T-cluster pair-coverage are addressed by ad-hoc conventions on top of the existing primitives, which then become a commitment that future T-cluster work would have to displace.

What Nostr proves: partial EI plus IP plus XP is a natural convergence point (content addressing with cryptographic peer identity, independently discovered); extreme simplicity is achievable and valuable at this pair-coverage profile; social convergence friction with released protocols is real even when changes are technically additive, because each ad-hoc tag convention and NIP kind assignment becomes a concrete-choice commitment that coordinates implementations.

7.4. AT Protocol: E+I+T+P — Closest Structural Match

AT Protocol is the closest structural match to the entity system we have found (Kleppmann et al. 2024). Per-user Merkle Search Trees, content addressing via CIDs, Lexicons as a schema system, DID-based identity portability, CBOR encoding throughout, signed commits — the structural parallels are extensive.

AT Protocol is the only non-entity-system we have identified at a strict-coherent configuration. Its primitive coverage (E+I+T+P) is exactly the EITP strict-coherent quad in the dependency sub-lattice. All 11 heavy pairs it covers (EI, IT, ET, IP, TP) are active in regime 3 or near it. This is the structural precondition for gap-fences over gap-walls: a system that sits on the coherent ridge can move toward fuller configurations through additive extension, because its existing primitives already satisfy the dependencies that future primitives will need.

The unique finding is a gap-by-gap analysis of what separates AT Protocol from the full primitive set:

• Gap 1 (fixed two-segment paths $\to$ arbitrary depth): Fence — MST key format is byte arrays; structure is convention, not data structure.
• Gap 2 (one repo per user $\to$ universal tree): Fence — tall, but additive. Three options exist, all feasible within the MST.
• Gap 3 (Lexicons as external schemas $\to$ types as data): Fence — purely additive. Define a com.atproto.lexicon.definition collection and store Lexicon definitions as records in repos. Self-description emerges for free.
• Gap 4 (no handler dispatch $\to$ computation in protocol): Partial wall — XRPC routes by NSID to HTTP endpoints. PDS architecture change required, not full protocol redesign.

AT Protocol is the only analyzed system where all structural gaps are fences. An incremental path to the full primitive set exists. Each step is independently useful. This is the strongest external validation that the six primitives form a reachable target, not an arbitrary bundle. Whether this path is taken is a social and organizational question, not a technical one: millions of accounts, hundreds of PDS implementations, one relay processing the global firehose, and a community identity as “social network builders” that constrains the question space.

7.5. Walls Versus Fences

The four high-primitive systems divide into two categories:

Walls — destructive changes required, must take things apart first:

• Holochain: undo DNA determinism, move types from code to data, add compositional extensions. Each requires deconstructing an existing invariant.
• Urbit: undo the Nock/Hoon commitment before adding content addressing. Types-as-data would break determinism guarantees. Without language-independent types and content addressing, the structural cascade cannot start.

Fences — additive changes, technically feasible without deconstruction:

• Nostr: add structural types, add tree, add handlers. Each is additive, but each step looks like unnecessary complexity from where Nostr stands.
• AT Protocol: move Lexicons into repos, add cross-user namespace, add handler dispatch. Each independently useful.

The distinction is about the nature of changes, not about whether they are hard. Technology attractors, emergent property invisibility, and social convergence friction apply to both walls and fences. The distinction determines whether progression requires rebuilding (walls) or extending (fences).

In pair-coverage terms, walls and fences correspond to on-ridge versus off-ridge positioning. A system on the coherent ridge (AT Protocol, at EITP) has fences: its existing primitives satisfy the dependency preconditions of primitives it lacks, so additional primitives can be layered without disturbance. A system off the coherent ridge (Holochain with missing T; Urbit with missing I) has walls: its existing primitives form an incoherent configuration, so adding missing primitives requires first satisfying the dependencies the existing structure violates. Holochain’s E+I+X+P violates T’s dependency via M and X (both require T); adding T forces revisiting the DNA-determinism architecture. Urbit’s T+X+P violates I’s dependency via T (T requires I); adding I requires abandoning Hoon’s type system as the identity substrate.

This connects to the entity system’s reductive methodology described in The Entity System. The cost asymmetry is stark: adding a pattern before release costs one specification change; adding it after costs a coordinated multi-implementation migration. Pre-release reduction was disciplined by that asymmetry, and what remains was driven to the point where further removals stopped appearing. Evolution happens in the type system, not the protocol.

8. The Seed Crystal and the Wall

Two mechanisms explain the structure of the landscape. One triggers development; the other prevents completion. Both are precise at the pair level.

8.1. The Seed Crystal: The EI Pair

Content addressing is the seed crystal. In pair-relationship terms, the seed crystal is the EI pair activating at Full I — content-derived identity over typed data. This single activation triggers a cascade that forces subsequent pair activations and ultimately reshapes the system toward the full primitive set.

When EI activates, a deterministic cascade follows: data becomes immutable (changing content changes the hash), the mutable/immutable split is forced (names must be separate from content), verification becomes authority-free (anyone can check a hash), deduplication is automatic, and cross-peer agreement becomes trivial (same hash at same path means converged). Each of these is a property of pair-bundles that become reachable once EI is active: IT becomes meaningful (the tree can bind paths to content hashes); IM and TM become necessary (change requires a name-content split); IX becomes available (convergence detection is just hash equality); IP becomes natural (peers can be content-addressed too).

Every system that activates EI develops these properties. Systems that do not — Inferno, Plan 9, Urbit — have the pair as null and the cascade never triggers. Urbit is the strongest evidence: closest in vision, seven independently discovered parallels (Section 5.2), but EI is the one pair it never activates and the cascade never starts. Clay stores data at paths with version numbers, not by content hash. Scry can retrieve a content hash (via %z care) but cannot retrieve by content hash.

Adding content addressing to Inferno — activating EI in a system that already has T, X, and P — triggers a nine-step cascade that restructures the entire system: files become immutable (EI activates), mutable bindings are needed (IT and TM activate), types emerge (Full E required for meaningful hashes), the protocol must carry types (EX activates), connection-scoped auth breaks (IXP capability triangle needs full Full-I). By step five, the entity system has crystallized out — not by design but because each pair activation depends on the previous.

8.2. The Database Family at $+I$: A Second Path to the Same Boundary

An independent computation corroborates the cascade narrative from the opposite direction. Rather than tracing the cascade forward from EI, one can measure, for every system in the corpus, its distance to the coherent sub-lattice — the minimum number of primitive additions that reaches a structurally coherent position. Twenty systems sit off the coherent manifold at the entity-system level. Sixteen of them fail on the same axis: Identity.

The sixteen are almost exactly the data-management tradition — PostgreSQL, MySQL, MongoDB, Redis, Valkey, SQLite — together with general-purpose runtimes and tools. Each has entities, structure, and often execution and distribution, but no content-derived identity; each is one coherent move from the manifold, and that move is always $+I$. Scoring noise would fail on scattered axes; a single shared axis across a recognizable family is structural.

The database paradigm sits one move off this manifold, on the Identity axis specifically, by construction: keys are assigned, not derived from content. This is the boundary the cascade narrative identifies, reached by a different method. It is not a deficiency. Externally-assigned identity has real benefits and the data-management tradition is among the most successful in computing; the off-manifold position is a deliberate, long-validated design choice, and the coherence model describes the entity system’s own structural commitments, not a universal standard against which other systems fall short. The structural claim is only that content-derived identity is the seed crystal for the entity system’s cascade — a different region of value, not a higher one.

The dependency that forces $+I$ is stated explicitly and the coherence model is analyst-authored; the claim is corroboration across two independent methods, not proof, and is open to challenge.

8.3. The Wall: Types-as-Data

No system has crossed E2 $\to$ Full E (types-as-data) without starting from primitives. This is the hardest threshold in the landscape.

A systematic survey across nine systems confirms the pattern:

Four reasons explain why types-as-data is the hard step:

1. It requires self-reference. The meta-type is a fixed point. Engineers find self-reference uncomfortable.
2. It collapses a familiar boundary. Data versus schema is deeply assumed in all software engineering.
3. It has cascading consequences. Dispatch, validation, self-description, and merge all become type-aware.
4. No existing library provides it. Content addressing has libraries (SHA-256, multihash). Peer identity has libraries (Ed25519, libp2p). Types-as-data has no equivalent.

The entity system’s competitive distinction is not cryptographic identity or content addressing — those are commodities. It is types-as-data and the self-description it enables. Content addressing is spreading. Types-as-data is not.

9. Why Systems Stop

Three forces explain why no system independently reaches all six primitives. They apply to all released systems, walls and fences alike.

9.1. Force 1: Technology Attractors as Pair-Strength Equilibria

Proven technologies exist for each missing primitive’s function, and each one occupies a stable pair-strength configuration that resists further activation:

Each adoption stabilizes a system at a specific pair-coverage profile. The stability is maintained by the attractor’s success: the system works at this configuration, so there is no internal pressure to move. Adopt HTTP and the dispatch abstraction lives outside the tree — TX cannot expand because there is no tree substrate for dispatch to walk. Adopt PostgreSQL and types are DDL strings — EI cannot reach Full because the identity is assigned rather than content-derived. Adopt Kafka and async processing is external infrastructure — MX cannot compose with ITM because there is no I-indexed content store and T-indexed tree for M to couple. The attractor trap is that each individually rational choice settles pair-strengths in configurations from which further activation is costly.

9.2. Force 2: Emergent Property Invisibility

The payoff of crossing a threshold only appears past the threshold. Emergent properties are pair-coverage predicates: a property requires specific pairs in regime 3. Below the threshold, the property is not merely weaker — it is absent. Each step toward the full set looks like unnecessary complexity from where you stand: “let’s build our own type system” sounds like more work than importing JSON Schema until the EIT triangle is complete and self-description becomes available; “let’s content-address everything” sounds like overhead until EI activates and the downstream cascade triggers.

This is why reduction discovers what construction does not. Reduction starts with the emergent properties already present (full pair-coverage, all triangles active) and works to preserve them during simplification. Construction starts from a domain problem, solves it with a partial pair-coverage, and never sees the properties that would emerge from the pairs it never activated.

9.3. Force 3: Social Convergence Friction

Released protocols resist change because interoperability depends on agreement on concrete choices, not on mathematical structure (see The Entity System). Every implementation and every deployed use is a coordination cost: changing a category (b) concrete choice (hash function, encoding, capability format) requires coordinating across all implementations simultaneously. Even additive “fence” changes face this friction when each step introduces new concrete choices that implementations must agree on.

AT Protocol faces a versioning paradox: the more decentralized it becomes, the harder coordinated changes become. Nostr faces a cultural ceiling: the community values simplicity above all, and each proposed addition is weighed against that identity — each NIP that proliferates is a concrete-choice commitment that constrains future work.

Social convergence friction applies equally to walls and fences. The distinction between walls and fences is about whether the structure can be moved (are existing primitives blocking new primitive activation?); the friction is about whether the coordination can be achieved (can implementations agree on the new concrete choices?). A system with HTTP as attractor, partial pair-coverage that hides the unified emergent properties, and released with users faces all three forces simultaneously.

9.4. Connection to Reduction

The three forces explain why construction — building from a domain problem — stops at two to three primitives with partial pair-coverage. Each system adopts attractors that stabilize pair-strengths at local equilibria, cannot see the emergent properties that would require more pair-coverage, and releases before reaching the full set, at which point concrete-choice agreement locks in the stopping point. The entity system went the other direction: instead of adopting attractors and gluing them together, it found the reduced structure and built outward from minimum pair-coverage to full pair-coverage. The reduction methodology requires not adopting attractors at each step. Every attractor adopted locks in pair-strength assumptions that prevent discovering the unified pair-coverage.

10. Composition Patterns: The Named Structural Triangles

The combinatorial analysis reveals that primitives cluster naturally. Three-primitive subsets with emergent semantic content recur across the system as recognizable structural units. The companion paper names five such triangles (see The Entity System); four of them match the clusters that appear in the landscape analysis.

10.1. The EIT Triangle: Self-Description (Information Cluster)

E+I+T always appear together in systems that achieve self-description. Entity provides the {type, data} structure (EI active). Identity makes types addressable by hash (IT active). Tree gives types a home at system/type/* (ET active). The fixed-point test — does system/type describe itself? — requires all three pairs in regime 3. Any system where any one of EI, IT, ET is absent fails this test. In the landscape, Git has EI + IT fully active but weak ET (types are hardcoded object types in C, not entities at tree paths); Plan 9 has ET-adjacent and partial T but no EI; both approximate self-description without achieving it.

10.2. The ITM Triangle: Versioning by Construction (Temporal Cluster)

I+T+M form the emit triangle: IT as the static substrate, IM and TM extending I and T into time. Emit and the evaluator are co-dependent in the TMX triangle below, but the ITM triangle exists before computation. Versioning by construction, append-only history, convergence detection — all are consequences of the full ITM triangle. Systems with partial M (Git with periodic commits; Datomic with transaction log) activate parts of the triangle but not the reactive cascade that TMX adds.

10.3. The TMX Triangle: Reactive Dispatch (Temporal Cluster + Execution)

Emit and the evaluator close a loop at the TMX triangle: evaluation produces emissions (M), emissions trigger further evaluation (MX), dispatch routes them (TX), and the loop closes. This is where reactive computation lives. Systems rarely have full TMX; partial forms appear in spreadsheet engines, reactive frameworks, and stream processors, but none over a content-addressed self-describing substrate.

10.4. The IXP Triangle: Cryptographic Capability (Distribution Cluster)

I+X+P form the capability triangle: content-addressed capability tokens (IX), dispatched cross-peer (XP), verified via content-addressed peer identity (IP). Full P requires this triangle. The landscape systems with P4 (role-based access) approximate capability semantics via ACLs or similar — reaching partial IP and partial XP but not the full IXP triangle.

10.5. The TXP Triangle: Distributed Dispatch (Infrastructure Cluster)

T+X+P form the distributed dispatch triangle: tree-walk routing (TX), peer-namespaced paths (TP), cross-peer dispatch (XP). This is the structural shape of REST and HTTP. Most networked systems settle here without activating the information triangle (EIT) or the emit triangle (ITM).

Pattern: each real-world system occupies one or two of these triangles. The entity system is distinguished not by reaching each triangle (individually, others do), but by reaching all five at regime 3 simultaneously. The combinatorial analysis in Section 2 makes this precise: reaching all 11 heavy pairs activates all five named triangles.

11. Reduction Versus Construction

Every analyzed system was built from a domain problem. Git from version control. IPFS from file distribution. Nostr from censorship-resistant messaging. AT Protocol from decentralized social networking. Holochain from agent-centric distributed computing. Urbit from personal computing. Each solved its problem and stopped.

The entity system was found by removing non-essential mechanisms. The relay insight is the clearest example: approximately fourteen message types reduced to one dispatch primitive when it was observed that a relay — a generic forwarder — could handle every message by wrapping it inside a single EXECUTE. The fourteen messages did not disappear; they moved into the extension layer as handler operations. Engineering independently arrives at fourteen; reduction reveals one.

Why construction stops: the domain problem is solved at two to three primitives. No force drives toward the remaining primitives. Mycelium (a typed workflow engine) is the paradigm case: it implements types and dispatch, its problem is solved, and there is no pressure to add content addressing, trees, or peer identity.

Why reduction works: the structure is in the information. Simplification reveals it rather than constructing it. The entity system commits to WHAT (typed entities with content-derived identity in a per-peer tree with handler dispatch) rather than HOW (WASM, Nock, DHT, relay networks). Holochain commits to HOW (WASM + DHT). Urbit commits to HOW (Nock + Hoon). Both made early commitments that create walls. The entity system’s distinction: it committed to data structure rather than execution mechanism.

Two necessary moves that construction misses: types-as-data (E) and tree-as-everything (T). Neither is a natural step from any domain problem. Types-as-data requires collapsing the schema/data boundary. Tree-as-everything requires recognizing that namespace, dispatch table, process table, and security boundary are one structure. Both require reduction — asking “what does information need?” rather than “what technology solves this?”

The attractor trap compounds. Systems built by construction adopt attractors at each step: HTTP for dispatch, SQL for storage, Kafka for messaging, Kubernetes for operations. Each attractor solves one gap but locks in assumptions that prevent seeing the unified structure. Reduction resists attractors by asking a different question.

12. Git to Entity System: A Worked Composition Path

The landscape analysis so far operates at the substrate level: which of the six primitives a system implements, at what partial level, with which pair-coverage. This is the right resolution for the structural argument. It is not the right resolution for a developer asking a practical question: what would it take to extend Git’s substrate position toward the entity system’s feature set? The answer to that question lives one level up, at the application-architecture surface — the feature space the substrate exposes.

This section is a worked example. We position Git and the entity system at the application-architecture surface, enumerate the partial-level moves between them, and observe that the path is purely additive: every move is permitted from a coherent starting point without first undoing any prior choice.

We use the worked example to concretize the “fence” claim from the Walls Versus Fences section. The substrate-level argument showed that AT Protocol is on the coherent ridge and that its substrate gaps are additive. The surface-level computation in this section shows the same for Git’s feature gaps to the entity system: every gap is one or more additive partial-level moves; none requires architectural retraction. The same structural property surfaces in two independent computations at two different levels.

12.1. Setup: The Application-Architecture Surface

The application-architecture surface is the chain level above the entity-to-app-bridge extensions. It has twelve primitives that recur across software applications:

The full analysis of this surface — partial-level decompositions, dependency DAG, pair-load classification, and coherent sub-lattice — lives in the application-architecture domain analysis (see Application Architecture). We use these labels here without re-deriving them; the structural worked example does not require the full primitive treatment. One caveat governs this whole section: unlike the six substrate primitives, which are settled in The Entity System, the application-architecture surface is a still-developing analysis — the primitive set and its partial-level scales are analyst-authored and not yet final in Application Architecture. The worked path below is therefore illustrative: it shows that a coherent additive path exists at the surface level, not that this exact set of moves is the canonical one.

12.2. Git’s Application-Architecture Position

Git’s position at the application-architecture surface, scored against the partial-level scales developed in the source analysis:

$$\text{Git} \quad = \quad \text{D5 Sh2 Ac2 Mt2 Pg0 Ch2 Hs5 Ev0 Pc1 Pn1 Bn1 Au1}$$

Two primitives are at the top of their scales: Data (D5) — Git’s object model treats data as first-class with structural references — and History (Hs5) — the version DAG is the central data structure. Both are content-addressed at the substrate (the I+T pair-coverage from Git’s substrate position E4 I3 T2 M0 X0 P0 is what supports D5 + Hs5 at the surface).

Other primitives sit at lower levels. Git’s Shape is Sh2: object kinds (blob, tree, commit, tag) plus ref naming conventions, but no general schema layer. Access is Ac2: log and diff queries plus direct content addressing, but no query language. Mutation is Mt2: structured commit operations, but no transactional multi-step changes. Coherence is Ch2: merge and conflict-resolution machinery, but not the full multi-axis consistency primitives. Perception and Presentation are at Pc1/Pn1: the CLI is the external interface; no embedded input or output beyond what an external shell provides. Boundary and Authority are at Bn1/Au1: filesystem boundaries and SSH keys; no protocol-level mechanism. Propagation and Evaluation are absent (Pg0, Ev0): Git has no built-in event propagation or in-system computation; hooks are external scripts.

This is a coherent position: every partial level satisfies the dependency DAG of the application-architecture surface. Git is not a fragmentary feature set; it is a complete, internally consistent position at a particular point in the surface space.

12.3. The Entity System’s Application-Architecture Position

The entity system’s position at the same surface, derived from the substrate-bridge extensions and the system-extension catalogue described earlier in this paper:

$$\text{Entity system} \quad = \quad \text{D5 Sh5 Ac5 Mt5 Pg5 Ch4 Hs5 Ev5 Pc4 Pn3 Bn5 Au5}$$

Most primitives are at their maximum partial level. Two are at intermediate levels: Coherence Ch4 — the system has multi-axis coherence (the IM/TM split of emit gives append-only content and mutable bindings; conflict resolution lives in the revision extension), but the full Ch5 partial level (which would require completed multi-peer transactional semantics) is not yet a settled design point. Presentation Pn3 — entity-native rendering and reactive UI bindings exist as patterns, but Pn4 and Pn5 (full media synthesis and adaptive presentation) are not in the current scope of the substrate-bridge extensions.

The remaining ten primitives are at the surface’s full level. D5, Hs5 match Git’s position — the entity system did not have to add Data or History; those were already present at Git. Sh5 (relational shape with content-addressed type entities), Ac5 (full query language plus indexed access), Mt5 (transactional mutation via the revision extension), Pg5 (the subscription extension’s reactive propagation), Ev5 (the compute extension’s reactive evaluation), Bn5 (peer boundaries with capability-scoped exchange), and Au5 (the IXP capability triangle from Entity System Security Architecture) are all additions over Git’s position. Pc4 is the perception layer that the inbox and continuation extensions support.

This is also a coherent position. The dependency DAG of the application-architecture surface is satisfied at every primitive.

12.4. The 34-Move Path

The pair $(\text{Git position}, \text{entity-system position})$ admits a monotone path through the application-architecture lattice. We compute it directly via single-partial-level moves, with each move advancing exactly one primitive by one partial level. The result is a 34-move sequence with three properties worth naming:

1. All 34 moves are additive. Every move is permitted from a coherent starting point without first retreating on any prior primitive. There are zero prerequisite-cross moves (moves that would require lowering some other primitive first), and zero off-manifold steps (intermediate positions that violate the dependency DAG).
2. The ordering admits ${\sim}6.87 \times 10^{27}$ monotone realizations, every one of which is coherent at every intermediate position. The path is not a single line; it is a 34-step corridor, and every traversal is valid.
3. Two primitives require no moves. Git is already at Data D5 and History Hs5. The entity system did not displace these; it extended them through additional primitive coverage.

Grouping the 34 moves by primitive:

The numerical breakdown is what the surface-level dependency DAG produces; the per-primitive role descriptions are short summaries of what the partial-level steps mean in the source analysis.

12.5. What the Computation Shows

Three observations follow from the path structure.

The path is purely additive. Git’s position at the application-architecture surface does not contain any commitments that would have to be undone before adding the missing primitives. The substrate primitives Git activates (E+I+T, with M, X, P at partial levels) are exactly the substrate the entity system also activates; the difference is the extension layer that turns substrate primitives into application-architecture surface primitives. Git stops at the boundary where the standard ecosystem layers other partial-primitive platforms on top (CI/CD pipelines, HTTP APIs, message queues, OAuth flows). The entity system continues past that boundary by activating the bridge extensions that turn substrate primitives into surface primitives directly.

The corridor is wide. A 34-step monotone walk through the surface lattice admits ${\sim}6.87 \times 10^{27}$ orderings, all coherent. This is not a single canonical path; it is a structural space of paths. Any deployment that wished to move through the path could choose its own ordering based on which features matter first, with the guarantee that every intermediate position is coherent and useful. The breadth of the corridor is what “fence” means at the surface level: not a single bridge, but a structural region with many bridges.

The result is a constructive complement to the abstract argument. The substrate-level analysis showed that AT Protocol’s gaps to the full primitive set are additive and that systems off the coherent ridge face walls (Holochain, Urbit). The surface-level computation here shows that Git’s gaps to the entity-system feature set are additive in the same constructive sense. Two independent computations at two different chain levels — substrate (six primitives) and surface (twelve primitives) — recover the same structural property: distance to the entity system from the I+T attractor is structural and walk-shaped, not architectural.

12.6. Caveats

The computation rests on three analyst-authored inputs that should be named.

The partial-level scoring of Git is documented in the unified-manifestations source analysis. Different reasonable judgments could place Git slightly higher or lower on a few primitives (e.g., Sh2 vs Sh3 depending on whether Git’s object kinds count as declared schema). Local reordering of the path is possible under such adjustments; the additive character of the path is robust to small score changes within the coherent region.

The entity-system target position is the architectural intent of the substrate-bridge extension set, not a measurement of a running deployment. The system is implemented across three languages (see The Entity Core Protocol); the partial levels at the surface are what those implementations target. The fact that the path computation has zero prerequisite-cross moves depends on the entity system’s target staying within the coherent sub-lattice it is designed for; if a future revision moved a target primitive below an entity-system-required threshold, the path classification would change.

The application-architecture chain-level partial-level scales are themselves analyst-authored. They could be refined as the corpus grows and as the application-development analysis in Application Architecture matures. We expect the additive-path conclusion to be stable under such refinement: the dependency DAG of the surface places few cross-primitive prerequisites, and Git’s starting position already satisfies the prerequisites that exist.

13. Discussion

13.1. The Pattern

The landscape exhibits a consistent pattern. Systems independently discover fragments of the same structure. The fragments map to specific primitive compositions. Systems stabilize at attractor states that provide “good enough” for their domain. The four closest systems each stop at a different boundary: Holochain at DNA determinism (wall), Urbit at the missing seed crystal and the Nock commitment (wall), Nostr at cultural resistance to complexity (fence), AT Protocol at social and organizational friction (fence).

The mechanism is not convergent evolution in the biological sense — systems moving toward the same phenotype through independent adaptation. It is incomplete reduction: every system encounters fragments of a structure that exists in the nature of information, but each stops excavating when its immediate problem is solved. Addition approaches from above. Subtraction approaches from below. Below is where the compressed structures live.

13.2. The Three Walls

Across all systems, three walls recur. Each is a pair-cluster that the system’s existing commitments block from activating:

1. Types locked in implementation language. Urbit: Hoon type nouns. Holochain: Rust enum indices in WASM. Cap’n Proto: external .capnp files. In pair-coverage terms: EI cannot reach Full because types are not data; the whole EIT triangle stays incomplete; the downstream IT and IM/TM pairs carry weak or no type-aware semantics.
2. No tree-as-everything. Holochain: flat DHT. Urbit: separate Clay, Gall, and scry systems. IPFS: separate specs for different concerns. In pair-coverage terms: the entire T-cluster (IT, ET, TM, TX, TP) is fragmented across incompatible subsystems rather than integrated over a single tree substrate.
3. No compositional extensions. Holochain: DNA monolithism. Urbit: ten fixed kernel vanes. HTTP: headers + status codes + methods interacting ad hoc. Nostr: NIPs accumulating in an uncoordinated space. Without the pair-relationship framework, extensions accumulate cross-cutting interaction surfaces that neither the base protocol nor any specification coordinates. The entity system’s orthogonality discipline — each extension actualizes a specific pair-bundle; overlapping work routes to SYSTEM-COMPOSITION or guide documents (see The Entity System) — is not observed in the surveyed systems. Orthogonality is not automatic; it is maintained by a specification process that audits pair-bundle overlap. What the framework adds is that orthogonality becomes testable: “what pair-bundle does this actualize? does it overlap with existing actualizers?” gives a principled merge decision.

These three walls are the recurring obstacles. They explain why the high-primitive systems — the ones that got closest — each stop at a different point but for structurally similar reasons: each fails to activate a pair-cluster that subsequent emergent properties depend on.

13.3. Connections to Companion Papers

The primitives and build-up sequence are developed in The Entity System. The structural methodology whose vocabulary this paper uses — pair-coverage, coherent sub-lattice, attractors, load-bearing compositions, walls/fences — is developed in A Structural Methodology for Information System Domains; the four-layer framework (substrate primitives → pair-relationships → internal partial levels → surface primitives) organizes the analytical scaffolding. The Layer-4 surface-primitive analysis of two protocol design spaces (type description and authorization) lives in Dimensional Completeness. The Urbit OS-level comparison belongs to DEOS. The Holochain security philosophy comparison belongs to Entity System Security Architecture. The AT Protocol wire format comparison belongs to The Entity Core Protocol. The computational architecture that the evaluator provides belongs to The Entity Church Architecture.

13.4. Continued Analysis as the Corpus Grows

The analytical machinery used here — per-primitive scoring, pairwise structural similarity at multiple chain levels and signatures, and scope-decomposed comparison against named structural regions — is tooling rather than evidence. It enables the same analysis to be repeated as more systems are added, alternative arrangements (biology, methodology, cognition) are scored, and the regions surveyed here are refined. Cluster boundaries we report should be expected to shift modestly with corpus expansion; the structural decomposition itself is the load-bearing claim, and the cluster patterns illustrate rather than prove it. Applying the same recipe to a small biology corpus, for instance, recovers familiar taxonomic groupings (mammals, vascular plants, prokaryotes) from primitive scoring alone — which we read as evidence that the framework is not software-specific, with the same caveats about sample size. An extended biology application via the structural methodology is developed in Abiogenesis as Progressive Hardening; an exploratory physics application in The Structural Methodology Applied to Physics.

13.5. Open Questions

Several questions sit alongside the analysis as standing tests. Each names a finding that would alter the framework if it surfaced; none has so far.

• A system with all six primitives independently derived. The landscape analysis suggests structural reasons no such system has been found, but the question stays open until one is.
• A fifteenth coverage property not explained by the six primitives. The fourteen properties catalogued here all ground in specific primitive compositions. A property requiring structure outside the six would indicate a missing primitive.
• A system that crossed E2 $\to$ Full E without starting from primitives. None has been identified. One would weaken the “types-as-data is a wall” claim.
• An attractor that entity primitives cannot subsume. Each attractor identified here maps to a primitive subset. An attractor requiring structure outside the six would indicate incompleteness.
• Whether layering converges. HTTP has been layering for thirty years. Whether the layered system approaches the full primitive set asymptotically or whether layering is a structural ceiling is a question for empirical observation over time.

14. Conclusion

We have analyzed fifteen distributed information systems through the lens of six primitives, fifteen pair-relationships, and five named structural triangles. The findings are consistent:

Every system implements a primitive subset at measurable levels and activates a specific pair-coverage profile. Coverage gaps are predictable from both primitive composition and pair-coverage. Most systems stabilize at two to three primitives with concentrated pair-coverage in one or two structural triangles.

Four high-primitive systems divide into walls (Holochain, Urbit — existing commitments block pair-clusters) and fences (Nostr, AT Protocol — missing pairs are additive). AT Protocol is the only non-entity-system positioned at a strict-coherent quad of the dependency lattice (EITP), which is the structural reason all its gaps are fences. Others pay the integration tax: IPNS for IPFS, .proto for gRPC, DNA for Holochain — each an external mechanism compensating for off-ridge pair-coverage.

Systems cluster at attractor pair-strength equilibria that provide “good enough” for their domain. When they need capabilities from higher pair-coverage, they layer partial primitives (HTTP’s ETag, cookies, WebSocket) rather than activating the underlying pair-bundle. The layers add symptoms without structure.

Three forces explain why no system independently reaches all six primitives and full pair-coverage: technology attractors hold pair-strengths at local equilibria, emergent properties appear only when specific pair-bundles reach regime 3, and social convergence friction resists the concrete-choice agreement required for released protocols to evolve.

The mechanism is incomplete reduction. Every system encounters fragments of the same pair-relationship structure — a structure that is in the information itself. Each system solves its problem and stops before activating the full pair-coverage. The entity system found the full structure through sustained alternation of construction and reduction — building mechanisms to face each next concern and then removing what the entity model could absorb, repeatedly, until only the primitives and their pair-relationships remained and every pair-bundle could reach full expressiveness without external compensation.

Generated under prompt-and-review. This paper, like the rest of the corpus, the supporting implementations, and the architectural specifications, is LLM-generated under direction from the author. The author provides prompts, evaluates outputs, redirects, and approves — text, code, and design refinements are generated rather than directly authored. The methodology this enables is described in The Entity Core Protocol.

15. References

DEOS: A Distributed Operating System over Content-Addressed Typed Data

1. Introduction

Ask what an operating system is and the usual answer points at hardware: the layer that schedules processes, protects memory, drives the disk and the network card. That answer is not wrong, but it is a frame of reference rather than a definition. Plan 9 took a different frame, organizing the whole system around one coordination abstraction — the file — so that devices, network services, and windows were all named and accessed the same way. By yet another reading, the operating system most people now live inside is the web browser: it is where their documents, their mail, their tools, and their colleagues are, and the machine underneath has become a detail. The question what is an operating system is answered by what you choose to coordinate and how, and the hardware answer is only the lowest of several honest ones.

This paper takes the coordination frame and pushes it one step further than it usually goes. The unit of a conventional operating system is the machine: the thing it manages is one computer’s resources. But a person today is not one computer. They have a laptop, a desktop, a phone, perhaps a home server and a tablet; an organization has fleets of them. The natural unit of coordination is no longer the box but the fleet — all of those peers, run as one coordinated system. That is what we mean by DEOS: The Entity System, viewed as the operating system of all your peers at once. When you have five machines on your home network and they hold one coherent, synchronized, capability-governed body of state that you reach the same way from any of them, the operating system is not any one of the five. It is the abstraction over all of them. That is why it is a distributed operating system, and the distribution is not a feature bolted onto a single-machine OS — it is the point.

The claim is structural, not a metaphor, and the rest of the paper makes it good. An operating system coordinates state, dispatch, processes, events, authorization, and the boundaries between its parts. The entity system’s standard peer — the core protocol plus the substrate-bridge extensions (see Convergent Evolution) — provides each of these, from the same six primitives, in the same typed and content-addressed substrate. The mapping from kernel service to extension is close enough to walk concept by concept, and we do.

The framing matters. The core protocol is a substrate, not a system: as developed in The Entity Core Protocol, the core ships a small set of live hooks — register a handler, dispatch outward, observe the emit pathway, check a capability, connect to a peer — and does not dictate what is layered above them. The extensions DEOS is built from are one coherent set of choices over that substrate, the set the architecture ships; they are not privileged by the core, and a community could compose a different operating system from the same hooks. So DEOS is one operating system the substrate can host — the reference build — not the operating system the substrate is. We keep that line sharp throughout, because it is the difference between describing a design and legislating one. This paper maps a space of possibilities and walks the reference point in it; it does not claim that point is the only one, or the best.

One consequence is worth stating plainly at the start, because it is the strongest version of the idea and the easiest to overstate. Because the substrate can carry computation as well as data, you could, if you chose, do all of your computing inside the entity system and never leave it — your storage, your coordination, your programs, your devices, all entities and dispatch in one operating system. That is an option the substrate makes available, not a mandate and not a description of how anyone runs today. It does not mean abandoning native code: a real deployment still has handlers written in a host language, still has lower-level infrastructure, still drops to the metal where it must. It means the architecture of your computing — the layer you think in — can be the entity operating system and the network of peers you call yours. How far anyone takes that is their choice; the system does not care.

This paper is one of three views of the same substrate, and keeping them apart keeps each one honest. This paper (DEOS) is the operating system you run your own devices on — the coordination, the kernel services, the fleet, the deployment. The developer’s view, building and serving an application on the substrate, is Application Architecture — that paper is the thing you build; this one is the system you build it on. And there is a third view, the subject of The Decentralized Systems Landscape: the entity system at internet scale, as a peer-to-peer and social-convergence substrate — what communities build on it, why sites and shared spaces and version-controlled repositories exist, the sharing and exchange that happen when your fleet connects to other people’s fleets. This paper hands off to that one at the seam where your operating system meets someone else’s. The three overlap — they share peers, compositions, the extension set — but they ask different questions, and DEOS holds the operational one.

1.1. What This Paper Covers

The paper is organized around the operating-system frame and the three moves above:

1. The reference operating system over an extensible substrate. Why the core is a kit and the standard peer is one operating system built from it, and what that buys.
2. The kernel as its own running state. A peer as a live configuration recorded in its own tree; the system that observes and heals itself.
3. The kernel-service mapping. The systematic correspondence between operating-system services and substrate extensions, where it exceeds Unix, where it breaks, and how the services coordinate internally.
4. Cross-peer coordination. What the system actually provides when peers diverge and reconcile — convergence as a primitive, consensus as a configuration — told honestly, including the open problems.
5. The network as transport substrate, the fleet, and the shell. How peers reach each other, how a fleet is run as one operating system across the deployment scales, and the distributed shell that drives it.

1.2. What This Paper Does Not Cover

The six primitives and the build-up sequence are in The Entity System; the protocol wire format, dispatch, and capability mechanics in The Entity Core Protocol; the computational model in The Entity Church Architecture; the compilation gradient and machine boundary in The Entity Machine Boundary; the landscape of existing systems in Convergent Evolution; the application developer’s view of the substrate in Application Architecture; the internet-scale and social-convergence view of the wider field in The Decentralized Systems Landscape; the security architecture in Entity System Security Architecture; and the structural methodology behind the analytical vocabulary this paper occasionally uses in A Structural Methodology for Information System Domains. We assume the primitives and the extension set from those papers and do not re-derive them.

1.3. Scope Discipline

The core protocol is stable, and the substrate-bridge extensions are the architecture-supplied set over it, carried to differing depths by the reference implementations. The operational tier a multi-peer deployment needs — identity, attestation, the network stack — is partly mature and partly still specified, and we mark which is which where it matters. The aim is to be useful to someone deciding how to run on the substrate, with the maturity of each piece stated plainly. Maturity is the part of this paper most likely to have moved by the time it is read; the extension specifications and the conformance matrix are where the current state lives.

2. The Reference Operating System over an Extensible Substrate

The reason DEOS is a reference operating system rather than the operating system is in the shape of the core protocol. The core is small and deliberately incurious about what runs on it. It defines the typed, content-addressed substrate — entities identified by the hash of their content, a mutable tree of named paths over an immutable content store — a single dispatch operation, capability-based authorization, and peer connection. Around that it exposes a handful of live hooks: register and unregister a handler, let a handler dispatch outward, observe the pathway by which writes emit their effects, check a capability, connect to another peer. And then it stops. It does not say what services should exist above those hooks; it says only how anything built there must behave.

An operating system is what you get when you commit to a particular set of services over that substrate. The standard peer is one such commitment: the core protocol plus the substrate-bridge extensions — the extended tree, types, content, inbox, subscription, continuation, compute, query, revision, history, and clock. Each is a service the application uses through the same dispatch as everything else, not a component the application contains. Together they cover what operating-system literature calls kernel services, and a peer that installs them is the kernel of a distributed operating system. That composition, plus the shell and deployment surface that make it usable, is what we call DEOS.

The full structure is a layered stack, and naming it once fixes the altitude for the rest of the paper. At the bottom is a thin platform bootstrap — the small body of native code each implementation needs to run at all, on the order of a few thousand lines. Above it sits the core protocol: the six primitives, dispatch, capabilities, the emit pathway, the type system’s fixed point. Above that is a coordination layer that specifies how multiple extensions behave when they observe the same write. Above that are the extensions themselves. Above those, the SDK presents the protocol in a host language; above the SDK, shared patterns; and at the top, applications. The architecture owns the core, the coordination layer, and the extensions; the layers above are the developer’s surface, which is Application Architecture’s subject.

The decisive point is that almost none of this is mandated by the core. These extensions are the architecture-supplied set, and the coordination layer that choreographs them is itself one set of choices about ordering and cascade behavior. The architecture’s own design notes are explicit that the reference implementations are proof the specification is implementable, not the canonical thing — the specification is the deliverable, and the concrete instantiation is “one set of choices; others are possible.” A community that wanted different messaging semantics, a different history model, or a different reactive discipline could build them on the same hooks and still interoperate at the core. This is exactly why application architecture on the substrate is a design space (see Application Architecture) rather than a single stack, and it is the same reason the operating system is a space too. DEOS is the region of that space the architecture has built out and tested. We walk that region in detail; the reader should keep in view that it is a region, not the whole map.

3. The Kernel Is Its Running State

A conventional kernel is a program: an image loaded into memory whose running state — its process table, open files, scheduler queues, socket buffers — lives in opaque data structures you inspect only through special interfaces, if at all. The entity system inverts this. A peer is not an image with hidden state beside it. A peer is its state, and that state is entities in a tree you can read like any other.

The architecture’s own definition is blunt: a peer is not a role but a configuration — its cryptographic identity, the handlers and extensions it has installed, the capabilities it holds and has issued, its tree, its active continuations, its active subscriptions, and its operational state. Two peers that run the same code are different peers if any of this differs. There is no separate notion of “the system” apart from this configuration; the configuration is the system. And because every part of it is written through the ordinary emit pathway, every part of it is an entity: stored by hash, bound to a path, subscribable, recorded in history, available to compute, indexed by query. The peer’s identity is at a known path; the transports it speaks and the addresses it listens on are entities; its view of which other peers are reachable is entities; its open connections, its held capabilities, its subscriptions and the durable continuations representing its in-flight work — all entities, all readable with the same get that reads a document.

This collapses three things a normal operating system keeps separate. The tree is the data store, plainly. It is also the process table: a peer’s running work is its active continuations and subscriptions, which are entities, so listing what the peer is doing is reading a path, and a tool that shows every continuation across every peer is a distributed process viewer over ordinary entity reads. And it is the management interface: there is no separate monitoring API and no admin console, because the state an operator would want to inspect or change is the tree, reached through the same dispatch and governed by the same capabilities as everything else. The operating system describes itself by being read.

The sharpest consequence is in recovery, and it is worth being precise about what is claimed. There is no write-ahead log, no journal, no checkpoint file, no separate recovery protocol, because the tree already is the durable record of intent. A peer with durable storage that stops and restarts is required to produce behavior equivalent to one that never stopped, holding the same state — this restart-equivalence is a normative property, not an aspiration. The peer recovers by reading its own state and acting on it: it sees which connections it had, which subscriptions it owed, which work was in flight, and re-establishes them. The system heals by being itself.

We should mark the line between what is settled and what is the direction. The operational-state types — transports, configuration, observed peer status, local aliases, connections — are specified, and restart-equivalence is normative. The fuller vision, in which a peer’s entire web of relationships is maintained as a self-repairing graph of running processes that needs no imperative reconnection code, is developed as the entity-native target in the architecture’s explorations; a peer that reconnects with ordinary host-language code interoperates identically and is the common case today. The property that makes the strong version coherent — that the operating system’s running state is nothing but readable, content-addressed entities — is real now. How much of the self-maintenance is expressed natively rather than in handler code is a gradient the implementations are still climbing.

4. The Kernel-Service Mapping

With the framing in place — a reference operating system whose running state is its own tree — the kernel-service mapping is the concrete demonstration that the standard peer covers what an operating system covers. The correspondence is not “DEOS resembles Unix.” It is that DEOS and Unix solve the same coordination problems, and for most of them the entity system has a single mechanism where Unix has one too.

4.1. A Systematic Mapping

Read the table as pairs. Where Unix raises a signal, the standard peer delivers a subscription event; where Unix opens a pipe, the standard peer routes an inbox message; where Unix forks a process, the standard peer advances a continuation. Each pair solves the same coordination problem with the same kind of mechanism — with the difference that the standard peer’s mechanism is content-addressed, typed, and capability-scoped from the first.

4.2. Where DEOS Exceeds Unix, and Where It Breaks

The substrate hands the kernel services properties a Unix-derived kernel does not have, because they are properties of the substrate, not features added to a kernel. Content addressing makes integrity verification, deduplication, and cross-machine cache reuse automatic — an entity’s name is the hash of its bytes, so identical things are the same thing. Authorization is per-operation and decentralized, granted by handing out attenuable tokens rather than by maintaining access lists, with revocation expressed in the tree (see Entity System Security Architecture). Versioning is built in: the store is immutable beneath a mutable namespace, so prior states remain addressable and audit and undo are structural. The system is self-describing — the type entities describe themselves and the protocol’s own structures — and dispatch is typed, so a class of error a Unix kernel meets at runtime is caught at the boundary.

The parallel also breaks, in three honest places. DEOS is distributed-first where Unix is local-first: Unix’s coordination mechanisms live within one machine and its distributed extensions reach across machines with weaker semantics, whereas a subscription, a continuation, or an inbox message crosses peers without changing what it means, and the single-machine case is a deployment configuration rather than a separate set of primitives. DEOS does not abstract hardware: process isolation, memory protection, scheduling fairness, and interrupts are the host’s job, and the kernel-service mapping is for the coordination layer that traditionally sits above the hardware-abstraction layer. And networking is a substrate, not an in-kernel service: Unix puts TCP/IP in the kernel, while DEOS treats the network as transport that an extension wraps — structurally cleaner, but it means the networking layer is younger than a Unix-derived stack’s, a point the next sections take up directly.

4.3. How the Services Coordinate

A Unix kernel’s services interact through the kernel’s implicit state machine, which is why a developer has to reason about signal-safe code, fork-safety, and file-descriptor races. The standard peer’s services do not interact implicitly. Every write travels the emit pathway — store the content, bind the path, raise the events — and the extensions that care register as consumers invoked in a fixed, specified order: persistence, then indexing, then time, then history, then computed values, then structural summaries, then automatic versioning, then subscription delivery. Delivery is two-phase, settling the synchronous cascade fully before the asynchronous broadcast. The cascade carries a depth counter with specified thresholds at which it suppresses further reactions, freezes recomputation, and finally refuses the write, so a runaway reaction is bounded by the protocol rather than by luck. And termination is content-addressed: when a recomputed result hashes to what is already stored, the write is suppressed and the cascade stops, because nothing changed.

This coordination layer is normative for a peer that runs several extensions — but, consistent with the substrate principle, it is normative given those extensions, not a claim that the core mandates them or their ordering. The discipline that makes it compose is that each extension does its own distinct job, and where two would touch the same surface the coordination layer specifies the interaction explicitly rather than leaving it to emerge. That explicitness is the property Unix lacks, and it is what lets the kernel services be installed in different combinations without implicit cross-talk.

5. Cross-Peer Coordination

If the kernel-service mapping is where DEOS earns the word operating system, cross-peer coordination is where it earns the word distributed — and it is the part most easily overstated. The honest account is more interesting than the slogan, so we give it in full, including what is not yet solved.

5.1. Synchronization Is a Gradient

Coordination between peers rests on synchronization, and synchronization is not one mechanism but a gradient of four, each independently useful. At the base is the raw tree: the current path-to-hash bindings, state with no history. Above it, the emit pathway records each write’s transition — the new hash, the previous hash, the author, the capability, the time — giving a per-path, per-peer history for free, though one that on its own says nothing about other peers. Above that are snapshots: a content-addressed capture of a subtree’s bindings, so that two peers comparing a snapshot hash know in one comparison whether they hold identical state. And above that is the version: a snapshot plus parent links, author, time, and message — which is, structurally, a commit in a content-addressed history. Zero parents is an initial version, one is linear progress, two or more is a merge, and because the parents are hashed into the version’s own identity, the version history has the same cryptographic integrity as a distributed version-control system’s commit graph.

Two peers reconcile by walking this structure. They negotiate heads — exchanging what each has and wants — find a common ancestor in the version graph, transfer the content that differs, and integrate, either fast-forwarding or merging. Merging has two layers: a structural layer that decides which hash sits at which path, and a semantic layer that reconciles the content when both sides changed the same path, through a pluggable strategy that defaults to a three-way merge and admits last-writer-wins, a conflict-free replicated type, manual resolution, or a custom handler. A guiding principle keeps this clean: a replicated data type is a merge algorithm, not a storage format (Shapiro et al. 2011), so no replication metadata is persisted — the strategy runs when a conflict arises and produces an ordinary entity. And a conflict is data, not a blocking state: an unresolved conflict is stored as an entity at the path and the tree moves on, to be resolved when convenient, rather than halting work until a human intervenes.

5.2. Convergence Is Provided; Consensus Is a Configuration

It is tempting to summarize all of this as “the revision extension gives you distributed consensus.” That would be an overclaim, and a revealing one. What the system provides, out of the box, is convergence: peers that exchange versions and merge reconcile toward a common state, and where they cannot — where two sides changed the same path incompatibly — the divergence is surfaced as data rather than silently lost. Whether they collapse to a single value depends on the merge: a conflict-free strategy converges by construction, while an ad-hoc one is only guaranteed to make the disagreement explicit. What it does not provide as a primitive is consensus in the strict sense — a single agreed linear log with bounded failover, the guarantee a protocol like Raft (Ongaro and Ousterhout 2014) or Paxos (Lamport 1998) is built to deliver.

The interesting part is that consensus is reachable, not as a built-in but as a configuration of the parts already described. The architecture’s exploration of this shows the decomposition cleanly: a leader is a peer holding the write capability; log replication is synchronization push; commitment is a quorum check over peers’ published head pointers; the heartbeat is a subscription with a timeout; and safety rests on content addressing. One can arrange the sync primitives, capabilities, and subscriptions into a spectrum from independent peers, through eventual convergence, through a coordinating hub, to leader-and-followers, to consensus with election. But the same exploration is candid about the cost of this generality. There is no formal safety proof; safety depends on the merge strategy being configured correctly, where a strict consensus protocol hardcodes the rules so it cannot be misconfigured. By default the system gives at-least-once version propagation and eventual convergence, not an exactly-once linear log — a linear log emerges only under a single writer, where the version graph degenerates to a chain. And the consensus pattern is documented guidance, not a shipped extension with conformance tests. So the honest claim is the narrower and, we think, more useful one: the substrate provides convergence and makes consensus configurable; it does not hand you a proven consensus protocol.

Said this way, the genuine strengths come forward rather than getting buried under a borrowed word. The version graph’s integrity is cryptographic, so any peer can verify the history rather than trusting a leader. The model is offline-first: a peer can fork, work disconnected, and reconcile later, which a leader-based protocol forbids by construction. Authority can be partitioned by path, so different subtrees can have different writers without a global leader. Synchronization is capability-scoped at the path level, so different peers legitimately see and reconcile different slices of the same tree — a property the existing distributed systems do not offer. And there is no idle cost: coordination happens when state changes, not on a constant heartbeat.

5.3. Concurrency Correctness Is a Separate Guarantee

One distinction prevents a common confusion. The coordination above is about peers diverging and reconciling over time. It is not the same as a peer being a correct concurrent server in the moment, and conflating the two is exactly the error the slogan invites. The latter is its own property, and it has recently been hardened into a tested, cross-implementation requirement: a peer must demultiplex concurrent requests on one connection correctly, tolerate out-of-order completion, never let one slow request block the others, and never deadlock under reentrant load. A conformance gate built for this caught real failures — independent implementations that were correct single-threaded and fell over under concurrent load, the precise “correct but it collapses” class the gate was built to catch — and folding it into the core conformance profile is what makes “the peer stays a correct server under load” a checked guarantee rather than a hope. The point for this paper is that this is about the peer as a correct server under concurrent load, which is necessary infrastructure for a distributed operating system but is a different claim from distributed consensus. We keep them apart.

5.4. The Open Problems

A distributed operating system is judged partly by the honesty of its account of what it has not solved, and the architecture flags several. Concurrent merges of the same divergence can produce a new divergence — two peers merging the same fork yield merge versions with identical parents but different identities — so what holds is eventual convergence over a bounded number of extra rounds, not single-round convergence, and pinning that down is open. Synchronization that walks the tree can stop at hash references buried inside entity data, so a naive transfer can move a file’s metadata without its content; closing that gap needs content-aware transfer rather than a pure structural walk. And there is a recurring class of cross-peer capability bug that local test fixtures mask, because a capability chain that roots correctly on one peer can come apart when a second peer is in the path — which has motivated a discipline of validating every cross-peer capability flow with a third peer that issued none of its links. These are real, and they are the frontier of the work; a paper that claimed cross-peer coordination was a solved one-liner would be contradicting the architecture’s own candor.

6. The Network, the Fleet, and the Shell

The previous section was about what coordination means; this one is about how it is actually carried, how a fleet of peers is run as a single operating system, and the shell that operates it.

6.1. The Network Is a Transport Substrate

The cleanest way to see the network layer is that the wire is abstract. A peer pushing signed entities to a store and another peer reading them is a transport, whether the store is a live socket, a polled endpoint, or a static file host on a content-delivery network. These differ only in latency, liveness, and direction — not in what flows, because what flows is content-addressed, signed, capability-bearing entities that are identical across every medium. The real axis is not live-versus-static but subscribe-versus-poll: how a peer learns that something changed. A peer that can be pushed to learns by subscription; a peer that cannot — a browser tab, a peer behind a restrictive network — learns by polling and diffing, which is the general pattern for any weak participant.

Two structural results fall out of this and are worth stating because they dissolve problems that look hard. First, a static store is already a relay: a peer that writes to a passive store and another that polls it have communicated, and the protocol cannot tell this apart from active forwarding, so a static host serving signed entities is a relay node by another name. Second, a relay is transport, not authority: when a message passes through a relay, the sender’s capability chain passes through unchanged, and the relay can drop or delay but cannot escalate, because it constructs no link in the chain and enforces only its own ordinary “you may relay through me” grant. Relaying therefore needs no special protocol amendment; it composes from the capability primitives already present.

The network extension is a specified, actively developed normative spec rather than a sketch. The transport family (direct connection, web-socket, request-response over HTTP, and a poll-only variant) is signed off across the implementations. Peer discovery and a name registry have landed as version-one specifications: discovery surfaces candidate peers and mediates an explicit human decision to admit them, defaulting to a zero-configuration local-network backend and failing closed so it never silently connects you to a stranger; the registry resolves a name to a peer through pluggable backends, shipping a local petname scheme first, with no backend privileged over another. A relay extension is specified and implementation-ready. The one piece still genuinely pending is a browser-to-browser transport, which is why peers discovered on a local network connect today over the ordinary transports rather than directly. The honest summary is that the network stack is young relative to a Unix-derived kernel’s networking but is specified and converging, not a set of gaps.

6.2. DEOS Is the Operating System of Your Fleet

This is the move the paper exists to make. A conventional operating system runs one machine; DEOS runs your fleet, and the same mechanisms hold across a spectrum of scales. On one machine it is a single peer, no network involved, used for development or for the programming model alone. On a personal cluster — a home network of a laptop, a desktop, a phone, a server — the peers find each other by local discovery, keep their state synchronized, and share names, and the economy here is that the group is its own registry: the membership of the home network already maps names to peers, so a personal cluster needs no dedicated infrastructure at all. Across the internet the same fleet adds a registry to resolve names and a relay to traverse networks. In an enterprise it adds dedicated registry peers or clusters and, at high population, gossip and distributed lookup. The mechanism does not change across these tiers; what changes is configuration — which is the same observation that made application architecture a design space, now at the scale of the whole fleet. A single rich peer and a multi-peer composition are points on the spectrum of one primitive, not different systems.

That this works is not only a design claim; it has been exercised. The reference workbench’s multi-peer testing brought up symmetric meshes of three and five peers, a five-peer hub-and-spoke, a cascade, and a ring, and all converged; a burst of writes across a five-peer hub delivered every update; saturation testing found and then lifted a delivery ceiling by an order of magnitude with parallel delivery, and the substrate degraded cleanly under stress rather than collapsing. We cite the failure modes too, because they are the honest part. Concurrent edits to the same file diverge and keep each side’s content — by design, since conflict-free merge is the revision extension’s job, not the substrate’s. A peer joining late catches up asymmetrically, receiving some prior state but not all, which is the worst shape a gap can take — partial state without the operator being told — and it argues for explicit reconciliation on join rather than a faith that everything simply arrives. And a chain rejected for want of a capability has, in places, failed silently, the kind of bug that costs an operator days. These are named in the architecture’s own reviews; a fleet operating system is more trustworthy for saying them out loud.

The texture of running a fleet differs from running a box in ways worth drawing out. Access across your own devices is capability-mediated rather than ambient: you reach another of your machines by holding a grant for exactly what you are allowed to touch there, so cross-device access is a set of explicit, attenuable permissions, not a shared login. Adding a person or a device is issuing identity and granting capabilities, not provisioning an account. And the operator’s view of the fleet is, again, just entities: a peer that synchronizes every other peer’s observed-status entities sees the whole network’s topology, including the asymmetries where two peers disagree about whether they are connected, as plain state rather than as hidden disagreements between connection managers. The image the architecture reaches for is session-based computing — edit on the laptop, walk to the desktop, and the work is there, scroll position and all, because the devices are interchangeable windows onto one operating system.

The host operating system, in all of this, is the substrate the peer runs on, and treating it that way is a strength rather than a concession. The peer is a userspace process on Linux, macOS, Windows, or Android; the native footprint it needs is small, on the order of a few thousand lines validated across the implementations; the host’s resources — files, processes, and in time devices and the network — surface through a reserved namespace as ordinary entities. Because the peer is not bound to the hardware, it is close to a pure build artifact: the only thing that must survive a machine is the on-disk identity material, backed up like a private key, and everything else — the local store, the connection state, the history — can be rebuilt, because content addressing makes republication idempotent. A validated deployment dry-run bears this out, reconstructing a peer’s content to byte-identical hashes after a full wipe, with identity preserved. There is also a more radical model, in which an entity peer runs on bare metal as the lowest layer — the operating system not on top of a host but in its place. We flag it as exploration: it is a coherent direction the substrate’s small native footprint makes imaginable, not a documented or implemented target, and we name it to mark the edge of the space rather than to claim it.

This is also the seam where DEOS ends and the field-map view begins (see The Decentralized Systems Landscape). Your fleet is one operating system; it connects to other people’s fleets — their own distributed operating systems — and what happens across that seam, the sharing and exchange and convergence at internet scale, is the subject of The Decentralized Systems Landscape rather than this one. DEOS holds the operating system you run; the network of operating systems is the next view out.

6.3. The Shell

Every operating system has a shell, and DEOS’s is not a convenience layered on top but an architectural layer in its own right, standing to the SDK as the SDK stands to the protocol. Its working directory is the entity tree — the current path is a tree path, not a host-filesystem path — and its verbs are a one-to-one projection of the SDK and handler operations into named commands. This is what lets a terminal, a graphical panel, and an embeddable library be presentations of one shell rather than separate programs.

A real shell binary runs today, with an interactive loop and a one-shot mode, line editing, completion against live tree contents, and persistent history; its core verbs and most of its extension-derived verbs work against both local and remote peers, with a connect that performs a genuine handshake and a copy that moves an entity across peers. Three independent implementations grew shells and converged on substantially the same surface, which is the same convergence-as-evidence the corpus leans on elsewhere. What is missing is composition: pipelines that flow typed entities from one command to the next are designed but not built, and the packaged single-shot utilities are a distribution decision still pending. The distributed shell is real and cross-implementation, with its compositional layer the open frontier.

7. The Collapsed Infrastructure Stack

A standard production deployment today is an assembly: a version-control system for state, a request protocol for dispatch, a message queue for events, a database for typed data, an orchestrator for namespacing and authorization, and — between all of them — an integration layer of pipelines, service meshes, APIs, and authentication flows. The parts are mature and the assembly works; the integration is where the operational complexity lives.

Seen through the primitive analysis of Convergent Evolution, each platform covers part of the primitive set and none covers all of it, and the integration layer is precisely what compensates for the gaps: it translates event semantics between the queue and the request services, reconciles build state with deployed state, and carries authorization across the boundaries between systems. This is the integration tax (see Convergent Evolution) — the cost of building on platforms that each sit off the coherent set of primitives, so that external machinery must bridge between mismatched coverage. The standard peer reaches the coverage of all six primitives in one substrate, so there is no integration layer because there is nothing to integrate: state, dispatch, events, queries, and authorization are properties of the same content-addressed substrate, and a cross-extension interaction is mediated by the protocol’s own dispatch rather than by glue between systems.

Two things keep this from being a slogan. First, it is not a recommendation to discard a working stack: the existing platforms are battle-tested and deeply embedded, the substrate’s claim is structural, and its operational maturity is younger. The honest framing is that the modern stack is an approximation, distributed across platforms and reconnected with integration, of what the substrate provides in one piece — a way of seeing where the substrate sits, not a demolition order. Second, adoption is incremental and through bridges: a peer can wrap an existing database or service and bring its data into the entity model, so a deployment absorbs the substrate piece by piece rather than all at once. That incremental path, and the bridge mechanism that carries it, are the developer’s concern and are developed in Application Architecture; here it matters only as the answer to “must I replace everything to begin,” which is no. Consistent with the substrate principle, none of this should be read as the core mandating these particular extensions — it is the reference operating system’s coverage, against the reference modern stack.

8. Related Work

DEOS sits in a lineage of distributed operating systems and a neighborhood of contemporary infrastructure. We place it against the closest of each.

Plan 9 and Inferno. Plan 9 (Pike et al. 1990) and Inferno (Dorward et al. 1997) are the closest architectural predecessors, and the resemblance is deep: both commit to a single coordination abstraction, where Plan 9 and Inferno make everything a file and DEOS makes everything an entity. The reduction discipline — replace mechanism with one substrate — is the same shape; the substrate differs, untyped bytes in a hierarchical namespace versus typed, content-addressed entities in a tree. What DEOS gains over the file abstraction is exactly what content addressing, types-as-data, and capability-based authorization add: integrity and deduplication from content-derived identity, structural validation at dispatch, and per-operation decentralized authority where Plan 9 carries conventional permissions.

Urbit. Urbit (Yarvin et al. 2016) is the closest in vision: both build a complete personal-computing environment from primitive coordination, both independently arrived at typed entities as the unit, and both treat the personal server as central. The divergence is in what each commits to. Urbit fixes a particular computational substrate — a small deterministic instruction set and a language above it — and derives determinism and replay from it; DEOS commits instead to typed content-addressed data and derives verifiable cross-peer convergence from content addressing. The trade-off is real and the two papers’ systems sit on different sides of it; DEOS’s substrate principle, which lets a different computational layer be composed over the same core, is a direct response to the cost of a fixed one.

Kubernetes. Kubernetes (The Kubernetes Authors 2014) and the container-orchestration lineage operate at a different level: namespace organization, container dispatch, and role-based access, without content addressing or typed application interfaces, with the container rather than the entity as the unit. It is mature production infrastructure, and the relationship is compositional rather than competitive — a standard peer can run as a workload on Kubernetes, providing entity-level coordination above the container-level coordination, the two operating at different abstraction levels.

NixOS and microkernels. NixOS (Dolstra et al. 2004) shares content-addressed reproducibility, reached at the package and build level; the standard peer extends that property past build artifacts to all entities, so what NixOS does for packages the substrate does for application data, types, and capability tokens. Microkernel architectures such as seL4 (Klein et al. 2009) and the modular design of Fuchsia (Google 2016) share the shape of a minimal core plus composable services with capability-based authorization; DEOS carries that shape to the distributed case, with content addressing and typed dispatch as additional substrate properties. The older distributed operating systems — Amoeba (Tanenbaum et al. 1990), Sprite (Ousterhout et al. 1988), and the Andrew File System (Morris et al. 1986) — pursued the single-system-image goal across machines that DEOS pursues across a fleet, and a fuller survey would engage them at length; the selection here is the structurally closest, and broadening it would deepen the comparison without changing the argument.

What recurs as DEOS’s distinguishing addition, across all of these, is the one developed earlier: the operating system’s running state is itself self-describing, content-addressed entities in the same tree it serves, so the system observes and recovers itself by being read. That property, more than the kernel-service mapping, is what the lineage does not already have.

9. Discussion

9.1. What the Paper Is and Is Not

This paper is a structural account of the entity system viewed as a distributed operating system, written for systems researchers and for teams who would run on the substrate. It is not an operations manual, and it is not a claim that DEOS is the operating system the substrate must become. It is one operating system the substrate can host — the architecture’s reference build — described as a region of a larger space, with the maturity of each part marked rather than smoothed.

9.2. What Is Settled and What Is in Motion

Settled: the core protocol and the six primitives beneath it; the kernel-service mapping, which follows from the extensions covering the operating system’s coordination concerns; the property that a peer’s running state is self-describing entities in its own tree, with restart-equivalence normative; and convergence as what cross-peer synchronization provides. These rest on running code and, for the protocol, on a conformance oracle that has been exercised across many languages.

In motion: consensus is reachable as a configuration of the synchronization primitives but is explored rather than proven or shipped, and the system provides convergence by default, not a linear log. The network stack is specified and converging but young — discovery and a registry have landed, relay is ready, a browser-to-browser transport is pending. The shell runs and is cross-implementation, but its compositional layer is unbuilt. Several cross-peer coordination problems are open and named. And behavior at production scale is demonstrated in multi-peer testing but not in long-lived deployments under real load. None of this undercuts the operating-system frame; it dates it.

9.3. A Note on Posture

The stance throughout is exploratory and pluralist, by choice. The substrate does not care which operating system you compose on it, and this paper maps the reference one rather than legislating it. The question it really pursues — what is an operating system, and how far does this substrate carry the idea — is a question about frames of reference, and the honest answer is a map of what becomes possible, not a verdict on the one right way. Other compositions are possible; a community could build a different operating system on the same hooks and still interoperate at the core. We think the reference build is a good one, and we say where it is strong and where it is unfinished, but the offer is a substrate to build operating systems on, not a finished operating system to adopt.

9.4. Limitations

• DEOS is one operating system the substrate can host, presented as the reference build; the operating-system framing is a frame of reference, not a claim of identity, and other compositions are possible.
• The strongest version of the “never leave the system” idea is an option the substrate offers, not how anyone runs today; real deployments retain native code and lower-level infrastructure.
• Consensus is configurable, not provided as a proven primitive; convergence is what the substrate guarantees.
• The network stack and the shell’s composition layer are young, and several cross-peer coordination problems are open; production-scale behavior is not yet established.
• Generated under prompt-and-review: this paper, like the rest of the corpus, the supporting implementations, and the architectural specifications, is LLM-generated under direction from the author — the author prompts, evaluates, redirects, and approves rather than authoring text directly. The methodology this enables is described in The Entity Core Protocol.

10. Conclusion

The entity system, viewed as a distributed operating system, is the operating system of your fleet rather than your machine. The standard peer — the core protocol plus the substrate-bridge extensions — provides what an operating system coordinates, from the same six primitives, in one typed and content-addressed substrate, and the mapping from kernel service to extension is concept-for-concept. The work this paper does is to frame that correctly. DEOS is one operating system the substrate can host, the reference build over an extensible core, not the operating system the substrate is. Its kernel is not an image but a live configuration recorded as entities in its own tree, so the system describes, observes, and recovers itself by being read. And its distribution is the default rather than an addition: the same coordination runs from one machine to a home network to a federation, and the operating system is the abstraction over all of them.

We have been honest where honesty is load-bearing. Cross-peer synchronization provides convergence, with consensus reachable as a configuration rather than handed over as a proven primitive. The network stack is specified and converging — discovery and a registry landed, relay ready, the shell running across three implementations — but it is young, and several coordination problems are open and named. The protocol’s convergence across languages is the proven half of the system’s story; whether people build operating systems on it, and converge on shared ones, is the open half, and no specification forces it.

Three invitations sit alongside the model, by design. An operating-system coordination concern that no extension can host would test the kernel-service mapping, and we would want to know which one. A coordination need the synchronization gradient cannot reach — something the convergence-to-consensus spectrum genuinely cannot express — would mark the substrate’s edge. And the largest question is not structural: whether the substrate’s small native footprint and self-describing state make it worth running a fleet on at all is a question running fleets will answer, not a specification. The substrate is offered as a thing to build operating systems on, with its early state stated plainly, in the belief that the honest version is the one worth offering — and that where this operating system ends, at the seam between your fleet and others’, the next view of the system begins.

Application Architecture on Content-Addressed Typed Data: A Design Space

1. Introduction

An application on the entity system does not have one shape. A content site is a body of typed entities a peer serves, and another peer can verify and re-host it without asking anyone’s permission. A version-control tool is a command-line program that boots a peer, runs its commands against the substrate, and exits — the person using it need never know a peer was involved. A collaborative workspace is several peers wired together, one of them holding the durable record the others never see directly. These are not three variations on a template. They are three points in a space, and the coordinates a developer chooses are the architecture.

The questions that fix a coordinate are few. How much of the substrate does the application stand on — the bare core protocol, or the core plus some chosen extensions? What is the application: entities the substrate runs directly, a binary in a host language that wraps a peer, a composition of several peers, or direct use of the system’s services the way one uses a filesystem? How is it deployed, how long does it live, how much identity does it need, and in which language is it written? Each answer carries consequences — in inspectability, in distribution, in what the application has to build versus what it gets for free — and a finished application is the conjunction of all of them. The work of application architecture here is choosing a location and knowing what that location gives you.

The starting point is higher than it sounds. A bare core-protocol peer is already an application: it has a typed, content-addressed store, capability-based access control, and a cryptographic identity, reachable through one dispatch operation. You do not assemble those; you start with them. Adding an extension does not wire in a subsystem so much as raise the floor — the revision extension gives the application a version history, the subscription extension gives it reactivity, and the application’s own code never implements either. Most of what a conventional application spends its effort integrating is, here, inherited from where it stands.

The system is not only peer-to-peer, and reading it as “a distributed-systems thing” mistakes one region of the space for the whole. A developer can run a single peer on one machine and never open a socket, because the programming model is reason enough to use it. Another can build an ordinary web application whose backend is a database peer and whose frontend talks to it — the familiar three-tier shape, with the tiers happening to be peers. A third can federate across administrative boundaries. All three install and run the same substrate; what differs is how many peers there are and how they are wired. The peer is the unit you deploy, and the topologies it composes into are the ones enterprise architecture already has names for.

Two properties make building here different from building on a conventional stack, and both recur through the paper. The first is inheritance: at a given depth in the substrate, an application is handed capabilities it would otherwise stitch together from separate tools — content-addressed storage with automatic deduplication, versioning, audit, reactivity, durable workflows, fine-grained authorization — so the developer writes domain logic and not the integration between a version-control system, a message queue, a cache, and an authorization service. The second is that the contract is the protocol itself, not a language or a runtime. A peer is anything that speaks the wire format correctly; the Keystone effort has generated conformant core-protocol peers in six more languages — from a managed-runtime actor store to no-garbage-collector systems code — each checked byte-for-byte against the specification by a conformance oracle rather than by sharing code. An application architect picks the language; peers written in different ones interoperate exactly.

We are honest about where this stands. The substrate is real and the patterns in this paper are drawn from working code, but the developer tooling and the SDKs are still in motion, and where the ergonomic layer will finally land is not settled. The reference applications named throughout — a content-site format, a version-control tool, an interactive workbench — are how the patterns were found and proof that they hold; they are reference implementations, not products, and whether they are the best way to build on the substrate is a question the paper leaves open on purpose. The system is offered as something to build on, and the shape of what gets built on it is, deliberately, not yet decided.

1.1. The Boundary with the Operating-System View

There are two ways to look at the same standard peer, and this paper takes one of them. Viewed as an operating system — kernel services, the shell, deployment across a network — the standard peer is the subject of DEOS, which calls that view DEOS. That is the system you run on: what coordination it provides, how its services map to the ones an operating system provides, how it scales. This paper is the complement: the application you build on it. The two share a vocabulary — peers, compositions, the extension set — but ask different questions. Paper 7 asks what the environment is; this one asks what shapes an application takes within it, and how a developer chooses among them.

The core protocol itself, the substrate both views rest on, is The Entity Core Protocol; the six primitives that generate it are The Entity System. A point worth keeping in view from the start, developed in those papers and sharpened as the protocol settled: the core is a substrate, not a system. It ships a small set of live hooks — register a handler, dispatch outward, observe the emit pathway, check a capability, connect — and does not dictate what is layered on top. The extensions this paper leans on are one coherent set of choices over that substrate, the set the architecture ships; they are not privileged by the core, and a community could build a different set. That is the deepest reason application architecture here is a space rather than a single stack: the substrate is designed to be built on in more than one way, and choosing how is the architect’s job.

1.2. What This Paper Covers

The paper is organized around the design space and the choices it offers:

1. The space and its axes. The dimensions a developer chooses along, and how the entity-system-shaped ones (substrate depth, form, topology, deployment mode, lifetime, identity depth, language) sit against the universal concerns every application has (where it runs, how it displays, how a user interacts with it) — including an honest account of which of those the substrate does not yet address.
2. What a location inherits. The properties an application gets for free at a given substrate depth, and how different locations lean on different ones.
3. The forms of an application. Entities the substrate runs, a binary that wraps a peer, a composition of peers, and direct service use — the four embodiments, how they combine, and how their topologies map to client-server, N-tier, and service-oriented shapes.
4. The application lifecycle. Boot, load, run, and exit for a peer that is a program; one-shot, long-lived, and persistent-restartable lifetimes; how identity depth is chosen.
5. The programming model, and language agnosticism. Writing application logic as content-addressed computation, the gradient from inspectable to compiled, and the protocol-as-contract property that lets a peer be written in any language.

1.3. What This Paper Does Not Cover

The six primitives and the build-up sequence are in The Entity System; the protocol wire format, dispatch, and capability mechanics in The Entity Core Protocol; the computational model in The Entity Church Architecture; the compilation gradient and machine boundary in The Entity Machine Boundary; the landscape of existing systems in Convergent Evolution; the operating-system view of the standard peer in DEOS; and the security architecture in Entity System Security Architecture. We assume the primitives and the extension set from those papers and do not re-derive them.

1.4. Scope Discipline

The core protocol is stable; the substrate-bridge extensions are the architecture-supplied set over it, with three reference implementations (Go, Python, Rust) at conformance parity on the core surface, and the broader multi-language realization is the Keystone effort. The operational tier a multi-peer deployment needs — identity, attestation, network, and others — is partly mature and partly still specified, and we mark which is which where it matters. The application-level conventions this paper draws on — a content-site format, the peer-composition catalog, an HTTP bridge — are mostly recent and still in draft; we cite them as drafts, not as settled standards. The aim is to be useful to a developer deciding how to build, with the maturity of each piece stated plainly rather than smoothed over.

2. The Design Space

Every application, on any platform, has to answer a few questions that have nothing to do with the entity system. Where does it run — a server, a laptop, a phone, a browser tab? How does it show itself — a window, a terminal, a web page, no surface at all? How does a person act on it — a click, a keystroke, a request, a command? These are the universal questions, and they are answered the same way they have always been answered, because the substrate has no opinion about most of them.

It is worth saying plainly which of these the entity system does not yet address. It does not provide a display layer. There is no entity-native windowing, no standard way to draw a button. The reference applications that have a graphical surface — the workbench discussed later — built that surface themselves, in the host platform’s UI toolkit, and an application that wants a screen does the same or falls back to whatever its language already offers. The substrate shapes where an application’s data and computation live and how its parts coordinate; the pixels are still the developer’s problem, and a paper that pretended otherwise would mislead.

What the substrate does shape is a smaller, sharper set of choices, and those are the axes of the design space. They are independent: a choice along one does not fix the others, and an application is a point across all of them.

The rest of the paper walks these axes. The form axis carries the most weight for a reader new to the system, because it answers the question that confuses people first — what is an application here, concretely? — so it gets its own section. The others are developed where they do the most work: substrate depth in the discussion of inheritance, lifetime and identity depth in the lifecycle, language in the programming model.

2.1. Where the Familiar Shapes Sit

A developer coming from conventional practice already has a vocabulary for arranging an application: a LAMP server, a client and a server, three tiers, a fleet of microservices, a service-oriented architecture with a bus in the middle. None of that vocabulary is wrong here, and none of it is replaced. It maps onto the topology axis directly, because the entity system’s unit of deployment — the peer — plays the role those architectures give to a process, a service, or a tier.

The mapping is close enough to use as a guide. A single peer on one machine is the local application, the desktop tool, the thing with no network at all. A frontend talking to a backend database peer is client-server, and adding an application-logic peer between them is the classic three tier. A set of interchangeable peers behind a router is a service pool, which is what a horizontally scaled service or a microservice deployment is. A federation across administrative boundaries is the wide-area, multi-organization case. What the entity system changes is not the shape but the seams: where those architectures wire their tiers together with REST, a message bus, and a database protocol — each its own format, each its own authorization story — the peers in an entity-system deployment speak one protocol, carry one kind of typed content, and authorize every operation the same way. The arrangement is familiar; the integration between the parts is not there to build, because the parts already share a substrate.

So the design space is not exotic. It is the application-architecture decisions a developer already makes — how to structure the thing, how to scale it, how the pieces talk — with a different and smaller set of consequences attached to each decision, because the substrate underneath every region of the space is the same.

3. What a Location Inherits

The single property that most distinguishes building an application on the entity system is that a location inherits. Stand at a given depth in the substrate, and the application is handed capabilities that, on a conventional stack, it would assemble from separate tools and wire together by hand. The bare core protocol already gives every application a typed, content-addressed store and capability-based access control. Each extension installed above it raises the floor again, and the raising is the point: the extension is a service the application uses, through the same dispatch as everything else, not a component the application contains.

What this collapses is the integration layer. A conventional application of any size assembles a version-control system for history, a message queue for events, a cache, a database, an authorization service, and a sync mechanism, and then spends much of its engineering on the wiring between them — the part where the formats disagree, the authorization models don’t compose, and the operational complexity accumulates. On the entity system those concerns are properties of where the application stands:

• Content-addressed storage with deduplication. An entity’s identity is derived from its bytes, so two identical things are the same thing, stored once. The application gets a cache whose invalidation is structural — the content hash is the key — without a caching layer.
• Versioning and audit. The store is immutable underneath a mutable namespace, so every prior state remains addressable. The revision extension turns that into a version history with three-way merge; the history extension turns it into a per-path log. Undo, audit, and provenance are not features the application builds.
• Reactivity. The subscription extension delivers an event when a path changes; the compute extension lets a value be defined as an expression over other values and re-evaluated when they change. Together they are a spreadsheet over content-addressed data: the application states a relationship once, and the substrate maintains it. A live view, a running metric, a cache that refreshes itself — each is an expression, not a pipeline.
• Durable workflows. The continuation extension records a multi-step process as entities in the tree, so a workflow survives a restart without a workflow engine.
• Asynchronous messaging. The inbox extension delivers a message to a peer that may be offline, so coordination between parts does not need a separate broker.
• Authorization. Every operation carries its own capability, checked before the handler runs; access is granted by handing out attenuable, revocable tokens rather than by maintaining an access-control list. The authorization model is the substrate’s, not a service bolted beside it.

Different locations lean on different parts of this. A collaborative editor lives on reactivity and versioning; a data pipeline on durable workflows and content-addressed computation; a content site on chunked storage and the embed format built over it. The substrate supplies all of it, and the application’s character is partly which inherited properties its handlers actually drive — a point the worked locations later make concrete.

Inheriting is not the same as having the problem solved, and it would be dishonest to suggest otherwise. The properties are there, but composing them into a particular application still takes design judgment: which extensions, wired how, with what capability boundaries. The reactivity has limits on how far a change cascades; the workflows have failure modes; the merge has cases a domain has to resolve. And the layer that would make all of this ergonomic — the SDKs, the higher-level patterns, the tooling — is in development, so a developer today works closer to the substrate than they eventually will. What the location gives you is a high floor. What you do from there is still architecture.

4. The Forms of an Application

Ask a developer from any background what an application is, and they have a ready answer — a process, a service, a binary, a page. On the entity system the question has four answers, and choosing among them is the most consequential coordinate in the space. They are not exclusive; a real application usually combines them. But they are genuinely different kinds of thing, with different inspectability, different visibility to their users, and different ways of shipping.

4.1. Entity-Native: The Application Is Data the Substrate Runs

The purest form has no binary of its own. The application is a body of entities, and the substrate already knows how to run them. A content site is the clearest example: a site is a manifest entity, a set of page entities, and a signed root that pins the whole subtree to its publisher’s identity, with media carried by a generic embed format layered over content storage. There is no server to deploy. A peer holds the entities; another peer fetches them, verifies the signature and the hashes, and re-hosts the site without coordinating with anyone, because the bytes carry their own identity. A repository of version-controlled files is the same kind of thing — typed entities under the revision extension — and so is a shared space.

What makes this form possible is that the substrate dispatches by what an entity is, not by where it sits. A handler is found through the system’s handler registry against an entity’s type, not against a path, so where an application puts things is a convention rather than a mandated location: paths are a convenience, and the entity graph is what carries coherence. An entity-native application is therefore defined by its types and the handlers registered for them, and a developer reads it the way they read data, because that is what it is. The cost is that this form reaches exactly as far as the substrate’s own evaluation: pure entity-native applications are maximally inspectable and transferable precisely because there is nothing in them but substrate. The conventions that standardize these forms — the content-site format, the embed format — are recent and still in draft, and we treat them as such; what is settled is that the form exists and the substrate runs it.

4.2. Wrapped Binary: A Program That Happens to Be a Peer

The second form is a program in an ordinary host language that uses the substrate as a library. From the outside it is a command-line tool, or a desktop application, or a service — something with a normal surface that does a normal job. Inside, it boots a peer, does its work as dispatches against the substrate, and presents the result through whatever interface it offers. A person using a version-control tool of this shape runs the commands they expect; they need never learn that a peer was created, that their files became content-addressed entities, that the history is a revision DAG. The peer is an implementation detail.

This shape was not designed so much as discovered. Two reference tools — one that publishes a peer’s content to a static origin, one that puts a version-control workflow over the revision extension — were built independently, and they turned out to be the same program with different verbs. Both boot a peer pointed at local resources; both reach the outside world through bridge handlers for the standard streams; both root their authority in a keypair on disk and attenuate from it; both render their output by dispatching through that bridge and translate a typed error into an exit code. The recurring skeleton — boot, bridge, identity, capability root, output convention, error-to-exit — is the wrapped-binary form, and finding the same skeleton in two tools built for different jobs is the evidence that it is a real pattern rather than one program’s accident.

4.3. Peer Composition: The Application Is Several Peers

The third form is more than one peer, wired together. A peer here is a full configuration — an identity, the handlers and extensions it has installed, the capabilities it holds and has issued, its tree, its live continuations and subscriptions, its operational state — and a composition is a family of such peers, coupled by capability grants and by who is subscribed to whom, that together produce something no single peer does. The architecture catalogs seven recurring ones: an operational peer that holds durable state outside the peer doing the work; an observer that watches without being able to interfere; a service pool for scale; a hub-and-spoke for coordination; a recovery cluster for identity that survives key loss; a bridge between two domains that do not trust each other; and a compute pool that isolates expensive work. Each is a configuration of the existing primitives, not a protocol feature, and each is named so that teams converge on the same vocabulary.

A composition can be deployed in either of two modes, and the mode is a property of the deployment, not of the composition. In the flat mode, every peer is equally visible — a federation, a public mesh. In the other, one peer presents a single identity to the outside while the supporting peers are invisible infrastructure: an external client sees one application, and the durable-state peer or the compute pool inside it is not on the public surface at all. The architecture borrows the cell for the picture — one organism outside, a cooperative interior — and the reference workbench is the existence proof: you inhabit one peer, and the operational peer keeping its durable record is not something its users ever address.

What keeps a composition alive rather than deadlocked is a property the catalog rests on: no single component can stall a peer indefinitely — a saturated path surfaces an error to the caller, never an unbounded block. Compositions that would otherwise form a reactive cycle, where two peers each wait on the other’s changes, are kept safe by a design rule on how the coupling is wired rather than by a runtime check. Both of these are recent, and the liveness property is not yet in the normative specification; we present the catalog as the draft guidance it is, sound in the implementations that hold the property in practice.

4.4. Raw Service Use: The Substrate as a Tool

The fourth form is barely an application in the usual sense, and naming it is mostly to bound the space. A developer can use the substrate’s services directly — list a tree, fetch an entity, run a query — the way one uses a filesystem from a shell. One does not usually call a program that navigates a filesystem an “application”; these are the system services that the operating-system view (see DEOS) provides, and a tool that simply exercises them sits at the floor of the design space. It matters because it is where the other forms begin: every wrapped binary and every composition is, underneath, raw service use with structure built on top.

4.5. How the Forms Combine

The forms are axes, not boxes. The wrapped version-control binary operates on an entity-native repository: a program in the second form whose data is in the first. A peer composition can present as a wrapped binary: an internal mesh behind one command-line surface. A content site is entity-native data that a wrapped publishing tool put in place and a wrapped browser reads back. A real application picks a value on this axis for each of its parts, and the interesting ones usually pick more than one. The worked locations later in the paper read several reference applications as exactly these combinations.

5. The Application Lifecycle

The operating-system view assumes a peer is a daemon: it starts, holds its subscriptions, reacts forever. That is the right default for a distributed substrate, but it leaves out the shape most developers reach for first — write a program, run it, get output, exit. Supplying that shape is its own coordinate, and it is one the OS view does not address.

A program, in this setting, needs no new machinery. It is an entity subgraph: an entry-point entity at a known path that the runtime knows how to dispatch, the code it runs (a compute expression, a handler, or a chain), any static data it reads, and the capabilities it needs to touch what it touches. That is the same shape as everything else in the tree; a program is just an entity subgraph with an entry-point convention and a capability story. What a run-mode adds is an execution convention over that data: a peer that boots, loads the program subgraph into its store, dispatches the entry point, bridges whatever the program produces to the outside, and exits when the program is done — rather than staying up and reacting. Boot, load, dispatch, output, exit.

Two more coordinates sit on this lifecycle. The first is lifetime. A one-shot peer runs a program and exits; it may not even want a durable identity, minting an ephemeral keypair for the run and discarding it. A long-lived service stays up and reacts. A persistent, restartable peer stops and starts again with behavior equivalent to one that never stopped, which is what a deployed application that must survive a crash requires. The second is identity depth, and it is a real choice rather than a default. A peer always materializes a root authority over its own namespace at startup, but how much identity it builds on top is up to the application: a bare keypair gives the full capability system, rooted in that one key, and nothing more; the full identity stack adds recovery, attestation, and quorum, at the cost of the machinery to run them. Many applications want the keypair and stop there. The capability system does not depend on the rest; the rest is for the applications that need to survive a lost key or prove who they are to a stranger.

The smallest example that exercises the whole substrate is deliberately not the hardest one. It is a one-way mirror. One peer holds a program; a second peer, with no copy of it, pulls the program subgraph across using the ordinary revision mechanism, dispatches its entry point, prints the result, and exits. No shared mutable state, no merge, no convergence to negotiate — just clone and run. It touches identity, transport, the content store, evaluation, the output bridge, and the exit condition, all on primitives that already exist, and it is the closest thing the system has to a hello-world that shows what it is for: a program is content, content moves between peers by identity, and a peer that receives it can run it.

6. The Programming Model, and Language Agnosticism

Underneath the forms is the question of how an application’s logic is actually written. The substrate’s answer is that computation is data: a program fragment is a content-addressed expression, an entity like any other, and the compute extension is its intermediate representation. Authoring is a stack of rungs over that representation. At the bottom a developer can write the expression entities by hand. Above that, a builder in the host language assembles them with the types checked. Above that, a lowering toolkit turns higher-level constructs into the canonical expression shape; and a surface syntax over all of it is deferred until the lower rungs show what it should target. The honest state is that the lower rungs work and the upper ones are in progress.

A handler’s logic is realized in one of three ways, and the choice is the application architect’s. It can be a precompiled service the system ships; it can be host-language code registered through the SDK, which is the common case and the pragmatic one; or it can be an entity-native expression the substrate evaluates directly. These line up with a gradient from fully inspectable to fully compiled. An entity-native expression is data — every intermediate step is an addressable entity, so the computation can be walked, replayed, and content-addressed — and it pays for that visibility in speed, since the substrate interprets it. A host-language handler is opaque to the entity model but fast, and the dominant idiom in practice is to drop down to it for the parts that need speed while keeping the rest as expressions. A developer can place each component where it needs to be on this gradient, and move a component along it later without changing how the rest of the application calls it, because the interface is the same typed dispatch at every stage. Much of the gradient beyond the inspectable end is designed rather than built; the compute representation is foundational and present, the compilation that would make it fast is largely future work, and we say so.

One more thing about surfaces. An application built on the substrate tends to grow several — a command line, a graphical panel, an embeddable library — and these are not separate programs. They are renders of one underlying shell, the way the shell is itself a render of the SDK and the SDK a render of the protocol. The logic lives once, in handlers and expressions; a surface is a presentation of it. This is why the reference workbench can offer a terminal interface and a graphical one over the same core without building the application twice, and it is the reason these are not, despite the name some of them carry, “just terminal apps.” It is also where the display gap from earlier returns: the substrate carries the surface down to the logic, but the logic up to the pixels — the actual drawing — is still the host platform’s job.

Then there is the language, and it is the property that most clearly separates the entity system from a framework. Rails is Ruby, Django is Python, Spring is Java; the framework and the language come together. Here the contract is the protocol, not a language and not a runtime. A peer is anything that produces and consumes the wire format correctly, and “correctly” is decided by a conformance oracle that checks bytes against the specification, not by sharing an implementation. The Keystone effort makes this concrete: from one specification it generates full core-protocol peers for a target language, and the cohort now spans dozens of them, alongside the three reference implementations in Go, Python, and Rust. The cohort deliberately reaches idioms that ordinarily share nothing — a managed-runtime actor store on one, no garbage collector and explicit allocation on another, a dynamic image-based system on a third. They converge to the same bytes against the same vectors. The generated peers share a generation lineage, so they are not independent implementations and are not counted alongside the three; what they establish is that the specification is precise enough to realize mechanically, which is the property an application architect is actually relying on here. Protocol convergence of this kind is decidable and has been demonstrated; it is the proven half of the system’s story. The other half — whether people adopt it, build on it, and converge socially — is the open one, and no amount of byte-level agreement settles it. For the application architect the consequence is plain: pick the language your team works in, and a peer written in it will interoperate, byte for byte, with peers written in any other.

7. Reaching the Outside World

A content-addressed substrate is, by itself, a closed world: it can talk to itself perfectly and to nothing else. An application that does anything useful has to reach outside it — to a filesystem, to the terminal’s standard streams, to an HTTP endpoint, to an existing database — and the way it reaches is a handler like any other, called a bridge. A bridge speaks the foreign protocol on one side and the entity protocol on the other; its authority, like every handler’s, is bounded by the capability it holds, so a bridge to one external system can do exactly what its grant permits and nothing more. Integration is not an escape from the model. It is a class of handler within it.

The architecture makes the boundary legible by convention: bridges to things the host owns live under a reserved namespace, so a filesystem bridge and a standard-streams bridge sit beside each other as obvious members of the same category, and future bridges — to a network socket, to audio, to the clock — follow the same pattern. The picture the project uses is a closed cell growing pseudopods to touch what is around it: the substrate stays content-addressed and verifiable inside, and the bridges are where it reaches out. The wrapped-binary form depends on exactly this — a command-line tool prints by dispatching through a standard-streams bridge, and reads files through a filesystem bridge — which is why the same small set of bridge handlers recurs across the reference tools.

The worked instance for the wider world is an HTTP bridge: a single handler that fetches a remote resource and returns it as a typed entity. Its load-bearing detail is verification — the caller can supply the hash it expects, and the handler refuses to persist a body that does not match, so a content-addressed system can pull bytes from an ordinary, untrusted origin and still know it got the bytes it asked for. The bridge is GET-only and egress-only in its first version, scoped by a capability that names which URLs it may reach, and it is a draft awaiting sign-off; bridges to databases and other protocols are named but not yet specified. We cite it as the concrete shape the abstract “bridge handler” takes, with its maturity marked.

8. Worked Locations

The way to read the space is to locate real applications in it and read their qualities off the coordinates. The reference applications that exist do exactly this, each landing at a different point.

A content site sits at entity-native form, standard-peer depth, flat deployment. Because it is entities and nothing else, it inherits the substrate’s verification and transfer directly: its qualities are that anyone can re-host it, anyone can check it, and it needs no running server. What it gives up is anything the substrate’s own evaluation cannot express — the form’s reach is the substrate’s reach, which for a document site is enough.

A version-control tool sits at wrapped-binary form over a revision-extension store, one-shot lifetime, keypair identity, command-line surface. Reading those coordinates: a user gets a familiar tool that shells in and out, with a full version history underneath that they never have to think about, an identity that is one key on disk, and no daemon left running. It is the same set of qualities a developer would choose for a small, sharp utility, arrived at by picking that corner of the space.

A web application backed by a database peer sits at client-server or three-tier topology — a frontend, an application-logic peer, a storage peer — and shows that the system is at home in the most conventional shape there is. The qualities it inherits over a normal three-tier stack are the ones from the inheritance section: the tiers speak one protocol, carry one kind of typed content, and authorize uniformly, so the integration between them is not the project.

An interactive workbench sits at peer-composition form in the endosymbiotic mode, full-peer depth, persistent lifetime, with several surfaces over one shell. Its coordinates read as the richest point: a single identity to its user, an operational peer keeping durable state inside, the full inherited property set, and a terminal and a graphical face over the same logic. It is the existence proof that the endosymbiotic mode and the multi-surface render model work, because it is built that way.

8.1. A Repository Whose Tree Is the Artifact

One location is worth more than a coordinate reading, because it is where several of the system’s properties compound. Take the version-control case and push it: put the program itself under version control — its types, its handlers, its compute expressions, all entities in the tree. Then the repository is not a place where the program’s source is stored pending a build. The tree is the program, in the form the substrate runs. Build, package, deploy, and version control, which conventional practice keeps as four separate systems with glue between them, collapse into operations on one content-addressed tree: to ship a change is to move the entities that changed; to deploy is to sync them to a peer; to roll back is to bind an earlier hash.

The nearest prior idea is Unison, where code is identified by the hash of its content and a definition is the same definition everywhere its hash appears. The entity system reaches the same place by a more general route — it content-addresses everything, not only code — and gains two things a file-based version-control system structurally cannot give. The artifact is executable in place: there is no separate build step turning source into a runnable form, because the entities the tree holds are already the form the substrate evaluates. And the authority travels with the artifact: the capabilities a program needs are entities in its tree, so cloning the program clones its authorization story, not just its bytes. What a conventional repository hands you is the source; what this hands you is the running thing and the permission to run it.

These are reference implementations and worked sketches, not products. They are how the patterns in this paper were found, and they are evidence that the patterns hold. Whether they are the best way to occupy these points in the space — whether the version-control verbs are the right verbs, whether the workbench’s composition is the right composition — is exactly the kind of question the system is still early enough to leave open.

9. What Is Demonstrated, and What Is Not

It is worth separating what the reference applications establish from what they do not, because the difference is easy to blur and the corpus’s promise depends on not blurring it.

What they establish is that the patterns hold and the architecture supports what this paper claims it does. A program really can be a peer that boots, runs, and exits; a composition really can present one identity over an interior of supporting peers; a publish-and-fetch path really does move content-addressed bytes through an untrusted origin and verify them on arrival. The collaborative case is worth stating directly, because the temptation is to undersell it: the architecture supports collaborative editing. The pieces it needs — a version history that merges, reactive notification of change, derived values that recompute — are the inherited properties, and a multi-peer collaborative-edit path has been exercised end to end in the reference workbench. What is ahead is not the capability but the product: a polished collaborative editor is a thing to build, and the substrate is in place for one.

What the reference applications do not establish is equally important. They are reference implementations, not production software. The work of building reference architectures and reference applications is a deliberate one — to show what the substrate makes possible and to give a community something to start from — and whether a community adopts them, extends them, or builds its own instead is an outcome, not a claim the paper gets to make. They do not include a display layer; the graphical ones drew their own. And they do not establish behavior at production scale: the implementations have been validated for correctness, across languages and against the specification, not run as long-lived deployments under real load.

That line — correctness demonstrated, adoption and scale open — is the same line the whole system draws. The protocol’s convergence is the decidable, proven half: peers across dozens of languages agree on the bytes, and a conformance oracle settles it. Whether the thing gets used, built on, and chosen — the social convergence — is the genuine unknown, and it is not something a specification can force. Saying so is not hedging. It is the only honest way to offer a substrate to the people who would build on it.

10. Related Work

10.1. Application and Enterprise Architecture

The arrangements this paper’s topology axis maps to — client-server, N-tier, service-oriented architecture, microservices — are the standard vocabulary for structuring and scaling an application, and the entity system inherits the vocabulary rather than replacing it. The difference is at the seams. Each of these styles spends its design effort on the integration between components: the protocols, the message buses, the data formats, the authorization that has to be reconciled across boundaries. On a shared substrate the components already speak one protocol and authorize uniformly, so the architectural shapes survive while the integration between their parts largely does not. The styles describe how to arrange peers; what they no longer describe is glue.

10.2. Application Frameworks

Rails (Hansson 2004), Django (Django Software Foundation 2005), and Spring (Johnson 2002) bundle infrastructure with application code: the framework supplies persistence, routing, authentication, background jobs, and the application supplies domain logic. Two differences stand out. The framework’s infrastructure is the framework’s, incompatible with every other framework’s, where the standard peer’s is the protocol’s and shared. And a framework comes with its language — Rails is Ruby, Spring is Java — where a peer can be written in any language with a conformant implementation. A framework is a way to build one application well; the substrate is a way for applications to share a foundation.

10.3. Local-First Software and CRDTs

The local-first program (Kleppmann, Wiggins, Hardenberg, et al. 2019) and the CRDT libraries that support it (Jahns 2019; Kleppmann, Wiggins, van Hardenberg, et al. 2019) address conflict-free replication without committing to a substrate underneath. The entity system’s relation to them is that a CRDT is a merge strategy its revision extension can carry, and the rest of what a local-first application needs — history, reactivity, transfer, authorization — comes from the substrate in the same model, rather than being assembled around the CRDT.

10.4. Content-Addressed Code

Unison (Chiusano and Bjarnason 2019) identifies code by the hash of its content, so a definition is the same definition wherever its hash appears, and renaming or moving it does not change what it is. This is the idea the repository-as-artifact location rests on, reached more generally: the entity system content-addresses every entity, not only code, so the property Unison gives definitions — identity from content, sameness by hash — it gives data, types, and capability tokens alike. The added step is that the addressed artifact is executable in place and carries its own authority.

10.5. Entity-Component Systems, Reactivity, and Notebooks

Entity-component systems (Unity Technologies 2019; Bevy contributors 2020) use a structural data model — entities as identifiers with attached components — inside a single process; the structural resemblance is real, but the entity system is the distributed generalization, with content-addressed identity and references that cross peers. Reactive programming (RxJS contributors 2012; Pivotal 2013) and the spreadsheet provide the reactive-evaluation model the compute and subscription extensions implement over content-addressed data. Computation notebooks (Kluyver et al. 2016; Bostock et al. 2017) make computation inspectable within a host environment; the substrate’s inspectability is structural and cross-implementation instead, since an expression is an entity any peer can read. The survey is selective by intent — the closest structural neighbors, not an exhaustive map.

11. Discussion

11.1. What the Paper Is and Is Not

This paper is a map of a design space, written for a developer deciding how to build on the substrate. It is not a manual and not a finished account of best practice, because best practice is one of the things the system is too early to have settled. Where a choice in the space has a clear consequence, the paper states it; where the right choice is genuinely open, it says that instead of inventing one.

11.2. What Is Settled and What Is in Motion

Settled: the core protocol and the six primitives under it; the inheritance property, that depth in the substrate hands an application capabilities it would otherwise assemble; and the protocol-as-contract result, demonstrated by conformant peers across dozens of languages converging on the bytes. These are the load-bearing claims, and they rest on running code and a conformance oracle.

In motion: the application-level conventions — the content-site and embed formats, the peer-composition catalog, the HTTP bridge — are recent and mostly in draft, cited here as drafts. The ergonomic layer, the SDKs and the higher rungs of the authoring stack, is being built. The compilation gradient is designed well past where it is implemented. The display layer is not the substrate’s at all. And behavior at production scale is unestablished. None of this undercuts the design space; it sets the date on it.

11.3. A Note on Method

The patterns in this paper were not specified in advance and then implemented. They were found — by building reference applications and noticing that the same shapes recurred, that two tools written for different jobs were the same program, that three independent implementations converged on the same composition. That the patterns emerged from the work rather than being imposed on it is part of why they are offered with the confidence they are, and part of why the open questions are left open: the system is still telling us what it is, and the honest posture is to report what it has shown rather than to legislate what it should be.

11.4. Limitations

• The design space is the paper’s own framing — a useful way to organize the choices, not a structure the architecture defines; a developer may find a coordinate the paper did not name.
• The reference applications are partial and are reference implementations; the scale and adoption questions are open by the system’s own account.
• The application-level conventions cited are drafts and may change.
• Generated under prompt-and-review: this paper, like the rest of the corpus, the supporting implementations, and the architectural specifications, is LLM-generated under direction from the author — the author prompts, evaluates, redirects, and approves rather than authoring text directly. The methodology this enables is described in The Entity Core Protocol.

12. Conclusion

An application on the entity system is a location in a design space, not an instance of a template. The coordinates a developer chooses — how much substrate to stand on, what the application is, how it is deployed, how long it lives, how deep its identity goes, and in which language it is written — determine what the application inherits and what it has to build. A bare peer is already an application; an extension raises the floor rather than adding a subsystem; a single local peer and a federated mesh are the same substrate installed as peers. The work of application architecture here is picking where to stand and knowing what that gives you.

Two properties make the picking worthwhile. A location inherits what a conventional application assembles — storage, versioning, reactivity, durable workflows, authorization — so the developer writes domain logic instead of integration. And the contract is the protocol, not a language, so the architect picks the language and the peers still agree. The familiar shapes of application and enterprise architecture survive the move; what does not survive is the glue between their parts.

Three things sit open alongside the model, by design. An application concern that maps to no axis and no form in this space would show the space is incomplete, and we would want to know which one. A form of application not reducible to the four named here — entities the substrate runs, a binary wrapping a peer, a composition of peers, raw service use — would extend the map. And the largest open question is not structural at all: whether people build on this. The protocol’s convergence is proven; the social convergence is not, and cannot be forced. The substrate is offered as a thing to build on, with its early state stated plainly, in the belief that the honest version is the one worth offering.

The Decentralized Systems Landscape: Content, Identity, Consensus, and Compute

1. Introduction

The effort to decentralize computing has not produced one system or one field. It has produced four, loosely related and mostly studied apart. One set of systems moves content without a server: you fetch a file from whoever has it, verified by its hash, and the origin need not be anyone in particular. Another set carries social identity and publishing without a platform owner: your account, your posts, your follow graph live across independently run servers, or on relays, or in a portable repository, rather than inside one company. A third set lets mutually distrusting strangers agree on a single shared state — a ledger of who owns what — with no admission control and no trusted operator. And a fourth set runs computation that a relying party can trust without re-doing or being shown it: a contract that executes the same way for everyone, a proof that a computation was performed correctly, an enclave that attests to what it ran, a credential signed by an issuer you accept.

These four are rarely placed on the same page. A developer who has internalized how BitTorrent swarms distribute a file starts from scratch when reasoning about how a blockchain orders transactions, and again when reasoning about how the Fediverse federates a timeline, and again when reasoning about what a zero-knowledge rollup actually proves. The vocabularies diverge, the communities barely overlap, and the result is that the decentralized field is hard to see whole. This paper tries to see it whole — not by reducing the systems to one mechanism, but by mapping them on a small set of shared dimensions and reading the map for what it shows.

The dimensions are few and concrete. How is a thing addressed — by where it sits, by the hash of its content, by the key of its writer? How does identity work — is it a server-bound handle, a bare keypair, a portable identifier? How is access controlled — not at all, by a coarse public-or-private flag, by fine-grained permission? What posture must a participant hold to take part — must they stay online and serving, or can they go passive and still count? How is trust in a computation established — by re-running it, by checking a proof, by trusting hardware, by trusting a signature? And how decentralized is the system once it is actually deployed, as opposed to in its design documents? These six questions are enough to place every system in the field beside every other.

A pattern emerges when the systems are laid out this way, and it is the paper’s main observation. Each deployed system occupies one region of the field at a fixed posture, and pays the characteristic cost of that fixity. A BitTorrent file is available only while someone is online seeding it; the price of its swarm model is that the long tail of unpopular content simply disappears. A Mastodon identity is your server’s to keep or lose; the price of federation-by-server is that migrating means abandoning your posts. An on-chain contract is trusted because every node in the network re-executes it; the price of that trust is that running code this way is among the most expensive ways to compute anything. None of these is a defect — each is the cost of a deliberate choice to fix one posture — but the costs rhyme across the field, and seeing them lined up is most of what the map is for.

The stance of the paper is cartographic, not competitive. We describe what is in the field and place every system on the same axes; we do not grade them or argue that one beats another, because that is not what a map is for and because the systems are answering genuinely different questions. The compute cluster, in particular, sorts so cleanly that it gets its own small map: there turn out to be five ways the field establishes trust in a computation, and naming them is one of the more useful things this survey can offer.

We do locate one further point on the map, and we are deliberate about how. Across this series of papers we have developed a content-addressed, typed, capability-secured substrate — the entity system (see The Entity System; The Entity Core Protocol) — and it belongs on this map because it speaks to all four clusters at once. But we place it the way we place every other system: on the same axes, described rather than sold. Its distinguishing position, when plotted, is that it can move posture rather than fixing one, and that it spans regions a single deployed system tends not to. We are equally explicit about where it is not on the map at all — it has no deployed users where the incumbents have tens of millions, and the properties it leans on, content addressing and signed identity and key-based control, are prior art it shares with IPFS and Hypercore and Nostr, not things it invented. The contribution of this paper is the map, and the entity system is one point in it.

1.1. The Boundaries with the Other Views

This paper is a survey of the outside field, and it sits beside three companion papers that look inward at the substrate, so the seams are worth naming. The structural landscape — what primitives each existing system is built from, analyzed by the methodology this corpus develops — is Convergent Evolution; where that paper asks what a system is underneath, this one asks what it is like deployed, what people run and at what cost, and cites the structural account rather than re-deriving it. The view of the substrate as the operating system of one’s own machines is DEOS, and it hands off to this paper exactly where a private fleet of devices meets the wider network of other people’s fleets. The view of the substrate as something a developer builds an application on is Application Architecture. Those three are about running and building on the substrate; this one is about the field the substrate would join, mapped on its own terms.

1.2. What This Paper Covers

1. The deployed field, cluster by cluster: content distribution, social and identity, consensus and ledgers, and contractual and verifiable compute — each as a deployed reality, with the posture it forces and the cost it carries.
2. The dimensions of the map — addressing, identity, access, posture, compute-trust, and decentralization-in-practice — drawn across all four clusters, with the comparison table that lays the field out at once.
3. The compute and trust models — the five ways the field establishes trust in a computation, the richest single dimension.
4. The entity system as one point on that map — where it falls, where it spans regions, and where it is honestly not comparable.
5. Social convergence — the open question of what people actually adopt, which no amount of technical merit settles.

1.3. What This Paper Does Not Cover

The six primitives and the substrate they generate are in The Entity System, The Entity Core Protocol; the computational model in The Entity Church Architecture; the structural analysis of the existing-systems landscape in Convergent Evolution; the operating-system view in DEOS; the application-development view in Application Architecture; and the capability and security model the map refers to in Entity System Security Architecture. We assume those and do not re-derive them. We also do not attempt a complete census of the decentralized field, which is vast and moving; we map the systems that anchor each cluster and are most instructive, and we mark where currency-sensitive facts may have moved by the time this is read.

2. The Deployed Field

The map is easier to read after a walk through the territory. We take the four clusters in turn, describing each system as it actually runs — the posture it forces and the cost that posture carries — rather than as its specification promises. Throughout, we cite the structural analysis (see Convergent Evolution) for why a system has the shape it does, and concentrate here on what that shape is like to live with.

2.1. Content Distribution

The oldest decentralized success is moving bytes without a central server. BitTorrent (Cohen 2003) does it by swarming: a file is split into hash-verified pieces, and every peer downloading also uploads, so popular content gets faster as more people want it — the one place in this whole field where load is a help rather than a cost. Discovery moved from central trackers to a distributed hash table (Maymounkov and Mazières 2002), so a magnet link needs no server at all. The posture BitTorrent fixes is the online, reciprocating peer: content exists exactly as long as someone is seeding it. The price is the dead torrent — the long tail of content with no seeders is simply gone, the distributed hash table remembering who claimed to have it but not the bytes. BitTorrent has no identity and no access control; the infohash is an unscoped bearer token, and a private torrent is private only because a community gatekeeps a tracker and keeps the hash secret.

IPFS (Benet 2014) generalizes content addressing from a whole torrent to every object: content is chunked into a Merkle structure, each node named by the hash of its bytes, so identity and integrity are intrinsic and identical content is automatically one thing. It adds peer identity and a signed mutable-pointer layer, which BitTorrent lacks. But the posture is much the same: content lives only while a node pins it and stays reachable, and unpinned data is garbage-collected. IPFS is widely mistaken for permanent storage; it is content-addressed caching with opt-in pinning, and permanence is a service one buys or runs. In practice the network re-centralized in two familiar places — a handful of public HTTP gateways through which most consumption flows, and a few commercial pinning services on which persistence concentrates — a drift the project itself names and is working to counter. One nuance matters for the map: because content is self-verifying, any holder can serve it and a client can check what it received, so a passive store can serve trustworthy bytes; what it cannot do is announce itself, so discovery still wants a live provider.

Hypercore (the protocol that grew out of Dat (Ogden et al. 2017; Holepunch 2023)) inverts the addressing choice instructively. Where BitTorrent and IPFS address immutable content by its hash, Hypercore addresses a signed, append-only log by its writer’s public key — the unit is a mutable, versioned stream owned by a keypair, with full history and the ability to fetch only the ranges you need. This is the deployed system closest to a signed, identity-rooted, mutable model, which makes it the most demanding comparison for anything claiming those properties. Its fixed posture is single-writer (multi-writer is an add-on), and like the others its availability still depends on someone staying online to replicate from. Its real deployment is small next to BitTorrent and IPFS, but it is the clearest evidence that “content addressing versus nothing” is a false binary — signed mutable streams are a third, well-explored point.

2.2. Social and Identity

The second cluster decentralizes publishing and social identity, and its systems share one defining trait worth stating before the differences: all of them are public-broadcast-first. None was designed primarily for private, selectively shared, or finely permissioned content, and each is now retrofitting that, late and partially. That shared gap is the cluster’s most important single fact.

ActivityPub (World Wide Web Consortium 2018), deployed mainly as Mastodon, federates servers: thousands of independently run instances exchange signed activities, and the unit of the network is the server, not the user. Your identity is your handle at your instance, your data lives in that instance’s database, and the instance holds your keys and must stay online for you to exist on the network. The posture is “be, or be hosted by, an always-on server.” The cost is that your identity and your history are hostages of one operator: account migration carries your followers but not your posts, and if your instance shuts down, your reach and your archive go with it. Visibility is a coarse server-enforced flag, and direct messages are not end-to-end encrypted — the admins on both ends can read them.

The AT Protocol (Bluesky Social 2024), deployed as Bluesky, splits the monolithic server into a personal data repository (a signed, content-addressed tree of your records), relays that aggregate everyone’s repositories into one firehose, and application views that build the actual product from that firehose, with identity carried by a decentralized identifier. This is architecturally the most interesting of the three for our map, because the repository is signed and content-addressed and can therefore be mirrored and verified independently — the closest the deployed social field comes to “a passive store can serve you.” Its headline is portability and “credible exit”: because your identity is a portable identifier and your data is a signed repository, you can in principle move your hosting and keep your identity and your posts, which Mastodon cannot offer. Honestly assessed, the exit is more credible than anywhere else here and less credible than the marketing: the identifier directory almost everyone uses is operated by one company today, and while the protocol permits many relays and application views, few run at scale, so the experience is in practice gated on a handful of central services. Private and permissioned data is not shipped; it is an active design effort.

Nostr (The Nostr Contributors 2023) is the minimal design: a client signs an event and pushes it to relays, which are dumb store-and-forward servers that do almost no logic, and clients reconstruct a view by querying many relays and merging. Identity is a bare keypair, bound to no server — the strongest identity portability in the field, since you are the same identity on any relay and can abandon any of them. The cost is the mirror image of Mastodon’s: nothing guarantees your content survives, is found, or is recoverable. Relays prune and come and go; key loss is final, with no recovery or rotation in practice. Nostr is public-by-default, with private messages available through a layered encryption convention but no capability model — the choice is “encrypt to a public key” or “broadcast,” with nothing structured in between. Its topology is the most decentralized here, yet it re-concentrates on a few popular relays because that is where the audience is.

2.3. Consensus and Ledgers

The third cluster solves a genuinely hard and distinct problem: letting mutually distrusting parties with no admission control agree on a single shared state. Bitcoin (Nakamoto 2008) produces one global, append-only ledger that every full node independently holds and validates, ordered by proof of work and a heaviest-chain rule, with agreement that is probabilistic — a transaction is never provably final, only exponentially unlikely to reverse. This is the open-membership case classical protocols cannot touch, and it is a real achievement. Its cost is structural: global redundancy, where every node stores and re-validates all history, deliberately the opposite of partitioning; a throughput ceiling of a few transactions per second; and proof of work’s standing energy cost, which is the literal mechanism by which the right to extend the chain is made expensive enough to resist forgery. Ethereum (Buterin 2014) keeps the one-global-ledger model but, since moving to proof of stake, derives its Sybil resistance from staked capital and slashing rather than burned energy, and offers sharper, checkpoint-based economic finality. What this cluster is for is trustless agreement among strangers; what it is wrong for is personal, private, mutable, or high-volume data, where having every node on earth hold a copy is a category error.

Behind the blockchains stand the classical consensus protocols they extend. Paxos (Lamport 1998) and Raft (Ongaro and Ousterhout 2014) give a provably linearizable replicated log — all correct replicas agree on the same sequence of commands — under crash faults, assuming known membership, quorums, and an elected leader; Byzantine fault tolerant protocols (Castro and Liskov 1999) give the same under up to a third of the participants behaving arbitrarily, at the cost of more nodes and more rounds, still with fixed membership. These run the coordination services and replicated databases that much of the centralized internet quietly depends on. Their relevant trait for the map is the one the open ledgers relax: with known membership they are cheap and provably correct, but a node on the minority side of a network partition blocks rather than diverging — it stops, by design, to preserve consistency. That deliberate choice, consistency over availability under partition, is the axis along which the rest of the field — and the substrate we will place — chooses differently.

2.4. Contractual and Verifiable Compute

The fourth cluster is about running computation that someone else can trust, and it is rich enough that its organizing structure — five distinct ways trust is established — gets its own section. Here we name its members. Smart contracts (Szabo 1997), deployed at scale on Ethereum’s virtual machine and its kin, are deterministic programs executing on a replicated state machine, trusted because every node re-runs them and must agree on the result. Non-fungible tokens (Entriken et al. 2018) are, stripped of the hype, ownership records over a token on such a chain, whose referent — the image, the metadata — usually lives off-chain, frequently as an IPFS hash, tying this cluster back to the first. Zero-knowledge proofs and the rollups built from them (Ben-Sasson et al. 2018) establish trust a different way: execute off-chain and post a succinct proof that the execution was correct, so a verifier checks the proof instead of re-running the work. Trusted execution environments (Costan and Devadas 2016) establish it in hardware, isolating and attesting which code ran, trading correctness-by-redundancy for trust in a chip vendor. Secure multiparty computation (Yao 1982) and fully homomorphic encryption (Gentry 2009) establish confidentiality rather than mere correctness, computing over data without exposing it. And underneath all of them, decentralized identifiers and verifiable credentials (World Wide Web Consortium 2022; World Wide Web Consortium 2025) carry the trust-the-signature model into decentralized identity — a signed claim a verifier checks against an issuer it accepts, without re-execution or proof. The next section draws these five into one small map.

3. The Dimensions of the Map

The walk through the clusters surfaces a small set of axes that recur in every one of them. Drawn together, they are the map’s coordinate system, and they let a system in one cluster be compared with a system in another — which is the point of mapping the field as one thing.

• Addressing. By location (a server URL), by the hash of content (a content identifier, an infohash), or by the key of a writer (a public key, a decentralized identifier). Content and key addressing decouple a thing’s identity from where it sits, which is what makes verifiable re-hosting possible.
• Identity. Bound to a server (a Fediverse handle), a bare keypair (Nostr, most chains), or a portable identifier with indirection (the AT Protocol’s). The axis that decides whether leaving a service means leaving yourself behind.
• Access and capabilities. None (a bearer hash), a coarse public-or-followers flag, encryption to a recipient, or fine-grained per-resource permission. The cluster of social systems sits, almost entirely, at the public-or-encrypt end.
• Posture and persistence. What a participant must do to keep taking part and to keep their data available: stay online and serving (BitTorrent, a Mastodon server), keep republishing to live relays (Nostr), pin (IPFS), or — a possibility most of the field does not offer — park signed, self-verifying state somewhere passive and remain a participant.
• Trust in computation. The compute cluster’s axis, drawn out in the next section: re-execute, prove, attest, hide, or sign.
• Decentralization in practice. Distinct from decentralization in design. Nostr’s topology is maximally decentralized yet its traffic re-concentrates on popular relays; the AT Protocol is the least decentralized in practice yet the most coherent as a product; IPFS is decentralized in principle and gateway-mediated in fact. This gap is the axis the map is most useful for, because it is the one marketing most often elides.

The table places the anchor systems on these axes at a glance, with the substrate this series develops added as the final row — placed the same way, on the same axes, and taken up in detail in its own section below. It is a reading aid, not a scorecard; a cell that looks thin is the cost of a posture chosen for a reason.

Read down any column and the field’s range is visible; read across any row and one system’s whole posture is. The recurring lesson, stated once: a system that decentralizes one thing well usually does so by fixing a posture on the others, and the map’s value is making that trade legible rather than hidden. The substrate’s row is the visible exception — a movable posture where every other row fixes one, and a fine-grained capability where the field sits at public-or-encrypt — which is why it earns its own section rather than a single line: the row places it on the axes, and the section reads what the placement means.

4. Compute and Trust Models

The compute cluster rewards a closer look because it sorts so cleanly. Strip away the branding and there are exactly five ways the decentralized field gets a relying party to trust a computation or a claim. Naming them is, we think, the most useful single thing this survey produces, because once named they are visible everywhere.

Verify by re-execution. Everyone re-runs the code and agrees on the identical result; trust comes from redundancy. This is the smart-contract model: a deterministic program on a replicated state machine, metered so it must halt, its state and bytecode public. It buys the strongest property in the field — agreement among mutually distrusting strangers with no trusted operator — and pays the steepest cost, because running code that the entire network must re-execute is the most expensive way to compute, with no privacy and a hard throughput ceiling. It is trust by having the whole world watch.

Verify by proof. Execute once, off to the side, and produce a succinct cryptographic proof that the execution was correct; a verifier checks the proof, which is far cheaper than redoing the work. This is the zero-knowledge model, deployed at scale as rollups that execute transactions off-chain and post a validity proof on-chain. Two honest qualifications belong on the map: “zero-knowledge” in this usage usually means succinct, not hiding — the value is compressed verification, and the privacy property is often unused — and most production systems today still run a centralized sequencer and a permissioned prover, so the proof is trustless while the ordering and liveness around it are not yet. The direction of travel is real and the proofs are sound; the decentralization is partial.

Verify by attestation. Run the computation inside a hardware-isolated enclave that attests, cryptographically, which code it ran, so a remote party can trust the result without seeing the data. This is the trusted-execution model, deployed as confidential virtual machines on the major clouds. It uniquely offers confidentiality during computation, but its trust roots in the hardware vendor and its microcode, and the lineage has a long history of side-channel breaks — “secure,” with the threat model spelled out.

Privacy by protocol. A cryptographic protocol lets parties compute over private inputs while revealing only the output, with no trusted host at all — secure multiparty computation, mature in narrow high-value niches like threshold key custody — or compute directly on encrypted data — fully homomorphic encryption, the strongest confidentiality story and the least mature, still carrying large overheads. Trust here comes from the mathematics rather than from redundancy, hardware, or a signer.

Trust the signature. No computation is re-run, proven, or attested; a claim is trusted because it carries a signature chain to an authority the verifier already accepts. This is the oldest model — classical public-key infrastructure and certificates — carried into the decentralized field by decentralized identifiers and verifiable credentials (World Wide Web Consortium 2022; World Wide Web Consortium 2025), where a holder presents a signed claim and a verifier checks the issuer’s signature without contacting the issuer. It is the cheapest to verify and the model most of digital identity actually runs on.

These five differ along clear sub-axes: the scope of trust (everyone, a verifier, a hardware vendor, the protocol’s participants, whoever accepts the issuer), whether the computation is confidential, and the shape of the cost (redundant work, expensive proving, near-native plus attestation, heavy cryptography, a single signature check). A secondary axis cuts across all five — where the computation is replicated: globally on a chain, off-chain with on-chain verification, on a single attested host, or among a few protocol participants. Laid out this way, the compute cluster is not a pile of competing buzzwords but a small, legible space, and a system can be located in it precisely.

5. The Entity System on the Map

The substrate this series develops (see The Entity System; The Entity Core Protocol) goes onto the map like everything else — on the same axes, with its costs and its absences stated as plainly as anyone else’s, and described rather than sold.

On the addressing and identity axes it sits with the content- and key-addressed systems: entities are named by the hash of their content, identity is rooted in keys, and both are therefore independent of where a thing is stored. This is shared ground with IPFS, Hypercore, and Nostr, not new ground, and saying so is part of placing it honestly. Where it differs is the access axis, where most of the field sits at public-or-encrypt: the substrate’s unit of authorization is a fine-grained, attenuable, revocable capability that travels with the artifact (see Entity System Security Architecture), so private and selectively shared state is native rather than retrofitted. That difference is thrown into relief by the social cluster’s defining trait — those systems are public-broadcast-first and are adding permissioned data late and partially — which is the clearest evidence in the field that fine-grained capability is a real gap and not a solved corner.

On the compute axis, the substrate falls in the re-execution family by mechanism — computation is content-addressed and deterministic, so a result can be re-run and checked by anyone holding the inputs, or trusted directly by its hash (see The Entity Church Architecture) — but at a scope the compute map does not otherwise contain. Where a smart contract is re-executed by every node in a global network to reach agreement among strangers, the substrate’s compute is verified at peer scope: a party who cares re-runs it or trusts its hash, and there is no requirement that the whole world re-execute and no global ledger ordering one shared state. It is a new cell — deterministic, verifiable compute at local scope, access-gated by capabilities, with no global consensus — and its nearest neighbor is not a blockchain virtual machine but the reproducible-build, content-addressed lineage of Git and Nix, extended from artifacts to computation.

The trait that distinguishes the substrate across the whole map, rather than on any one axis, is posture. Every deployed system in the field fixes one: the online seeder, the always-on server, the pinning node, the full validator. The substrate’s posture is movable, because state is content-addressed, signed, and capability-rooted wherever it sits, so the same participant can be a live peer, or park its state on a passive store and go quiet, or poll when weak, or work offline and reconcile later — and a static host serving signed, self-verifying entities is a first-class participant, not a dumb cache. The field’s nearest approaches to this are instructive and worth crediting: IPFS’s verifiable gateways already let a passive store serve trustworthy bytes, and the AT Protocol’s signed repository can already be mirrored and verified. The substrate’s distinct position is the full range of postures as a property of one system, and that a passive participant is an authorized one, discovery and access included, rather than only a server of verifiable bytes. That movable posture also makes it scale-independent: with no posture forced and no central operator required, the substrate works as readily between two peers on a home network as across many, so its decentralization is a structural property rather than a deployment statistic — which is what the map’s practical-decentralization cell records for it, what its operation requires rather than how many run it.

What the substrate provides on the consensus axis must be stated with care, because it is the easiest thing in this field to overclaim, and the honest version is sharper. It provides convergence, not consensus. Peers reconcile a content-addressed version history by walking to a common ancestor and merging, surfacing conflicts as data rather than blocking on agreement; this yields eventual, partition-tolerant convergence whose single-valued result is guaranteed only when the merge is a proper join, and otherwise guarantees the weaker but still useful property that divergence is represented rather than silently lost. Strict linearizable consensus in the Paxos or Raft sense — one agreed log with bounded failover — is not provided. The primitives could be configured toward it, with a write capability serving as leadership and a quorum over published heads as commitment, but that is a sketch, unproven under a fault model and unshipped, and a single, totally ordered log arises directly only under a single writer, where the problem is replication rather than agreement. Nor does content addressing buy Byzantine agreement: it detects tampering with content, not lying about which version is canonical, so the substrate is partition-tolerant with cryptographic integrity, not a Byzantine fault tolerant protocol and not the trustless-among-strangers agreement that a blockchain exists to provide. It occupies the available, capability-scoped, offline-first, integrity-verifiable corner of the space — a different problem from the one consensus protocols solve, and strictly weaker than they are on the one problem they are built for.

Three absences round out the honest placement. The substrate is not zero-knowledge or succinct — re-running to verify is the opposite of checking a proof cheaper than the work. It is not confidential compute — it is public to whoever holds the inputs, with capabilities gating access rather than visibility during computation the way an enclave or a multiparty protocol does. And it has no deployed user base where the social and ledger incumbents have tens of millions; its richer model is unproven at the scale they have reached, and it carries operational questions — moderation, abuse, key compromise, revocation at scale — that capability-based and content-addressed designs raise freshly rather than inherit solved. And the map captures only the substrate’s outward, networked face: its role as the programming substrate that applications are built on Application Architecture and as the operating system of one’s own machines (see DEOS) are powers these axes are not built to show, so placing it among deployed networks is fair only with that limit named — it is being measured here on one of the several things it is. The point of placing the substrate on the map is not to crown it. It is to show that a system shaped as a substrate rather than an application lands not in one region but across several, and that this spanning is itself the interesting property — the same observation the companion papers make from the inside, that the substrate fits wherever you point it (see DEOS; Application Architecture), seen here from the outside, against the field.

6. Social Convergence

A map of technical positions is not a map of what people use, and the gap between the two is the decentralized field’s most honest open question. It is worth separating two kinds of convergence that the field’s discourse routinely runs together.

The first is protocol convergence: whether independent implementations of a system agree, down to the bytes, on what is valid. This is a decidable property, and for a well-specified protocol it is achievable and checkable — the systems in this survey that are precisely specified can be implemented compatibly by parties who never coordinate, and that is a real and provable kind of agreement. It is the kind this corpus reports elsewhere as settled for the substrate.

The second is social convergence: whether people choose to run a thing, build on it, bring others to it, and stay. Nothing technical forces it. The standing evidence is in the deployed-user numbers this survey has been careful to cite — the social and ledger incumbents carry user bases orders of magnitude larger than anything newer, including more elegant designs, and a system’s position on the map predicts very little about whether it will be adopted. Network effects, timing, funding, community, and accident do most of the work, and a better answer to a technical question loses to a worse answer with a head start more often than not.

This bears on every system in the field, and on the substrate placed among them, in the same way. A favorable position on the map — spanning regions, moving posture, controlling access finely — is a reason a thing could be adopted, not a reason it will be. The properties that lower the cost of leaving a system and starting in another, the portability and the absence of lock-in that several systems here pursue and the substrate shares, plausibly lower the activation energy for social convergence; they do not generate it. The cartographer’s honesty is to map the technical terrain accurately and to decline to predict the weather. What people run is decided in a space the map does not cover, and saying so is not a hedge — it is the one claim about adoption that the evidence actually supports.

7. Discussion and Conclusion

The contribution of this paper is the map: one field where the literature usually sees four, laid out on a small set of shared axes so that a content-distribution system and a consensus protocol and an identity scheme and a compute model can be read against one another. The map’s two most useful products are the five-way structure of the compute cluster — re-execute, prove, attest, hide, sign — and the recurring pattern across all four clusters, that each deployed system decentralizes one thing well by fixing a posture on the rest, and pays the characteristic cost of that fixity. Seeing the costs lined up is most of what mapping the field whole is for.

The one further point we placed on that map, a content-addressed, typed, capability-secured substrate, is instructive not for superiority on any single axis — its addressing and identity are shared prior art, its consensus is weaker than a real consensus protocol, it has no deployed users — but for spanning regions a single deployed system fixes one of, and for moving posture where the others choose one — which it can do because it is a substrate rather than an application. That spanning is the same property the companion papers describe from inside the substrate (see DEOS; Application Architecture), visible here from outside, against the field it would join.

This is a map of a moving field, and we have tried to date it honestly rather than freeze it. Several facts most likely to drift were flagged where they appear: the social protocols’ private-data and governance efforts are in active development; the zero-knowledge systems’ decentralization of sequencing and proving is partial and advancing; the deployed-user figures are volatile and were given as ranges; and the credential standards are newly ratified. A reader should re-check the currency-sensitive cells before relying on them. The structural account that explains why the systems have the shapes they do is Convergent Evolution, and is the companion to this deployed account.

We close, as the other papers in this series do, with the invitations a map makes available. A decentralized system that the six axes cannot place — one whose addressing, identity, access, posture, compute-trust, and practical decentralization do not locate it — would show the coordinate system is incomplete, and we would want to know which axis it needs. A participation posture the field forces that this survey did not name would extend the persistence axis. And a sixth way of establishing trust in a computation, beyond re-executing, proving, attesting, hiding, and signing, would extend the compute map and would be, of everything here, the most interesting thing to find. The field is young enough that all three are live possibilities, and a map’s purpose is partly to make its own gaps visible.