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).