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

The Entity Core Protocol: Wire Format, Dispatch, and Capability Verification

1. Introduction

This paper presents the Entity Core Protocol: a protocol for distributed information systems defined by six primitives.

The six primitives are:

• Entity: the typed data unit — {type, data}
• Identity: content-derived hash — same content, same identity, everywhere
• Tree: mutable namespace — path $\to$ hash bindings over immutable content
• Emit: the atomic state change — Store (content) and Bind (tree), each independently observable
• Execution: typed dispatch — EXECUTE and EXECUTE_RESPONSE
• Peer: the participant — identity, capabilities, connection

These six are irreducible. A reducibility analysis on the resulting protocol shows that removing any one primitive loses expressiveness — you do not get the system. The structure of the primitives is the system.

The paper presents them in the order the spec develops them — foundations, types, protocol messages, connection, capabilities, handlers — then examines the properties that arise and the extension architecture that composes on top.

The cycle that produced the spec: mechanisms were built to face each next concern, then removed where the entity model could absorb them, then built again, then reduced again, until the cycle stopped finding things to remove. The protocol shrank while the type system grew. What remains is minimal — there is nothing left to remove. The architectural methodology that drove this cycle — simplicity, convergence as the stopping rule, mathematical structure where it reaches, considered convention where it does not — is described in The Entity System and applied here as the lens through which the spec was assembled.

2. Background

Just enough to situate the protocol; the full landscape is in Convergent Evolution.

2.1. Content Addressing

Git, IPFS, Nix: content-derived identity in specific domains (version control, distribution, builds). Each gets immutability, deduplication, verification. None carries type information with the data. None generalizes to a protocol with dispatch or capabilities.

2.2. Typed Protocols

Protobuf, Cap’n Proto, gRPC, Thrift: typed messages, but schemas are external — compiled from definition files, not carried with the data. The data doesn’t know its own type. No content addressing.

2.3. Capability Systems

Macaroons, UCAN, Biscuit: authorization with delegation and attenuation. Not integrated with content addressing or typed data. Authorization as a separate subsystem attached to other protocols.

2.4. Distributed File Systems

Plan 9/9P, Inferno/Styx: everything as files, namespace composition. Untyped bytes on the wire. No content addressing. Per-connection auth (which breaks when data is mobile across connections).

2.5. What’s Missing

Existing systems implement subsets of the six primitives. Content-addressing systems lack types. Typed protocols lack content addressing. Capability systems are bolted on. No existing system integrates all six as a coherent minimal protocol. The entity core protocol does.

3. Foundations

The structures the rest of the protocol builds on.

3.1. Entity

The fundamental data unit:

Entity := { type: string, data: any, content_hash: bytes }

Type is constitutive — an entity without a type is not an entity. This distinguishes it 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. Content Hash

content_hash(entity) = format_code || SHA256(ECF_encode(type, data))

Input: {type, data} only — the hash itself is not hashed. ECF = Entity Canonical Form: deterministic CBOR (RFC 8949 §4.2). Same {type, data} $\to$ same hash, everywhere, always. Different type $\to$ different hash even with identical data. Identity is intrinsic.

Format code byte pins both the encoding version and hash algorithm. Current: 0x00 = ECFv1-SHA-256, 33 bytes total.

Consequences of content-derived identity:

• Immutability: changing content changes identity — it’s a new entity
• Deduplication: same content stored once, referenced everywhere
• Verification: anyone with the hash can verify the content
• Convergence: peers with the same hash at the same path have converged

3.3. Entity Canonical Form (ECF)

Deterministic CBOR encoding rules ensuring identical bytes for identical data:

• Map keys sorted by encoded byte length, then lexicographically
• Minimal integer encoding; definite lengths only
• Shortest float preserving value; no duplicate map keys
• All field values preserved (entity fidelity)

3.4. URI and Path Model

URI := "entity://" peer_id "/" path

All paths are peer-namespaced. Short-form URIs (no prefix) scope to the local peer. Paths are UTF-8; / separates segments; * is reserved for capability patterns.

Dispatch routing: a peer processes only requests targeting itself. Cross-peer forwarding is provided by extension (relay), not core dispatch.

3.5. Identity

PeerID := Base58(key_type || hash_type || SHA256(public_key))

Ed25519 key pairs. Peer identity is derived from the public key — content-addressed identity applied to participants, not just data.

3.6. Storage: The Two Address Spaces

Content Store: hash → entity   (immutable, deduplicated)
Entity Tree:   path → hash     (mutable, namespace)

The content store is “what things are.” Append-only. The entity tree is “what things are called right now.” Bindings change.

These two spaces are forced: if identity = content, content can’t change, but you still need “the current version.” The tree is that mutable layer. Together they give versioning by construction — rebinding a path preserves the old entity (it still exists by hash).

The tree is a logical namespace (flat path $\to$ hash mapping), not a filesystem. A path may be simultaneously bound to an entity and serve as a prefix for child paths.

3.7. Envelope Structure

Envelope := { root: entity, included: map<hash, entity> }

Root: the primary entity. Included: flat map of referenced entities. Sender controls materialization depth. Same structure for wire and storage. No re-encoding at boundaries.

3.8. Entity Fidelity

Implementations MUST:

• Validate hash on receipt (recompute from {type, data}, compare)
• Trust validated hash for all subsequent operations
• Store and forward original bytes (no re-serialization)
• Preserve unknown fields (forward compatibility)

3.9. Namespace Design

Two layers: structural (dispatch, capability scoping, self-description) and naming (paths, domain grouping, conventions). Structural properties are mathematical — would be rediscovered by any implementation. Naming is design within the space structure leaves open. The sole structurally fixed path: system/protocol/connect (connection handler). All other paths communicated through initial capability grants.

4. Type System

Types are entities; entities carry types.

4.1. Type Definition

Every type is an entity of type system/type:

system/type := {
  name:        type_name,
  extends:     type_name?,
  fields:      map<string, field-spec>?,
  layout:      [string]?,
  type_params: [string]?,
  type_args:   map<string, type_name>?
}

Types stored at system/type/{type_name} in the entity tree. Types are entities. Entities carry types. This recurses.

4.2. Bootstrap Types

The type system is seeded by fourteen bootstrap types: eight primitives (string, bytes, uint, int, float, bool, null, any) and six structural types — system/hash, the meta-type system/type, system/type/field-spec, system/tree/path, system/type/name, and system/identity/peer-id. The structural root entity ({type, data}) is built from them.

These fourteen are sufficient to describe all types — including themselves. system/type is itself a system/type. This is a fixed point.

Self-description is not a designed feature. It’s what happens when everything is entities: descriptions of entities must also be entities, described by the same type mechanism. The recursion bottoms out at the bootstrap types.

The protocol’s own constructs — handlers, capability tokens, grant entries, envelopes, execute and execute_response, signatures, operational state, errors — are themselves entity types, defined from the bootstrap set rather than added to it.

4.3. Structural Typing

Types describe shape: fields, field types, optionality. Validation is structural: does this entity match its type definition? Single inheritance via extends. Open types preserve unknown fields. Generics via type_params/type_args.

4.4. Types Cross the Wire

Unlike Protobuf (schemas compiled from .proto files) or Inferno (bytes on the wire, types only in application code), entity types travel with the data. The protocol is typed end-to-end: no type gap at protocol boundaries. A handler receives typed params, returns typed results. The tree stores typed entities. The wire carries typed entities.

5. Protocol Messages

The protocol has two message types.

5.1. EXECUTE

The request: dispatch typed parameters to a handler.

system/protocol/execute := {
  request_id, uri, operation, resource?, params,
  author, capability, deliver_to?, bounds?
}

Every interaction is an EXECUTE: queries, mutations, subscriptions, connection setup. The operation vocabulary is unbounded — any handler can define any operation. The message structure is fixed.

5.2. EXECUTE_RESPONSE

The response: deliver a result entity to the caller.

system/protocol/execute_response := {
  request_id, uri, result, status, deliver_to?
}

5.3. Why Two Suffices

Every distributed interaction is “I want something done” + “here is the result.” The “something done” is parameterized by handler, operation, and resource. There is no interaction pattern that requires a structurally different message.

Query?     EXECUTE uri: system/tree, op: get
Create?    EXECUTE uri: system/tree, op: put
Subscribe? EXECUTE uri: system/subscription, op: subscribe
Connect?   EXECUTE uri: system/protocol/connect, op: hello

The vocabulary of operations is unbounded. The message structure is not.

5.4. Why Two Messages

The reduction to two message types was discovered during relay implementation. Earlier drafts carried a separate message for each kind of interaction — query and response, subscribe and event, execute with its stream/complete/error replies, the connection and identity exchanges — on the order of a dozen, and shrinking draft to draft. A relay forwards operations between peers. When building it, every message type was wrapped inside an EXECUTE for forwarding. The wrapping was lossless — a relay doesn’t need type-specific logic.

If a generic forwarder can handle all interactions with one message structure, the separate message types are syntactic sugar. The earlier messages (query, subscribe, and the rest) moved into the handler layer as operations. The protocol boundary compressed; the operation vocabulary expanded.

The computational significance of EXECUTE — its structural correspondence to beta-reduction in lambda calculus — is examined in The Entity Church Architecture. The deeper conceptual reformulation this wire reduction expressed — a shift in what a message is — is developed in §The Relay Insight below.

6. Connection Establishment

How two peers connect.

6.1. Flow

The mandatory handshake is two EXECUTE round-trips:

1. Initiator $\to$ hello (peer identity, protocol version, capabilities) Responder $\leftarrow$ hello response (responder identity, negotiated params)
2. Initiator $\to$ authenticate (signed challenge) Responder $\leftarrow$ authenticate response (verified; carries the initial capability grant)

The initial capability grant rides back in the authenticate response, not a separate exchange. The protocol also defines a symmetric third leg — the responder authenticating back to the initiator — but it is optional and reachability-gated: it applies only when the initiator is itself a serving peer the responder can later call into, and no current implementation sends it. A client-style initiator (browser, CLI, conformance harness) completes the handshake on the first two round-trips alone.

Connection uses EXECUTE with pre-authorization at system/protocol/connect. No special connection protocol — the same dispatch mechanism used for everything else.

6.2. Pre-Authorization

Before authentication completes, only system/protocol/connect is reachable. The handler is pre-authorized: no capability required. After authentication, the initial capability grant defines what the connecting peer can access. Everything is communicated through grants.

6.3. Initial Capability Delivery

The initial grant tells the connecting peer:

• Which handlers it can reach (handler patterns)
• Which data it can access (resource patterns)
• Which operations it can perform
• Which peers it can interact with

Paths in the grants communicate the peer’s actual namespace layout. Peers that follow naming conventions get predictable trees; peers that diverge remain conformant — they communicate their paths through grants.

7. Capability System

Authorization integrated with the protocol.

7.1. Four-Dimensional Grants

Each capability grant specifies scope on four dimensions:

grant_entry := {
  handlers:   scope,    -- which handlers (path patterns)
  resources:  scope,    -- which data paths (path patterns)
  operations: scope,    -- which operations
  peers:      scope     -- which remote peers
}

scope := { include: [pattern], exclude: [pattern]? }

All four dimensions must match in a single grant (conjunctive). Uniform pattern matching across all dimensions.

7.2. Attenuation by Construction

Child grant $\subseteq$ parent grant on all four dimensions. Enforced by cryptographic chain: each child references its parent by content hash. Cannot insert or modify chain links without breaking hashes. Capabilities can only be narrowed, never amplified.

Delegation caveats: max_depth (default 64), max_ttl, no_delegation. The chain is a content-addressed linked list — each token is an entity, verifiable independently.

7.3. Verification Algorithm

On each EXECUTE:

1. Verify capability signature chain (each link signed by granter)
2. Check handler scope (does the grant cover this handler path?)
3. Check operation scope (does the grant cover this operation?)
4. Check resource scope (does the grant cover the target resource?)
5. Check peer scope (does the grant cover this peer?)
6. Verify delegation chain (parent $\to$ child attenuation valid?)

Root capability granter must be the local peer.

7.4. Two-Level Enforcement

Level 1 (dispatch): before the handler runs, check all four dimensions. Level 2 (handler): handler re-checks capability against specific paths. Defense in depth: dispatch catches broad violations, handler catches specific.

7.5. Per-Message Authorization

Each EXECUTE carries its own capability token. No session state. Content-addressed entities are self-verifying — they can be relayed, stored, and forwarded across connections. Per-connection auth breaks when entities are mobile.

8. Handler Model

How handlers register, dispatch, and execute.

8.1. Registration

Handlers are entities registered at tree paths: system/handler/{pattern}. A handler entity describes: which path prefix it serves, what operations it supports, its interface type (input/output types per operation). Handler registration and unregistration are themselves EXECUTE operations to the system/handler handler.

8.2. System Handlers

Four core handlers are mandatory:

• system/tree: entity storage — get, put, delete, list
• system/handler: handler lifecycle — register, unregister
• system/capability: capability management — request, revoke, configure, delegate
• system/protocol/connect: peer connection — hello, authenticate

A fifth handler, system/type (type validation — validate), is conditional: a peer registers it when it supports type validation, and omits it otherwise.

These four plus the infrastructure they operate on (entity structure, content store, tree, emit pathway) are the core protocol. Everything else — including all extensions — is handler registrations.

8.3. Path Dispatch

EXECUTE arrives with a URI. Dispatch finds the handler with the longest matching prefix:

EXECUTE uri: local/files/home/doc.txt
  → longest matching handler prefix: local/files
  → handler-relative path: home/doc.txt
  → handler executes with context

The tree is the dispatch table. No separate routing mechanism. Path simultaneously serves as: name (human-readable address), dispatch key (which handler), and scope boundary (capability checking).

8.4. Handler Freedom

The protocol imposes almost nothing on handler implementations. A handler receives typed parameters and returns typed results. What happens inside is unconstrained: call a database, read a file, invoke an AI model, do nothing. Domain semantics live in handlers. The protocol provides: dispatch, capability checking, typed interface. The handler provides: everything domain-specific.

9. The Emit Pathway

The atomic operation of the protocol. Every state change is this.

Emit is two coupled 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. The Store event and Bind event are independently observable — consumers register on either or both, depending on which axis they care about.

This is the crossing point between the two address spaces. An entity is born eternal (content store, immutable, by hash). A binding gives it a temporal name (tree, mutable, path $\to$ hash). Events make the change observable along either axis.

Every state change — handler result, tree modification, entity creation — is a sequence of emit pathway crossings. This is irreducible.

Properties that fall out:

• Versioning by construction: rebinding preserves the old entity
• Audit trail: content store is append-only; history is cryptographic
• Event sourcing: emit events form a complete log of state changes
• Extension integration: extensions consume either or both events, depending on what they observe

Consumer coordination — how multiple extensions compose over shared emit surfaces, ordering rules, cascade depth, convergence classes, well-behaved-consumer patterns — is specified in the SYSTEM-COMPOSITION layer, not in the core protocol. The core protocol specifies the primitive; SYSTEM-COMPOSITION specifies how consumers compose over it.

10. The Extension Architecture

The core protocol is complete and useful alone. Extensions compose on top using the same mechanisms: handler registration, typed dispatch, capability checking, emit pathway events. Extensions don’t modify the core — they add handler operations at new path prefixes. The protocol boundary is unchanged.

10.1. How Extensions Work

An extension registers a handler at a system/* path prefix, defines types for its operations, and optionally consumes emit pathway events. It uses the same EXECUTE dispatch, the same capability model, the same entity tree. There is no extension API separate from the protocol itself.

10.2. The Extension Landscape

The system-extension layer is stratified. The substrate-bridge extensions are the structural set that carries the core primitives up to where applications are built:

• system/tree (extended): bulk operations — snapshot, diff, merge, extract
• system/type: value-level constraints and type analysis
• system/content: content chunking, deduplication, manifests; consumption-format descriptors as tags over blobs (proposed)
• system/inbox: async cross-peer message delivery
• system/subscription: reactive event streams on tree changes
• system/continuation: durable execution chaining, cross-peer workflow
• system/compute: expressions, derived entities, reactive evaluation
• system/query: secondary indexes and compositional queries
• system/revision: version DAG, three-way merge, cross-peer sync
• system/history: per-path transitions, audit, rollback
• system/clock: system time — wall-clock plus logical/vector references

Alongside the substrate-bridge set, three further categories are recognized but distinct in role. Operational extensions — identity management, attestation, quorum, role-based authority, group membership, network connectivity, peer discovery, relay — provide the operational semantics any deployed multi-peer system needs; they are not part of the substrate-bridge set that carries the core toward application development. First-pass-grounding extensions — currently system/transaction — frame major CS concepts the community will expect, held loosely as anti-fragmentation work. Exploratory extensions — currently system/durability — preserve reference designs after a retraction or before a driver is identified.

The dependency graph within the substrate-bridge set is sparse. Most extensions depend only on core. Common dependencies include subscription on inbox (delivery mechanism) and revision on tree extended (snapshot/diff/merge). Everything else composes through the handler interface and emit pathway independently.

Four extensions consume emit events: subscription (pattern-matched notifications), history (transition recording), compute (reactive re-evaluation), and query (index maintenance). They hook into the same event independently — no coordination required.

10.3. Composability

The extension architecture is evidence that the core protocol is compositional: a broad range of distributed system concerns (async messaging, event streaming, content distribution, computation, time, synchronization) all compose through the same six primitives. No extension requires modifying the core protocol or adding new message types. The protocol boundary absorbs new functionality through handler registration and type definition alone.

11. The Reduction

The protocol was assembled by alternating construction and reduction: mechanisms were built to face each next concern, then removed where the entity model could absorb them, repeatedly, until the cycle stopped finding things to remove. The principles below describe the architectural methodology that ran the cycle; the named cycles after that locate where each major reductive move happened; the catalogs of what was removed and what was added show the shape at the level of specific spec changes. The relay insight, treated separately at the end of this section, was the structurally most consequential single move.

11.1. Architectural Methodology

The cycle was guided by a small set of design values:

• Simplicity. Every mechanism in the protocol must justify its presence. A mechanism that another already covers does not stay — and the reductive pass is where this is forced.
• Convergence as the stopping rule. Construction stops introducing new mechanisms and reduction stops removing them. The result is then tested, verified, and security-patched until stable.
• Mathematical principles where they reach; considered convention where they do not. Where the structure is determined by mathematics — content addressing, deterministic encoding, hash-derived identity, the dispatch primitive — the spec follows the math. Where it is not, the spec records the convention and marks it as such.
• The protocol layer settles so layers above it can. Extensions, application architecture, and user-space sit on top; if the protocol underneath them keeps shifting, they cannot stabilise. Running this layer to convergence is what makes those layers tractable.

Counted decision histories are the wrong instrument here. What matters is whether the cycle converges and whether what remains can no longer be simplified. The cycles that follow show the structurally significant moves; the system-level statement of these principles is in The Entity System.

11.2. Cycles That Produced This Protocol

Each cycle is anchored in a specific review or implementation experience that exposed a redundancy, not in a counted decision tally. The structurally significant cycles directly shaping the spec presented in this paper:

The substrate leap. The protocol began as the distributed-substrate piece of an earlier entity-centric tool — a network-and-host visualization tool whose unified-entity refactor needed entities to be coherent across peers. The work crossed from “an application’s entity model” into “a distributed substrate’s entity model”; the leap from local refactor into protocol design produced the first version of the spec.

The relay insight. Review of a system/relay extension exposed that the protocol’s distinct message types (QUERY, EXECUTE, SUBSCRIBE, and others) were artificial: a generic relay carried all of them as EXECUTE with entity payloads. §The Relay Insight below traces it and the reformulation it forced.

The wire reduction. The previous insight, conceptual at first, materialized at the wire: the protocol shrank to two message types — system/protocol/execute and system/protocol/execute/response. Every operation (queries, subscriptions, computation, bootstrap) became a typed EXECUTE dispatched to a handler by URI path. The two-message protocol presented in §Protocol Messages is the surviving form.

The capability invariant. Multiple competing interpretations of capability-chain semantics collapsed into a single three-slot invariant: Root (resource owner), Grantee (EXECUTE author), In-chain Granters (attenuators). The trigger was a class of cross-peer capability bugs the running implementations surfaced. The resulting three-slot model is the structure presented in §Capability System.

These are not the only cycles, but they are the structurally significant moves. Each is triggered by an implementation or review experience that exposed a redundancy; each removal feeds the next cycle’s construction. The full project sequence is recorded in working notes.

11.3. What Was Removed

• Separate local/wire code paths $\to$ unified model (everything through protocol)
• Inline fields $\to$ entity references (author, signature, bounds = entities)
• Handler list operation $\to$ tree data (handlers are entities in the tree)
• Namespace scoping machinery $\to$ tree structure alone (the tree is the scope)
• Distinct message types $\to$ one dispatch primitive (the wire reduction, a dozen-odd message types down to two)
• Special-case APIs $\to$ entity operations (everything is an entity)
• Namespace-scoped indexes $\to$ flat tree with capability filtering
• Multiple capability-chain interpretations $\to$ one three-slot invariant

11.4. What Was Added

• Path type, type name type (paths and type names as first-class entities)
• Resource field on EXECUTE (making operation targets explicit)
• Operational state types (peer state visible as entities)
• Handler interface type (external discovery contract)

11.5. The Pattern

Removals are structural: mechanisms are replaced by the entity model itself. Additions are types: the type system grows to cover what mechanisms used to do. The protocol shrinks while the type system grows.

This is the signature of reduction to a single substance. When you find that a mechanism can be expressed as entity data dispatched through handlers, the mechanism is redundant. What remains after all such reductions is the irreducible core: the six primitives.

11.6. Cost Asymmetry

Adding a pattern now (during specification) costs one spec change. Adding a pattern after deployment costs coordinated migration across all implementations, users, and deployed systems. This asymmetry incentivized aggressive pre-release reduction: it was cheaper to remove now and discover the consequences than to leave complexity in and remove it later. The cycle’s pre-release intensity is a direct consequence.

11.7. The Relay Insight

The relay insight was the most consequential single move in the whole cycle. Its mechanism is the one traced in §Why Two Messages — a generic relay forwards every message by wrapping it in one EXECUTE, which makes the distinct message types syntactic sugar over a single dispatch. Its consequence went deeper than the wire: a different idea of what crosses it.

The protocol’s framing changed accordingly. It is not messages that carry entities — it is entities that manifest in peer contexts. An entity arrives, its type determines what happens, and that is the entire computational model. Message types collapsed into entity types; dispatch collapsed into handler lookup by URI path; the protocol’s surface area dropped sharply.

The wire-level collapse to two message types followed in a later cycle, once the implications were worked through across the extension landscape. EXECUTE and EXECUTE_RESPONSE, presented in §Protocol Messages, are the operational form of this reformulation.

12. Properties and Emergent Structures

What arises from the six primitives without being designed in.

12.1. Emergent Properties

• MVCC: content addressing = version column. Rebinding a path creates a new version; the old entity still exists by hash. You can’t opt out of versioning with immutable content + mutable bindings.
• Relational structure: typed records with hash references form relations. Entities are rows; types are tables; hashes are primary keys.
• Self-description: types describe types. The protocol describes itself in its own terms. This closes at the bootstrap types — a fixed point. (The computational implications of self-description — meta-circular evaluation, comparison to homoiconicity — are examined in The Entity Church Architecture.)
• Audit trail: content store is append-only. Emit events form a log. History is cryptographic (hash chains, verifiable).
• Convergence detection: peers with the same hash at the same path have provably converged, without coordination protocol overhead.

Additional computational structures emerge when the extension architecture is considered: actor model (inbox + continuation), CPS (EXECUTE as continuation), reactive cascades (subscription + emit). These are examined in The Entity Church Architecture.

12.2. Stability Under Evolution

Wire format: unchanged throughout the type system’s expansion. Entity structure: unchanged. Envelope structure: unchanged. Two-message model: unchanged. What changed: type definitions, handler conventions, capability fields. The protocol is stable. The type system grows. Evolution happens at the type level, not the protocol level. This separation is itself a property of the six primitives — the protocol is the primitives; the type system is extensible within them.

13. Implementation and Evaluation

13.1. Three Implementations

All three are at conformance parity on the normative surface. They are distinguished by the role each plays in the validation loop and by their secondary targets, not by completeness.

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

Independent stack reading the same spec; surfaces ambiguities the other two would miss.

Rust

Targets performance and portability.

The three are not independent attempts at the same target. They are the operational loop through which the specification itself is refined — the methodology that has kept this spec converging as it has matured.

13.2. The Development Loop

The spec is the language-agnostic invariant; the three implementations are its validators. The operational cycle:

1. Spec refinement. A change is proposed in the architecture specification, written in language-neutral terms — wire formats, algorithm pseudocode, normative MUST/SHOULD/MAY clauses, type shapes, dispatch semantics — never in language-specific constructs.
2. Cross-peer implementation. All three peers attempt to implement the refinement. None is “the reference”; the spec is the reference. The implementations are validators of the spec, not authorities over it.
3. Validation testing. The implementations are tested for cross-peer conformance: same entity $\to$ same hash everywhere; same EXECUTE $\to$ same handler dispatch everywhere; same capability chain $\to$ same verification outcome everywhere. This began as live testing — the implementations run against each other and disagreement surfaces at runtime — and has since been joined by byte-pinned test-vector corpora, so a conformance claim can be checked against captured state rather than only against a running peer.
4. Feedback to architecture. When implementations diverge, one of three things is true: the spec was ambiguous (and is tightened), one implementation got it wrong (and is corrected), or the model itself has an unsoundness (which triggers a new reductive cycle). The first two are common; the third has been the trigger for several of the major cycles named in §The Reduction above.
5. Convergence. When all three implementations agree on the conformance surface and no spec ambiguity remains, the refinement lands.

Three implementations rather than two. Two implementations can rationalize their differences against each other — “maybe both readings of the spec are reasonable; let’s pick one and move on.” Three cannot. When three diverge, at least one is unambiguously wrong, which pushes the question back to the spec rather than letting the implementations negotiate. Three also surfaces accidental homography (same word used for different things) mechanically: when two peers agree and the third does not, the spec word that allowed the disagreement is the one to fix.

13.3. Generating Peers From the Specification

The three implementations answer whether careful people reading the same document arrive at the same bytes. A second exercise asks a different question: whether the specification is precise enough that a peer can be derived from it mechanically, into a language nobody wrote the specification with in mind.

A generator takes the specification and emits a complete core-protocol peer for a target language, and the emitted peers are run as a cohort against the same conformance gate as the reference implementations. The cohort spans dozens of languages, and it deliberately includes substrates that share almost nothing: managed runtimes and manual memory, garbage-collected and reference-counted, a stack machine, an array language, a live image-based system, and ports to more than one instruction set. When a peer in such a language reaches the same bytes on the same vectors, the agreement is not attributable to shared idiom, shared libraries, or shared habits of mind — there are none to share.

What this demonstrates has to be stated carefully, because the obvious reading is stronger than the true one. The generated peers share a generation lineage. They are not independent implementations, and a cohort of them all passing one author’s vectors is cohort-consistent rather than independently convergent. What the cohort establishes is that the specification is precise enough to be mechanically realized across substrates with nothing in common — which is a claim about the specification, not about the number of people who have implemented it. The independent evidence remains the three bespoke implementations, and the two kinds of evidence should be reported separately rather than summed.

Two observations survive that caveat. First, no new wire contradictions surfaced after roughly the first eight peers, which suggests the core surface is tight rather than under-specified — had the specification been leaving decisions to the implementer, the additional languages would have kept finding them. Second, the exercise forced a distinction the specification needed anyway: a core conformance profile separable from the extension surface, so that “this peer conforms” names a definite set of obligations rather than an open-ended one.

The cohort’s per-peer state — which peer, which specification version, which oracle commit, and what is known to be missing — is published as a matrix rather than a headline. It is re-measured against newer oracles rather than carried forward, and the figures move when it is; a result quoted without its oracle commit and its pass/warn/fail/skip breakdown is not a conformance claim. The current tallies live in that matrix, and they belong there rather than here: a figure printed in a paper is a measurement stripped of the scope that made it meaningful, and it dates the moment the cohort grows. What travels is the discipline, not the number.

Why this is faster, not slower. The naive intuition is that three implementations mean three times the work. The actual outcome is the opposite: the largest cost in distributed-protocol design is specification ambiguity that survives until production. Catching an ambiguity at the implementation stage — when only the three peer codebases exist and no deployed users do — costs one round of spec-and-implementation work. Catching the same ambiguity in production costs a coordinated migration across all deployed peers, an incompatible-version dance, and breaking existing users. The three-peer model collapses this cost. Ambiguities are forced out before deployment because the implementations literally cannot agree until the spec is unambiguous.

What the methodology requires of the spec. Language-neutral normative text; concrete wire formats and hash algorithms spec-fixed (SHA-256 as the baseline hash, CBOR with deterministic encoding); pseudocode for algorithms where implementations could legitimately disagree if left to taste (capability verification, emit ordering, handler dispatch). The disciplines are not optional — they are what makes three-implementation validation actually validate.

Honest gaps in the loop. The clean description above is the loop at its best. Several real limitations sit alongside it.

• Three may not be enough. Three surfaces ambiguities better than one or two, but it is a small number. Agreement among three is evidence that the spec is unambiguous to people who think like the three implementers — a fourth implementation from outside the team’s reasoning style might still find a divergence. Premature convergence at $N=3$ is a real risk.
• The implementations are not fully isolated. All three are driven by one overarching team. Implementers talk to each other, share design discussions, and absorb each other’s assumptions. Clean independent implementation is an ideal that is hard to achieve in practice; some of the agreement is the team agreeing with itself.
• Spec review sometimes lags implementation. To keep moving, implementations occasionally align on a reading pragmatically before spec review. We try to bring such alignments back to spec/architecture review when possible, but the loop is not as clean as its description.
• The spec is narrative. The text uses prose plus pseudocode plus normative clauses; this has worked for the iteration tempo but leaves more interpretation room than formal specification would. Formal methods (TLA+, Lean) sit in Limitations as the natural complement that has not been done.
• Encoded biases and bugs. Three implementations cannot catch a bug that lives in the spec itself; the loop validates cross-implementation agreement, not spec soundness. The team’s blind spots and the project’s tooling biases are likely encoded somewhere.

What it does not claim. Three implementations do not prove correctness. They prove the spec is unambiguous to within the team’s reasoning style, not that it specifies the right thing. The methodology surfaces inconsistencies, not unsoundness; the spec’s own bugs and biases pass through unfiltered. The result has converged technically; that is real, but it is not the same as a soundness claim.

Technical convergence is not social convergence. The loop gets the protocol to a state where implementations agree and the wire format is stable — technical convergence. It does not, by itself, get other people to independently arrive at the same primitives or to adopt them. Social convergence has its own dynamics: substrate attractors that hold designs in adjacent shapes, the invisibility of emergent properties before someone has built with them, the friction of moving a working ecosystem onto a new substrate. A clean technical substrate makes social convergence more likely; it does not produce it. The broader corpus (especially Convergent Evolution) takes up this question explicitly. Anyone reading the spec presented here should be aware that converging the protocol and converging the field are different problems.

13.4. Normative Algorithms

Five normative algorithms are specified and must match across implementations:

1. Content hash: SHA-256 of ECF-encoded {type, data}
2. Signature: Ed25519 sign/verify
3. Peer ID: Base58(key_type || hash_type || SHA256(public_key))
4. ECF encoding: deterministic CBOR subset
5. URI normalization

SHA-256 and Ed25519 are the conformance baseline, not a hard-wiring: a one-byte format code selects the hash (SHA-384, 0x01, is validated and cross-implementation byte-equal) and key_type selects the signature scheme (Ed448, 0x02). The byte-exact agreement requirement holds per selected algorithm.

Plus conformance algorithms (type resolution, type validation).

13.5. Cross-Implementation Validation

Same entity $\to$ same hash in Go, Python, Rust (cross-validated). Same delegation chain $\to$ same accept/reject across implementations. This validates the normative algorithms are unambiguous.

13.6. Conformance Requirements

The spec defines three levels: MUST (wire framing, hashing, capability verification, dispatch, connection protocol, entity fidelity), SHOULD (root grant tracking, type system L1, tree extensions, operational state), MAY (type validation L2, system extensions, additional hash/key algorithms).

The MUST floor also covers the substrate staying up, not only being correct. A conformant peer’s content store and tree index must be safe under concurrent dispatch; under sustained load it must stay responsive, bound its resources, never silently drop a request it admitted, not crash, and recover when load drops; and it must enforce finite limits on inbound payload size and capability-chain depth, rejecting over-limit input with a coded error while continuing to serve. These are outcome guarantees — graceful degradation, no silent loss — not throughput or latency promises, which are implementation- and deployment-dependent. The limit values are configurable defaults, not protocol constants.

14. Discussion

14.1. Construction and Reduction

Most protocols accumulate: features are added as they are needed, and the protocol grows. This protocol alternated instead — each pass built mechanisms for the next concern, then tested whether the substrate already present could absorb them. The result is six primitives, each independently necessary, together sufficient. The structure surfaced through the cycle rather than being designed up front.

14.2. Irreducibility

The six primitives have been tested by the cycle itself. Every reductive pass that did not remove one is evidence the primitive resisted removal under active pressure to remove it. The standing question: is there a reduction the cycle missed? Removing any one of entity, identity, tree, emit, execution, or peer should either lose a property the system currently has or expose a redundancy the cycle did not catch. No such reduction has been found so far.

14.3. Scope

This paper is the protocol layer. Two analyses build on it and are not attempted here: the computational reading of EXECUTE as a reduction (see The Entity Church Architecture), and the operating-system framing of a fully-loaded peer (see DEOS). The protocol itself is not a framework or library — it has specific structure, and it does not prescribe domain semantics. Handlers are free.

14.4. Limitations

No formal verification: protocol model checking (TLA+) is invited, not attempted. Correctness is validated by implementation, not proof. No production-scale evaluation: three implementations exist but no large deployment. Performance characteristics are uncharacterized at scale. Streaming data: content addressing requires content to be fixed for hashing. Continuous streams require discretization at the boundary — a genuine tension, not a defect.

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 development methodology described in §The Development Loop above is what the prompt-and-review tempo makes tractable; the honest gaps catalogued there (three may not be enough, peers not fully isolated, encoded biases) apply to the generation of this paper too. A real factor readers should weigh.

15. Conclusion

The entity core protocol is defined by six primitives: entity, identity, tree, emit, execution, and peer. These six are irreducible — the reducibility analysis found no further simplification. Remove any one and the system loses expressiveness.

The protocol shrank while the type system grew. What remains is minimal: the substrate the construct-and-reduce cycle could not absorb into the entity model.

On its own, the core protocol provides typed content-addressed storage, a mutable namespace with handler dispatch, per-message capability security, self-describing types, and emergent versioning. The extension architecture composes on top without modifying the core — the substrate-bridge extension set covering reactive computation, version coordination with peer sync, subscriptions, durable workflow, queries, content distribution, history, messaging, and time — all compose through the same six primitives.

Three open invitations to refute the closure claims sit alongside the protocol. If any of the six primitives can be removed without losing a property the system currently has, the irreducibility analysis is wrong. If any interaction requires a structurally distinct third message type, the two-message reduction is incomplete. If any representable structure escapes the bootstrap types, the self-description claim is wrong. None has been identified.

Future work: formal protocol verification (TLA+), performance at scale, production deployment, domain bridge catalog.

Dimensional Completeness: Validating Protocol Design Through Irreducible Primitives

1. Introduction

A protocol that changes after release imposes migration costs on every implementation and deployment. If specific design choices can be validated before release — if the type system can be shown to cover the structural primitives of data description, and the capability system can be shown to cover the structural primitives of authorization — then the protocol resists the kind of post-release changes that are most expensive: structural ones.

This paper applies a design validation procedure to two design spaces within The Entity Core Protocol: the type system and the capability system. The procedure is the same in both cases: survey existing systems in the design space, identify the irreducible primitives that any system in the space must address, decompose each primitive into partial levels, categorize any gaps, and test whether the protocol covers the space.

The entity core protocol is built from six substrate primitives — Entity, Identity, Tree, Emit, Execution, and Peer — described in The Entity System. These substrate primitives and the fifteen pair-relationships they produce determine what properties the protocol has. But the substrate primitives alone do not tell you whether the type system’s field vocabulary is sufficient, or whether the capability grant’s four fields are the right four. Those are specific design choices that require specific validation against the primitives of the relevant surface design space.

Two independent analyses — one examining type systems, the other examining capability and authorization systems — each find eight irreducible primitives. Each primitive decomposes into 3–6 partial levels. The analyses were conducted by examining existing systems, not by deriving from the entity substrate primitives. The results map back: each surface primitive requires specific pair-coverage among the substrate primitives. The type primitives require pairs within the EIT (self-description) triangle; the capability primitives span the EIT, TMX (reactive dispatch), and IXP (cryptographic capability) triangles. This convergence between bottom-up analysis of an existing design space and top-down structure from the substrate primitives provides confidence that the protocol’s design choices cover what they need to.

A third validation — the cross-compilation partition — examines what happens when programming language features are translated to entity computation. The partition into three categories is uniform across five languages with radically different type systems, suggesting the entity type system captures a natural level of abstraction.

A note on this paper’s history. This paper was first authored before the structural methodology of A Structural Methodology for Information System Domains crystallized. The early work captured the right intuition — survey the landscape, extract the primitives, ground them in the substrate — but using coarser vocabulary (“dimensions”), implicit irreducibility tests, and no formal partial-level decomposition. The methodology, later formalized and applied across roughly twenty domains, was applied back to this paper’s two design spaces under formal procedure. The result: minor refinements for the type system (one additional primitive, three renames) and substantive refinements for the capability system (two additional primitives, including the Authority primitive that the protocol spec independently arrived at by debugging cross-peer capability bugs — §5.2 “three slots”). The appendix records the reconciliation in detail.

The primitive combinatorial analysis — partial levels, pair-coverage scoring, attractor states, and landscape positioning across the entity substrate itself — is developed in the companion paper on Convergent Evolution. The full methodology of structural domain analysis is in A Structural Methodology for Information System Domains. This paper focuses on validating specific protocol design choices through primitive coverage within two surface design spaces, using pair-relationships as the analytical layer that connects surface primitives to substrate primitives.

Companion papers. The six substrate primitives, fifteen pair-relationships, and five named structural triangles are in The Entity System. The protocol specification is in The Entity Core Protocol. The computational architecture and two-level type architecture are in The Entity Church Architecture. The full landscape analysis with pair-coverage scoring across the substrate is in Convergent Evolution. The structural methodology in full generality is in A Structural Methodology for Information System Domains.

2. Type System Design Validation

2.1. The Question

The entity core protocol defines a structural type system. Type definitions are entities — stored at system/type/* in the tree, subject to the same content addressing and dispatch as all other data (see The Entity System; The Entity Core Protocol). But what fields should a type definition have? What structural vocabulary is sufficient for describing data exchanged between peers?

These are not questions the primitives answer directly. The primitives establish that types are entities (E), types have content-derived identity (I), and types live at known paths (T). But the specific structural vocabulary — which fields, which composition mechanisms, which constraints — is a design choice. To validate it, we examine what existing type systems do.

2.2. Eight Primitives of Type Description

Analysis of 16 independent type systems — spanning schema systems, programming languages, and data description formats — reveals eight irreducible primitives that any type system addresses. (Earlier work, before the structural methodology of A Structural Methodology for Information System Domains crystallized, listed seven “dimensions”; the methodology’s formal procedure — explicit irreducibility tests on the landscape, plus partial-level decomposition — surfaces Naming as a separable primitive that the earlier survey took for granted, and clarifies three other primitives via partial-level analysis. See appendix.) Each primitive addresses a structural question that any system exchanging structured data must answer. Each also requires specific pair-coverage over the entity system’s substrate primitives — pairs of substrate primitives that must be in full expressiveness for the surface primitive to operate (see The Entity System).

Each primitive is irreducible: removing any one loses expressiveness that no combination of the others recovers.

Shape without constraint can describe structure but cannot validate values. Constraint without shape can validate values but has no structure to attach them to. Composition without naming can relate types only by inline embedding, which collapses into Shape. Equivalence without representation can compare by nominal labels but cannot establish cross-system agreement on canonical content. Representation without evolution can serialize data but cannot handle format changes. These are independent axes.

The derivation is forced by the nature of structured data exchange. Data has shape. Shape has fields. Fields have cardinality. Fields have value constraints. Types compose. Types need names. Types need equivalence rules. Types cross wire boundaries (representation). Types change (evolution). Each step follows from the previous. The structural vocabulary is not arbitrary — it is what any system must address when describing data for exchange.

All eight primitives require pairs within the EIT triangle (the self-description triangle from The Entity System). Composition requires the full triangle (all three pairs at full strength); other primitives require specific sub-pairs. The concentration of all eight type primitives within a single named substrate triangle is itself a structural finding: type description is the informational substrate at work, and the EIT triangle is precisely what activates when the informational substrate is complete. A system that does not reach the full EIT triangle will fail to support at least one type primitive; this is predictive and testable.

Partial levels

Each primitive decomposes into partial levels — a gradient from absent to fully elaborated (see A Structural Methodology for Information System Domains). Three excerpts illustrating the pattern (see the methodology domain analysis for the full eight-by-five table):

• Naming: Nm0 anonymous structural types only / Nm1 type aliases / Nm2 first-class named definitions / Nm3 namespaced names (packages, modules) / Nm4 globally addressable names (URI / hash / DID — the entity system’s level).
• Equivalence: Eq0 no equivalence rule / Eq1 nominal (same name) / Eq2 structural (same shape) / Eq3 content-derived (same canonical bytes / hash). Phase transition at Eq2→Eq3: requires the substrate’s Identity primitive at Full I.
• Representation: Rp0 in-memory only / Rp1 single encoding / Rp2 multiple encodings / Rp3 canonical encoding (deterministic single canonical bytes) / Rp4 self-describing encoding (decode without external schema).

The phase transitions matter for the entity system’s distinctive contribution: Eq3 requires Rp3 plus substrate-Identity, and this cascade is what makes type identity intrinsic across peers without coordination.

2.3. The 16-System Comparison

We compared 16 type systems across the eight primitives, scoring each system’s partial level per primitive. Two scoring views are reported: a per-primitive partial-level matrix (full detail in the methodology domain analysis) and an aggregate static-coverage figure for backward continuity with the original analysis.

The aggregate static coverage figures (percentage of the primitive space each system covers with its built-in mechanisms, ignoring type-level computation). These are not summed from the partial-level matrix; each is an analyst estimate of the share of that system’s type-description features that map directly onto the entity type system’s built-in mechanisms — features that need the compute extension or are fundamental gaps do not count. They are coarse by construction (rounded to the nearest 5%), reported here only for continuity with the original seven-dimension analysis; the per-primitive partial levels below are the load-bearing measure.

The pattern is similar to the earlier seven-dimension scoring, with one shift: the entity type system’s distinctive Eq3 (content-derived equivalence via canonical encoding) now shows as a partial-level peak rather than as a single binary dimension. Schema systems concentrate at Eq1 (nominal) regardless of how strong their other primitives are; IPLD is the only surveyed schema system reaching Eq3 in any form (via CID-keyed schemas, not content-derived equivalence of values). This sharpens the earlier seven-dimension “entity system exceeds most systems on Identity” claim — now grounded in a specific phase transition (Eq2→Eq3 requiring substrate-Identity at Full I).

Systems with highest aggregate coverage are schema and protocol systems — Avro, Protobuf, AT Protocol, Cap’n Proto, IPLD, CDDL. These systems focus on describing data structure for exchange. They are the entity type system’s closest relatives. In pair-coverage terms, these systems concentrate their coverage within the EIT triangle: strong EI (typed data with identity), strong ET (types at known paths or in known schemas), and strong IT to the extent their schemas are addressable. Gaps reflect incomplete triangle coverage rather than structural absence.

Programming languages score lower not because they are less capable, but because they invest type expressiveness in Composition (Cp4–5: generics, type classes, conditional types) and in type-level computation, rather than in the description primitives the protocol/schema cluster optimizes for. Haskell’s type classes, TypeScript’s conditional types, and Rust’s trait system are Composition mechanisms at Cp4–5. They extend beyond Shape description into program verification, which we treat as a scope-excluded primitive (see Gap Categorization below). When type computation is removed, the underlying description vocabulary is the same: Haskell’s data declarations describe the same Shape space as Protobuf messages. The pair-coverage pattern differs: programming languages activate EX (typed computation) and EI (types as language constructs) strongly but often do not settle on a shared wire-level ET, which is why translating a Rust type to a Protobuf message requires an explicit schema commitment.

2.4. Convergence Evidence

14 of 16 systems independently develop vocabulary for the same structural primitives:

No system achieves data shape description with a structurally different vocabulary. Systems that appear different — CUE’s lattice-based types, Haskell’s algebraic data types, SQL’s relational model — decompose to the same structural primitives when the type computation layer is removed. The structural convergence across 16 independently designed systems is strong evidence that the vocabulary is not arbitrary.

2.5. Gap Categorization

Every gap between the entity type system and any of the 16 systems falls into one of three categories:

Type computation (intersection types, conditional types, negation types, mapped types, higher-kinded types, information objects): computations over types that produce new types. These are expressiveness that belongs in the compute extension — they extend beyond structural description into type-level programming.

Encoding-specific (field tags and ordinals, zero-copy layout directives, CBOR-specific validation rules, multiple encoding rule sets): properties of particular wire formats. Excluded by design from an encoding-independent type system. ECF (Entity Canonical Form) deterministic encoding means the entity type system is deliberately encoding-independent — bridge handlers translate encoding-specific features when crossing the protocol boundary.

Domain-specific validation (format validators, uniqueness constraints, cross-field arithmetic constraints): domain rules that depend on application context. These belong in handler validation or the type extension’s value-level constraint mechanism, not in the structural type system.

This categorization means the entity type system is complete for structural type description. What it excludes is excluded by design, with a specific mechanism for where each category belongs: type computation in the compute extension, encoding specifics in bridge handlers, domain validation in handler logic.

2.6. Entity Type System Coverage

The entity type system covers all eight primitives, with the following partial-level positions:

• Naming: Nm4 (globally addressable). Types live at system/type/X paths in the tree; type-refs are paths; type identity is intrinsic to the path-and-content pair.
• Shape: Sh4–Full Sh. Records, sequences, maps, unions (via union_of), tuples. Self-describing types (system/type is itself an entity type).
• Cardinality: Ca2–3. Required, optional, repeated. Open types preserve unknown fields for forward compatibility. Richer cardinality (uniqueness, exactly-k) in the type extension.
• Constraint: Co2–3 in core, Co3 in the type extension. Pattern validation, range constraints, enumerations at core; cross-field arithmetic in the extension’s value-level constraint mechanism. Co4 (refinement / dependent constraint) is scope-excluded by design.
• Composition: Cp3–4. Single inheritance (extends), entity references via content hashes, generics, union types. Cp5 type-level computation is scope-excluded from the type system itself and lives in the compute extension.
• Equivalence: Eq3 (content-derived). Same canonical bytes hash to the same identity everywhere. The distinctive entity-system contribution; depends on Rp3 + substrate-Identity at Full I.
• Representation: Rp3 (canonical). ECF (Entity Canonical Form) gives encoding-independent structural description with deterministic canonical bytes. Self-describing types support an Rp4-like behavior (decoders can resolve type definitions via tree paths).
• Evolution: Ev2–3. Open types, compatibility rules, deprecation in core. Dynamic aspects (schema migration, live type evolution) distributed across extensions.

The two-level type architecture described in The Entity Church Architecture maps onto these primitives: Level 1 (structural types, core protocol) covers Naming, Shape, Cardinality, Composition, Equivalence, Representation, and Evolution. Level 2 (value constraints, type extension) covers Constraint. The separation reflects an observation: structure is universal (every system exchanging data needs to know field shapes), while value-level validation is domain-specific (what counts as valid varies by application).

3. Capability System Design Validation

3.1. The Question

The entity core protocol defines a capability system with four-dimensional grants (see The Entity Core Protocol). Each grant entry has fields for handler scope, resource scope, operation scope, and peer scope. Capability tokens carry these grants with cryptographic attenuation chains, temporal windows, and explicit revocation. The system has been refined across many spec revisions, including the normative addition of “three slots” for cross-peer capability provenance (see below).

But why these particular fields? Are they the right ones? Is the design space complete?

3.2. Eight Primitives of Authorization

Analysis of capability systems, access control models, and authorization frameworks reveals eight irreducible primitives. (Earlier work, before the structural methodology of A Structural Methodology for Information System Domains crystallized, listed seven “dimensions”; the methodology’s formal procedure surfaces two additional primitives — Authority as separate from Subject, and Revocation as separate from Time-expiry — both of which the protocol spec independently arrived at by debugging cross-peer flows. See appendix for the reconciliation.)

Each primitive corresponds to a structural aspect of authorization that any system must address. The primitives operate at three protocol layers (per-grant-entry scope, per-token scope, separate lifecycle mechanism); one primitive (Context) operates across both grant and token layers, giving the natural breakdown below.

Per-grant-entry scope primitives (one field per grant entry in a token’s grants array):

Per-token scope primitives (one field on the capability token itself):

Lifecycle mechanism (operates outside the token via separate entity):

Context (Cx) operates at both grant and token layers because the design space has both a spatial scoping axis (which peers) and a temporal scoping axis (which time window), and the methodology treats them as partial-level axes of one Context primitive rather than as two separate primitives. The architecture team’s choice to express the spatial axis per-grant (peers field) and the temporal axis per-token (expires_at, not_before) is a structural design choice within Context, not a difference in primitive identity.

An extensibility escape hatch — the constraints field — allows domain-specific coordinates without adding primitives.

Three primitives require Full I to activate (Sb, Au, At) because their supporting pairs (IP, IX) are phase-transition pairs: they do not operate at partial identity levels (see The Entity System). A system at I1 (assigned identity, not content-derived) cannot express these primitives in the entity-system sense, regardless of how many grant fields it has. This is the structural reason capability-based security in the entity system requires Full I and not merely some form of identity.

3.3. The Three-Slot Convergence (Spec ↔︎ Methodology)

The Subject/Authority/Attenuation distinction is the most consequential refinement in the eight-primitive analysis, and it has a notable provenance: the architecture team and the structural methodology arrived at the same three-slot decomposition by entirely independent routes.

The spec route was operational. §5.2 (“Cross-peer capability provenance — the three slots”, normative) was added after a recurring class of cross-peer capability bugs in which the local case of authorization (where the requester, the resource owner, and the in-chain granters collapse onto one identity) silently omitted two of the three slots. Cross-peer flows force the slots apart, and code paths reasoned about only the local case mis-attributed authority. The amendment names the three slots — and pins each to a different check point. In the spec’s own words:

A capability presented in an EXECUTE has three independent identity slots, each checked at a different point. […]

• Root — the peer that owns the resource being acted on. A chain can authorize action on peer X’s resource only if it roots at an authority X conferred. […]
• Grantee (of the leaf) — the wielder: the identity that authors the EXECUTE. […] The cap must be granted to whoever presents it.
• In-chain granters — every party that attenuated along the way, including any installer/minter that pre-mints a cap for later use. […] requires only that the writer appear as a granter somewhere in the chain — not that the chain roots at the writer.

— ENTITY-CORE-PROTOCOL §5.2

That the three slots are checked at three different points is the operational payoff: it is exactly the structure that the local case hides. §5.2 makes the slots an enforced invariant — any cross-peer capability-bearing operation must fill all three explicitly — and EXTENSION-SUBSCRIPTION §1.2 and EXTENSION-CONTINUATION §4.2 case 3 are now framed as instances of this one model, not as independent designs.

The methodology route was theoretical. The structural decomposition of capability-systems-as-a-domain (per A Structural Methodology for Information System Domains, the canonical analysis is under the project’s methodology directory) tests primitive candidates by irreducibility, compositional productivity, and empirical recurrence. The candidate primitive set for authorization includes Subject (the requester at request time) and Authority (the source of permission). They are independent: every delegated grant has a Subject distinct from its Authority, and the cap-systems literature (Dennis & Van Horn 1966; Miller 2006) treats them as separate concepts.

Both routes arrive at the same decomposition: Subject (grantee), Authority (chain root), Attenuation (in-chain granters). The convergence is structural evidence: the decomposition is not an artifact of either route. It is what the design space requires.

3.4. Why Each Primitive Is Irreducible

Removing any primitive loses authorization expressiveness:

• Without Subject: cannot distinguish who is acting. Every request is anonymous.
• Without Mechanism: cannot scope by handler. Authorization is mechanism-blind.
• Without Verb: cannot distinguish read from write from delete. All operations are equivalent within a mechanism.
• Without Object: cannot scope by data. Authorization is all-or-nothing on data access.
• Without Context: capabilities are unconditional — no time bounds, no spatial scoping, no environmental conditions.
• Without Authority: cannot answer whose permission is this exercising; every capability appears equally valid; cross-peer authorization collapses.
• Without Attenuation: capabilities cannot be safely delegated; every grant must come from root with full power.
• Without Revocation: capabilities are eternal — expiry without revocation handles only foreseeable cancellation, not compromise or policy change.

Each is an independent axis. Mechanism and Verb are distinct because the same verb (e.g., “read”) may be authorized on one mechanism but not another. Object and Context are distinct because the same object path may be accessible in some contexts but not others. Authority and Subject are distinct in any delegated grant (the holder of the capability is not its root). Attenuation and Revocation are distinct temporal modes: Attenuation is forward-narrowing at delegation time; Revocation is backward-cancellation after grant.

3.5. Capability as Region

A capability token is not a point in the eight-dimensional space — it is a region. Each grant entry defines a volume in the per-grant primitives: a set of mechanisms, a set of objects, a set of verbs. The token adds Subject, Context, Authority, and Attenuation constraints. Revocation can subsequently reduce the volume to zero.

Authorization is checking whether a point (the current request) falls within the region (the capability token) and the region has not been revoked. Attenuation is creating a sub-region — every attenuated capability is a smaller volume within the parent. The volume can only shrink, never grow. This is monotonic attenuation: delegation can restrict but never amplify. Revocation is a discrete event: the volume goes from positive to zero on a specific token.

3.6. The Four-Dimensional Grant Within an Eight-Primitive Structure

The entity system’s grant entry has one field per per-grant-entry primitive:

• handlers (Mechanism)
• operations (Verb)
• resources + exclude (Object)
• peers (Context, spatial axis)

This is the original “four-dimensional grant” framing of this paper. It remains accurate as a description of what varies per grant entry. The methodology refinement shows that the four-dimensional grant is one layer in a larger eight-primitive structure: four per-grant scopes inside a token that itself carries four additional primitives (Subject as grantee, Authority as granter, Attenuation via parent chain, Context-temporal via expires_at / not_before), with Revocation operating as a separate lifecycle mechanism (system/capability/revocation).

Counting the layers: 4 per-grant + 4 per-token (where Context appears at both layers as different partial-level axes) + 1 lifecycle = the 8 primitives. The earlier framing of this paper called the per-grant set “the four-dimensional grant” and treated the remainder as “Subject + Time + Delegation” — which collapsed Authority into Subject and bundled Revocation into Time. The methodology view separates these correctly and adds Revocation as a first-class lifecycle primitive.

The four-dimensional grant is therefore a principled and correct architectural choice for what varies per authorization scope; the methodology refinement is to the enumeration of what surrounds the grant, not to the grant itself.

3.7. Comparison to Existing Systems

Five capability and authorization systems illustrate different coverage patterns. Each system is scored at the partial-level of each of the eight primitives (per the methodology analysis).

The entity system reaches the highest partial level on six of eight primitives. UCAN matches Sb4 (both use content-addressed identity); CHERI matches At3 (sub-capability derivation in hardware); none of the surveyed systems reaches Ob5, Cx3-with-spatial-axis, or Au3-with-per-peer-root in combination.

The pair-coverage view explains the differences. Each system activates a subset of the capability-relevant substrate triangles:

• Zanzibar activates IP (subject) and TX (resource via relations), concentrated in a single-domain IP+TX cluster. Au1 (central authority) means the IXP triangle does not fully activate.
• UCAN activates IP (DID), EX (ability), and the IX aspect of IXP (proof chains) but not the full IXP triangle (no TP, no XP for topology). Revocation stays at Rv1.
• Macaroons activate IP (bearer), partial EX (caveat-encoded operations), and IM/TM (time caveats), but no TX for resource routing. At3 makes Macaroons attenuation-strong but Au1 limits provenance reasoning.
• Biscuit extends Macaroons’ caveat model with Datalog, reaching Vb3 and richer Cx, but stays at Au1, At3, Rv1.
• CHERI activates capability-as-machine-word with hardware enforcement. At3 (sub-capability derivation) is hardware-implemented. But Mc0 (memory-bound, not mechanism-aware) and Cx0 (no environmental conditions) limit its scope to the per-memory-access level.

The entity system activates the full IXP capability triangle plus TX (handler dispatch), TP (peer-namespaced objects), and IM/TM (temporal context). Authority at Au3 (per-peer roots) requires substrate-Identity at Full I; this is the cascade that lets the entity system reach the highest partial levels across the most primitives in one composition.

This also maps to classical access control theory (ABAC): Subject attributes map to Sb. Action attributes map to Mc + Vb. Resource attributes map to Ob. Environment attributes map to Cx. Meta/policy attributes map to Au + At. Lifecycle management (often outside ABAC’s frame) maps to Rv. The entity system provides finer granularity than ABAC by separating Action into Mechanism and Verb (distinct pair-coverages: TX vs EX), keeping Authority distinct from Subject (the cert-chain framework in Entity System Security Architecture operates on this distinction), and treating Revocation as a first-class lifecycle primitive.

4. Cross-Compilation Partition

4.1. The Partition

When translating any programming language to entity computation, language features partition into three categories (see The Entity Church Architecture):

Category A (maps directly): data types, functions, closures, generics, async, pattern matching, modules, interfaces. These map to entity types, handlers, compute expressions, type parameters, continuation chains, and tree structure.

Category B (erases): lifetimes, ownership, borrow checking, GC internals, access modifiers, stack layout, laziness strategy. Machine-level concerns that the content-addressed substrate handles structurally.

Category C (requires handler embedding): SIMD, inline assembly, memory-mapped I/O, raw pointer arithmetic, hardware register access. These need the actual machine and live inside native handlers, opaque to the entity model.

4.2. Uniformity Across Languages

The partition is uniform across five languages with radically different type systems and runtime models:

In every case: Category A represents what the language says about data and its transformation. Category B represents what the language says about the execution substrate — these erase because entity computation is a different substrate. Category C represents machine-level operations that the language exposes.

The entity type system abstracts away the same things across all languages. Rust’s lifetimes, Haskell’s laziness, TypeScript’s access modifiers, C’s pointer arithmetic, Python’s GC — all are Category B. All erase. What survives is the data transformation semantics, and those are universal.

4.3. Category B as Purity Boundary

Why does Category B erase? Consider Rust’s ownership model. It prevents use-after-free, double-free, and data races. In entity computation, none of these problems exist:

• Use-after-free: entities are content-addressed and immutable. Nothing is freed.
• Double-free: there is nothing to free. Content-addressed entities persist.
• Data races: entities are immutable. Path rebindings are serialized through the emit pathway.

Lifetimes compile to nothing. They erase completely. Not because entity computation cannot express them, but because the problems they solve do not exist in a content-addressed, immutable-entity, single-emit-pathway model. The entity computation substrate inherently provides the guarantees that lifetimes enforce in Rust.

The same pattern applies to every Category B feature across every language. Each Category B feature manages an aspect of the execution substrate — memory layout, evaluation strategy, access scope — that the content-addressed model handles structurally. Content addressing provides identity and lifetime semantics. The emit pathway serializes state changes. Open types handle forward compatibility.

4.4. Category C as Handler Boundary

Category C features require machine access. They cannot be expressed in content-addressed typed data because they need the physical machine: specific instruction sets, memory-mapped hardware, operating system interfaces. These live inside native handlers, which are opaque to the entity model — typed parameters in, typed result out, machine access inside.

Category C defines the machine boundary — where entity computation ends and physical computation begins. This boundary is examined in The Entity Machine Boundary.

4.5. Independent Validation

The cross-compilation partition validates the type system from a different direction than the 16-system comparison. The type comparison asks: does the structural vocabulary cover the description space? The cross-compilation partition asks: does the abstraction level capture the right things?

The uniformity of the partition across five languages — the same A/B/C split despite radically different type systems — suggests the entity type system sits at a natural level: above machine computation (Category B erases), below human-level intention (Category A maps), with a clean boundary to hardware (Category C embeds). Entity computation sits above machine computation but below human-level intention. It operates at the level of data transformation and coordination.

5. Connection to Substrate Primitives

The type primitives and capability primitives were identified by examining existing systems — bottom-up analysis within each design space. The six substrate primitives were identified by alternating construction and reduction of the protocol — top-down design (see The Entity System). That the two routes converge through pair-coverage provides independent validation.

5.1. The Four-Layer Analytical Framework

The grounding from substrate primitives to surface primitives is not a single step but passes through an intermediate layer. Four layers of analysis are available:

The surface-primitive analyses in this paper live at Layer 4. They were identified through formal methodology procedure (see A Structural Methodology for Information System Domains) applied to each design space independently; that they ground cleanly back through Layers 3, 2, and 1 is what “convergent validation” means here. Pair-relationships are the natural intermediate layer: they explain why particular surface primitives require particular substrate primitives, because each surface primitive requires specific pair-coverage to operate.

5.2. Type Primitives Ground in E+I+T via the Information Pair-Bundle

The eight type primitives map to informational substrate primitives, and more precisely to specific pair-coverage:

All eight type primitives require pairs within the EIT triangle (the self-description triangle from The Entity System). This is consistent with the observation that information precedes computation: the type system describes structure, which is informational. Constraint enforcement (checking values against constraints) requires computation (X), but the constraints themselves are structural descriptions over the EIT triangle.

5.3. Capability Primitives Ground in the Full Substrate via Multiple Pair-Bundles

The eight capability primitives ground in different substrate primitives and pair-bundles:

The capability primitives require all six substrate primitives and reach into multiple named triangles: EIT (types-as-tokens), TMX (dispatch + temporal scoping), IXP (capability cryptography), and the temporal axis IM/TM (lifecycle). Together, the 16 surface primitives (8 type + 8 capability) require all six substrate primitives and the five named structural triangles from The Entity System.

5.4. Phase-Transition Pairs Constrain Capability Completeness

Two of the 15 pair-relationships are phase-transition pairs (see The Entity System): they do not activate gradually but require Full I on their Identity endpoint.

• IX (convergence check): requires content-derived identity. Runtime equality of typed outputs depends on Full I.
• IP (content-addressed peer ID): requires Full I to derive a peer’s identifier from a key hash.

These phase transitions matter for capability completeness. Three capability primitives — Subject (via IP), Authority (via IP+IX), and Attenuation (via IX) — do not come in gradations at all; they require Full I to function. A system at I1 (assigned identity) cannot have capability-chain verification in the entity-system sense, even if it otherwise implements every grant field. This is the structural reason the entity system requires Full I: without it, the IXP capability triangle cannot activate, and three of the eight capability primitives degrade.

5.5. Convergence of Analyses

Three observations about this mapping.

First, the type primitives require only pairs within the EIT triangle, while the capability primitives span multiple triangles and require the full substrate. This reflects the 3+2+1 structure of the primitives described in The Entity System: information (E, I, T) is foundational; time (M, X) and space (P) build on it. Data description is an informational concern; authorization is a concern that spans all three domains.

Second, the two analyses were conducted by different procedures, and a third independent route reinforces them. The type analysis surveyed 16 existing type systems and found eight irreducible primitives by structural test. The capability analysis examined capability literature and surveyed five capability/access-control systems and found eight irreducible primitives. The protocol spec, refined operationally by debugging cross-peer capability bugs, arrived at the same Subject/Authority/Attenuation decomposition in §5.2. Three routes (methodology over types, methodology over capability, spec operational refinement) converge on consistent decompositions. None was derived from the substrate primitives or the pair-relationship framework. That all three map cleanly back through pair-coverage and substrate grounding is convergent evidence that the substrate primitive set spans these design spaces.

Third, the pair-relationship layer provides a more precise validation than substrate-level grounding alone. “Composition requires E+I+T” is true but coarse; “composition requires the full EIT triangle” is precise and testable. Systems that cover only part of the EIT triangle (Git has EI + IT but weak ET; Plan 9 has ET + (partial T) but weak EI) would not support composition in the entity-system sense. The pair-coverage view predicts this; the primitive-count view does not.

The full substrate combinatorial analysis — partial levels, internal dimensions, attractor states, and landscape scoring across existing systems — is developed in Convergent Evolution. The methodology that produces surface-primitive analyses of the kind in this paper is in A Structural Methodology for Information System Domains.

6. Discussion

6.1. Design Validation as Procedure

The procedure applied in this paper has general applicability. For any protocol design decision:

1. Declare the design space and its type (substrate / surface / bridge / ecosystem / context) (see A Structural Methodology for Information System Domains). The declaration predicts filter stringency and core triad function.
2. Survey the landscape: examine existing systems that address the same problem.
3. Extract irreducible primitives via three tests: structural minimality (removing forfeits expressiveness), compositional productivity (combinations yield new capabilities), empirical recurrence (shapes design decisions across instances).
4. Decompose each primitive into partial levels (typically 3–6 per primitive). Iterate steps 3 and 4 until both the primitive set and partial levels stabilize.
5. Identify dependencies, pair-relationships, and load-bearing compositions within the primitive set.
6. Categorize gaps: classify any features the protocol does not cover, and determine whether each gap is by design (excluded with a designated mechanism) or by omission.
7. Map back to substrate primitives via pair-coverage: verify that each surface primitive grounds in specific pair-relationships within the substrate primitive set. Surface primitives that require substrate pair-bundles the substrate cannot activate signal a missing substrate primitive or missing structural capability.

This is the structural methodology of A Structural Methodology for Information System Domains specialized to design validation. It is not specific to the entity system: any protocol with a type system could survey existing type systems for primitive coverage; any protocol with an authorization model could survey existing authorization systems. The procedure produces structured confidence, not proof — but structured confidence that specific primitives have been checked is more useful than informal intuition about completeness. The pair-coverage step adds precision: “does primitive X require pair-bundle Y?” is a testable question.

6.2. Two Independent Analyses Converging on Eight

Both the type analysis and the capability analysis found eight irreducible primitives. This is a coincidence of count, not of structure — the two sets are entirely different, addressing different design spaces. But the convergence is worth noting: in both cases, the dimensionality is low enough to be tractable (eight, not eighty) and high enough to capture meaningful distinctions (eight, not three).

The pair-coverage mapping shows why both counts land in this range. The type primitives all live within a single named substrate triangle (EIT); eight pair-sub-coverages within one triangle is a natural granularity for data description. The capability primitives span three named triangles (EIT for tokens-as-typed-data, TMX for reactive-dispatch + temporal, IXP for capability cryptography) plus the TX and TP pairs for routing and the IT+TM pair for revocation; eight distinct authorization-relevant coverages across this span is similarly natural. Neither number is an accident of measurement; both reflect the pair-coverage structure required.

The earlier seven-dimension framing in this paper missed one primitive in each design space — Naming for types (taken for granted because every surveyed system has it), and Revocation for capability (bundled into Time/expiry) — and bundled Authority into Subject for capability. The methodology surfaced all three. In the capability case, the protocol spec independently surfaced the Subject/Authority distinction by operational debugging (§5.2), reaching the same decomposition as the methodology by a separate route.

Both results sit as open invitations rather than proofs. A ninth type primitive independent of the eight — a question about data description that does not decompose into naming, shape, cardinality, constraint, composition, equivalence, representation, or evolution, and that does not reduce to pairs already covered within the EIT triangle — would refute the closure claim on type description. A ninth capability primitive independent of the eight — a request attribute or token-lifecycle property that is not subject, mechanism, verb, object, context, authority, attenuation, or revocation, and that requires pair-coverage outside the triangles already named — would do the same for authorization. None has been identified.

6.3. Protocol Stability

The practical outcome of primitive validation is protocol stability. The entity core protocol’s wire format has remained unchanged across many revisions (see The Entity Core Protocol). Entity structure has remained unchanged. The two-message model has remained unchanged. What has changed: type definitions, handler conventions, capability grant fields, and the operational sharpening that produced amendments like §5.2’s three-slot model (which clarified rather than restructured the underlying mechanism). Evolution occurs within the type system and extension architecture rather than requiring protocol changes.

The primitive analyses explain this stability. If the type system covers all eight description primitives (via full pair-coverage over the EIT triangle), there is no structural gap that would force a protocol change. If the capability system covers all eight authorization primitives (via pair-coverage across EIT, TMX, and IXP plus IT+TM for revocation), there is no authorization gap that would force a grant restructuring. Gaps are accommodated by the mechanisms already in place: type computation in the compute extension, encoding specifics in bridge handlers, domain validation in handler logic, additional authorization constraints in the constraints field, revocation in system/capability/revocation. In pair-coverage terms: the triangles are complete, so extensions can operate within them without requiring the core protocol to add new pair-relationships.

6.4. Limitations

Several limitations should be noted:

• Irreducibility is empirical. The arguments that each primitive is irreducible are structural and empirical, not mathematical proofs. A ninth primitive in either design space, or a demonstration that two of the eight reduce to each other, would refute the closure claim; none has been found.
• The 16-system type comparison is not exhaustive. Additional type systems (dependent-type systems, refinement-type systems, effect systems) could be included. We selected systems spanning schema formats, programming languages, and data description languages to cover the space broadly, but gaps in coverage are possible. Dependent-type systems would primarily exercise Cp5 (type-level computation), which is scope-excluded from the entity type system by design.
• Coverage scores are partial-level assessments. The per-primitive partial-level positions are analyst assessments, not measurements. Different evaluators might assign slightly different levels. The relative ordering is more reliable than the absolute levels.
• Capability system comparisons are structural. We compared primitive coverage at the partial-level resolution, not operational characteristics like latency, scalability, or deployment model. Zanzibar’s scalability advantages are real and are not captured by primitive analysis.
• The cross-compilation partition has been validated on five languages. Additional languages might reveal edge cases, though the structural argument (Category B erases because the content-addressed substrate provides equivalent guarantees) applies generally.
• 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.

7. Related Work

Type system theory. Pierce (Pierce 2002) provides the foundational treatment of type systems and programming languages. Cardelli and Wegner (Cardelli and Wegner 1985) analyze types, data abstraction, and polymorphism. Our analysis differs in focus: we examine type systems as data description mechanisms for inter-system exchange rather than as program verification mechanisms, which explains why schema systems score higher than programming languages on our metric.

Capability systems. The object-capability model originates with Dennis and Van Horn (Dennis and Van Horn 1966). CHERI (Watson et al. 2015) implements hardware-level capabilities. Zanzibar (Pang et al. 2019) provides scalable relation-based authorization. UCAN (Zelenka et al. 2022) provides decentralized capability delegation. Macaroons (Birgisson et al. 2014) provide contextual caveat-based attenuation. Biscuit (Couprie et al. 2021) combines Macaroons-style attenuation with Datalog-based authorization logic. Our contribution is identifying eight irreducible primitives that span these systems and showing that each system covers a different subset, and noting that the Subject/Authority/Attenuation decomposition was independently arrived at by the protocol spec under operational refinement (§5.2).

Authorization models. RBAC (role-based access control), ABAC (attribute-based access control), and ReBAC (relationship-based access control) represent successive generalizations of authorization. The eight capability primitives map to ABAC’s attribute categories with finer granularity: ABAC’s Action attributes map to Mechanism + Verb (distinct pair-coverages), ABAC’s Environment attributes map to Context, ABAC’s policy attributes map to Authority + Attenuation. Lifecycle management (often outside ABAC’s frame) maps to Revocation.

Content-addressed systems. Git (Torvalds 2005), IPFS (Benet 2014), and Nix (Dolstra et al. 2004) occupy specific positions in the entity substrate primitive space (see The Entity System). Their type system limitations correspond to their positions in the type primitive space: Git’s four hardcoded object types cover Shape partially but lack Composition, Equivalence-for-types, Representation independence, and Evolution.

Schema systems. Avro, Protobuf (Varda 2013), CDDL (Bormann and Hoffman 2020), Cap’n Proto, and ASN.1 are the entity type system’s closest relatives. The convergence of these independently designed systems on the same structural vocabulary is evidence that the vocabulary is forced by the domain.

8. Conclusion

We have described a design validation procedure — declare the design space, survey the landscape, extract irreducible primitives with partial levels, categorize gaps, and map results back to substrate primitives via pair-coverage — and applied it to two design spaces within the entity core protocol.

In type description, eight irreducible primitives emerge from analysis of 16 independent type systems. The entity type system covers all eight at high partial levels. Gaps across all 16 systems fall into three categories (type computation, encoding-specific, domain-specific), each excluded by design with a designated mechanism. The convergence of 14 of 16 systems on the same structural vocabulary is evidence that the vocabulary is forced by the domain rather than chosen by convention.

In authorization, eight irreducible primitives emerge from analysis of capability and access control systems. The entity system covers all eight at high partial levels — the highest of any surveyed system in five-of-eight primitives, tied for highest in two more. Comparison to Zanzibar, UCAN, Macaroons, Biscuit, and CHERI shows that each covers a different subset; none covers all eight. The protocol spec’s §5.2 three-slot model, developed operationally to fix cross-peer capability bugs, independently arrives at the same Subject/Authority/Attenuation decomposition the methodology produces by structural test — a convergence between operational refinement and theoretical decomposition that strengthens both.

The cross-compilation partition provides a third independent validation: the same A/B/C split across five languages with radically different type systems suggests the entity type system captures a natural abstraction level.

All three analyses — type primitives, capability primitives, cross-compilation partition — were conducted independently of each other and independently of the substrate primitive analysis. That the type primitives ground in E+I+T, the capability primitives ground in the full set, and together the 16 surface primitives require all six substrate primitives is convergent evidence that the protocol’s design choices cover the relevant design spaces.

Open questions:

• Can the irreducibility of either set of eight primitives be formally proved?
• Are there design spaces within the entity system beyond type description and authorization that warrant primitive analysis (e.g., subscription, query, revision)?
• Can the procedure be applied to other protocols to identify primitive gaps before release?
• Is the coincidence of both analyses finding exactly eight primitives structurally significant, or is it coincidence?
• The convergence of methodology and spec on the three-slot (Sb/Au/At) decomposition is the load-bearing example; are there other places where the methodology and spec routes would be expected to converge and have not yet been checked?

9. Appendix: History and Methodology Reconciliation

This appendix records the reconciliation between this paper’s original framing (seven dimensions per design space) and the formal structural methodology of A Structural Methodology for Information System Domains (which surfaces eight primitives per design space). It is included for transparency about the paper’s evolution and as a worked example of methodology-applied-back to validate pre-methodology analytical work.

9.1. How this paper began

The first version of this paper was authored before the structural methodology of A Structural Methodology for Information System Domains had crystallized. The intuition was already operative — survey the landscape, find the irreducible axes, validate against the entity primitives — but the formal procedure was not. Steps that the mature methodology requires explicitly (domain-type declaration; partial-level decomposition; dependency graph among primitives; Hasse lattice; build-up sequence; load-bearing composition identification; emergent-property prediction map; cross-domain structural pattern observation) were either absent or implicit. The paper used “dimensions” rather than “primitives” — a choice that turned out to elide the distinction between Layer 1 (primitives) and Layer 4 (emergent surface properties) in the four-layer framework.

The paper produced two findings nonetheless: seven type description dimensions and seven authorization dimensions, with both grounded in entity-substrate pair-coverage. These findings were substantially correct — the seven dimensions in each design space all correspond to real structural axes — but the formal methodology, applied back to the same two design spaces, surfaced refinements:

9.2. Type-system reconciliation

The methodology applied to type-systems-as-a-domain produces eight primitives: Naming, Shape, Cardinality, Constraint, Composition, Equivalence, Representation, Evolution. The original seven dimensions map as follows:

The substrate-grounding finding (all type primitives ground in the EIT triangle) is preserved exactly: Naming grounds in ET, the other seven ground as in the original. The refinement is more accurate vocabulary, not a structural revision.

9.3. Capability-system reconciliation

The methodology applied to capability-systems-as-a-domain produces eight primitives: Subject, Mechanism, Verb, Object, Context, Authority, Attenuation, Revocation. The original seven dimensions map as follows:

The Context merge (Peer + Time → Context) is a methodology choice with a defensible alternative — splitting them back out, as the original did, is also reasonable for distributed systems. Both decompositions agree on the substrate pair-coverage requirements; the disagreement is at the surface-primitive level only.

The Authority and Revocation additions are the substantive refinements. Both are present in the spec and in the cap-systems literature, and both were missed in the original analysis. The reconciliation surfaces them, the comparison table now scores systems on both, and the entity system’s reach across all eight primitives is recorded.

9.4. What the reconciliation does not change

• The grounding of all surface primitives in substrate primitives via pair-coverage.
• The use of EIT, TMX, and IXP as the named structural triangles that surface primitives activate.
• The phase-transition pairs (IX, IP) requiring Full I for capability completeness.
• The cross-compilation partition.
• The “schema systems concentrate in EIT triangle” observation.
• The 4+4 architecture of the capability grant (the four per-grant primitives + four per-token/lifecycle primitives).

9.5. How the methodology was applied back

The methodology canonical analyses for type systems and capability systems are under the project’s methodology directory (methodology/type_systems_domain_analysis/ and methodology/capability_systems_domain_analysis/). They follow the 12-step procedure of A Structural Methodology for Information System Domains §2.1: information gathering, landscape analysis, primitive extraction with partial-level iteration, dependency specification, pair enumeration and load classification, coherent sub-lattice construction, build-up sequences, load-bearing composition identification, emergent-property prediction, cross-domain pattern observation, literature alignment.

The methodology-applied-back exercise is itself an example of methodology-on-methodology: applying the structural procedure to pre-methodology empirical work to test whether the empirical analysis would survive formalization. In this case, it largely did. The refinements are sharpening, not overturning. This is the kind of cross-validation that gives the methodology its claim to general applicability: the same procedure that surfaced primitives across roughly twenty other domains (see A Structural Methodology for Information System Domains) also reproduces and refines the pre-methodology findings of this paper.

9.6. Why this matters beyond this paper

Two practical consequences:

1. The protocol spec is already where the methodology says it should be. Authority is §5.2’s “root” / chain root slot. Revocation is the spec’s “Revocation model” section and the system/capability/revocation entity type. Naming is the system/type/X path convention. No spec amendments are implied by the methodology refinements above. The discrepancy was entirely between this paper and reality; the spec and reality agreed.

2. The convergence of operational refinement (the spec’s §5.2) with theoretical decomposition (methodology) is itself a finding. It suggests that the substrate primitive set is structurally complete for these design spaces in a sense neither route could have established alone. Two independent routes arriving at the same three-slot decomposition is the kind of evidence the paper’s whole design-validation thesis is about. The third route (cross-compilation partition) gives a fourth piece of consistent evidence within the type-system half of the analysis.

The Entity Church Architecture: Computation in Content-Addressed Typed Data

1. Introduction

This paper examines what computation becomes in the entity system — a system built from six primitives (entity, identity, tree, emit, execution, and peer), the fifteen pair-relationships they produce, and five named structural triangles that recur across the system as units (see The Entity System).

The answer is not a new computational formalism. It is a computational architecture — a structural context in which computation occurs. The architecture does not prescribe how to compute. Lambda calculus, Turing machines, dataflow graphs — any model works. What the architecture determines is what properties computation inherits by existing in the system.

The central observation: the tree is the computational substrate. A handler reads from the tree (state), transforms entities (computation), and writes back via emit (result). The tree before the operation is the input. The tree after is the output. The emit events are the record. State and computation are not separated. In pair-relationship terms, computation lives within the TMX triangle (reactive dispatch) operating over the ITM triangle (emit) and the EIT triangle (self-description). These three triangles together form the computational core: information substrate plus temporal coupling plus reactive dispatch.

This paper does not claim new computational power. Church-Turing equivalence holds — the same class of computable functions. What we observe are structural properties that computation inherits from the architecture: reactivity (the TMX triangle), self-description (the EIT triangle), versioning and audit potential (the ITM triangle), persistence, addressability, and authorization. These come from the architecture’s triangle coverage, not from any particular compute model within it.

One structural property deserves special emphasis. Entity-native computation — computation expressed as entities in the tree, reducible by the compute extension’s fixed evaluator — is Turing-complete. Combined with content-addressed identity, it is also transferable: a compute expression, as entity data, can cross between peers that share the evaluator specification and execute identically. The compute extension is therefore not an ordinary extension. It is the bridge that makes the rest of the system’s functionality transferable as computation, in the sense developed in The Entity System. This is the entity system’s analog to the ribosome in biology (see The Universal Computational Genome) or the metacircular evaluator in Lisp.

The two orderings suggest that the properties at each level may be structural — arising from the ingredients rather than from implementation choices — but formal proofs have not been constructed.

Companion papers. The six primitives, pair-relationships, and structural triangles are developed in The Entity System. The protocol specification is in The Entity Core Protocol. The convergent evolution of existing systems is analyzed in Convergent Evolution. The machine boundary — where entity computation meets physical hardware — is examined in The Entity Machine Boundary. The biology parallel — how similar structures arise in molecular biology — is explored in The Universal Computational Genome.

2. Computation as Entity Transformation

2.1. The Tree as Ground

The tree is always present — before, during, and after computation. It is a namespace of path $\to$ hash bindings over content-addressed entities.

A handler reads from the tree (state), transforms what it reads (computation), and writes back via emit (result). The tree before the operation is the input. The tree after is the output. The emit events are the record. These three roles — state, record, result — are not separated into different systems. The tree serves all three.

2.2. The Tree as Memory Model

The tree is not only a namespace — it is the computational memory model. Each peer has its own tree, and that tree includes the peer’s local view of other peers’ state. This gives the memory model specific properties.

The namespace is universal — one address structure for everything: data, handlers, types, configuration, peer state. It is authority-scoped: each peer is authoritative over their own tree. When you observe another peer’s tree, you see their state as they have published it, stored locally as your view of their bindings. Their changes do not affect your local state until you choose to act on them.

This means conflict is not the default. Each peer’s tree is their own — there is nothing to conflict with until synchronization is explicitly requested. When a peer you are syncing with updates a binding, you receive the new hash. You can see what changed. Whether you update your own local state to reflect theirs is a decision, not an automatic consequence. The content-addressed structure makes this practical: you know what they have (by hash), you know what you have, and the difference is computable without coordination.

The structural tools for resolving differences — merge strategies, CRDTs, version DAGs — operate within this model. They can reconcile divergent state mechanically in many cases. But they have limits: the namespace and its verification layers can determine structural consistency (do the hashes match? do the types validate?) but cannot determine truth or correctness beyond what the structure itself encodes. A peer’s claim at a path is that peer’s claim — verifiable as theirs, but not necessarily correct. The bounds of what the memory model can resolve are the bounds of structural verification.

2.3. The Emit Pathway

The atomic state crossing: two coupled operations on distinct primitives. Store enters the entity into the content store (the Identity axis, immutable by hash); Bind updates the tree binding (the Tree axis, mutable). Each operation produces an independently observable event when it does real work. Every computation produces results through this pathway. Emit is the crossing point between content (which persists by hash) and naming (which changes over time) — the temporal coupling of Identity and Tree.

As established in The Entity System, emit introduces mutability — the tree can change, and before-and-after now exist. But emit alone does not compute. It provides the mechanism of state change along two axes; the evaluator provides the computational structure that gives those changes meaning.

2.4. The Evaluator

The evaluator reads typed structures from the tree, transforms them, and emits results back. At the protocol level, this takes the form of EXECUTE and EXECUTE_RESPONSE — dispatch typed parameters to a handler, receive a typed result.

The evaluator has two activation modes, each with distinct pair-coverage. In directed mode, an EXECUTE message explicitly invokes a handler. This exercises the EX pair (typed dispatch) and the TX pair (tree-walk to find the handler) — a directed use of the TMX triangle’s EX+TX edges. In reactive mode, an emit event triggers re-evaluation. This exercises the MX pair (the cascade edge of the TMX triangle): emit produces an event; the evaluator consumes it; its output becomes a new emit; the cycle closes. Both modes produce results through the emit pathway; both are aspects of the TMX triangle operating in different directions.

Without the evaluator, the tree is a static store — data accumulates but nothing processes it. The ITM triangle (emit + information) is active but the MX cascade edge is not: emit events have no consumers that produce further state changes. With the evaluator, the TMX triangle closes and all temporal properties are actualized: versioning, audit trails, reactive cascades, MVCC (see The Entity System).

2.5. EXECUTE and Beta-Reduction

There is a structural correspondence between EXECUTE and beta-reduction in lambda calculus:

What EXECUTE adds beyond pure reduction: statefulness (emit, via ITM triangle), identity (content hash, EI pair), authorization (capability, IXP triangle), and locality (peer boundaries, TP+XP pairs). This is an observation about structural correspondence, not a claim of formal equivalence. The computational analysis that follows builds on this correspondence.

3. Information Before Computation

The companion paper on the six primitives (see The Entity System) establishes that the primitives divide into three domains: informational (E, I, T), temporal (M, X), and spatial (P). The informational primitives exist as pure structure without requiring time, space, or agency. Computation is what the temporal and spatial domains add on top.

3.1. Computation as Structure and as Activity

A pure function is a mapping from inputs to outputs — a set of (input, output) pairs, a mathematical object rather than a process. In the entity system, a function’s inputs are entities, its outputs are entities, and the mapping itself can be represented as entities in the tree. The function’s identity (its content hash), its type, its structure — all exist as information in E+I+T.

Consider, as a thought experiment, a complete E+I+T tree containing every possible structure and relationship. Every computable function would already be present as a lookup entry. Computation-as-activity — the temporal process of evaluation — would be unnecessary. You would navigate rather than compute.

This is an infinite space. No finite tree contains all computable functions. Computation-as-activity exists because the complete tree is infinite — we must evaluate specific functions on specific inputs because we cannot store the infinite lookup table. Evaluation requires time (M) and agency (X).

This gives the observation “information precedes computation” a precise meaning:

• Computation-as-structure: the mathematical object — what a function is — is information. It lives in E+I+T.
• Computation-as-activity: the temporal process — evaluating a function — requires the evaluator (X) operating through emit (M).

3.2. The Purity Boundary

The entity system makes this distinction structural through two reference types:

• Hash reference (system/hash): points to an entity by content hash. Referentially transparent — the referent is the same everywhere, always. This is computation-as-structure: the referenced entity exists as information.
• Path reference (system/tree/path): points to a tree path. What lives there may change over time via emit. The answer depends on current state. This is computation-as-activity: the result must be evaluated.

Expressions using only hash references are pure — their results exist as information regardless of when or whether anyone evaluates them. Expressions accessing paths are impure — their results depend on the tree’s current state. This classification arises from content addressing, not from language design.

3.3. Verification, Coherence, and Trust

The information space is not undifferentiated. Structures in the entity system have verifiable properties — but verification operates at distinct layers, each with different reach.

Structural integrity is mechanically checkable. Content hashes verify that data matches its claimed identity. Type validation confirms an entity conforms to its declared shape. Cryptographic signatures verify provenance. Capability chains trace to root grants. These compose: an entity that passes all layers carries its verification as entities in the tree. Once verified, the result persists by hash — re-verification is a hash comparison, not a re-derivation.

But structural integrity says nothing about correctness. A structurally valid entity can contain a false statement. An entity of type proof with a valid hash may contain an invalid proof.

Mathematical coherence is a different layer. The relationships within a structure are consistent — the proof is valid, the function computes what it claims, the derivation follows from the axioms. Checking this requires evaluating the mathematics, which is computational work. The entity system can host this verification (compute expressions, proof-checking handlers) but coherence is not a structural property — the evaluator must do the work. The coherent structures are a subset of the structurally valid ones.

There is a tension here. A result at compute/{fn}/{input} might already be correct. Content addressing preserves it: if the hash checks out, the content has not changed. But structural integrity does not tell you the result is mathematically correct — only that it has not been altered. Someone or something had to produce it correctly in the first place, or you must re-derive it. Verification is itself computation, producing another result whose correctness you must then trust or verify. Content addressing collapses re-verification to a hash comparison once the initial work is done, but that initial work still has to happen. The relationship between structural presence, mathematical coherence, and verified knowledge is an interplay the system makes visible but does not fully resolve.

Historical accuracy is yet another layer. A peer claims “this is the complete history of this entity.” The system can verify the claim’s structural integrity (typed, signed, authorized) but cannot verify that the history is actually complete without independent access to it. Corroboration from other peers helps but is itself a trust relationship.

Correspondence — does the claim match reality? — is outside the system. The map can verify its own coherence but not its relationship to the territory.

These layers do not reduce to each other. Each provides something the previous cannot. The entity system has concrete tools at the structural layer and can host verification at the mathematical layer through computation. The historical and correspondence layers require something the system cannot provide on its own: independent knowledge, or trust.

In a distributed system with no central authority, the gap between structural verification and historical truth is filled by trust relationships between peers. The capability system manages these relationships — typed, content-addressed tokens expressing who is authorized to do what. Capabilities do not create trust; they give peers tools to express and scope the trust relationships they have decided on.¹

3.4. The Tree as Relation Space

The tree is not only a namespace — it is a relation space over content-addressed data. Path segments can contain content hashes, bridging content space and naming space:

• Arity 0: config/settings $\to$ value (named constant)
• Arity 1: signatures/{A} $\to$ sig (unary relation)
• Arity 2: diff/{A}/{B} $\to$ result (binary relation)
• Arity 3: merge/{A}/{B}/{base} $\to$ result (three-way merge)

The hash space is universal — paths can reference content that exists, will exist, or could theoretically exist. This makes the “infinite lookup table” concrete: the path compute/{fn}/{input} is the table entry for “apply fn to input.” What materializes the entry is the evaluator:

• Stored relation: the result already exists at the path. Structure. The answer is there.
• Computed relation: the evaluator generates the result on demand. Activity.
• Hybrid: computed once, then stored. Activity crystallizes into structure — memoization as the transition from computation-as-activity to computation-as-structure.

Two caveats. First, the invariant pointer pattern (peer + convention + hashes $\to$ deterministic path) is coordination-free for addressing but convention-dependent for semantics. Second, the tree expresses claims, not truths. A peer’s entry at diff/{A}/{B} is that peer’s claim about the diff — it could be incorrect. Per-peer namespacing makes provenance explicit, but provenance is not correctness.

4. The Computational Model

4.1. What the Architecture Is

The entity system has a specific computational character. It is not neutral about computation — it makes a specific structural commitment: computation is the transformation of typed data in a content-addressed tree by evaluators that read structures and emit results.

This works because the substrate is information. The system represents computation, state, types, handlers, capabilities, and programs as the same thing — typed entities with content-addressed identity, organized in a tree, mutated through emit. The generality comes from the observation that a very broad range of what systems do can be represented as information and state changes. The structural properties (self-description, versioning, convergence, verifiability) are not designed in — they are enforced by the primitives. Content addressing enforces immutability and identity. The tree enforces namespace and addressability. Emit enforces atomic state crossing. These are consequences of the structure, not features added on top.

4.2. Fixed Evaluators and Universality

At any point in time, every evaluator that is actually running is a fixed evaluator. A registered handler is a fixed piece of code that processes typed inputs and produces typed outputs. Open dispatch — the ability to register new handlers at tree paths — is potential, not a property of the running system. At any moment, the system is a fixed configuration of fixed evaluators operating on typed data in the tree.

This is not a limitation. A fixed evaluator operating on sufficiently expressive data exhibits computational universality. The compute extension’s six core expression forms — literal, lookup, apply, if, let, lambda — are a lambda-calculus kernel, Turing-complete on their own; the further expression types it ships (arithmetic, comparison, field access, and the rest) are added for ergonomics, not power. The evaluator does not change; the data it processes determines what gets computed. Universality lives in the expressiveness of the data, not in the complexity of the evaluator.

This has a direct consequence for the system’s structure: because entity-native computation is Turing-complete, any computable function can in principle be expressed as entity-native data and transferred between peers. Hash functions, encoders, type validators, domain handlers — all computable, therefore all structurally expressible as compute expressions, therefore all transferable as entity data once peers share the evaluator specification. This is the structural foundation for the transferable-genome claim developed in The Entity System and The Universal Computational Genome: the native platform code required for participation is small (evaluator + primitive I/O + a few standardized natives), and everything else is data that can cross the wire.

This may say something about computation in general. A CPU is a fixed evaluator — fixed instruction set, fixed logic gates. It achieves universality because the instruction set is expressive enough for the fixed evaluator to compute anything. A ribosome is a fixed evaluator — it reads codons and produces amino acid chains according to fixed rules. It achieves biological universality because the genetic code is expressive enough for the fixed evaluator to produce any protein. In each case, the evaluator is fixed and the data carries the program.²

The entity system makes this explicit. The evaluator reads typed structures from the tree. The structures are data — entities with content-addressed identity. The evaluator transforms them and emits results back. What the evaluator computes depends entirely on what data is in the tree. “Open dispatch” means the tree can contain handler registrations that change which evaluators are active — but this is itself a data change processed by a fixed dispatch mechanism. The compute extension, in this framing, is the structurally privileged bridge: the single native-implemented evaluator that makes the transferable computation layer possible.

4.3. Hosting Other Models

Because computation is represented as typed data, the architecture can host any compute model. Lambda calculus, Turing machines, register machines, dataflow graphs — any of these can be represented as typed entities in the tree and processed by an appropriate fixed evaluator. The current compute extension uses lambda calculus-style expressions:

• compute/literal — constant values
• compute/lookup — variable reference
• compute/apply — function application
• compute/if — conditional
• compute/let — binding
• compute/lambda — abstraction

Nothing prevents defining alternative expression types — compute/register-machine, compute/dataflow-node — processed by different fixed evaluators registered at different paths.

4.4. Inherited Properties

Any compute model hosted in the entity system inherits structural properties from the architecture:

• Reactivity: subscription + emit means any compute subgraph can trigger on tree changes
• Self-description: compute expressions are typed entities — the system can inspect, validate, and transform its own programs
• Versioning: content-addressed compute graphs have structural history — every modification preserves the previous version
• Persistence: compute subgraphs survive restart — the tree is durable
• Addressability: every compute node is an entity with a path — composable by reference, shareable across peers
• Authorization: capabilities scope what computation can do

These properties come from the architecture’s own structure, not from any hosted compute model. Lambda calculus alone does not provide reactivity or persistence. Turing machines alone do not provide self-description or addressability. The architecture provides what no individual model provides on its own.

4.5. Computational Equivalence

Entity computation does not claim new computational power. The same class of computable functions. What we observe is different: structural properties that computation inherits by existing in content-addressed typed data. Same power, different structure.

5. Formal Systems and Mathematics

5.1. Mathematics as Information Structure

Mathematics is a structural information system — typed objects with relationships. A formal system has axioms (typed entities), inference rules (transformations), theorems (derived entities), and proofs (chains of entities connecting axioms to conclusions through valid steps). All of these are information: typed, structured, with relationships that can be verified.

In E+I+T, a formal system is a region of the tree. Its axioms are entities at known paths. Its inference rules are structural relationships between entity types. A proof is a chain of entities, each referencing the previous, forming a path from axioms to conclusion. The proof’s content hash is its identity — the same proof, constructed independently by different agents, produces the same hash.

This is not a claim that E+I+T is a new foundation for mathematics. It is an observation that mathematics, as a structural information system, maps directly to the entity system’s representational model. Typed data with content-addressed identity and named organization is what formal systems already are — the entity system makes this explicit.

5.2. The Complete Tree and the Incompleteness Theorems

The complete E+I+T tree would contain every formal system, every proof in every system, and every theorem reachable from every set of axioms. It would also contain every false statement and every invalid proof — E+I+T does not discriminate. The coherent structures (valid proofs, satisfied type constraints, consistent relationships) are a subset of all possible structures.

Each formal system occupies a region of this space — a subtree with its own axioms and rules. Gödel’s incompleteness theorems show that no single region contains proofs for all truths reachable from its axioms. The complete E+I+T space contains all regions, all proofs, all truths. Incompleteness is a property of regions (specific formal systems), not of the space itself.

Three distinct things:

1. A theorem — a structural relationship in E+I+T. It holds as information.
2. A proof — a path through E+I+T from axioms to conclusion. Also information.
3. Finding the proof — searching the space. This requires computation (M+X), which requires time and a physical evaluator.

Computation does not create mathematical truth. It locates specific structures in an information space too large to materialize. The evaluator’s role is navigation — finding the coherent structures among all possible structures.

5.3. Informational Closure and Physical Incompleteness

The entity system is informationally closed: every aspect of the system — data, types, evaluators, execution traces, the evaluator’s own specification — is representable as entities in the tree. There is no information about the system that cannot be expressed within the system.

But the system is not physically closed. The tree contains the evaluator’s description, but a description does not execute itself. An evaluator described in the tree still needs another evaluator to run it. That evaluator is also describable, requiring yet another. The regression is infinite in description but terminates in physics: at the bottom, a physical process (silicon, chemistry) implements state transitions governed by physical law, not by another evaluator.

This is the entity system’s version of the limits of self-reference:

• Gödel: a formal system cannot prove all truths about itself (logical incompleteness)
• Turing: a program cannot decide all questions about programs (computational incompleteness)
• Tarski: a language cannot define its own truth predicate (semantic incompleteness)
• Entity system: the tree cannot execute its own evaluator from within (physical incompleteness)

The entity system’s version is physically grounded. The information is complete — everything is representable. What is missing is not information but actuality. Having the description does not equal running it. The bootstrap evaluator (see The Entity Machine Boundary) is where this limit is concretely encountered: a physical process, external to the tree, must read the description and begin evaluation.

6. Self-Description

6.1. The Fixed Point

system/type is itself of type system/type. The type system describes itself. The recursion bottoms out at a small set of bootstrap types — primitive value types, meta-types for describing types, and a few structural types for hashes, paths, and type names. These seed the type system. The protocol’s own structures (execute, handler, capability token, and others) are then defined as ordinary type entities using this bootstrap set.

6.2. Why Self-Description Emerges

When everything is an entity, the system’s own description is entities. Type definitions are entities. Handler manifests are entities. Capabilities are entities. The system describing itself in its own terms is not a designed feature — it is what happens when a system commits to a single representational substrate.

6.3. The Meta-Circular Evaluator

The dispatch layer evaluates compute expressions that are themselves entities in the tree. The evaluator’s own handler manifest is an entity. The evaluator’s type definitions are entities. The system that evaluates programs is described by the same structures it evaluates.

This is structurally analogous to LISP’s homoiconicity and Smalltalk’s metaclass hierarchy, with two differences: content-addressed identity (the evaluator’s description has a verifiable hash) and persistence (the description survives in the tree across restarts). Unlike reflective towers (3-LISP), which require an infinite tower of meta-levels, the entity system’s self-description closes at a finite fixed point.

7. Types in Entity Computation

Types in the entity system are not external annotations. They are computational data — entities in the tree that participate in dispatch, validation, self-description, and authorization.

7.1. Types as Data

In most systems, types are external to the data they describe: schemas compiled from .proto files (Protobuf), hardcoded object types in source code (Git), codec IDs (IPFS), integer enums (Nostr), byte streams with types in a separate language (Inferno).

The entity system crosses this boundary: type definitions are entities of type system/type, stored at system/type/* in the tree, subject to the same content addressing, versioning, and dispatch as all other data. This crossing — the types-as-data transition — has cascading consequences: dispatch becomes type-aware, validation becomes data-driven, extensions become self-describing, and the protocol describes itself in its own terms.

This transition is examined across existing systems in Convergent Evolution, where it appears to be a stopping point that no comparable system has independently crossed.

7.2. Two-Level Type Architecture

The entity type system separates into two levels:

Level 1 — Structural types (core protocol): Shape description — what fields exist, their types, optionality. Single inheritance via extends. Open types by default (unknown fields preserved). Generics. Content-addressed identity. No value validation — structure only.

Level 2 — Value constraints (type extension): Pattern validation, range constraints, enumerations. Narrowing rules: child constraints must be equal to or more restrictive than parent. This guarantees Liskov substitution — any entity valid under a child type is valid under the parent.

This separation reflects an observation: structure is universal (every system needs to know field shapes), while validation is domain-specific (what counts as valid varies). The core protocol enforces structure; extensions enforce domain constraints. Both are entity-native.

7.3. Two Reference Semantics

The type system reveals two reference semantics that correspond to the computation-as-structure / computation-as-activity distinction:

Hash reference (system/hash): value reference. Points to content-addressed entity. Immutable, pure, referentially transparent.

Path reference (system/tree/path): location reference. Points to a tree path. Mutable (binding can change via emit). Impure — the answer depends on when you look.

This maps onto well-known territory: value vs. reference types, immutable vs. mutable bindings, pure vs. effectful computation. What is notable is that the distinction arises structurally from content addressing rather than from language design.

7.4. Cross-Compilation Partition

When translating any programming language to entity computation, language features partition into three categories:

Category A (maps directly): Data types, functions, closures, generics, async, pattern matching, modules, interfaces. These map to entity types, handlers, compute expressions, type parameters, continuation chains, tree structure.

Category B (erases): Lifetimes, ownership, borrow checking, GC internals, stack layout. Memory management concerns that do not cross the content-addressed boundary. Content addressing provides its own identity and lifetime semantics.

Category C (requires handler embedding): SIMD, inline assembly, memory-mapped I/O, raw pointer arithmetic. These require machine access and live inside native handlers, opaque to the entity model. See The Entity Machine Boundary for the machine boundary analysis.

The partition is uniform across languages: Rust, Go, Python, Haskell, and C all exhibit the same A/B/C split despite radically different type systems and runtime models. This uniformity suggests the entity type system captures a natural level of abstraction — the level at which computational structure is independent of runtime representation. The formal dimensional analysis is developed in Dimensional Completeness.

7.5. Curry-Howard Interpretation

The entity type system admits a Curry-Howard reading: type definitions as propositions, conforming entities as proofs (witnesses), type validation as proof checking. An entity that validates against a type definition is a constructive witness that the shape specification is satisfiable. The bootstrap types are axioms. The fixed point is a self-referential axiom.

This interpretation is suggestive, not formal. The entity type system is a shape description language, not a dependent type theory. But the structural correspondence is present: types constrain entities as propositions constrain proofs, and content-addressed identity means the same witness always has the same identity regardless of who constructs it. Whether a full Curry-Howard correspondence can be established is an open question.

8. Three Execution Models

Three models describe the temporal relationships between agent activity and information transformation. Each activates a different pair-coverage over the computational triangle (TMX) and its supporting structure.

8.1. Synchronous

Computation happens now, in response to a request. EXECUTE $\to$ handler runs $\to$ EXECUTE_RESPONSE returns. Connection-scoped. Results are transient unless explicitly stored. The familiar request-response pattern. In pair terms: EX + TX directed; no MX cascade required; no persistence across the request boundary.

8.2. Continuation

Computation happens later, triggered by an event. EXECUTE creates a continuation chain stored in the tree. Each step is an entity. Execution state persists across restarts — CPS (Continuation-Passing Style) made explicit. The execution state is inspectable, composable, and referenceable because it is entities in the tree. In pair terms: TX + EX + TM — dispatch with typed params, plus tree bindings for the chain entities that provide durability.

8.3. Reactive

Computation happens whenever a dependency changes. Compute expressions in the tree react to tree-binding changes (the Bind event) via the emit pathway. When an input’s binding updates, dependent expressions re-evaluate automatically. Spreadsheet semantics: cells are entities, formulas are compute expressions, changes propagate through the dependency graph. Cascades driven by the Bind event are canonical; cascades driven by content-store changes alone (the Store event in isolation) are structurally possible but currently untested territory. In pair terms: the full TMX triangle activated, with IX added for convergence detection (same-hash-no-write stops the cascade).

8.4. Temporal Coverage

These three models cover three temporal relationships:

• Synchronous: now, in response to a request (EX + TX)
• Continuation: later, triggered by an event (EX + TX + TM)
• Reactive: whenever a dependency changes (full TMX + IX)

We have not identified a fourth temporal relationship that does not reduce to one of these three or a composition of them. Each model is independently Turing-complete. These are execution models (when computation happens), not compute models (how it computes). Any compute model can be evaluated in any execution model.

The three models correspond to protocol mechanisms: synchronous execution is core (EXECUTE/EXECUTE_RESPONSE), continuation uses the continuation extension, and reactive uses the compute + subscription extensions. All three compose through the same handler mechanism, each pushing a specific subset of the TMX triangle’s pairs into regime 3.

9. Emergent Computational Structures

Several computational structures appear without being explicitly designed in. They emerge from the primitives.

Actor model. An entity at a tree path with an inbox handler is structurally an actor: identity (peer + path), state (tree subtree), behavior (handler), mailbox (inbox). This was not designed as an actor model.

CPS. Every EXECUTE is structurally a continuation. Synchronous execution uses implicit continuations (the connection). Asynchronous execution uses explicit continuations (deliver_to paths). CPS is what EXECUTE structurally is.

Reactive cascades. Subscription + emit produces reactive propagation. A tree-binding change (the Bind event) triggers subscriptions, which may trigger further computation, which emits further changes. The cascade is the computation.

Relational structure. Typed records with hash references form relations. Entities are rows. Types are tables. Content hashes are primary keys. Hash references are foreign keys. The explicit layer (hash-in-path relations) and implicit layer (hash references within entity data) compose to give the tree both navigational and structural relational expressiveness.

10. Two Orderings

The entity system can be approached from two directions. Each reveals different structure. Together they show the full picture.

10.1. The Entity Ordering (Information-First)

The build-up sequence from The Entity System, read as triangle activation:

• E+I+T: pure information — the EIT triangle (self-description) complete. Convergence of structural truth without an evaluator.
• E+I+T+M: mutability — the ITM triangle (emit) complete. IT substrate plus IM and TM extending into time. Structural potential for versioning and audit exists; no evaluator yet to actualize it.
• E+I+T+M+X: the evaluator — the TMX triangle (reactive dispatch) complete. Computation, dispatch, convergence, reactivity — all temporal properties actualized through MX closure.
• E+I+T+M+X+P: distribution — the IXP (cryptographic capability) and TXP (distributed dispatch) triangles complete. Capabilities, trust boundaries, cross-peer cascade.

Information precedes computation. Self-description and convergence exist at E+I+T without any evaluator — the EIT triangle alone is sufficient. The properties are structural — they follow from the triangles that become active at each step, not from the choice of compute model within the evaluator.

10.2. The Church Ordering (Computation-First)

Starting from lambda calculus and extending:

• L0 (lambda calculus): pure computation — Turing completeness
• L0 + identity: computation with content-addressed identity and state
• L0 + identity + locality: located computation with bounded transfer
• L0 + identity + locality + authority: authorized computation

This shows how to arrive at the entity system from established formal territory. Church provides the computational base. Content addressing provides identity. Envelopes provide locality. Capabilities provide authority.

The three extensions beyond lambda calculus produce $2^3 = 8$ combinations, each a coherent system:

Known systems occupy specific positions in this space.

10.3. What the Two Orderings Show Together

The entity ordering reveals something the Church ordering obscures: some properties that the Church ordering attributes to “computation + identity” emerge from identity and structure alone, without computation. Self-description at E+I+T is a structural fact. Convergence is the same. No evaluator is needed.

Neither ordering is more correct. The Church ordering is analytically useful — it connects entity computation to established formal domains. The entity ordering is structurally revealing — it shows that information structure exists independently of computation. Together they show that the same position in a combinatorial space can be reached from either direction.³⁴

11. Related Work

Lambda calculus and typed lambda calculi. Church’s untyped lambda calculus (Church 1936) provides the computational base. The entity compute extension implements lambda calculus directly. System F, the Calculus of Constructions, and dependent type theories provide increasingly expressive type disciplines; the entity type system is deliberately simpler (structural shapes, not dependent types), trading expressiveness for universality across languages.

Process calculi. The pi-calculus (Milner et al. 1992) models mobile processes with channel communication. The entity system has structural parallels — per-peer trees as boundaries, EXECUTE as communication, capability-scoped mobility — but starts from data rather than processes.

Actor model. Hewitt’s actor model (Hewitt et al. 1973) and Agha’s formalization (Agha 1986) define concurrent computation through identity, state, behavior, and mailbox. The entity system produces actor structure from its primitives (inbox + continuation) without designing for it.

Content-addressed computation. Git (Torvalds 2005) provides content-addressed version control without computation. IPFS (Benet 2014) provides content-addressed distribution. Nix (Dolstra et al. 2004) provides content-addressed builds with domain-specific computation. Unison (Chiusano and Bjarnason 2019) is the closest prior art for content-addressed code, but with a different architecture (no tree, no emit pathway, no capability model).

Self-describing systems. LISP’s homoiconicity, Smalltalk’s metaclass hierarchy, and reflective towers (Smith 1984) provide self-description through different mechanisms. The entity system’s self-description is finite (fixed point), content-addressed (verifiable), and structural (not nominal).

Persistent data structures. Clojure and Datomic use immutability and structural sharing but with assigned identity (not content-derived). The entity system’s persistence follows from content addressing rather than from design choice.

12. Discussion

12.1. Architecture vs. Formalism

This paper does not present a new computational formalism. It presents a computational architecture — a structural context that determines what properties computation has. A formalism says what is computable. An architecture says what structure computation has when it occurs in a particular context. Entity computation says nothing new about computability. It describes structural properties.

12.2. The Formal Gap

The analysis rests on structural observations rather than on mathematical proofs. Operational semantics, confluence proofs, and minimality proofs are all open research directions. The two orderings provide independent structural reasoning — properties predicted by one ordering appear in the other — but structural correspondence is not proof.

12.3. The Boundary Principle

The six primitives define a boundary. Everything inside — 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.

This boundary explains the agnosticism properties: any compute model that crosses the boundary via emit gets the guarantees. Any type system that maps to entity types gets structural typing and content-addressed identity. Any language that implements the interface participates. Internal details are invisible at the boundary.

The boundary is also the trust boundary. Capabilities are checked at the boundary. A handler’s internal state is not accessible except through EXECUTE.

Systems with fewer primitives have narrower boundaries (see The Entity System). 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 broad coverage.

12.4. Connections to Other Papers

This paper’s analysis connects to several companion papers:

• Machine boundary (see The Entity Machine Boundary): Category C features (those requiring hardware access) define where entity computation ends and physical computation begins. The bootstrap evaluator — the minimal mechanism that reads typed structures and reduces them — is the machine boundary question.
• Computational genome (see The Universal Computational Genome): The biology parallel maps to the evaluator, not to the protocol. The ribosome is a fixed evaluator operating on typed structures via biochemical “emit.” The abiogenesis question — how does the first evaluator arise? — is both biological and architectural.
• Dimensional Completeness: The cross-compilation partition and type dimension coverage connect to formal dimensional analysis.
• Convergent Evolution: Types-as-data appears to be the transition that no comparable system has independently crossed — the analysis of why is developed there.
• Information as Substrate: The computation-as-structure / computation-as-activity distinction is foundational to the philosophical analysis of information and physicality.

12.5. Limitations

• No formal operational semantics defined
• No confluence or minimality proofs
• The compute extension is the only implemented compute model — agnosticism is argued structurally, not demonstrated with alternative implementations
• The L0–L3 analytical framework is suggestive rather than rigorous
• The Curry-Howard interpretation is structural, not formal
• Related work engagement is incomplete — deeper treatment of process calculi, reflective towers, and persistent data structure theory is needed
• 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.

13. Conclusion

The Entity Church Architecture describes what computation becomes when it occurs in content-addressed typed data. It is a computational architecture, not a new formalism — same computational power, different structural properties.

The architecture is compute-model agnostic. Any model embedded in it inherits reactivity, self-description, versioning, persistence, addressability, and authorization. These are architectural properties that no individual compute model provides on its own.

Two orderings reveal the architecture’s structure. The entity ordering shows that information structure exists at E+I+T before computation enters — self-description and convergence are structural facts, not computational results. The Church ordering shows how to arrive at this architecture from lambda calculus through three extensions: identity, locality, authority. The $2^3 = 8$ combinations map known systems to positions in the resulting space.

Three execution models — synchronous, continuation, reactive — cover the temporal relationships we have identified between agent activity and information transformation.

The tree is the computational substrate — simultaneously state, record, and result. As a memory model, it provides a universal, authority-scoped namespace where each peer’s state is their own and synchronization is opt-in. The emit pathway provides the atomic state crossing. The evaluator actualizes what the structure makes possible. The verification layers — content hashes, type validation, signatures, capabilities — compose so that structure carries its own proof.

Open questions:

• Are the properties at each Church extension level structural — would any system with the same ingredients exhibit them?
• Is there a fourth execution model that does not reduce to the three identified?
• Can an alternative compute model be implemented in the entity tree and shown to inherit (or not inherit) the architectural properties?
• Can the cross-compilation partition be formalized and the uniformity proven?

14. Appendix A: Computation as a Domain — A Structural Decomposition

This appendix treats computation as a domain in its own right and applies the structural-analysis methodology developed in A Structural Methodology for Information System Domains to it. The purpose is to surface the primitives a computation domain must have at the resolution at which it can be analyzed structurally, and to use the resulting decomposition to discriminate entity computation from the standard lambda-calculus presentation. The body of this paper assumed a working notion of “computation” throughout; the appendix makes that notion structural.

14.1. The domain

We analyze “computation expressed as the reduction of structured expressions” as a domain. Instances include the untyped lambda calculus, typed lambda calculi (simply-typed, System F, dependent), combinator calculi (SK, BCKW), term-rewriting systems, abstract reduction systems, process calculi, and entity computation as described in this paper. The domain excludes computation as physical activity (which belongs to the machine-boundary domain The Entity Machine Boundary) and computation as information structure without an evaluator (which belongs to the substrate domain The Entity System, Information as Substrate).

14.2. The primitives

Six primitives survive the structural-minimality / compositional- productivity / empirical-recurrence tests at this resolution. We use two-letter codes to avoid collision with the entity-system primitives of The Entity System:

• Ex (Expression). The structural form being reduced. Each instantiation chooses a syntax (terms, combinators, processes); the primitive is the structural unit a reduction operates on.
• Rd (Reduction). The operational unit. A reduction transforms one expression into another according to a fixed rule (beta, eta, delta, rewrite-step, transition). Without Rd, expressions are static information; Rd is what makes them computational.
• Ev (Evaluator). The agent that performs reductions. In the untyped lambda calculus tradition, Rd and Ev are often presented as a single concept: reduction is what the evaluator does. The methodology separates them because they admit different partial-level decompositions and are independently varied across instances (a fixed evaluator that reads a typed expression language is distinct from a programmable evaluator that reads any expression).
• Ty (Type). Structural annotation on expressions. Untyped systems are at Ty=0; simply-typed systems at Ty=1; polymorphic at Ty=2; dependent at Ty=3; types-as-data systems (entity computation) at Ty=4.
• Rf (Reference). How expressions refer to other expressions. Lambda calculus uses variable binding (Rf=1: name-based reference). Entity computation splits Rf into two modes: hash-reference (content- derived, eternal) and path-reference (name-based, temporal) — partial-level Rf=2 with the purity boundary between them.
• Pe (Persistence). The layer in which referenced expressions reside between reductions. Lambda calculus is at Pe=0 (expressions exist only within the reduction context); recursion-equation systems at Pe=1 (a global environment of definitions); entity computation at Pe=2 (the tree as content-addressed persistent store).

14.3. Dependency structure

Ex is the root: every other primitive operates on or annotates expressions. The dependencies are:

• $\mathrm{Dep}(\mathrm{Ex}, \mathrm{Rd})$ — reduction needs something to reduce.
• $\mathrm{Dep}(\mathrm{Rd}, \mathrm{Ev})$ — the evaluator performs reductions; without Rd the evaluator has nothing to do.
• $\mathrm{Dep}(\mathrm{Ex}, \mathrm{Ty})$ — types annotate expressions.
• $\mathrm{Dep}(\mathrm{Ex}, \mathrm{Rf})$ — references point to expressions.
• $\mathrm{Dep}(\mathrm{Rf}, \mathrm{Pe})$ — persistence is reference- resolved storage; without Rf there is nothing to store-and-retrieve.

The coherent sub-lattice filters $2^6 = 64$ subsets to those satisfying all dependencies. The interesting positions are:

14.4. Pair classification

Six primitives produce $\binom{6}{2} = 15$ pair-relationships. The heavy pairs — those carrying the bulk of structural load — are:

• Ex-Rd. What reduction is: a transformation on expressions.
• Ex-Ty. Type-annotation: typed lambda calculus’s structural content.
• Ex-Rf. Variable binding and hash-reference both live here.
• Rd-Ev. Operational semantics: the rules an evaluator follows.
• Rd-Ty. Type preservation and progress (subject-reduction).
• Rf-Pe. Reference-resolved storage: the lookup operation.
• Ev-Pe. The evaluator reads from persistent storage.

The remaining eight pairs are derivative — they hold relations that follow from the heavy pairs combined.

14.5. Core triads

Three triads carry load:

• $\{$Ex, Rd, Ev$\}$ — the reduction core. What makes computation computation. Every instance has this triad.
• $\{$Ex, Ty, Rd$\}$ — the typed-reduction core. Type preservation, progress, soundness all live here. Distinguishes typed from untyped computation.
• $\{$Ex, Rf, Pe$\}$ — the persistent-reference core. Where the tree-as-memory enters. The purity boundary is structurally located at the Rf primitive’s partial-level decomposition: Rf=2 with hash-reference and path-reference as two sub-axes.

14.6. What the decomposition discriminates

The body of this paper claims entity computation differs from standard lambda calculus not in computational power but in architectural properties. The methodology decomposition makes this precise:

• Untyped lambda calculus sits at $\{$Ex, Rd, Ev$\}$ with Ty=0, Rf=1, Pe=0. Three-primitive configuration.
• Simply-typed lambda calculus sits at $\{$Ex, Rd, Ev, Ty$\}$ with Ty=1, Rf=1, Pe=0. Four-primitive configuration.
• Entity computation sits at $\{$Ex, Rd, Ev, Ty, Rf, Pe$\}$ with Ty=4 (types-as-data), Rf=2 (hash-reference and path-reference distinguished by the purity boundary), Pe=2 (the tree as content-addressed store). Six-primitive configuration.

The architectural properties the body of this paper credits to entity computation — self-description, versioning, addressability, reactivity — map to specific pair activations the configuration makes available:

The cross-compilation partition discussed in the body — pure computation (Class T) versus effectful native handlers (Class N) — maps to the partial-level structure of Rf: Class T computation uses only hash-references (Rf-hash sub-axis); Class N computation crosses the purity boundary into path-references and native effects (Rf-path sub-axis).

14.7. Trajectory observations

Instances of this domain cluster into three structural trajectories when ordered by primitive accumulation:

1. The Church extension trajectory. Untyped lambda calculus $\to$ simply-typed lambda calculus $\to$ System F $\to$ dependent types. Adds Ty in successive partial-level steps. Pe stays at 0.
2. The persistence trajectory. Untyped lambda calculus $\to$ recursion-equation systems $\to$ ML with refs $\to$ persistent typed environments. Adds Rf to Rf=2 and Pe to Pe=2. Ty stays at 0 or 1.
3. The entity-computation trajectory. The combined endpoint: six primitives at full partial levels, with the purity boundary formalized inside Rf’s partial-level structure.

The body’s “two orderings” (entity-first and Church-first) are the projections of trajectories 2 and 1 onto the entity-system primitive set of The Entity System. The structural-methodology decomposition exhibits them as two routes through the coherent sub-lattice of the computation domain.

14.8. What this appendix does not establish

The decomposition is a Layer-1 application of the structural methodology (see A Structural Methodology for Information System Domains) to the computation domain. It is not a proof of irreducibility in the formal sense; the primitive set is the current iteration of the 3/3b loop and a refinement that combines Rd and Ev into a single primitive remains open (the case for separation rests on partial-level divergence across instances, which the methodology accepts as sufficient grounds for separation but does not prove necessary). Whether the trajectory taxonomy generalizes beyond the three identified routes is an open question.

The Universal Computational Genome: Self-Description, Self-Replication, and the Biology of Content-Addressed Systems

1. Introduction

A genome is more than a sequence. It is a system that contains its own specification, builds organisms from that specification, and maintains the specification’s integrity across generations. The genome does not merely store information — it stores the information needed to interpret, replicate, and repair the information store itself.

This paper asks whether a digital system can have the same property. Not as metaphor — many systems are loosely called “self-describing” — but structurally: a system whose data contains the complete specification of the system that processes that data, including the specification of the specification.

We define a computational genome as an information system satisfying three properties:

1. Self-description: the system contains type definitions that describe all types, including the type that defines types
2. Self-replication: the system contains its own build instructions and can bootstrap on a new physical substrate
3. Self-maintenance: the system can verify its own integrity, validate its own structure, and track its own history

We show that a computational genome is constructible from the six entity system primitives, fifteen pair-relationships, and five named structural triangles developed in The Entity System. The construction is concrete: a small set of bootstrap types seeding the self-description (EIT) triangle, a tree namespace, and a bootstrap evaluator estimated at approximately 400–500 lines of C. The description grows as the system evolves. The evaluator stays small. This asymmetry may be a structural property of systems approaching the self-description fixed point.

In the transferability framework of The Entity System, this structure divides cleanly: the bootstrap evaluator plus primitive I/O is Class N (platform-native, ~hundreds of lines per platform, not transferable between peers); standardized algorithms (hash, encoding, bootstrap type validator) are Class S (spec-fixed natives, implemented identically per platform); everything else — type definitions, handler implementations, domain logic — is Class T (transferable as entity-native data). The compute extension’s evaluator is Class B, the bridge that makes Class T transferability work by providing a shared reduction semantics across peers. This classification matches the biology: ribosome plus minimum cellular machinery is the native bootstrap; the genetic code is the spec-fixed universal; the genome is the transferable content that can cross between cells.

The construction reveals structural parallels with biological information systems. The entity system was not designed to resemble biology — the parallels emerged once the construct-and-reduce cycle described in The Entity System had run the system to its irreducible form. Three independent lines of analysis — engineering reduction, structural comparison with molecular biology, and operational analysis against physical constraints — arrive at the same structural vocabulary. We develop these parallels in detail and argue that they arise from shared information-theoretic constraints rather than from analogy.

Companion papers. The six primitives, pair-relationships, and transferability framework are in The Entity System. The computational architecture and Turing-completeness of entity-native computation are in The Entity Church Architecture. The machine boundary — where the evaluator meets hardware — is in The Entity Machine Boundary. The philosophical grounding is in Information as Substrate.

2. The Computational Genome

2.1. Definition

A computational genome is an information system satisfying:

These three properties are individually present in various systems. Reflective languages have self-description. Build systems have self-replication. Version control has self-maintenance. What distinguishes the computational genome is that all three properties arise from the same mechanism — content-addressed typed data in a named tree — rather than from three separate mechanisms layered together.

2.2. Self-Description

The entity system’s type system is built from a small set of bootstrap types. Eight are primitive value types (string, bytes, uint, int, float, bool, null, any). The remaining bootstrap types are structural types needed for the system to describe itself:

• system/hash — content hash reference
• system/type — type definition (the meta-type)
• system/type/field-spec — field specification within a type
• system/tree/path — tree path address
• system/type/name — type name (type identity)
• system/identity/peer-id — peer identity

The critical entry: 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 the bootstrap types, which implementations must recognize as built-in. Every subsequent type — protocol structures, extension types, domain types — is defined as an ordinary entity using this bootstrap set.

One structural note: system/identity/peer-id is conceptually debatable as a bootstrap type. The self-description fixed point is reached at E+I+T, before Peer enters. A system operating at E+I+T+M+X can fully self-describe without peer identity — peers are not required for the type system to be closed. Peer-id appears in the bootstrap set because peer identity uses the same content-derived hash mechanism as entities, making it natural to include at the encoding level. Whether it belongs conceptually in the bootstrap set or is better understood as the first type whose presence anticipates the P primitive is a question the reduction history has not fully resolved.

Self-description is not a feature that was designed in. It is the inevitable consequence of a single representational substrate. When everything is an entity — data, types, handlers, capabilities, the evaluator’s own specification — the system describes itself in its own terms because there is nothing else to describe it in. The self-description fixed point (“where the system’s state contains a complete specification of its transition function”) requires the complete EIT triangle from The Entity System: content-addressed entities (EI pair, so the description has identity), a named tree (IT and ET pairs, so the description has a location and the type-entity binding closes the recursion), and compute expressions (execution added in The Entity Church Architecture, so the description is executable). The EIT triangle is where self-description lives at pair-coverage resolution.

The evaluator gap is the one thing self-description cannot close. The tree contains a complete description of the evaluator — its state machine, its dispatch logic, its type — but a description does not execute itself. This gap is the abiogenesis problem, treated below.

2.3. Self-Replication

The entity tree is the genome. It contains:

• Type definitions at system/type/* (the “genes” — what the system can build)
• Handler manifests at system/handler/* (the “regulatory elements” — how the system responds)
• Compute expressions (the “instructions” — what the system evaluates)
• Configuration and seed data (the “initial conditions” — where the system starts)

Given this tree and a conforming evaluator (the bootstrap evaluator is a design estimate of approximately 400–500 lines of C), the full system boots. With machine architecture types and compiler handlers in the tree, the system compiles its own evaluator for any supported architecture.

If the design estimate holds, the size asymmetry is large — three to four orders of magnitude below comparable self-hosting systems. The comparison is between one estimated number and four measured ones, so read it as a projection, not a benchmark:

This is not because the bootstrap evaluator does less. It is because the entities in the tree do more. The evaluator is minimal because the data is maximally structured — typed, content-addressed, self-describing. The evaluator needs only to read typed structures and dispatch. The complexity lives in the data, not in the machine.

In transferability-framework terms (see The Entity System), the asymmetry is the division between Class N (platform-native, small) and Class T (transferable genome, unbounded). The entity bootstrap evaluator is essentially pure Class N: 400–500 lines per platform that cannot cross between peers because platform instructions differ. Everything else — type definitions, handlers, compute expressions, domain entities — is Class T: entity data that any peer with a conforming evaluator can evaluate identically. This is the same division biology makes: ribosome plus primitive cellular machinery is the native bootstrap (Class N analog); the genetic code is the spec-fixed universal (Class S); genome content is transferable between cells (Class T). The structural claim in The Entity System that “nearly all system functionality is Class T” is the computational-genome claim stated in transferability vocabulary.

The current state of self-replication is bridge-based: implementations use Git for source management and Nix for reproducible builds. Entity-native self-replication — where the build system itself is entity computation — is the long-term target. The five-step compilation gradient illustrates the proposed path:

1. External bootstrap evaluator reads the entity tree
2. Entity-native compiler (a handler) reads source entities from the tree
3. Compiler produces instruction entities (intermediate representation as entities)
4. Assembler produces byte entities (machine code as content-addressed data)
5. System runs on its own output

Steps 2 through 5 are a proposed architecture, not an existing implementation. The entity-native build system is a Phase 3 goal. We are explicit about this: the computational genome is constructible in principle and partially realized in practice.

When moving a peer to new hardware, you do not copy the entire content store (every entity ever emitted, every historical state). You compile down to the computational genome: minimal set of core types, handler definitions, seed data sufficient to bootstrap, and the evaluator description. Ship the genome, bootstrap on the new substrate, reconstruct state from seed data and sync from connected peers. The genome is the survivable form. The running peer is the expressed form. The content store is the accumulated form.

2.4. Self-Maintenance

Content addressing provides integrity verification as a structural property. Five properties emerge from a single mechanism — the content hash function:

• Identity: same content produces the same hash, everywhere, always
• Equality: O(1) comparison via hash
• Integrity: verify content against its hash
• Deduplication: same content stored once
• Convergence: two peers with the same hash at the same path have provably the same content, without coordination

The type system provides structural validation. Every entity carries a type. The type definition is itself an entity in the tree. Validation checks whether an entity conforms to its declared type. Because types are content-addressed, type validation is deterministic: the same entity against the same type definition produces the same result on every peer.

The version DAG provides history. Every emit (state change) is recorded. The content store is logically append-only — old entities persist by hash even after the tree binding changes. Walking the version DAG backward reconstructs any prior state. This is self-maintenance: the system tracks its own history using its own mechanisms.

2.5. The Abiogenesis Problem

The entity tree containing a complete evaluator description is inert. It describes computation perfectly. But it does not compute. As the architecture analysis states: “computation is not a property of information. It’s a property of information plus an evaluator plus time.”

This is the abiogenesis problem. In biology: DNA without a ribosome is inert chemistry. A ribosome without DNA has no instructions. Life requires both simultaneously. Neither is prior. The question is: how does the first evaluator arise from a substrate that does not yet evaluate? A full structural decomposition of the biological R0-to-R2 transition — using the structural methodology of A Structural Methodology for Information System Domains to surface eight sub-levels with explicit dependencies and phase transitions — is developed in Abiogenesis as Progressive Hardening; here we treat the abiogenesis-equivalent question at the level the computational genome encounters it.

In biology, the leading hypothesis involves an RNA world — molecules that serve simultaneously as information storage (like DNA) and as catalytic machinery (like ribosomes). RNA is both description and evaluator, collapsing the two roles into one molecule. From this dual-role starting point, the roles gradually separated through abiogenesis: DNA specialized for storage, proteins for catalysis, and the ribosome crystallized as the minimal evaluator that bridges them. Abiogenesis is the bootstrap phase during which these roles separate and the substrate’s flywheel begins to turn; the ribosome is what persists from that phase. Once biology is running, the pre-life chemistry that produced the ribosome is no longer load-bearing — the substrate carries itself forward.

In the entity system, the bootstrap evaluator (~400–500 lines of C, a design estimate) is the analog of the ribosome: the minimal evaluator that persists once the substrate is running and that bridges the informational layer (entity-native computation in the tree) to the functional layer (executed reductions). In the transferability classification from The Entity System, this is the Class B (bridge) role: the compute extension’s fixed evaluator is not an ordinary extension; it is the structurally privileged substrate that takes Class T data (entity-native computation) and executes it. Every peer needs a native Class B implementation. Once the bootstrap evaluator runs, it reads the tree. The tree contains handler definitions, type specifications, compute expressions. The evaluator processes them. The system is alive. From this point, the system can describe, extend, and eventually compile its own evaluator through Class T handler definitions. But the first evaluation is external — a physical process (a programmer, a compiler, electricity through silicon) that the system itself did not produce.

The ribosome plays the Class B role in biology, and the same structural constraint applies: the ribosome is genetically specified, but the first ribosome had to exist before any gene could express one. The Class B bridge is always platform-native and always prior to the substrate it enables.

The evaluator regression terminates at physics. Evaluator A (the bootstrap evaluator) can be described in the tree. But running that description requires evaluator B. Evaluator B is also describable, requiring evaluator C. The chain is infinite in description but terminates in physical law: at the bottom, silicon implements state transitions governed by physics, not by another evaluator. The system is informationally closed (everything is describable) but physically incomplete (descriptions do not execute themselves) (see The Entity Church Architecture).

The bootstrap evaluator is where abstract information meets physical reality. It is what persists from the abiogenesis-equivalent transition — not the transition itself, but its surviving Class B bridge. In framework terms: the Class B bridge is the persistent mechanism through which Class T transferable genome becomes executable.

We Are Currently in the Bootstrap Phase

The biological parallel runs deeper than a one-time correspondence: the entity system itself is in an abiogenesis-equivalent bootstrap phase today. What we are building — the Go, Python, and Rust peer implementations — is the pre-life chemistry of the entity system. These implementations carry both the description (handler logic encoded in host-language code) and the execution (the host-language runtime) in the same medium, exactly the way the RNA world’s dual-role molecules carry both storage and catalysis at once.

The transition out of this phase is the gradual movement of handler logic from host-language code into entity-native computation under the compute extension. Each handler re-expressed as a system/compute expression in the tree is one step from pre-life chemistry to biology: from a Class N implementation that only the host language can execute to a Class T description that any conforming evaluator can execute identically. The compute extension is the mechanism of the transition; the bootstrap evaluator (the ribosome) is what crystallizes out and persists; the entity-native compute tree (the computational genome) is what carries the substrate forward.

The endpoint is the entity-native peer — a system whose Class N footprint is the bootstrap evaluator and primitive I/O alone, with everything else (handlers, types, extensions, domain logic) running as Class T entity-native computation. At that point, the language-specific implementations that hosted the bootstrap phase are theoretically discardable in the same sense that pre-life chemistry is discarded once biology is running. In practice they are likely retained for performance reasons (a compiled Go handler will outperform an entity-native evaluation for hot paths), but they are no longer load-bearing for the substrate’s identity or continuity. The substrate runs on the bootstrap evaluator plus the computational genome; the Go, Python, and Rust code becomes performance scaffolding rather than required infrastructure.

This puts the current moment in clear structural relief: the entity system is not yet a running biology; it is partway through abiogenesis. The bootstrap evaluator design is the design of our ribosome. The compute extension’s progressive coverage of handler functionality is the autocatalytic spiral that closes the gap between description and execution. The transferability classification names what is on each side of the transition. When the system is post-bootstrap, the language-specific scaffolding is discardable; until then, it is what holds the substrate together.

2.6. Content Addressing as Enabler

Content addressing is what makes self-description concrete rather than abstract. In a system with assigned identity (UUIDs, auto-increment), a type definition can describe structures, but two independent peers cannot verify they have the same definition without coordination. With content-derived identity, same content = same hash = same definition, everywhere, always. Self-description becomes structurally verifiable — a property of the data, not a claim about it.

This is why the build-up sequence produces the computational genome at E+I+T: the combination of typed data (E), content-derived identity (I), and named organization (T) is sufficient for self-description. Mutability (M) adds the ability to change. The evaluator (X) adds the ability to act on the description. Distribution (P) adds the ability to replicate across peers and substrates.

3. How to Build It

3.1. The Primitives, Briefly

The entity system is built from six primitives: Entity (typed data unit), Identity (content-derived hash), Tree (mutable namespace over immutable content), Emit (atomic state crossing), Execution (typed dispatch), and Peer (participant with identity, capabilities, and position). The full treatment is in The Entity System. The computational architecture is in The Entity Church Architecture. Here we need only the structural roles they play in the genome.

3.2. The Tree as Genome

The tree is the genome: named organization of typed information that determines what the system can do and how. The correspondence is specific:

The tree is simultaneously several things: a Kolmogorov program (the description the evaluator interprets), a Shannon codebook (mapping names to content identities), a computational environment (handlers read from and write to it), and a self-description (the tree contains entities describing its own structure). Biology’s genome has the same multi-role character: it is simultaneously an information store, a regulatory network, a construction manual, and a self-copying machine.

3.3. The Evaluator as Ribosome

The evaluator reads typed structures from the tree and produces new structures. At the protocol level: EXECUTE dispatches typed parameters to a handler; the handler processes them; EXECUTE_RESPONSE returns a typed result, emitted back into the tree.

The ribosome does the same thing. It reads codons (three-nucleotide typed units) from mRNA, matches each codon to an amino acid via tRNA (a type-directed lookup), and chains the amino acids into a protein. The ribosome is a bridge handler: it reads typed input in one encoding (nucleotides) and produces output in a completely different physical form (amino acid chains). The handler output — the protein — is not raw tree data. It is the result of evaluation: translated, processed, physically transformed.

Both the evaluator and the ribosome are fixed evaluators in the sense developed in The Entity Church Architecture. The ribosome implements a fixed mapping: 64 codons to 20 amino acids plus stop signals. No handler registration. No open dispatch. No extensibility at the evaluation level. Yet biology achieves effectively infinite variety because the protein space is combinatorially vast ($20^n$ for a chain of $n$ amino acids). Turing-complete computation through combinatorics on a fixed evaluator: this is exactly the pattern the entity system’s compute extension implements, where six expression types (literal, lookup, apply, if, let, lambda) processed by a single fixed evaluator produce Turing-complete computation (see The Entity Church Architecture).

The entity system pseudocode for the core evaluation loop maps directly to ribosomal translation:

loop:
  request = queue.dequeue()          -- read next codon from mRNA
  handler = registry.match(request)  -- tRNA anticodon matching
  result  = handler.execute(request) -- amino acid synthesis
  emit(result)                       -- chain extension / protein output

Biology has additional layers beyond the ribosome’s X0 fixed evaluation. Gene regulation (promoters, repressors, transcription factors) maps to the subscription extension — emit triggers further evaluation. Signal transduction cascades map to reactive compute chains. Epigenetics (methylation, histone modification) maps to tree metadata annotations. The immune system and nervous system may represent biology’s progression up the execution gradient: innate immunity at X0 (fixed pattern recognition), adaptive immunity at X1–X2 (VDJ recombination generates novel receptors — a form of handler generation), and neural computation at X2–X3 (flexible dispatch, learned patterns, routing that changes with experience).

3.4. Von Neumann’s Constructor Model, Realized

Von Neumann’s theory of self-reproducing automata (Neumann 1966) identified two components necessary for self-reproduction: a constructor that builds things according to instructions, and a description that specifies what to build. Crucially, the description plays a dual role: it is both interpreted (read by the constructor to build a copy) and copied (duplicated literally so the offspring has its own instructions).

The entity system realizes this model:

• Description: the entity tree (type definitions, handler manifests, evaluator specification)
• Constructor: the bootstrap evaluator (reads the tree and builds the running system)
• Dual role: the tree is both interpreted (the evaluator reads it to dispatch handlers and process types) and copied (tree snapshot + sync replicates the tree to a new peer)

Biology realizes the same model:

• Description: DNA
• Constructor: the ribosome and associated cellular machinery
• Dual role: DNA is both interpreted (transcribed and translated into proteins) and copied (replicated during cell division)

Von Neumann predicted this structure from logical analysis of self-reproduction in 1948. Biology had been implementing it for 3.8 billion years. The entity system arrived at it through engineering reduction. Three independent paths to the same architecture.

3.5. The Self-Hosting Loop

Self-hosting — a system compiling itself — follows the same bootstrap pattern in compiler engineering. GCC compiles GCC. The Mes bootstrap project builds a C compiler from a minimal Scheme interpreter. The pattern: start with a minimal external evaluator, use it to build a more capable evaluator described in the system’s own terms, then use the new evaluator to replace the original.

The entity system’s path follows the same structure. The bootstrap evaluator (~400–500 lines of C, a design estimate) is the external starting point. It reads the tree. The tree contains handler definitions that, when evaluated, constitute a more capable system. Eventually, the tree will contain compiler handlers that produce the bootstrap evaluator itself as output — closing the loop. At that point, the system is self-hosting: it contains its own build instructions and can reproduce on any substrate that can run the bootstrap evaluator.

The bootstrap evaluator is the entity system’s prime mover. It needs to act only once. After the first evaluation, the entity-native cascade takes over.

4. The Biology Parallel

4.1. Why Biology

The structural correspondence between the entity system and molecular biology was not designed. It was noticed after the construct-and-reduce cycle (see The Entity System) had run the protocol down to six primitives. The architecture documentation classifies the biology parallel as an emergent property: “appeared through simplification and analysis, not planned.”

Three independent paths arrived at the same structural vocabulary:

1. Engineering reduction: alternating construction and reduction over a working protocol; removals letting the entity model absorb mechanisms that another already covered. Arrived at E+I+T+M+X+P.
2. Structural comparison: examining how biological systems store, process, and exchange information. Found the same patterns.
3. Operational analysis: examining how the protocol’s runtime behavior maps to physical constraints. Found the same structures.

The correspondence exists because both are instances of information processing under physical constraints. Biology runs on physics. Computation runs on physics. Both inherit the constraints of the physical medium.

4.2. Level-by-Level Correspondence

The entity calculus defines four levels (L0–L3), each adding a capability. Each level has a precise biological counterpart:

L0 — Transformation. Lambda calculus provides pure functional transformation: take an input, produce an output, no side effects, no identity. The biological analog is enzyme catalysis: a substrate binds, a product is released, the enzyme is unchanged. The enzyme does not know its own identity. It transforms. This is Level 0. The dependency ordering holds in biology: enzyme catalysis works without DNA — ribozymes (catalytic RNA molecules) demonstrate this.

L1 — Identity and state. Content-addressed entities in a named tree provide identity (the hash) and persistent state (the tree). The biological analog is DNA: a gene sequence IS its own identity (change a base pair, change the gene). The genome IS the named state (genes at chromosomal locations, organized by chromosomes, regulatory regions, and promoters). DNA-based life requires catalysis (L0 is prior to L1), and DNA works without cells — viruses demonstrate this.

L2 — Locality. Envelopes provide bounded projections for transfer between contexts. The biological analog is the cell: a membrane creates a local computational context with its own state (cytoplasm contents), its own programs (expressed genes), and its own evaluator (ribosomes). Vesicle transport is materialization — bounded packages of molecular entities transferred between cellular compartments. A molecule binds to a membrane receptor (capability match), the membrane invaginates and brings the molecule inside as a vesicle (envelope), and the vesicle is processed internally (handler dispatch). This is structurally identical to an entity arriving with a capability, passing the check at the trust boundary, entering the peer’s computational space, and being dispatched to a handler.

L3 — Authority. Capabilities provide authorization: who can do what, verified at the boundary. The biological analog at the cellular level is receptor-ligand specificity at the cell membrane. Receptor binding IS capability checking: does this molecule have the right shape (type) to pass? The cell membrane IS the trust boundary. At the multi-cellular level, the immune system provides self/non-self recognition — a more sophisticated authorization model. The dependency ordering holds: cells work without immune systems (single-celled organisms), but immune function requires cells, DNA, and catalysis.

The refined cellular-level correspondence:

4.3. Key Structural Correspondences

The emit pathway is gene expression, not DNA copying. The emit pathway crosses from stored information (the tree) to expressed output (handler results). This is transcription and translation: DNA $\to$ mRNA $\to$ protein. It is NOT a direct copy. The stored information is transformed through a handler boundary into a physically different form. Organisms do not communicate by sending DNA. They communicate by sending proteins and chemicals — the results of evaluating genetic information through the ribosome handler boundary. The raw genetic data stays inside the cell. What crosses the cell membrane is handler output. The entity system has the same architecture: the raw tree is internal to the peer. What crosses the connection boundary is EXECUTE messages — structured, typed requests and responses that are the result of handler evaluation. Direct genetic exchange (horizontal gene transfer in bacteria, sexual reproduction) is the exception — like sync, which directly exchanges tree-level information between peers.

Content addressing is molecular identity. A molecule’s structure determines its identity. The same amino acid sequence folds into the same protein shape, producing the same function. Change one amino acid and you may get a different shape, a different function, a different molecule. This is content-derived identity: the thing IS what it’s made of. The entity system implements the same principle digitally: same type and data produce the same hash. Different content produces a different hash. Identity is intrinsic to content, not assigned by an authority.

Bootstrap types are the genetic code. The bootstrap types are the entity system’s codon table. They define the fundamental encoding — the mapping from raw representation to structured meaning. The codon table (64 codons mapping to 20 amino acids) has been stable across all known life for approximately 3.8 billion years. The entity system’s wire format has been stable throughout the protocol’s evolution; structural change happens at the type-system level, not the wire. Both are conserved for the same structural reason: changing the substrate-level encoding breaks everything that depends on it. The cost of change is proportional to the total amount of existing content (or life) that would break.

The core protocol is the central dogma. Crick’s central dogma (Crick 1970) describes the directional flow of genetic information: DNA $\to$ RNA $\to$ protein. The entity system’s core protocol describes the same flow: tree (stored typed information) $\to$ handler dispatch (type-directed processing) $\to$ emit result (expressed output). Both describe how information moves from persistent storage through interpretation to functional expression.

Communication through handler outputs, not raw data. Organisms communicate through proteins and chemicals — the products of evaluating genetic information through the ribosome. The raw genetic data stays inside the cell. The entity system’s peers communicate through EXECUTE messages — the products of handler evaluation. The raw tree stays inside the peer. Direct tree exchange via sync is the analog of horizontal gene transfer: structurally possible, but not the default mode of interaction.

4.4. Differentiation and Speciation

Two additional parallels connect to the entity system’s Peer primitive.

Differentiation: cells with the same genome produce different proteins based on context (position in the organism, received signals, developmental history). Same genome + different position = different evaluation. This maps to entity peers: same types + different peer context (different capabilities, different local state, different handler configuration) = different computational results. The types (genome) are shared. The evaluation (phenotype) is local. Differentiation is P operating on shared E+I+T through context-dependent M+X.

Speciation: the core protocol defines what can exchange with what. Two peers with the same core protocol can exchange entities — hashes agree, types are compatible, wire format matches. Two peers with incompatible protocols cannot. This IS speciation. The wire format is the DNA alphabet — universal encoding that does not vary. What varies is the content: different types, different tree structure, different handler diversity. Speciation in entity terms: two populations diverge when their types become incompatible enough that sync no longer produces coherent state, even though the encoding (wire format) is still shared.

4.5. What the Parallel Does Not Claim

The claim is not that biology is computation, nor that computation is biology. The claim is narrower and testable: both are information systems operating under physical constraints, and the same constraints produce the same structural solutions.

The criterion for distinguishing structural correspondence from metaphor: if the correspondence is structural, then predictions derived from one domain should hold in the other. Biological strategies (immune response patterns, neural network architectures, evolutionary algorithms) should be directly implementable as entity system patterns — not as simulations but as native structural analogs using the same primitives. And entity system patterns (content-addressed convergence, capability-based isolation, typed self-description) should have identifiable biological analogs. This is a concrete research program.

5. Shared Constraints

5.1. Why the Same Structures Appear

Both biological and digital information systems exist in a universe with specific physical properties: time flows in one direction, space separates agents, energy is required for state transitions, information propagates at finite speed. These constraints are not optional. Any system that processes information physically inherits them.

5.2. The Two-Layer Primitive Structure

Both systems exhibit a two-layer structure that maps to the entity system’s 3+2+1 primitive decomposition (see The Entity System):

Information primitives (exist without agents): datum (content exists), identity (same content = same thing), type (information has kind), composition (information relates to information). In biology: molecules have structure, molecular structure determines identity, molecules have kinds, and molecules relate to each other structurally. These are the E+I+T primitives.

Physical primitives (require agents in a universe): transformation (information changes over time), persistence (information is remembered), locality (information occupies place), authority (information has ownership). In biology: chemistry transforms molecules, cells persist molecular state, membranes create locality, and immune systems enforce authority. These are the M+X+P primitives.

The entity system made these constraints explicit as primitives. Biology evolved them as mechanisms. Physics defines them as laws. The structural vocabulary is shared because the constraints are shared.

5.3. Convergence Without Coordination

A specific shared property deserves emphasis. In both systems, convergence does not require a coordinator. It requires three conditions:

1. Shared typed data (genome / entity types): the same structural description available to all evaluators
2. Deterministic evaluation (ribosome / content-addressed handlers): same input produces same output
3. Content-addressed identity (genetic sequence / content hash): same content is recognizably the same regardless of where or when it was produced

Two cells reading the same gene produce the same protein. Two peers evaluating the same typed expression produce the same content hash. The convergence is structural, not coordinated. This differs from distributed computing models like MapReduce (centrally coordinated), actor models (message-passing coordination), or consensus protocols (voting). It is closer to crystallization — independent units arriving at the same structure because the structural constraints leave no alternative.

5.4. The Prediction

If the correspondence is structural rather than accidental, a prediction follows: any sufficiently complex information system operating under physical constraints will develop these structures. Not because it copies biology, not because it copies the entity system, but because the constraints are the same. Content-addressing, typed data, named state, evaluator-mediated transformation, bounded locality, and authorization are not design choices. They are what information processing looks like in a universe with time, space, finite energy, and multiple agents.

6. The Substrate Question

6.1. What Varies, What Does Not

Biology and the entity system implement the same information-processing architecture on different physical substrates:

What varies is the physical encoding and the energy source. What does not vary is the information structure: typed data with intrinsic identity, organized in named state, transformed by evaluators through state crossings, bounded by locality, and governed by authority.

This invariance has a formal analog. For any two valid materializations $M_1$ and $M_2$ of the entity calculus, the translation cost between them is bounded by a constant — analogous to Kolmogorov’s invariance theorem for universal machines. The specific hash algorithm, wire encoding, and signature scheme are materialization choices. The structural properties (self-description, convergence, versioning) follow from the information structure regardless of materialization.

6.2. Wire Format Stability as Substrate Conservation

The entity system’s wire format has been stable throughout the protocol’s evolution. The codon table has been stable across all known life for approximately 3.8 billion years. Both are conserved for the same structural reason: changing the substrate-level encoding breaks everything that depends on it.

The entity system’s format code byte selects the encoding and hash algorithm rather than hard-wiring one: 0x00 is the SHA-256 baseline, 0x01 (SHA-384) is already validated, and further codes remain available. The byte lets multiple encodings coexist — analogous to the minor codon table variations found in mitochondria, which are endosymbiotic remnants carrying a slightly divergent encoding within the same cell.

6.3. The Conservation Gradient

Self-modification is possible in both systems, but a conservation gradient makes deeper layers progressively harder to change:

The gradient has the same shape in both domains because it arises from the same cause: dependency depth. The deeper the layer, the more that depends on it, the higher the cost of change. CRISPR operates at layers 2–3 (editing genes and regulatory elements), not layer 4 (the genetic code itself). Entity system self-modification operates at layers 1–2 (handlers and extensions), not layers 3–4 (bootstrap types and wire format). Full native access to the encoding exists structurally in both systems — you CAN modify bootstrap types, you CAN edit ribosomal genes — but practical constraints make deep modification effectively impossible without rebuilding from scratch.

6.4. The Genome as Minimal Representation

DNA is not a backup of the organism. It is a minimal representation that can reconstruct the organism. The human genome is approximately 750 megabytes — five orders of magnitude smaller than the organism it produces (~37 trillion cells). The compression ratio is extreme.

The computational genome is the same structure: not a backup of the running system but a minimal representation sufficient for reconstruction. Core types, handler definitions, seed data, evaluator description. Ship the genome to a new substrate, bootstrap, reconstruct.

The lifecycle is shared:

Genome (minimal representation)
  -> Bootstrap evaluator (physics)
    -> Running peer (full state, accumulating)
      -> Storage pressure (physical limits)
        -> Compile to genome (compression)
          -> Transfer to new substrate
            -> Bootstrap again

Biology: DNA $\to$ ribosome $\to$ organism $\to$ resource pressure $\to$ produce gametes $\to$ transfer $\to$ bootstrap again (development).

This lifecycle is not a feature of the entity system. It is a structural consequence of information processing under finite storage constraints. Any system that accumulates state, operates under finite storage, and needs to persist beyond its current substrate will evolve this lifecycle. Biology did. Computing will.

7. Related Work

Von Neumann’s self-reproducing automata. Von Neumann (Neumann 1966) established the theoretical framework for self-reproducing machines: a constructor plus a description, where the description plays a dual role (interpreted by the constructor and copied for the offspring). The entity system realizes this model concretely, with the tree as description and the evaluator as constructor. Von Neumann’s analysis predicted the dual-role requirement; molecular biology confirmed it; the entity system implements it digitally.

Tierra and Avida. Ray’s Tierra (Ray 1991) demonstrated self-reproducing digital organisms in a shared memory space, producing parasitism, symbiosis, and arms races through competition for CPU cycles. Ofria and Wilke’s Avida (Ofria and Wilke 2004) extended this to a platform for studying digital evolution with environment-dependent fitness landscapes. Both demonstrate that self-reproduction and selection are achievable in digital substrates. The entity system differs structurally: Tierra and Avida organisms are machine instructions competing in a fixed environment, while the entity genome is typed, self-describing data that can be verified, transferred, and composed across substrates. The entity genome is portable; Tierra organisms are not.

Autocatalytic sets. Kauffman (Kauffman 1993) proposed that life arose through autocatalytic sets — collections of molecules where each molecule’s formation is catalyzed by some other molecule in the set. The entity system’s bootstrap cascade has autocatalytic structure: the evaluator processes type definitions, which define the evaluator’s own types, which enable further type processing. Whether the formal properties of autocatalytic sets (closure, self-maintenance, RAF theory) apply to the entity bootstrap is an open question for future work.

The central dogma and molecular biology. Crick (Crick 1970) described the directional flow of genetic information. The structural correspondences we identify (evaluator/ribosome, emit/gene expression, tree/genome) are grounded in standard molecular biology. Our biological claims are at textbook level. Deeper engagement with molecular biology literature — ribosome crystallography, codon table evolution, the RNA world hypothesis, Eigen’s hypercycle — would strengthen specific correspondences but does not affect the structural argument.

Self-hosting compilers and bootstrapping. The GCC bootstrap (GCC compiling GCC), the Mes project (bootstrapping C from Scheme), and the stage0 project (bootstrapping from hex) demonstrate that self-hosting is achievable and that the minimal bootstrap can be small. The entity system’s bootstrap evaluator (~400–500 lines of C, a design estimate) is at the extreme small end of this spectrum, which follows from the structured data doing more of the work.

Reflective towers and metacircular evaluators. Smith’s 3-LISP (Smith 1984) and Smalltalk’s metaclass hierarchy demonstrate computational self-description through reflective towers where each level interprets the one below. The entity system’s self-description is structurally different: it closes at a finite fixed point (system/type is system/type) rather than requiring an infinite tower. Content-addressed identity gives the self-description a verifiable hash — something reflective towers lack.

Content-addressed computation. Git (Torvalds 2005), IPFS (Benet 2014), Nix (Dolstra et al. 2004), and Unison (Chiusano and Bjarnason 2019) provide content-addressed storage, distribution, builds, and code respectively. None achieves all three genome properties (self-description, self-replication, self-maintenance) simultaneously from a unified mechanism. Git has self-maintenance (hash integrity, version history) but not self-description (types are hardcoded blobs). Nix has reproducible builds but not self-description. The entity system achieves all three from content-addressed typed data in a named tree.

Limitations of related work coverage. This paper draws biological parallels from structural analysis, not from primary biological research. A thorough engagement with the origins-of-life literature (RNA world hypotheses, protocell research), the convergent evolution literature (formal definitions, comparative methodology), and the artificial life literature beyond Tierra and Avida would strengthen the paper’s claims. We note this as a gap for future work.

8. Discussion

8.1. Structural Correspondence vs. Metaphor

The central methodological challenge: how to distinguish a structural correspondence from a metaphor. Metaphors are useful but unfalsifiable — calling DNA a “blueprint” does not predict anything about DNA that the metaphor itself constrains. Structural correspondences make predictions.

Our criterion: if the biology-entity correspondence is structural, then mechanisms discovered in one domain should have functional analogs in the other, and strategies that work in one should be implementable in the other — not as simulations but as native structural patterns.

Candidate predictions:

• Biological horizontal gene transfer (direct exchange of genetic material between organisms) should map to entity sync (direct exchange of tree state between peers). It does.
• Biological cell differentiation (same genome, different expression based on position and signals) should map to peer differentiation (same types, different handler configuration based on context). It does.
• Biological speciation (divergence until exchange no longer produces viable offspring) should map to protocol divergence (type incompatibility until sync no longer produces consistent state). The structural parallel holds.
• Biological communication through handler outputs (proteins, hormones, not DNA) should map to peer communication through EXECUTE messages, not raw tree state. It does.

These are concrete, testable mappings.

8.2. The Pre-Genetic-Code Era

Computing in 2026 is structurally analogous to the pre-LUCA (Last Universal Common Ancestor) era of life: multiple competing information encodings (HTTP, SQL, gRPC, Git, Protobuf, JSON), no universal encoding for typed content-addressed data, and enormous integration overhead (CI/CD, service meshes, REST APIs, webhooks). Every system reimplements identity, types, dispatch, and state. This is structurally like every pre-LUCA replicator having its own encoding. (For the biological side of the same structural pattern — the progressive hardening of pre-existing roles through the R0-to-R2 transition, the genetic code’s crystallization, and recent LUCA reconstruction — see Abiogenesis as Progressive Hardening.)

If a universal encoding stabilizes (the entity system’s core protocol or something isomorphic), the biology parallel predicts what follows: the encoding becomes invisible infrastructure that nobody thinks about (like the codon table), and the handler layer explodes with diversity. Same core protocol, infinite variation — like all life sharing DNA but producing bacteria to blue whales. The tree of types becomes the tree of structured knowledge, analogous to the phylogenetic tree of life.

8.3. Three Stages of Self-Modification

A progression through increasing awareness of the system’s own structure, observed in both domains:

Stage 1 — Blind copy. Pure replication with occasional random mutation. No awareness of structure. Biology: binary fission, budding. Entity system: peer replication (blind state copy). Novelty: random only. Slow exploration.

Stage 2 — Structural recombination. Two sources merge, producing novel combinations. Selection filters results. Still no awareness of structure, but the mechanism explores combinatorial space efficiently. Biology: meiosis, crossover, mate selection ($2^N$ possible combinations from N genes across two parents). Entity system: sync + merge (two peers with divergent trees merge, producing combinations neither had). Sexual reproduction is the intermediate stage that matters most: it solves the combinatorial exploration problem without requiring any understanding of structure.

Stage 3 — Intentional modification. The system understands its own structure and makes directed changes. Biology: CRISPR, synthetic biology (humans read DNA, understand gene function, edit intentionally). Entity system: self-modification through the native interface (read system/type/*, understand structure, modify types/handlers, verify through type checking). The entity system achieves this at the speed of its own evaluation. Biology achieves it through an indirect path requiring laboratory equipment.

The entity system has all three stages available simultaneously. Biology took 3.8 billion years to progress through them. This is not because the entity system is more advanced — it is because the entity system was designed by systems already at Stage 3 (human cognition). Biology had to bootstrap from Stage 0 (no replication at all) through chemistry.

8.4. Connections to Other Papers

This paper’s analysis connects to the companion series:

• The Entity System: the build-up sequence and six primitives that this paper maps to biology
• The Entity Church Architecture: fixed evaluators on expressive data — the pattern shared by ribosome and entity evaluator; computation-as-structure vs. computation-as-activity in biological terms
• The Entity Machine Boundary: the bootstrap evaluator specification — the entity system’s “ribosome” and the machine boundary where information meets physics
• Convergent Evolution: convergent evolution of existing software systems toward these primitives — the landscape evidence for shared constraints
• Information as Substrate: the philosophical implications of information preceding computation, the two-layer primitive structure, and the abiogenesis question as a limit of self-reference
• A Structural Methodology for Information System Domains: the structural methodology that organizes the biology parallel as a typed cross-domain edge bundle (developed in this paper’s Appendix A)
• Abiogenesis as Progressive Hardening: the methodology applied to the abiogenesis problem in detail — the R0-to-R2 transition decomposed into eight sub-levels with explicit molecular configurations, dependencies, and phase transitions

8.5. Limitations

Several limitations should be noted:

• No primary biology literature. Biological claims are drawn from structural analysis, not from molecular biology research. The parallels are at textbook level. Expert review from molecular biologists would strengthen or correct specific claims.
• No entity-native self-replication yet. The computational genome is constructible in principle. The current implementation uses bridge-based replication (Git + Nix). Entity-native self-compilation (steps 2–5 of the compilation gradient) is unimplemented.
• Formal methodology gap. The “structural not metaphorical” claim lacks a formal methodology for distinguishing structural isomorphism from analogy. We offer testable predictions as a substitute, but a formal framework would be stronger.
• No production-scale validation. The genome properties have been analyzed structurally but not tested at ecosystem scale.
• 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. The methodology this enables is described in The Entity Core Protocol.

9. Conclusion

The computational genome is constructible from content-addressed typed data. The construction requires a small set of bootstrap types seeding the type system, a named tree, and a bootstrap evaluator estimated at approximately 400–500 lines of C. It satisfies three properties — self-description, self-replication, and self-maintenance — that arise from a single mechanism rather than from three separate mechanisms layered together.

The structural correspondence with biological information systems is specific and detailed: the evaluator maps to the ribosome, the emit pathway maps to gene expression, the tree maps to the genome, the bootstrap types map to the genetic code, and the abiogenesis problem is shared. These parallels were not designed. They emerged from engineering reduction and are explained by shared information-theoretic constraints: any information system operating under physical constraints (time, space, finite energy, multiple agents) must solve the same problems and arrives at structurally similar solutions.

The biology parallel confirms the entity system’s structure; it was not the source of it. The entity system was found by reducing a working protocol until nothing more could be removed. That the reduced form mirrors molecular biology’s information architecture is evidence that the reduction found something about the structure of information processing itself, not merely a good engineering design.

Open question. Does the structural correspondence have a definite limit? Identifying a biological information-processing property with no entity system analog, or an entity system property that biology could not develop, would sharpen the boundary. Alternatively, a different primitive set that achieves the same genome properties with fewer components would challenge the irreducibility claim.

Future work. Entity-native self-compilation (closing the self-hosting loop). Formal comparison to autocatalytic set theory. Primary biology literature engagement for each structural correspondence. Ecosystem-scale observation of protocol divergence and convergence dynamics. Formal methodology for distinguishing structural correspondence from metaphor; an initial version of that methodology is applied in Appendix A.

10. Appendix A: Cross-Domain Structural Mapping — Methodology Applied

This appendix recasts the body’s biology-computing parallels using the structural analysis methodology developed in A Structural Methodology for Information System Domains. The body has been asserting that the parallels are “structural, not metaphorical,” and the Limitations section noted the absence of a formal methodology for that distinction. The appendix supplies an initial version of that methodology: it exhibits the parallels as a complete role-identification edge bundle between two independently extracted primitive sets, in a documented cross- domain graph with a closed typology of edge kinds.

10.1. The two domains

The methodology analyzes biology and computing as two distinct domains. Each domain’s primitive set is extracted independently through the 12-step procedure of A Structural Methodology for Information System Domains; the alignment between the resulting sets is itself the structural finding.

Computing substrate (The Entity System) has six primitives: Entity (E), Identity (I), Tree (T), Emit (M), Execution (X), Peer (P).

Biological substrate (cell-level, A Structural Methodology for Information System Domains’s biology arrangement) has six primitives at the same resolution. The canonical names are given in A Structural Methodology for Information System Domains; for this appendix we refer to them by functional role: typed substrate unit, content-derived identity, named persistent organization, atomic state crossing, dispatch/catalysis, and bounded locality with capabilities.

The two primitive sets were extracted from independent corpora. The 1:1 alignment of cardinality and structural role is not a design choice in either analysis; it is the body’s “structural correspondence” claim visible at the primitive level.

10.2. The cross-domain edge bundle

Layer 2 of the methodology catalogs typed edges between domains (see A Structural Methodology for Information System Domains). The body’s parallels all fall under a single edge type: role identification — the claim that two primitives in different domains play the same structural role within their respective substrate.

The complete bundle:

Each row is one role-identification edge in the cross-domain graph. The structural-correspondence claim of the body is, in methodology terms, the claim that all six role-identification edges land simultaneously — a complete primitive-set bundle.

10.3. What kind of cross-domain edge is not being claimed

The methodology distinguishes several edge types beyond role identification; clarifying which are not in play is as important as naming the one that is.

• Realization is not claimed in either direction. Computing is not implemented in biological substrate, and biology is not implemented in computing substrate. Realization edges in the methodology’s chain go physics $\to$ chemistry $\to$ biology and (separately) physics $\to$ chemistry $\to$ digital. Biology and entity-system computing are parallel substrate-style endpoints of a fork, not nested.
• Decomposition is not claimed. The two substrates are not finer and coarser views of one substrate.
• Feedback is not claimed. The two substrates do not exert mutual selection pressure in the analysis.
• Coupling is not claimed at the substrate level. (Coupling between a computing system and a cognitive substrate is the subject of A Structural Methodology for Information System Domains’s cross-arrangement coupling discussion; that lives at a different layer.)

The claim is specifically: a complete role-identification edge bundle. This is the strongest cross-domain edge bundle the methodology recognizes short of realization.

10.4. Pair- and triad-level alignment

Role identification at primitives carries to the pair and triad level. Three of the entity system’s structural triangles (see The Entity System) have aligned biological structures:

• EIT triangle (self-description) $\leftrightarrow$ the genome closure. The entity system’s system/type is of type system/type. Biologically, the genome contains the specification of the machinery that interprets the genome — DNA encodes the polymerases that transcribe DNA, the ribosomal proteins that translate mRNA, the regulatory factors that control gene expression. Both are fixed-point structures at the information-cluster triangle.
• TMX triangle (reactive dispatch) $\leftrightarrow$ gene-expression cascade. Transcription cascades, signaling pathways, and dependency- driven regulation are the biological analog of the compute extension’s reactive cascade. Both close the loop evaluator produces emission; emission triggers evaluator; dispatch routes the trigger.
• IXP triangle (cryptographic capability) $\leftrightarrow$ receptor- ligand specificity at the cell membrane. Receptor binding is capability checking: molecular shape acts as a content-derived capability token; binding is verification at the cell boundary; the resulting cytoplasmic processing is the dispatch. This is the most developed pair-triad alignment in the bundle.

The ITM (versioning) and TXP (distributed dispatch) triangles have weaker biological alignments: ITM partially through DNA replication and lineage, TXP through tissue-level cell-cell communication. They are not absent biologically, but the alignment is less crisp than the three above.

10.5. What the appendix establishes

It exhibits the body’s structural-correspondence claim as a documented complete role-identification edge bundle in the cross-domain methodology graph. This is a structural relationship in a formal sense: the relationship is one of a closed enumerable set of edge types, applied between two independently extracted primitive sets, and the bundle’s completeness is itself a structural property (incomplete bundles are weaker findings).

This addresses, in part, the Limitations section’s “formal methodology gap.” It does not eliminate the gap. Whether a complete role-identification edge bundle constitutes structural isomorphism or a weaker form of structural correspondence is a question the methodology cannot fully resolve from inside itself; resolving it requires either an external discriminator (e.g., a predicted property that distinguishes the two substrates) or further methodology development.

10.6. What the appendix does not establish

The bundle does not predict specific properties of either domain beyond what the body already asserts. It documents the parallels as a typed edge bundle rather than as a collection of metaphors, but the testable predictions in the body remain the falsification path. The appendix does not address the chemistry-biology bridge (the abiogenesis problem), which is treated separately in Abiogenesis as Progressive Hardening using the methodology’s bridge-domain framework.

The Entity Machine Boundary: From Content-Addressed Computation to Physical Hardware

1. Introduction

The companion paper on computation (see The Entity Church Architecture) establishes that the entity system has a specific computational character: fixed evaluators processing typed data through emit, with universality arising from data expressiveness rather than evaluator complexity. This paper asks the next question: what does that evaluator need from physical hardware, and what does the path from entity computation to machine execution look like?

Most systems leave this boundary implicit. Programs are written in high-level languages, compiled to machine code, and the relationship between the computational model and the hardware is managed by compilers and runtimes that are not part of the system’s own description. The Java Virtual Machine abstracts the machine behind bytecode. WebAssembly defines a portable instruction set. The Erlang BEAM provides a concurrent runtime. In each case, the boundary between the computational model and the physical hardware is a fixed, opaque layer — the programmer cannot inspect it, the system cannot describe it, and the compilation process is external to the data model.

The entity system makes the boundary explicit because its computational model — typed data, content-addressed, organized in a tree, mutated through emit, processed by evaluators — is structurally different from the von Neumann model that conventional hardware implements. The entity system stores immutable content by hash, dispatches by type and path, and verifies capability tokens per operation. Von Neumann hardware operates on mutable memory at addressed locations through a sequential instruction stream. These are different computational assumptions, and making the boundary between them explicit is the first step toward understanding what each requires from the other.

This paper describes the compilation gradient (four stages from entity compute graph to machine code), five machine boundary profiles (from pure entity computation to entity-native silicon), the bootstrap evaluator (the minimal mechanism that boots the system), and an analysis of what entity-native hardware would look like. It also examines how machine architecture itself becomes an entity domain — instructions, registers, and ABIs described as typed entities in the tree — closing the self-description loop.

In the transferability framework of The Entity System, the machine boundary is the interface between Class N (platform-native code — bootstrap evaluator, primitive I/O, architecture-specific compiled handlers) and Class T (transferable content — entity-native computation expressions that any peer with the same evaluator specification can execute). The compilation gradient is the path that carries Class T data through progressively more Class-N-specific forms. Stage 1 is pure Class T (the entity compute graph is data). Stage 4 is pure Class N (machine code for a specific architecture). The intermediate stages trade Class T inspectability for Class N execution efficiency.

The machine boundary is where The Entity Church Architecture’s “computation-as-structure” becomes “computation-as-activity” — where inspectable, self-describing information in the tree becomes opaque physical execution on hardware. The stages of the gradient trace this transition. The fixed points — operations that cannot be compiled away at any stage — define the irreducible interface between entity computation and the physical substrate. The bootstrap evaluator is the minimum Class N footprint: ~400–500 lines of platform-specific code per implementation. Everything else in the entity system can in principle be Class T, transferable between peers.

Companion papers. The six primitives and their combinatorial analysis are in The Entity System. The computational model is in The Entity Church Architecture. The biology parallel — the ribosome as nature’s bootstrap evaluator — is in The Universal Computational Genome. Application development patterns using the compilation gradient are in Application Architecture. The security architecture, including hardware capability verification, is in Entity System Security Architecture.

2. The Compilation Gradient

Entity computation exists as typed data in the tree. Machine execution exists as electrical signals in silicon. Between them lies a gradient of four stages, each trading inspectability and portability for execution efficiency.

2.1. Stage 1: Entity Compute Graph

Compute expressions are entities in the tree — content-addressed, typed, fully inspectable. A compute subgraph at this stage is pure information. You can read it, verify it, compare it by hash, transform it, version it, transfer it between peers. It has all the architectural properties described in The Entity Church Architecture: self-description, versioning, addressability, persistence, and authorization.

The compute extension defines a set of core expression types — compute/literal (constant values), the compute/lookup family (resolve a name in scope, in the tree, or by content hash), compute/apply (function application), compute/if (conditional), compute/let (binding), and compute/lambda (abstraction) — alongside inline types for common operations: arithmetic, comparison, logic, field access (compute/field), record construction (compute/construct), and array operations. Together these form a Turing-complete entity-native compute language. At this stage, the program IS data — indistinguishable from any other entity in the tree, subject to the same content addressing, type validation, and capability scoping.

Every expression entity has a content hash. Two independently constructed but structurally identical compute graphs produce the same hash. This is not a cache optimization — it is a consequence of content addressing. The identity of the computation is intrinsic to its structure.

2.2. Stage 2: Partial Compilation

Pure subgraphs — those using only hash references, with no dependency on mutable tree state — can be evaluated at compile time. Their results exist as structure (computation-as-structure from The Entity Church Architecture); the compiler materializes them. Collapse replaces a subgraph of expression entities with a single result entity. The semantics are identical — the result IS what the expression produces.

Content addressing makes this safe and aggressive. The cache key for any pure subexpression is its content hash: expression_hash $\to$ result_hash. If the expression’s input hashes have not changed, the result is cached. This is memoization as a structural consequence of content addressing, not an optimization strategy that must be proven correct.

What remains after partial compilation is the impure skeleton: expression subgraphs that reference tree paths (mutable state) or depend on runtime values. These define the runtime’s calling convention — the interface between compiled code and the entity system:

• ctx.tree.get(path) — read current tree binding
• ctx.tree.put(path, entity) — write through emit pathway
• ctx.dispatch(path, operation, params) — handler invocation
• ctx.check_permission(capability, scope) — authorization check

These four calls are the impure boundary. Everything between them can, in principle, be compiled to native code.

2.3. Stage 3: Compiled Handler

Entity compute expressions are compiled to native functions. The handler receives typed parameters, executes native code, and returns typed results through the emit pathway. The interior of the handler is now opaque — no longer inspectable entity data. This is where computation-as-structure becomes computation-as-activity.

The handler still crosses the entity boundary on both sides: typed input, typed output, capability verified, emit pathway available. What is lost is inspectability and portability. The compiled handler is architecture-specific — an x86_64 compiled handler does not run on ARM64. But its source (Stage 1 entities in the tree) remains, and recompilation for a different target is a matter of invoking the compiler with different machine type definitions.

2.4. Stage 4: Machine Code

Native instructions on physical hardware. Architecture-specific, opaque to the entity model. The entity system’s typed data model has been fully translated to register operations, memory access patterns, and I/O calls. At this stage, the program is invisible to the entity system — it is an artifact of a specific physical substrate.

2.5. Properties Across the Gradient

The gradient trades inspectability and portability for performance. But not all properties are lost:

Determinism and capability-scoping are preserved at all stages. The entity system’s security model works regardless of compilation level — capabilities are checked at the impure boundary, which exists at every stage. The gradient trades visibility for speed, but the security invariants hold throughout.

The transferability transition happens between Stages 2 and 3. At Stage 2 the expression skeleton is still entity data; two peers with the same evaluator specification can exchange the skeleton and execute identically. At Stage 3 the handler is compiled native code specific to an architecture; it cannot be transferred to a peer with different native architecture without recompilation. This is the boundary between Class T and Class N: each peer carries its own Stage-3 compiled handlers, produced by compiling received Stage-1/Stage-2 entity data.

2.6. What Cannot Be Optimized Away

At every stage, certain operations remain irreducible — they define the interface between entity computation and the physical substrate:

1. Tree writes: state crossings through the emit pathway — store, bind, event
2. Cross-peer exchange: serialization to wire format, network I/O, envelope construction and verification
3. Capability checks: authorization verification at dispatch boundaries
4. Handler transitions: crossing from entity-native to handler-internal and back

These four categories are the machine boundary’s fixed points. Any observable effect in the entity system falls into one of them. No compilation stage can eliminate them because they are where the entity model touches the physical world — where information crosses from one state to another, from one peer to another, or from one authority domain to another.

2.7. The Purity Boundary and Cross-Compilation

The purity boundary from The Entity Church Architecture maps directly to the compilation boundary. Hash references are pure — their referents are immutable, and expressions using only hash references can be collapsed at compile time. Path references are impure — their referents depend on mutable tree state, and expressions using them must remain as runtime evaluation.

This connects to the cross-compilation partition described in The Entity Church Architecture. Category A features (data types, functions, closures, generics) map to entity compute expressions and survive the full gradient. Category B features (lifetimes, ownership, borrow checking, GC internals) erase at the content-addressed boundary — they are substrate management that entity computation provides structurally. Category C features (SIMD, inline assembly, memory-mapped I/O) require machine access and live inside native handlers at Stage 3 or below, opaque to the entity model. The compilation gradient is where Category C meets the physical world. The formal dimensional analysis of these categories is developed in Dimensional Completeness.

3. The Bootstrap Evaluator

The bootstrap evaluator is the minimal mechanism that can read a conforming entity tree and begin evaluation. It is the answer to: what is the smallest fixed evaluator that boots the system?

3.1. Design Specification

The bootstrap evaluator is designed at approximately 400–500 lines of C.¹ This estimate derives from component analysis: the evaluation algorithm for the core expression types accounts for roughly 130 lines of pseudocode (based on the compute extension specification), CBOR decoding adds approximately 100 lines, SHA-256 computation approximately 80 lines, content store management approximately 40 lines, location index approximately 30 lines, and I/O bootstrap approximately 20 lines.

The bootstrap evaluator performs eight core operations:

1. Read entity tree: navigate the path $\to$ hash namespace
2. Resolve hashes: look up entities by content hash in the content store
3. Dispatch on type: route evaluation based on the entity’s type field
4. Evaluate compute expressions: reduce the core expression types — literal, the lookup family, apply, if, let, lambda — plus the inline operation types (arithmetic, comparison, logic, field access, construction, array operations)
5. Manage scope: maintain variable bindings during evaluation (lexical scoping for lambda/let)
6. Read/write tree: access and modify tree bindings through the emit pathway
7. Compute hashes: SHA-256 over ECF-encoded content to derive content identity
8. Encode/decode CBOR: parse and produce Entity Canonical Form for serialization

These eight operations decompose into seven irreducible machine-level requirements — the minimal hardware interface:

1. Byte manipulation: read, write, compare byte sequences
2. SHA-256: cryptographic hash computation
3. CBOR encode/decode: parse and produce deterministic binary encoding
4. String comparison: match type names and path segments
5. Integer arithmetic: basic operations for expression evaluation
6. Memory allocation: dynamic allocation for entities, scopes, and intermediate results
7. I/O: read from storage (to load the initial tree), write results

These seven are what the bootstrap evaluator needs from the physical substrate. Everything above this — type dispatch, expression reduction, scope management, content addressing — is entity-native logic built from these machine primitives.

What the bootstrap evaluator does NOT need is notable: no networking, no full protocol implementation, no process management, no domain-specific handlers, no capability verification (the bootstrap runs in a trusted, single-peer context). It needs only enough to read a conforming tree and evaluate the compute expressions it finds there. Everything else can be bootstrapped from within the entity system once the evaluator is running.

The protocol specification requires three handlers to exist from initialization: system/tree (get, put), system/handler (register, unregister), and system/protocol/connect (hello, authenticate); the type handler (system/type validate) is bootstrapped as well when the implementation supports type validation. These are what “booting from a conforming tree” means at the protocol level — the bootstrap evaluator provides their functionality directly, and additional handlers (the capability handler among them) register through the standard mechanism once the system is running.

3.2. The Opcode Question

The opcode set is a design question, not a settled number. An entity-native instruction set would draw its opcodes from the compute extension’s expression-constructing types — the types a programmer writes: literal, the lookup family, apply, if, let, lambda, and the inline operations (arithmetic, comparison, logic, field access, construction, array indexing). Distinct from these are the extension’s operational types — compute/closure (a lambda with captured scope), compute/scope (evaluation context), compute/result (evaluation output), and compute/error (evaluation failure) — which the evaluator produces during reduction rather than reading from source.

The distinction matters: the expression-constructing types are what the programmer writes and the compiler processes; the operational types are intermediate representations the evaluator manufactures, not source-level constructs. An entity-native instruction set would likely need an opcode per expression-constructing type and microcode or internal operations for the operational ones. The exact size of the expression set depends on the compute extension’s current definition — which is still settling, having grown since this analysis was first drafted — so this paper describes the structure of the mapping rather than committing to a count.

3.3. Connection to the Fixed Evaluator Insight

The companion paper on computation (see The Entity Church Architecture) observes that at any point in time, every evaluator that is actually running is a fixed evaluator, and that universality comes from data expressiveness rather than evaluator complexity. The bootstrap evaluator makes this concrete: it is a specific, minimal, fixed evaluator. Its approximately 400–500 lines of C are the physical mechanism that reads typed structures and reduces them. What makes the system universal is not the evaluator’s complexity but the expressiveness of the typed data it processes — the core expression types and their inline operations form a Turing-complete language.

The computation gradient is the process of producing more efficient fixed evaluators. Stage 3 (compiled handler) is a fixed evaluator specialized for a particular set of entity types. Stage 4 (machine code) is a fixed evaluator specialized for a particular architecture. Each is less general but faster than the one above. The bootstrap evaluator is the most general and slowest — and the only one needed to start.

3.4. The Self-Hosting Loop

Once the bootstrap evaluator runs, the system can compile itself:

1. Bootstrap (compiled externally): an external compiler produces the bootstrap evaluator binary for the target architecture. This is the one-time external dependency — the analog of the ribosome’s prior existence in biology, the persistent minimal evaluator that the abiogenesis-equivalent transition leaves behind (see The Universal Computational Genome).
2. Read tree: the bootstrap evaluator reads the entity tree, which contains the source for an entity-native compiler (itself an entity — typed, content-addressed, at a known path).
3. Compile: the entity-native compiler, running as a handler, compiles its own source (entity compute expressions in the tree) to instruction entities for the target architecture.
4. Assemble: an assembler handler translates instruction entities to executable byte entities.
5. Self-sustaining: the system runs on its own output. The externally compiled bootstrap is no longer needed.

At step 5, the system is self-hosting. It contains its own build instructions, its own compiler, its own evaluator source, and has used them to produce its own executable. The self-hosting loop closes. The parallel to GCC compiling itself is exact: GCC was first compiled with another compiler; now GCC compiles itself. The parallel to biological self-replication is structural: DNA encodes the proteins (including replication machinery) that read DNA. The key requirement in both cases: the description must include knowledge of the substrate. DNA encodes enzymes that manipulate chemistry. Entity trees must contain type definitions that describe machine architectures. Without substrate awareness, the system can describe itself but not reproduce itself.

Hash-based verification replaces test suites for replication correctness. Deterministic compilation means: same source entities + same compiler entities = same output hash. Verification is a hash comparison, not a test suite execution. The self-hosting loop also enables a defense against Thompson’s “trusting trust” attack (Thompson 1984) through diverse double-compilation: compile with Implementation A to produce hash $H_a$, with Implementation B to produce $H_b$, with Implementation C to produce $H_c$. If $H_a = H_b = H_c$, the output is trustworthy — no single implementation could have inserted a backdoor that all three reproduce identically. The entity system has three implementations (Go, Python, Rust) that could serve this role.

3.5. The Cosmopolitan Pattern

A practical deployment concern: the bootstrap evaluator must run on multiple architectures. The cosmopolitan pattern addresses this by packaging per-architecture evaluators with a multi-architecture selector in a single binary:

[Multi-architecture bootstrap selector]     (~200 bytes)
[x86_64 bootstrap evaluator]                (~2KB compiled)
[ARM64 bootstrap evaluator]                 (~2KB compiled)
[RISC-V bootstrap evaluator]               (~2KB compiled)
[Entity tree / content store]               (the actual system)

The selector detects the current architecture and jumps to the appropriate evaluator. The per-architecture evaluators share the same entity-reading logic — tree navigation, hash resolution, type dispatch, expression evaluation — with different machine code for the seven irreducible machine-level operations. A single entity peer binary runs on any supported architecture.

If the 400–500 line design estimate holds, a compiled bootstrap evaluator would be on the order of a few kilobytes per architecture. Everything else is entities: the compiler, the type system, the handlers, the protocol, the extensions — all entity data, architecture-independent, verified by content hash. The architecture-specific surface area would therefore be very small relative to the total system. Whether this holds in practice depends on the actual line count and the degree to which the bootstrap evaluator can share code across architecture targets.

3.6. The Abiogenesis Connection

The bootstrap evaluator is where the entity system meets the question examined in The Universal Computational Genome and decomposed in detail in Abiogenesis as Progressive Hardening: something must run first. The entity tree can contain its own specification, its own compiler, its own evaluator source — but none of this evaluates itself. A physical process (the bootstrap evaluator, running on electricity in silicon) must read the tree and begin reduction.

This is the entity system’s analog of the abiogenesis-equivalent transition — the co-arising of evaluator and data. The bootstrap evaluator is what persists from that transition (the analog of the ribosome), not the transition itself. The single external requirement is: one running evaluator on one architecture. From that seed, the system can build evaluators for other architectures, compile its own tools, and replicate to new hardware. But the first evaluator must come from outside — compiled by an external compiler, running on existing hardware.

In biology, the ribosome does not run by itself — chemistry and thermodynamics drive molecular interactions. In computation, the bootstrap evaluator does not run by itself — electricity and physics drive state transitions. The evaluator is where abstract information meets physical reality. The bootstrap evaluator, the ribosome, and the CPU are all instances of the same structural relationship: a fixed mechanism that reads typed structures and produces new structures, driven by physical forces it does not control.

The abiogenesis-equivalent problem for entity-native hardware (discussed below) shifts but does not disappear: instead of “compile the first evaluator with an external compiler,” it becomes “fabricate the first entity processor with existing semiconductor processes.” The dependency on the external physical substrate is irreducible.

4. Machine Boundary Profiles

Five profiles describe the continuum from pure entity computation to entity-native hardware. Each is independently viable — a valid deployment target with specific tradeoffs between entity-native control and reuse of existing infrastructure. The line counts below are design estimates, not measured implementations, on the same basis as the bootstrap evaluator’s; they indicate relative scale across profiles, not figures to be implemented against.²

4.1. Profile 1: Compute-Only Peer

Lines of machine-specific code: approximately 400–500. Dependencies: memory allocation, hash computation. Use cases: embedded systems, WebAssembly targets, formal analysis, testing.

No I/O. The evaluator and entity tree exist in memory. Compute expressions evaluate within the tree. This is the bootstrap evaluator stripped to its minimum — the pure computational kernel. Useful for environments where the entity system runs as a sandboxed computation engine with no access to the host environment.

4.2. Profile 2: Storage Peer

Lines: approximately 600–700. Dependencies: file or block I/O. Use cases: single-machine entity stores, embedded devices with persistent storage.

Adds tree persistence backed by local storage. The entity tree survives across evaluator restarts. Architecture-independent — the evaluator runs on any platform that provides storage and basic I/O. This is where the bootstrap evaluator naturally operates: it reads entities from storage, evaluates, and writes results back.

4.3. Profile 3: Network Peer (OS-Hosted)

Lines: approximately 800–1000. Dependencies: POSIX syscalls (or equivalent OS interface). Use cases: current entity-core implementations (Go, Python, Rust).

Adds networking and process management via host OS facilities. This is where the three existing implementations operate — handler logic in the host language, entity protocol at the boundary, OS-provided networking and storage. The machine boundary is the host language’s FFI: entity types cross into Go structs, Python objects, or Rust types, and back.

4.4. Profile 4: Hybrid Kernel

Lines: approximately 1500–2000. Dependencies: Linux syscall ABI (or equivalent kernel interface). Use cases: entity-native OS environment, dedicated entity servers.

The entity system runs as a kernel-level service rather than a user-space application. Device drivers are handlers. The file system is the entity tree. Process isolation uses entity capabilities rather than OS-level permissions. This profile corresponds to the DEOS vision described in DEOS — the entity system as operating system.

4.5. Profile 5: Bare Metal / Entity-Native Hardware

Lines: approximately 5000+ (or 0 with entity-native silicon). Dependencies: CPU architecture, essential hardware interfaces. Use cases: dedicated entity hardware, FPGA prototypes, entity-native silicon.

Hardware designed to execute entity computation directly. At the extreme end, entity-native silicon would have zero lines of translation — the hardware’s instruction set IS entity computation. The machine boundary disappears because there is no translation between computational models.

4.6. Each Profile Is a Deployment Target

The profiles are not a progression. Profile 3 (OS-hosted) is not “worse” than Profile 5 (entity-native hardware). They are different tradeoffs:

• Moving left (toward Profile 1): smaller machine boundary, fewer dependencies, more portable, less capable
• Moving right (toward Profile 5): larger machine boundary, more dependencies, less portable, more capable, less translation overhead

The machine boundary is not binary (entity vs. machine) but a spectrum of how much of the machine substrate is absorbed into entity computation. Most deployments will operate at Profile 3 for the foreseeable future, using existing OS infrastructure. Profiles 4 and 5 are longer-term targets that become relevant as the entity system matures and performance characteristics are better understood.

The Distributed Entity Operating System layer model (see DEOS) provides complementary context: host OS $\to$ entity core protocol $\to$ system extensions $\to$ standard library $\to$ application. The machine boundary profiles describe where entity computation begins in this stack. Profile 3 starts at the entity core protocol layer. Profile 4 pushes entity computation into the OS layer. Profile 5 pushes it into the hardware.

5. Entity-Native Hardware Architecture

This section is speculative — no entity-native hardware exists. We analyze what it would look like based on the computational model’s requirements. The analysis is architecturally grounded: the component technologies (CAM, LPM, SHA-256 acceleration, capability hardware) exist individually in production or research hardware. What is novel is their composition into a unified architecture for entity computation.

5.1. Three Memory Regions

The entity computational model naturally separates memory into three regions with different properties:

Content store (gigabytes to terabytes, immutable): hash $\to$ entity. Write-once, read-many. Content-addressable memory (CAM) is the natural hardware primitive — lookup by content rather than by address. Because content is immutable once written, there is no cache coherency problem for the content store. Multiple processors can read from it without coordination. In a workload where the content store constitutes most of total memory (a reasonable assumption for data-heavy applications), coherency traffic would be limited to the location index. The extent of the reduction depends on the content store/index ratio for the actual workload, which varies. This addresses a recognized bottleneck in conventional multi-core systems, where cache coherency protocols (MESI, MOESI) consume significant bus bandwidth.³

Location index (megabytes to gigabytes, mutable): path $\to$ hash. This is the tree’s binding state — the mutable namespace. It requires traditional cache coherency because bindings change via emit. Trie or longest-prefix-match (LPM) structures are the natural hardware — these exist in production network routing ASICs. The location index is small relative to the content store (paths are shorter than content), making coherency manageable.

Evaluation state (kilobytes per core, ephemeral): scope bindings, partial results, evaluation stack. This is working memory for the evaluator — conventional SRAM, local to each processing core, discarded after evaluation completes. No cross-core sharing, no coherency needed.

The three-region separation is not arbitrary — it follows from the entity model’s separation of immutable content (E+I), mutable naming (T+M), and temporal evaluation (X). Each region has different access patterns, different mutability properties, and therefore different optimal hardware implementations.

5.2. Why Content-Addressed Data Is Hardware-Friendly

The conventional “performance overhead” of entity computation — hashing every entity, looking up content by hash, comparing hashes for equality — appears inherent when standing inside the von Neumann paradigm. Hashing costs cycles; associative lookup is slower than addressed access on current hardware. The hypothesis is that these costs are artifacts of the hardware model rather than the computational model.

The parallel to graphics processing is suggestive: before GPUs, data-parallel graphics on CPUs was slow because the hardware was not designed for it. Hardware designed for the workload changed the performance picture. Whether entity computation follows an analogous path remains an open question — the analogy is structural, not a prediction.

On von Neumann hardware, the evaluator interprets entity expressions on top of machine instructions — two levels of interpretation. On entity-native hardware, entity expressions would be the instruction set — one level. Whether this eliminates the interpretation overhead entirely, or introduces different overheads, is what an FPGA prototype would test.

Entity computation has cache locality properties that may be easier to exploit on entity-native hardware than on von Neumann architectures:

• Reference locality: hash references are known before the entity is needed, potentially enabling speculative fetch
• Type locality: entities of the same type are structurally similar, potentially improving prediction
• Cascade locality: dependency chains in reactive evaluation define access patterns ahead of time

The potential advantage over von Neumann’s statistical spatial/temporal heuristics is that the locality is structural — determined by the data model — rather than statistical. Whether this structural locality translates to better hardware performance depends on whether entity-native hardware can exploit it efficiently, which is an empirical question.

5.3. Entity Instruction Pipeline

An entity-native processor would have a six-stage pipeline derived from the evaluator’s operation:

$$\text{FETCH} \to \text{TYPE\_DISPATCH} \to \text{OPERAND\_FETCH} \to \text{EXECUTE} \to \text{RESULT} \to \text{EMIT}$$

This differs from a von Neumann pipeline (fetch, decode, execute, memory, writeback) in two structural ways. First, type dispatch replaces instruction decoding — the processor routes based on entity type rather than opcode byte. The entity type IS the opcode; there is no separate encoding layer. Second, the final stage is emit (atomic state crossing: store, bind, event) rather than memory writeback. The emit stage is where computation produces observable effects in the entity model.

Each expression-constructing type maps to an opcode — the entity type IS the opcode (see “The Opcode Question” above for the distinction between expression-constructing and operational types). The core types map as follows:

5.4. Capability Verification in Hardware

On entity-native hardware, capability verification would be inserted at the TYPE_DISPATCH stage of the pipeline:

• Set membership (bitmap check): potentially single cycle. Is this operation in the capability’s allowed set?
• Pattern matching (LPM/glob): potentially single-digit cycles. Does the target path match the capability’s scope pattern? Uses the same LPM hardware as handler dispatch.
• Path scope check: does the requested path fall within the capability’s resource scope?

With a capability cache (analogous to a TLB for address translation), the common case — a recently verified scope — could have near-zero additional latency. Cache misses would fall through to full verification, which involves cryptographic signature checking (computationally expensive but rare for repeated operations on the same scope). The actual latency profile is an empirical question.

This approach contrasts with conventional hardware security models (x86 ring levels, ARM TrustZone) where security boundaries are coarse-grained and expensive to cross. Entity-native capability verification would be fine-grained (per-operation) and potentially cheap for cached cases. The CHERI capability architecture (Watson et al. 2015) is the closest existing research in this direction — hardware-enforced capabilities with per-pointer bounds — though CHERI operates at the memory access level while entity capabilities operate at the semantic dispatch level.

5.5. Layer-by-Layer Hardware Mapping

Each layer of the entity system maps to specific hardware components. The “benefit” column describes the hypothesized advantage on entity-native hardware relative to a software implementation on von Neumann hardware — none of these are measured results:

The pattern is consistent with hardware/software co-design generally: regular, frequent, well-defined operations move to hardware; irregular, rare, policy-driven operations stay in software. What stays in entity-native software: handler logic (arbitrary computation), GC policy (heuristic), deep delegation chains (rare), revocation propagation (complex), tree merge conflict resolution (policy-dependent), complex type validation (open-ended).

5.6. Performance Inversion Hypothesis

The performance inversion hypothesis is that certain operations expensive on von Neumann hardware would become cheap on entity-native hardware, and vice versa. This is architectural reasoning, not measured performance.

Potentially entity-native wins: content verification (hash comparison vs. full re-hash), multi-core sharing (immutable content store requires no coherency traffic), per-operation authorization (pipelined rather than context switch), deduplication (CAM lookup vs. explicit comparison), dependency tracking (hardware-assisted rather than software-maintained), speculative prefetching (hash references enable structurally precise prefetch rather than statistical prediction).

Potentially von Neumann still wins: sequential arithmetic on large arrays (conventional ALUs optimized for this), large contiguous memory scans (DRAM burst mode), execution of legacy code (by definition), workloads that are purely sequential with no content-addressing benefit.

The hypothesis is not that entity-native hardware would be universally faster, but that for workloads matching the entity computational model — content-addressed data, typed dispatch, capability-scoped operations, reactive cascades — translation overhead on von Neumann hardware may be the dominant cost, and removing that translation could recover significant performance. Whether this hypothesis holds is what implementation and benchmarking would determine.

5.7. Feasibility Path

An incremental approach to entity-native hardware:

1. FPGA prototype: implement the six-stage pipeline and three memory regions on an FPGA. Measure actual performance characteristics. Validate the architectural assumptions.
2. Accelerator card: entity-native co-processor (like a GPU for entity computation) that handles content-store operations, hash computation, and capability verification while the host CPU runs handler logic.
3. System-on-chip: full entity-native SoC with content-store memory, location-index trie, and entity instruction cores.
4. Entity-native system: standalone hardware running entity computation as its native model.

Each step is independently useful and provides validation data for the next.

6. Machine Architecture as Entity Domain

At Profile 4 and above, the machine architecture itself is described as entity types in the tree. This is not a convenience — it is the completion condition for self-descriptive completeness.

6.1. Architecture as Type Definitions

A machine architecture is a system with data types (registers, instructions, memory regions), operations (instruction semantics), and constraints (alignment, encoding rules). Each of these maps to entity infrastructure:

machine/x86_64/register    -> {name: "rax", width: 64, class: "general"}
machine/x86_64/instruction -> {opcode: "mov", operands: [...]}
machine/x86_64/abi/sysv    -> {arg_registers: ["rdi","rsi","rdx",...], ...}
machine/x86_64/memory-model -> {ordering: "tso", page_size: 4096, ...}

These architecture descriptions are entities — content-addressed, typed, capability-scoped, transferable, inspectable. Same architecture definition produces the same hash, enabling automatic deduplication. The type system validates instruction entities against architecture constraints. Compilation to a target architecture can be authorized via capabilities. Architecture definitions travel between peers in envelopes.

6.2. Multi-Architecture Compilation

The architecture type tree provides a systematic structure for multi-target compilation:

system/types/machine/x86_64/  (register, instruction, operand, abi/sysv, abi/win64)
system/types/machine/arm64/   (register, instruction, operand, abi/aapcs64)
system/types/machine/riscv64/ (register, instruction, operand, abi/lp64d)

The compiler knows its target because the target’s instruction set is typed data it can read. Multi-architecture compilation is not a separate compiler feature — it is a consequence of the target being data. Same entity compute graph, different machine type definitions, different instruction entity output. The compilation logic is the same; only the type definitions change.

An assembler is a handler that reads instruction entities and produces byte entities. A disassembler reads byte entities and produces instruction entities. Both are ordinary domain handlers operating on typed data. There is no special “assembly language” — machine instructions are entities like any other.

6.3. The Entity ABI

Traditional operating system concepts map to entity equivalents:

This mapping is not metaphorical — it is operational. The entity ABI replaces the traditional OS ABI. A “process” is a peer. A “file” is an entity at a tree path. An “open” is a tree get. A “write” is an emit. The entity system does not simulate these concepts — it provides them through the six primitives in a unified, typed, content-addressed framework.

In entity computation, source is compute expression entities in the tree. The compiler is a handler (an entity). The binary is byte entities in the tree. The running process is the evaluator interpreting entities. All four — source, compiler, binary, process — are entities. Same substance. Same security model. Same inspection tools. Same lifecycle.

6.4. The C/Unix Co-Evolution Parallel

C and Unix co-evolved: C assumes addressed mutable memory, and the von Neumann architecture provides it. C’s memory model (pointers, stack, heap) maps directly to hardware capabilities. The language and the hardware reinforce each other.

Entity computation and entity-native hardware would co-evolve in the same way: entity computation assumes content-addressed immutable data with capability-scoped dispatch, and entity-native hardware would provide it. The entity compute language’s expression types map to pipeline opcodes. The tree’s path $\to$ hash structure maps to LPM hardware. Content addressing maps to CAM. The computational model and the hardware model reinforce each other.

This parallel suggests that the performance characteristics of entity computation on von Neumann hardware may not be representative of the model’s natural performance — just as performance of data-parallel graphics on CPUs was not representative of what became possible with dedicated hardware. Whether the parallel holds for entity computation is an open question; it motivates the FPGA prototype path as a way to find out.

6.5. Entity-Native Virtualization

When machine architecture is an entity domain, virtualization becomes entity-native. A virtual machine’s CPU state is an entity subtree: vm/cpu/rax, vm/cpu/rsp, vm/memory/page/0x1000. Instruction execution is handler evaluation on instruction entities. Memory access is tree navigation. The virtual machine IS an entity system evaluating machine-type entities in the tree.

This observation applies recursively: an entity system running on entity-native hardware, virtualizing a von Neumann machine, running conventional software, is a fully inspectable, auditable, capability-scoped virtualization stack — every level described in the same terms.

7. Related Work

7.1. High-Level Synthesis

Bluespec, Clash, and Chisel generate hardware descriptions from functional specifications. These share the entity system’s premise that computation-as-structure can produce hardware, but they target register-transfer-level descriptions of conventional circuits. The entity-native hardware proposal goes further. Where these tools generate conventional circuits from a functional description, entity-native hardware would make the model’s operations the hardware’s own — eliminating the translation layer rather than re-describing the function in silicon.

7.2. Content-Addressable Memory

CAM exists in production hardware. TCAMs in network switches handle packet classification with millions of entries at moderate speed. TLBs in CPUs use fully associative CAM for virtual-to-physical address translation at high speed but small scale. The entity-native content store proposes using CAM for a different purpose — entity lookup by content hash — at a scale between TLB (too small) and TCAM (closer but still potentially insufficient). Hardware SHA-256 acceleration is also in production: Intel SHA Extensions (SHA-NI) and ARM Cryptographic Extensions provide pipelined hash computation.

7.3. Tagged and Capability Architectures

The Burroughs B5000 (1961) pioneered tagged memory, where each word carries a type tag checked by hardware. The entity system’s type dispatch at the pipeline level is a descendant of this idea, extended from word-level tags to full structural types.

CHERI (Watson et al. 2015) (Capability Hardware Enhanced RISC Instructions) implements capability-based security in hardware, with the ARM Morello prototype demonstrating practical capability enforcement at pointer granularity. Entity-native capability verification operates at a higher semantic level — per-dispatch authorization rather than per-pointer bounds — but the hardware techniques (tag bits, capability caches, bounds checking) are directly applicable.

7.4. Self-Hosting and Bootstrapping

The self-hosting loop has precedent in compiler bootstrapping. GCC, the Rust compiler, and the Go compiler are all self-hosting — compiled by earlier versions of themselves. The entity system’s self-hosting loop is structurally identical but extends beyond the compiler: the entire system — evaluator, type system, protocol, extensions — is described in entities and can be compiled from entities.

The diverse double-compilation defense against trusting trust attacks was formalized by Wheeler (Wheeler 2009). The entity system’s three independent implementations (Go, Python, Rust) provide the necessary diversity. Content addressing adds a verification mechanism that Wheeler’s analysis does not assume: same source + same compiler = same output hash, checkable without executing the output.

7.5. Virtual Machine Design

The JVM, WebAssembly, and Erlang BEAM each define an instruction set, memory model, type system, security model, and I/O model. The entity system as virtual machine compares as follows:

The entity VM is distinguished by the absence of a separate “program” concept — programs are entities, subject to the same content addressing, type validation, and capability scoping as all other data. The security model is internal (capabilities checked at every dispatch) rather than external (OS-level process isolation). The I/O model is unified with computation (both use handler dispatch through the tree).

7.6. Smart NICs and DPUs

NVIDIA BlueField and AMD Pensando are production data-processing units that offload protocol handling from the host CPU. Entity-native protocol processing — CBOR decoding, hash verification, signature checking, envelope validation — is a natural fit for DPU offload, even without full entity-native hardware. This represents a near-term path to hardware-accelerated entity processing at the network boundary.

8. Discussion

8.1. The Gradient as Structure-to-Activity Transition

The compilation gradient traces the transition described in The Entity Church Architecture: from computation-as-structure (Stage 1 — inspectable, content-addressed, self-describing information) to computation-as-activity (Stage 4 — temporal, opaque, machine-specific execution). Each stage trades inspectability for performance. The fixed points — tree writes, cross-peer exchange, capability checks, handler transitions — define the irreducible interface between the entity model and physical reality. These are the operations that must survive compilation because they are where the entity model’s guarantees are enforced.

The gradient also makes visible what is lost at each stage and what is preserved. Content-addressed identity persists through Stage 3 (the source hash identifies the compiled handler). Determinism and capability-scoping persist through Stage 4. Inspectability is lost at Stage 3. Portability is lost at Stage 3. The tradeoffs are explicit, not hidden behind opaque compilation.

8.2. The Evaluator Regression and Physical Grounding

The entity system is informationally closed: every aspect of the system — data, types, evaluators, execution traces, the evaluator’s own specification — is representable as entities in the tree. But informational closure is not physical closure. The tree contains the evaluator’s description, but a description does not execute itself. An evaluator described in the tree still needs another evaluator to run it. That evaluator is also describable, requiring yet another. The regression is infinite in description but terminates in physics: at the bottom, a physical process (silicon, chemistry) implements state transitions governed by physical law, not by another evaluator.

This is the entity system’s version of the limits of self-reference, as examined in The Entity Church Architecture:

• Gödel: a formal system cannot prove all truths about itself
• Turing: a program cannot decide all questions about programs
• Entity system: the tree cannot execute its own evaluator from within

The bootstrap evaluator is where this limit is concretely encountered. It is a physical process, external to the tree, that must read the description and begin evaluation. Entity-native hardware does not escape this — it moves the boundary from “software evaluator running on conventional hardware” to “hardware evaluator fabricated by conventional semiconductor processes.” The dependency on the physical substrate is irreducible.

8.3. What Entity-Native Hardware Would Prove

If the entity-native hardware architecture were implemented and showed the hypothesized performance characteristics — near-zero overhead for content verification, coherency-free multi-core sharing, per-cycle capability checking — it would support the conclusion that the apparent performance cost of content-addressed computation is a hardware mismatch rather than a computational limitation.

If it did NOT show these characteristics — if CAM at scale proved impractical, or if the six-stage pipeline introduced unexpected stalls, or if the location index became a bottleneck — that would be equally informative. It would identify which aspects of the entity computational model are genuinely expensive regardless of hardware, distinguishing fundamental costs from translation artifacts.

Either outcome advances understanding. The speculative analysis in this paper provides the architectural framework for both experiments.

8.4. Open Questions

Several questions bear on the claims in this paper:

• CAM scaling: The entity-native hardware analysis assumes content-addressable memory can scale to millions-to-billions of entries. Current TCAM scales to millions. Whether scaling breaks down due to power, density, or cost constraints is the primary open question for entity-native hardware. If it does, a different approach to content-store implementation (such as CAM-indexed DRAM) would be needed.
• Opcode completeness: The expression opcodes derive from the compute extension’s expression-constructing types. Whether that set is complete, or whether an additional primitive expression type would be needed for some class of programs, is a design question that implementation will settle.
• Bootstrap evaluator line count: The 400–500 line estimate is a design analysis. Implementing and measuring the actual count would identify which components are over- or under-estimated.
• Compilation gradient completeness: Whether the four stages form a complete gradient, or whether a distinct compilation level exists between the stages described, is an open structural question.

8.5. Limitations

Several limitations should be noted:

• No implementation evidence. No bootstrap evaluator has been implemented. No architecture type definitions exist in any entity tree. No entity-native compiler handler exists. No FPGA prototype has been built. The paper describes a design specification, not measured results. It is classified as Tier 3 / Phase 3 specifically because it needs implementations.
• Hardware feasibility is unvalidated. CAM scaling, power consumption, pipeline stall analysis, and the economics of entity-native silicon are all open questions. The architectural analysis is sound, but architecture is not implementation.
• The opcode count is design-level. The gap between the expression-constructing types (which an opcode set would mirror) and the operational types the evaluator produces reflects a design distinction that implementation may collapse or expand; the compute extension’s type inventory is itself still settling.
• Performance claims are structural, not measured. The performance inversion hypothesis (entity-native potentially wins vs. von Neumann potentially still wins) is derived from architectural reasoning about the computational model’s properties, not from benchmarks or implementation experience.
• Related work gaps. The engagement with CHERI, TCAM specifications, functional hardware synthesis, and tagged architecture history is based on published descriptions rather than deep technical analysis. A fuller treatment would require implementation-level comparison.
• 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.

9. Conclusion

The entity system defines an explicit machine boundary — the interface between content-addressed computation and physical hardware. Making this boundary explicit, rather than hiding it behind compilers and runtimes, allows the system to reason about its own physical realization.

The compilation gradient traces four stages from entity compute graph (fully inspectable, portable, self-describing information) to machine code (opaque, architecture-specific physical execution). At each stage, determinism and capability-scoping are preserved while inspectability and portability are traded for performance. The fixed points — tree writes, cross-peer exchange, capability checks, handler transitions — define the irreducible interface between entity computation and the physical substrate.

Five machine boundary profiles describe the deployment continuum (line counts are design estimates, not measured implementations):

A bootstrap evaluator designed at approximately 400–500 lines of C suffices to boot the full system from a conforming tree. It performs eight core operations over seven irreducible machine-level primitives. The self-hosting loop, once completed, enables the system to compile its own evaluator, verify its output by hash, and replicate to new architectures.

Entity-native hardware would naturally separate into three memory regions, with the immutable content store particularly suited to content-addressable memory. The six-stage instruction pipeline gives one opcode to each expression-constructing type in the compute extension, distinct from the operational types (closure, scope, result, error) that arise during evaluation. The machine architecture itself, described as entity types in the tree, enables multi-architecture compilation from a single source and closes the self-description loop.

The machine boundary is where abstract information meets physical reality — where the entity system’s typed, content-addressed, self-describing computational model is translated into electrical signals in silicon. The vision is hardware that understands the data model — where the translation overhead disappears because the computational model and the hardware model are the same. Whether that vision is practical is an engineering question. That it is architecturally coherent is what this paper aims to show.

Open questions:

• Can the bootstrap evaluator be implemented and measured? Does the 400–500 line estimate hold?
• Is CAM practical at content-store scale, or do hybrid approaches (CAM-indexed DRAM) prove necessary?
• What are the performance characteristics at each compilation stage? Where does the translation overhead dominate?
• Can the self-hosting loop be completed — the system compiling its own evaluator from entity-native source?
• Would an FPGA prototype validate or invalidate the performance inversion hypothesis — that translation overhead dominates for entity-matching workloads?

Entity System Security Architecture: Capabilities, Identity, and Trust in Content-Addressed Typed Data

1. Introduction

Security in distributed systems is usually bolted on. Identity, authorization, audit, revocation, and confidentiality each get their own subsystem, their own data model, their own deployment story. The integration between them — expressed in TLS configurations, IAM policies, session cookies, audit logs, certificate revocation lists, and out-of-band key exchanges — accumulates as accidental complexity.

The entity system is built differently. The same six primitives that define the system (see The Entity System) also carry every security mechanism. Capability tokens are entities. Peer identities are entities. Delegation chains are content-addressed. Revocation uses the tree’s mutable binding layer. Encryption wraps entities and preserves their identity. There is no separate “security layer” because there is no separate substance: typed content-addressed data is the substrate for data and for security alike.

This paper is the dedicated treatment of how that security model works end-to-end. The Entity Core Protocol covers the security mechanisms in protocol context — wire format, message structure, capability-token layout, the connection handshake. This paper goes deeper: how the mechanisms compose, how they are deployed, what they imply about peer roles and trust boundaries, and where they sit in the broader landscape of capability-based and access-control systems.

1.1. What Lives Where

Security in the entity system lives at the IXP capability triangle (see The Entity System) — one of the five named structural triangles formed by the six primitives. The triangle’s three pairs each carry part of the substrate:

• IX (Identity × Execution): the capability-as-content-addressed-entity. A capability token is an entity, its identity is its content hash, and verification across implementations converges by hash equality.
• XP (Execution × Peer): cross-peer dispatch carrying capabilities. Every EXECUTE between peers carries its own capability token; authorization is per-message, not per-session.
• IP (Identity × Peer): content-addressed peer identity. A peer’s ID is a hash of its public key. Same key, same ID, everywhere, always.

Two of these pairs are phase-transition pairs in the sense developed in The Entity System: IX (capability convergence verification) and IP (peer-ID derivation) do not activate at partial Identity levels. A system at I1 (assigned identity, not content-derived) cannot host the entity system’s capability model regardless of how richly its grant structure is specified. This is the structural reason content-derived identity is a precondition for the security model, not a complement to it. Without Full I, the IXP triangle has at most one pair active (XP), and the capability mechanism degrades to a session-bound authorization model.

Security mechanisms outside the IXP triangle ground in other structural locations:

• Authorization at the dispatch boundary uses the TX pair (handler dispatch via tree-walk) and the EX pair (typed handler operations). The four-dimensional grant covers exactly these: handler (TX), operation (EX), resource (TP for peer-namespaced paths), and peer (XP).
• Audit uses the ITM emit triangle (see The Entity System). Content storage is append-only along the IM axis (Store is monotone over content); the binding layer at TM carries revocation as ordinary binding changes. The IM/TM split is what lets audit and revocation compose without conflict: they live on different axes of the same primitive.
• Confidentiality lives at the EI pair: encrypted entities are typed and content-addressed exactly like any other entity. Authorization (IXP) and confidentiality (EI) are independent dimensions; either can apply without the other, and together they give defense in depth.

The capability model is the only authorization mechanism in the entity system. There is no parallel ACL system, no role table, no session cookie. Roles are expressed as capability-issuing patterns; groups are membership records that produce capabilities; clusters are mutual-trust patterns that share generation pools. The same mechanism handles every authorization question because the substrate provides only one.

1.2. What This Paper Covers

The paper is organized around five questions:

1. Who is acting? The identity model: content-addressed peer IDs, algorithm agility, identity entities as mini-trees, the connection handshake, peer roles.
2. What may they do? The capability architecture: four-dimensional grants, attenuation by construction, delegation chains, two-level verification, handler authority.
3. What happens when they should no longer act? Revocation: tree-based unbinding, generation pools, TTL, and the tiered implementation that scales from minimal deployments to large clusters.
4. What may they understand? Encryption: entity-level encryption with self, peer, and group modes. Scoped to stateless single-shot use — interactive session encryption is separate work and is not covered here — and specified but not yet exercised in deployment.
5. How is this used in practice? Deployment patterns: peer-role configurations, delegation patterns, cluster and group patterns, information disclosure control, incident response.

A comparative analysis section positions the entity system against existing capability systems (Macaroons, UCAN, Biscuit, Zanzibar) and against the security philosophies of high-primitive systems (Holochain’s “trust the code”, Plan 9’s “trust the steward”). The analysis grounds in the landscape developed in Convergent Evolution: of the systems analyzed there, the entity system is the only one that activates the full IXP triangle simultaneously.

1.3. What This Paper Does Not Cover

The six primitives and their build-up sequence are in The Entity System. Wire format, message layout, and the bootstrap handler manifest are in The Entity Core Protocol. Computational architecture and self-description are in The Entity Church Architecture. The full landscape analysis with cross-system scoring is in Convergent Evolution. OS-level deployment patterns and security tiers belong to DEOS; application-level security guidance belongs to Application Architecture. We assume familiarity with the primitives and pair-relationship framework from The Entity System; specific pair and triangle names (IXP, EIT, ITM, TMX, TXP) are used without re-introducing them.

2. Identity

Authorization rests on identity, but in this system “identity” is not one thing. It is a small stack of structurally distinct mechanisms composed under a discipline. At the bottom sits a cryptographic peer ID — the per-keypair identity that lets a peer sign and be recognised. Above that sits an optional identity layer that maintains a peer graph of attestations over time, supports recovery from key loss or compromise, and exposes a stable handle to contacts even as the underlying keys rotate. This section describes both: the peer-keypair foundation, the four-extension identity stack on top, the standard setup users should default to, and the recovery model that makes the whole thing survivable.

2.1. Peer IDs and the Peer Keypair Entity

The lowest layer of identity is per-keypair. Each peer has an Ed25519 keypair; the peer’s identifier is derived deterministically from the public key:

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

Three single-byte format codes pin the cryptographic choices:

• key_type: which signature algorithm the public key uses (currently Ed25519, code 0x00).
• hash_type: which hash algorithm derives the ID from the key (currently SHA-256, code 0x00).
• A separate format code on every content hash pins the content-addressing algorithm (also 0x00 for ECFv1-SHA-256 today).

The three namespaces are independent: a deployment can adopt a new content-hash algorithm without changing peer IDs, a new peer-ID hash without changing keys, and a new signature scheme without changing existing hashes. Algorithm agility is built into the format, not bolted onto a separate negotiation layer.

The resulting peer ID is 46 characters of Base58. Collision analysis under generous assumptions ($10^9$ peers, $10^{12}$ connection events per peer per year) yields a per-event collision probability around $10^{-38}$, which is structurally adequate: a collision would not produce a security failure but would produce a routing confusion that any two affected peers could detect by comparing keys.

The peer’s keypair is itself an entity — the peer keypair entity at system/peer — holding the public key, key-type, and a self-signature. Every peer has one; it is the substrate every other identity mechanism builds on. An earlier revision named this entity system/identity; it was renamed to system/peer to avoid colliding with the identity-extension layer above.

A peer keypair is not yet a user identity. A single-user, single-device deployment can use the peer keypair as their identity (and we describe this as the core-only configuration below). For anything beyond that — multi-device, recovery from key loss, stable handles that survive key rotation — the identity extension layers on top.

2.2. Three Structurally Distinct Validation Classes

Before we describe the identity layer, the security architecture rests on an invariant that constrains its shape: there are three parallel classes of signed entity in the system, and they share no validator.

1. Core capability tokens — chain-walked by the core protocol’s verify_capability_chain, which checks the parent-reference chain, signature at each link, attenuation on every grant dimension, and freshness. Capabilities are how peers authorise specific actions.
2. system/attestation entities — signed claims that one peer makes about another, with kind-discriminated semantics. Validated by EXTENSION-ATTESTATION helpers plus consumer-specific predicates. Attestations are how peers certify state without thereby authorising operations.
3. system/quorum entities — K-of-N signer sets, validated by EXTENSION-QUORUM’s verify_k_of_n_signatures. Quorums are how a collective decision is expressed as a single verifiable entity.

These are three distinct entity types validated by three distinct functions and dispatched along three distinct paths. No code path treats a capability token, an attestation, and a quorum entity as interchangeable signed objects. This is a security invariant, not a stylistic choice. The natural implementation mistake — reusing the capability-chain walker for “anything multi-signed” — would collapse the security model: a multi-sig capability could be confused with a quorum decision; a controller certificate could be confused with a delegated authorisation. The architecture forbids this and the conformance tests check that implementations honour the separation.

The identity layer above composes these three classes into deployment-ready identity machinery; the separation gates the composition rather than constraining it.

2.3. The Identity Stack

Four extensions, in two layers, comprise the identity machinery:

The two substrate extensions are kind-agnostic by design: their primitives are reusable by any future consumer (group, transaction, governance, verifiable credentials, reputation, provenance, audit). The two composition extensions encode identity-specific and role-specific semantics on top.

Three of the four are specified and implemented; the role extension is the one still settling, and we mark where the paper leans on it. We name no version numbers: extension versions move independently of this paper, and a reader who needs the current revision of any of them should read the extension specification rather than trust a number printed here.

Implementations may opt out of the identity layer entirely (the core-only configuration described below); when an implementation installs IDENTITY it MUST also implement ATTESTATION and QUORUM, because IDENTITY’s mechanics actively compose them (registering an identity-resolved resolver against QUORUM at install time, wrapping ATTESTATION’s create/supersede/revoke ops with identity-specific properties and path conventions, dispatching side effects on attestation arrival via a process_attestation sync hook).

2.4. The Cert-Chain Framework

Identity, as the extension models it, is a peer graph rooted at a quorum. A K-of-N quorum sits at the structural root; certs are directed edges; functions (controller, agent, identifier, app-defined) are graph positions established by certs rather than properties stored on peers.

The model has four characteristic features:

Quorum-rooted. Every cert chain terminates at a top-level cert whose attesting field references the quorum’s identifier. The quorum is the trust anchor; verifiers walking any cert chain back to the quorum can validate the chain end-to-end against the K-of-N requirement.

Four standard functions. A cert’s properties.function field names a structural position:

• controller — authority to delegate within the identity (sign agent certs, write internal-management entities, issue local-peer capabilities to the controller’s keypair).
• agent — authority to act on behalf of the identity from a specific device. One agent per device daemon, typically; agent certs are signed by the controller (in the three-key default) or by the identifier (in the four-key advanced shape).
• identifier (four-key only) — the cert function contacts cache as the identity’s handle. Distinct from controller so that controllers can rotate without contacts re-validating.
• app-defined — consumers can register additional function values for domain-specific authority (audit-log signer, service account, custodial agent, etc.).

Chain depth bounded but flexible. Sub-controller chains allow a controller to issue a subordinate controller cert; the chain MUST terminate at a top-level controller (attesting = quorum_id). Default maximum chain depth is 32 per the substrate’s walk_attesting_chain parameter; identity sub-controller chains are typically shallow (2–3 levels).

Functions emerge from graph position, not from peer-side state. A peer is a controller because a cert with function="controller" chains it back to a quorum; revoking that cert (via supersedes, retirement, or revocation) removes the function. The peer’s keypair is unchanged; what changes is its position in the identity graph. This makes role transitions a graph operation, not a state migration.

The four identity-context attestation kinds (registered under the substrate’s kind-ownership table, namespace-prefixed with identity-) carry the lifecycle:

• "identity-cert" — active certification of a peer for a function.
• "identity-rotation-handoff" — graceful key roll; dual-signed by old and new key.
• "identity-rotation-recovery" — compromise-recovery; K-of-N signed by the quorum.
• "identity-retirement" — explicit cert retirement; K-of-N signed.

The substrate’s universal "revocation" kind applies on top of these, with identity’s own authority rules over who may revoke what (per identity_is_authorized_revoker).

2.5. Configuration Progression

The identity extension is opt-in, and not every deployment needs the full machinery. Configurations form a progression from cryptographically minimal (per-keypair only) through the recommended default (three-key with recovery) to advanced shapes:

Core-only

The identity extension is not installed. Each peer’s identity IS its keypair; the peer ID derived from the public key is the identity handle. Single-device, single-key, no recovery, no rotation. Loss of the key is loss of the identity; cross-peer recognition is by raw peer ID. Valid for closed networks, dev environments, IoT devices not intended to survive replacement.

1-of-1 quorum

The identity extension is installed but the quorum has one constituent with threshold 1. The cert-chain machinery operates correctly — agent certs sign other entities, rotation events compose — but no recovery is possible (loss of the single quorum constituent is catastrophic). Useful when a deployment wants the architectural shape (rotation, agent abstraction, controller-mediated grants) but accepts no recovery property.

Three-key default (recommended)

The canonical setup. Three peer functions:

• Quorum constituents. N peers, K-of-N threshold (typically K = 2, N = 3 or 5). Constituent keys held in cold custody: paper backup, hardware token, secondary device, or trusted holder. Used rarely — only for recovery, quorum updates, and minting new top-level controller certs.
• Controller. Hot, encrypted at rest. Signs internal-management entities: peer-config writes, role-assignment records, agent certs. In the three-key default the controller’s key IS the identifier — contacts cache the controller’s public key as the identity’s handle.
• Agents. One per device daemon, hot, on each running device. Sign cross-peer capability tokens (core-standard, per The Entity Core Protocol). The controller authorises each agent via an agent cert.

This configuration delivers the three properties most users actually want: recovery (K-of-N quorum can recover from controller compromise), multi-device (each device runs its own agent with its own keypair, all under the same controller), and stable cross-peer recognition (contacts cache the controller’s key; the identity survives device additions and replacements).

The setup ceremony is documented in §6 of EXTENSION-IDENTITY and is exposed via the system/identity:configure handler. In outline:

1. Choose N quorum constituents and the threshold K. Distribute the constituent keys across diverse custody (geographic, custodial, hardware-class) so that an attacker cannot reach K of them simultaneously without an extraordinary effort.
2. Mint the initial quorum entity (system/quorum:create) and seed it with the N constituent public keys plus the threshold.
3. K of the constituents sign the controller cert (kind = identity-cert, function = controller, attesting = quorum). The cert lives at system/identity/public/cert/{cert_hash_hex} and is published as part of the contact-facing sync surface.
4. The controller mints agent certs for each device (kind = identity-cert, function = agent, attesting = controller’s key). Initially each agent cert lives in mode = internal (privacy default); contacts who need to recognise the agent receive published versions (mode = public or mode = relationships/{contact_id}) per the deployment’s contact policy.
5. Each agent runs system/identity:configure to bind its local peer-config to the trusted quorum, validate the live controller cert chain, and mint the local-peer-to-controller capability that lets subsequent operations dispatch under the controller’s authority.

After this ceremony the identity is operational. Day-to-day work runs through the agents under controller-derived authority. The quorum constituents return to cold custody until rotation, recovery, or membership change.

Four-key advanced

The three-key default conflates the controller (signs internal management) and the identifier (contacts cache as the handle). Some deployments want these separated — controllers should rotate frequently for hygiene, but contacts should not re-validate every rotation. The four-key advanced shape adds an identifier peer:

• The controller rotates frequently; this is invisible to contacts.
• The identifier rotates rarely (only on compromise of the identifier itself). Contacts cache the identifier’s key as the handle.
• Agent certs are signed by the identifier (not the controller), since contacts cache the identifier’s key as the recognition anchor.

Most deployments do not need this. We document it as opt-in; the three-key default carries the load-bearing properties.

Other supported variants

The following composition shapes are normative configurations that compose from the same primitives:

• Multi-binding. A single host machine MAY operate as multiple agents (one per identity it serves) — personal and service-account on the same laptop, for example. Each agent has its own peer-config in its own peer namespace; peer-configs MUST NOT share state across identities.
• Concurrent multi-controller. Multiple controllers live concurrently under the same quorum (desktop + phone deployments where each device holds its own controller). Each agent holds one local-peer-to-controller capability per live controller.
• Sub-controller chains. A controller cert can be issued by another controller (rather than directly by the quorum), enabling delegated management hierarchies. The chain MUST terminate at a top-level controller whose attesting = quorum_id.
• App-defined functions. Custom function values (e.g., function="audit-log-signer", function="service-account") follow the standard cert lifecycle uniformly.
• Parent-managed. Controller keys held initially by a parental peer; the subject acquires their own keys over time via quorum-update ceremonies that add the subject’s peers to the quorum and eventually remove the parental ones. Used for child-account or device-onboarding scenarios.

The progression composes: a deployment can adopt the three-key default and later add sub-controllers, transition from parent-managed to self-custody, or expand to four-key when contact-stability requirements emerge. Each transition is itself a sequence of standard cert lifecycle events.

2.6. The Recovery Cluster

The quorum at the root of an identity is the recovery mechanism. We describe it as a recovery cluster to emphasise its operational character: it is not a routine signing surface but a small set of cold-stored keys whose collective authority can re-establish the identity if a controller is lost or compromised.

Custodial diversity. The N constituent keys should be held across diverse failure modes:

• Geographic diversity. Constituents in physically separated locations so a single fire, theft, or seizure does not reach K of them.
• Custodial diversity. A mix of self-held (paper backup in a safe, hardware token on a keychain, secondary device in a different location) and trust-held (lawyer, family member, employer). The trust assumption is that at most N − K of them collude or are coerced simultaneously.
• Hardware diversity. Some constituents on hardware tokens (YubiKey-class devices), some on software wallets, some on paper. A single supply-chain compromise does not reach all custody.

The threshold K controls the survivability/safety trade-off: low K (1-of-3) tolerates more loss but accepts lower attacker work; high K (3-of-5) tolerates one or two losses but requires more attackers to collude. The recommended default for personal identities is K = 2, N = 3 or K = 3, N = 5; institutional identities often use higher thresholds.

Recovery flow. When a controller is compromised or its key is lost, recovery proceeds as follows:

1. The user assembles K constituent signatures (K-of-N) on an identity-rotation-recovery attestation. This is a coordinated event: the constituents need to be reachable, but the K-of-N signature gathering can be asynchronous (via the proposals subtree convention in §8 of EXTENSION-IDENTITY).
2. The recovery attestation references the prior controller cert (in properties.target_cert) and asserts a new controller cert (in the same supersedes chain) issued to a fresh controller keypair.
3. Contacts processing the recovery attestation validate the K-of-N signatures against their cached quorum-publish attestation for the identity — the prior signer set that the contact already trusts. If the K-of-N signatures verify against that cached state, the contact accepts the new controller and updates its handle cache to the new key.
4. Contacts that never received a quorum-publish for this identity MUST reject the recovery (fail-closed). Deployments opting out of quorum-publish publication accept that compromise-recovery falls back to out-of-band re-establishment: the user sends contacts a fresh signed introduction, and contacts trust-on-first-use the new identity.

The fail-closed property is load-bearing for the security model. Without it, an attacker holding arbitrary signatures could synthesise a “recovery” event and convince contacts to update their address books. The cached quorum-publish is the contact’s trust anchor; recoveries that cannot validate against it are not honoured.

Quorum compromise. If more than N − K of the quorum’s constituent keys are compromised simultaneously, the attacker can sign any quorum-authorised attestation and the identity is fully compromised. The architecture mitigates this through K, N, and custodial diversity, but cannot eliminate it. Quorum compromise is the worst-case failure mode of any K-of-N system; the parameters are deployment choices reflecting the deployment’s threat model.

2.7. Rotation Mechanics

Three kinds of rotation appear in the cert lifecycle, each with distinct signing requirements and use cases:

• identity-rotation-handoff (graceful, dual-signed). Routine key roll: the old key signs and the new key signs the same attestation, demonstrating that the rotation is consensual. Used for hygiene rotation, scheduled key replacement, and planned device replacement. The dual signature is the security property — an attacker holding only the old key cannot complete the handoff alone; an attacker holding only the new key cannot either.
• identity-rotation-recovery (compromise, K-of-N quorum signed). Described above. Used when the old key is unavailable (lost, compromised, or destroyed). The quorum is the only signing path that does not require possession of the old key.
• identity-retirement (explicit termination, K-of-N quorum signed). Marks a cert as terminally retired (no successor); the chain dead-ends. Used when an identity is decommissioned (former employee, retired service account) or when a delegated sub-controller is removed without replacement.

Identity-rotation-handoff and identity-rotation-recovery preserve the identity (the handle the contacts cache); they replace the key behind the handle. The contact-side caching layer (§5.1 in EXTENSION-IDENTITY) tracks the supersedes chain and updates the handle cache to the current live key as rotations arrive. Identity-retirement terminates the chain; subsequent attestations attempting to reference the retired cert do not chain-validate.

2.8. Public-Facing Identity

What contacts see depends on which subtree of an identity is exposed to sync. The identity extension defines a small set of audience tiers:

• system/identity/internal/... — internal management state. NOT synced to contacts. Includes peer-config, internal-mode agent certs (privacy default), sub-controller certs that are deployment-internal.
• system/identity/public/... — the public face of the identity. Synced to all contacts. Contains the top-level controller cert (in the three-key default) or identifier cert (in the four-key advanced), plus agent certs in mode = public.
• system/identity/relationships/{contact_id}/... — per-relationship publication. Synced only to the named contact. Used for agent certs the identity has minted specifically for one contact (mode = per-relationship).
• system/quorum/{trusts_quorum}/... — the quorum’s published state, including quorum-publish events that contacts cache as the recovery trust anchor. Synced to all contacts as part of the identity’s dual-subtree sync surface.

Dual-subtree sync. Contacts receive both system/identity/public/... AND system/quorum/{trusts_quorum}/... as a unit. The quorum state is necessary for recovery validation; the public certs are necessary for connection authentication. Either alone is insufficient.

Operational-key confinement (MUST). Controller signatures NEVER appear under system/identity/public/.... This is a structural invariant: implementations MUST reject attestations under public paths carrying signatures from any currently-live controller of the trusted quorum. The invariant prevents an attacker who has compromised a controller from publishing controller-signed attestations to public paths and tricking contacts into trusting them. Controllers sign internal-management entities only; the K-of-N quorum signs everything that crosses to the public surface.

Privacy opt-out. Deployments may decline to publish quorum-publish. The trade-off is recovery ergonomics: contacts cannot validate identity-rotation-recovery events without a cached quorum-publish, so compromise-recovery degrades to out-of-band re-establishment. The architecture honours both choices: high-privacy deployments accept the out-of-band recovery flow; high-availability deployments publish quorum-publish so recovery is automatic.

2.9. Connection Establishment

The three-message connection handshake (see The Entity Core Protocol) is structured as three EXECUTE round-trips:

1. HELLO. Initiator presents its peer keypair entity, protocol version, and supported algorithm sets. Responder presents the same. The intersection of algorithm sets becomes the negotiated set for this connection.
2. AUTHENTICATE. A nonce-based proof of possession: each peer signs a challenge produced by the other. The signature is verifiable against the public key referenced in the peer keypair entity. Mutual authentication completes here.
3. Initial capability grant. The responder issues the initiator a starting capability covering what the initiator may immediately do — typically read access to the responder’s handler manifest plus the ability to request additional capabilities.

For peers running the identity extension, the HELLO carries the peer’s agent cert (and the cert chain back to the quorum) alongside the peer keypair entity. The responder validates the agent cert chain against the trusted quorum’s cached quorum-publish and (if accepted) issues the initial grant under authority derived from the identity context. For core-only peers, the HELLO carries only the peer keypair entity and the responder authenticates against the raw peer ID.

The handshake uses the same EXECUTE dispatch as everything else; there is no special connection protocol. Pre-authentication, only the connection handler at system/protocol/connect is reachable; post-authentication, the initial grant determines reachability.

2.10. Peer Roles in Deployment

In deployment, peers occupy a small number of structural roles, each with a characteristic capability and tree configuration. These are patterns the system supports rather than enumerated types; deployments compose them as needed.

• Long-lived peers. Stable identity (durable controller-cert chain in a three-key or four-key setup), persistent tree, full capability model. The typical user-facing peer.
• Service peers. Handler-focused. Limited tree (just the handler manifest, configuration, and operational state), grant-scoped to the operations they implement. Identity-wise, often a service-account identity with its own quorum.
• Relay peers. Route messages between peers without reading content. Capabilities cover routing operations (forwarding, queueing); encrypted content remains opaque to them. May run as a core-only peer if no identity-layer features are required.
• Light peers. Minimal tree, request-only, no handler hosting. Mobile clients, IoT devices, ephemeral session participants. Typically agents of a heavier identity (the user’s main identity) rather than identities of their own.
• Cluster peers. A set of peers with mutual full trust within an infrastructure boundary, sharing generation pools. Note: cluster in this sense refers to the planned system/cluster runtime-coordination layer (HA, replication, leader election), distinct from group, which is the identity-level concept for multi-user collective identities (per EXTENSION-GROUP). Cluster peers are an infrastructure pattern; group identities are an identity-extension consumer.

Each role is a configuration of identity, capability, tree, and (when applicable) encryption. The roles do not need separate spec support: they emerge from how the primitives are deployed.

2.11. Key Hierarchy

Three classes of keys appear at distinct lifetimes:

• Identity keys. Long-lived. Ed25519 keypairs whose public key derives the peer ID. Quorum constituent keys, controller keys, identifier keys (four-key only), and agent keys all sit here. Rotated under controller authority (handoff) or quorum authority (recovery) through the identity extension.
• Encryption subkeys. Long-lived but separately rotatable. X25519 keypairs derived from, or attested by, identity keys. Used for key agreement when establishing per-entity encryption keys. Separating signing and encryption follows standard cryptographic practice: an identity-key compromise does not immediately decrypt past traffic if the encryption subkey is rotated independently.
• Ephemeral keys. Short-lived. Per-entity or per-session symmetric keys, derived from key agreement, discarded after use. Forward secrecy lives here: a compromise of long-lived keys does not retroactively decrypt past sessions, because the ephemeral keys are no longer available.

The key hierarchy is enforced through the extension layer (identity for the long-lived part, the encryption extension for the ephemeral part). The substrate is agnostic: any peer that signs entities, derives content hashes, and verifies signatures has the cryptographic primitives the substrate requires.

3. Capability Architecture

The capability system is the core authorization mechanism. Every EXECUTE carries its own capability token; verification is per-message and stateless. We describe the structure of a capability, how attenuation is enforced, how delegation chains are verified, and how the two-level dispatch check works.

3.1. Four-Dimensional Grants

A capability token is an entity:

system/capability := {
  granter:        bytes,        # peer ID hash of the issuing peer
  grantee:        bytes,        # peer ID hash of the receiving peer
  parent:         hash?,        # content hash of parent capability (null for root)
  grants:         [grant_entry], # what this capability authorizes
  caveats:        map?,         # delegation constraints (depth, TTL, no-delegate)
  not_before:     timestamp,
  expires_at:     timestamp,
  signature:      bytes         # signature by granter over the rest
}

grant_entry := {
  handlers:       scope,        # which handlers (path patterns)
  resources:      scope,        # which data paths (path patterns)
  operations:     scope,        # which operations
  peers:          scope         # which remote peers
}

scope := {
  include:        [pattern],
  exclude:        [pattern]?
}

The grant entry has one field per per-grant-entry primitive that varies per grant: handler (Mechanism), resource (Object), operation (Verb), peer (Context spatial axis). These four are derived in Dimensional Completeness from analysis of the attribute structure of distributed-system authorization requests. A request to a peer for an operation on a resource via a handler has exactly these four per-grant-entry scopes; four additional per-token primitives (subject, authority, attenuation, and context-temporal) live at the capability-token level above the grant entries, and a separate revocation mechanism operates outside the token via system/capability/revocation.

All four dimensions in a single grant are conjunctive: a request matches the grant only if every one of (handler, resource, operation, peer) falls within its respective scope. Two grants in the same token are alternative: a request is authorized if it matches any of the token’s grant entries. This gives capability tokens compositional structure: a single token can authorize different things on different paths to different peers, without forcing a one-grant-per-target inflation.

The scope structure (include plus optional exclude) supports the same patterns across all four dimensions: exact matches, prefix patterns, wildcards. Pattern matching is uniform: the same matching algorithm applies to a handler scope as to a resource scope as to a peer scope. This uniformity is what makes the four-dimensional grant tractable: a verifier has one matching primitive, applied four times per check, rather than four different match logics.

3.2. Attenuation by Construction

A child capability must be a subset of its parent on every one of the four grant dimensions. Verification enforces this:

• For each grant entry in the child, there exists a grant entry in the parent such that every dimension of the child’s entry is a subset of the corresponding dimension of the parent’s.
• Subset is structural: every pattern in the child’s include must be covered by the parent’s include and not excluded; the child’s exclude can be larger than the parent’s.
• Caveats can only narrow: a child can shorten the not-before / expires-at window, lower the max-delegation-depth, or add a no-delegation caveat, but cannot expand any of these.

The verification is mechanical. Given a child and its parent, walking the four-dimensional containment check is bounded by the number of patterns in the scopes (typically small) and produces a single accept/reject. There is no semantic interpretation: subset is set containment, not policy interpretation.

The cryptographic enforcement is the parent-reference chain. The child capability includes parent: hash(parent_capability), and the parent’s content includes its own parent reference, and so on to a root capability. Any attempt to amplify — to insert a more-permissive intermediate, or to swap in a different parent — changes the content hash of the modified link, which breaks the chain because subsequent links reference the original hash. The chain cannot be modified without invalidating it. Amplification requires forging the signature of an intermediate granter; the entity model provides no other path.

3.3. Delegation Chains

A capability’s authority traces to a root capability through a chain of intermediate delegations. The root is a capability whose granter is a peer with structural authority over the resources being granted — typically the peer that owns the relevant tree subtree.

A delegation chain is content-addressed end-to-end. Every capability in the chain references its parent by hash; every reference is verifiable; the chain as a whole is verifiable by walking it and checking signatures, attenuation, and freshness at each step. The chain is also transferable: an EXECUTE envelope can carry the full chain in its included map, and the receiving peer can verify the chain without consulting any other peer. This is what self-authentication means for entity-system capabilities: a token plus its chain is, by itself, sufficient to prove authority.

Chains have a maximum depth (recommended default 64, configurable per deployment). Verification walks the chain link by link, so its cost is linear in depth — each link is a signature check. An attacker who could present an unbounded chain could therefore force unbounded verification work, so a conformant peer MUST enforce a finite maximum depth and reject an over-depth chain cleanly, with a chain_depth_exceeded (400) response, while continuing to serve other requests. The status is deliberately a structural error, not an authorization denial: a too-deep chain is something the caller corrects, not a statement that the caller lacks the capability. The bound’s value is a deployment choice, not a protocol constant — the requirement is that some finite bound is enforced; beyond capping verification cost, the bound forces deployments to design their delegation patterns rather than letting chains grow without limit.

A subtle point about chain verification: the chain proves what was granted at issue time, not what remains valid now. To verify a capability currently authorizes a request, the verifier must additionally check:

• Every link’s signature is valid.
• Every child is properly attenuated against its parent.
• Caveats are satisfied (delegation depth, TTL, no-delegation).
• The current time is within the token’s [not_before, expires_at] window.
• The root capability is still bound in the granter’s tree.

The last point is the link to revocation, covered next.

3.4. The Three Slots: Subject, Authority, Attenuation

A capability chain names three structurally distinct identities, and conflating them is the recurring source of cross-peer authorization bugs. They are independent slots:

• Subject — the grantee at the chain’s tip: the peer that authors the EXECUTE. Verification checks that the requester is this grantee (grantee == EXECUTE author).
• Authority — the chain root: the peer with structural authority over the resources, the source from which permission flows.
• Attenuation — the in-chain granters between root and tip, the installer among them: each link may only narrow what it received, never widen it.

In the single-peer case the three collapse onto one identity — a capability a peer issues to itself has the same peer as subject, authority, and sole attenuator — which is why the distinction is invisible locally and easy to miss. Cross-peer dispatch pulls them apart: the resource owner, the requester, and the attenuators become three different peers, and a check that silently treats any two as one is exactly the class of bug the spec kept hitting.

The protocol spec reached this decomposition empirically. Its §5.2 records the three slots as a clarifying note written after a run of cross-peer capability bugs, each one a place where two slots had been conflated — a chain root mistaken for an in-chain granter, a grantee mistaken for the author. The structural methodology of Dimensional Completeness arrives at the same three by irreducibility testing of the authorization attribute space. Both routes converge.

3.5. Two-Level Verification

A capability check happens at two levels in the dispatch path:

• Level 1 (dispatch). Before the handler runs, the dispatch layer checks the capability token against the four grant dimensions: does any grant entry in the token cover this handler, this operation, this resource, this peer? If not, the request is rejected before the handler sees it.
• Level 2 (handler). Inside the handler, before reading specific paths or performing specific operations, the handler re-checks the capability against the actual paths it will touch. The handler has its own grant (issued when it was registered); the effective authority is the intersection of the caller’s capability and the handler’s own grant.

The two levels are defense in depth. Level 1 catches broad violations cheaply (a peer with a read-only grant attempting a write is rejected at dispatch). Level 2 catches specific violations that the dispatch layer cannot anticipate (the handler may compute the specific path from the request and check it; the dispatch layer only sees the request’s declared scope).

Level 2 also handles the handler-on-behalf-of-caller pattern. When a handler issues sub-requests to other handlers (or to other peers), it can do so on its own authority (using the handler’s own grant) or on the caller’s behalf (passing the caller’s capability through). The two-grant intersection ensures that handlers cannot escalate: a handler issued a narrow grant cannot grant its callers broader access than its own, even if a caller’s capability would have allowed it.

3.6. Handler Authority

A handler’s grant is itself a capability token, issued when the handler is registered and stored at a known path under the handler manifest. The grant defines what the handler is permitted to do — which sub-handlers it may call, which paths it may write, which peers it may contact. Handler registration is an EXECUTE to the system handler at system/handler, and the registering peer’s capability must cover the registration scope: this prevents arbitrary peers from registering handlers with arbitrary grants.

The result is that handler authority is itself capability-scoped. A handler that promises to operate only within a subtree is structurally limited to that subtree by its own grant; if it attempts to act outside, its own capability check fails. The discipline forces handlers to declare their authority surface up front, and the system enforces the declaration.

4. Revocation

A capability that cannot be revoked is, in practice, a capability that lasts forever. TTL bounds are a partial answer; explicit revocation is the complete one. The entity system handles revocation as a tree operation: revoking a capability is unbinding it.

4.1. The Mechanism

A root capability is stored at a known path in the granter’s tree, typically:

system/capability/active/{root_hash}

The system/capability/active/ subtree is the set of currently-active root capabilities the granter has issued. To revoke a capability, the granter unbinds it:

EXECUTE put system/capability/active/{root_hash}  →  (binding deleted)

Verification then includes a tree-lookup step: at the end of chain walking, the verifier checks whether the root capability is still bound under system/capability/active/. If the binding is present, the chain is live. If absent, the entire chain rooted there is revoked — and because the chain is content-addressed and ordered, every descendant capability also becomes invalid.

This mechanism eliminates the blacklist problem. A blacklist grows monotonically: every revoked credential remains on the list, and verifiers must check the list on every authorization. The tree-based mechanism uses the same lookup that capability verification already requires (a tree get), with no auxiliary structure that grows over time. Revoked capabilities leave no trace in the active set; their content remains in the content store (audit is preserved by the IM axis of emit), but the tree no longer binds them (revocation is the TM axis).

4.2. The IM / TM Split

The two-axis structure of emit (see The Entity System) is what makes audit and revocation compose. Every emit is a Store event (the IM axis: a new content hash enters the immutable content store) and a Bind event (the TM axis: a path’s binding is updated).

• Audit lives on the IM axis. The content store is append-only: every capability ever issued, every entity ever stored, remains addressable by its content hash. A revoked capability is still inspectable; the binding has been removed, but the content endures. Audit logs are queries over the content store, not over the active bindings.
• Revocation lives on the TM axis. The binding at system/capability/active/{root_hash} is mutable; unbinding it is a TM event. The TM axis is where state changes meaningfully over time; the IM axis preserves history.

Because the two axes are independently observable, an audit consumer can subscribe to IM events (recording every capability issuance) without conflicting with a revocation consumer that subscribes to TM events. The split is structural, not implementational: it follows from how emit is defined as a primitive (see The Entity System).

4.3. Generation Pools

Individual revocation handles individual capabilities. Some deployment scenarios need broader revocation: an employee leaves the company; a relay peer is compromised; a key is rotated. Revoking each affected capability one at a time is slow and error-prone. The generation pool mechanism provides O(1) scoped mass revocation.

A capability can be issued under a pool: a named subtree like system/capability/pool/external_sharing/. The pool itself has a generation counter, stored at system/capability/pool/external_sharing/generation. Capabilities issued under the pool carry a pool_generation field with the value of the counter at issue time.

Verification adds one step: the verifier reads the pool’s current generation and compares it to the capability’s pool_generation. If they match, the capability is current; if they don’t, the capability is revoked. Incrementing the pool’s generation revokes every capability issued under that pool, instantly and in O(1) work: one tree write, with no need to enumerate the affected capabilities.

Pools are independent: revoking the external_sharing pool does not affect the internal pool or the audit pool. Deployments use pools to partition revocation domains: one pool per role, one per cluster, one per project, with revocation of each domain scoped to its pool. The cost of mass revocation becomes constant in the number of affected capabilities, rather than linear.

4.4. TTL as Baseline

Every capability carries not_before and expires_at fields. TTL is the baseline revocation mechanism: a capability with a short TTL is revoked when it expires, with no action required from anyone. Short TTLs (minutes to hours) force frequent refresh and bound the damage window of any single token. Long TTLs (days to weeks) reduce refresh overhead at the cost of slower natural revocation.

TTL handles offline peers without coordination: a peer that cannot reach the granter cannot refresh, and stale capabilities simply expire. The combination of TTL plus explicit revocation gives deployments two knobs: short TTL plus rare explicit revocation, or long TTL plus aggressive explicit revocation, depending on which cost they prefer to pay.

4.5. Tiered Implementation

Real deployments need different levels of revocation infrastructure. The capability specification supports a tiered model:

• Tier 0: TTL only. Capabilities expire; no explicit revocation. Suitable for short-lived sessions and simple deployments.
• Tier 1: + delegation chains with attenuation and caveats (depth, TTL, no-delegation). Still no explicit revocation, but delegation is structured.
• Tier 2: + explicit revocation via the tree-based mechanism. Individual capabilities can be revoked.
• Tier 3: + generation pools, push/pull propagation between peers. Scoped mass revocation, online-optimistic propagation.
• Tier 4: + relationship derivation. Capabilities derived from group membership, role assignment, or other patterns. The most expressive tier; required for large deployments with rich access patterns.

Unknown caveats are rejected (fail-closed). A peer that does not implement a higher tier cannot accidentally accept a capability that relies on a caveat it does not understand: the verifier rejects what it does not know how to check.

4.6. Trade-Offs

The tree-based mechanism is not free. Three trade-offs are worth naming:

• Online vs offline. Verification requires a tree-lookup against the granter’s current state. Offline verifiers must either trust a recent snapshot (with the staleness window as the revocation lag) or refuse to verify until they reconnect. TTL bounds the staleness exposure.
• Selective vs mass. Tier-2 individual revocation is selective but linear in revocations; Tier-3 pool revocation is mass but coarse-grained (the pool is the unit). Deployments compose both.
• Immediate vs eventual. Tree-unbinding is immediate locally: the granter sees the revocation as soon as the emit commits. Propagation to other peers is eventual: they see it when they next consult the granter’s tree (push notifications via subscriptions accelerate this). A revoked capability presented to a peer that has not yet seen the revocation will be accepted; the staleness window is the propagation lag. Deployments that need provably-immediate revocation must combine pool revocation with subscription-based push.

The mechanism handles most production revocation scenarios at low cost; the residual cases (immediate-globally, fully-offline) are handled by extension-level patterns rather than by the substrate.

5. Encryption

Encryption on this substrate is deliberately narrow, and the scope line is the first thing to understand about it. What is specified is stateless, single-shot encryption: an entity is encrypted once, for storage or for one recipient, and the ciphertext stands on its own. Stateful interactive encryption — sessions, streaming, chat, the ratcheting constructions of Signal, Noise, and MLS — is a structurally distinct problem and is a separate piece of work, sharing this substrate rather than extending it. Anything below is about the single-shot half. The other half is real, and it is not here.

The narrowness is deliberate rather than a gap: the design under-promises so that an implementation builds to the threat model actually met, and we follow that discipline rather than smoothing it. What the substrate has not had is use. The mechanisms have conformance vectors, not deployments; nothing here has been exercised against a real adversary, over real time, at real scale. Treat this section as a description of a design that fits the substrate, not as a report from production.

Encryption is independent of authorization. The capability system answers who may act; encryption answers who may understand. Both can apply to the same entity, either can apply without the other, and together they give defense in depth.

5.1. Entity-Level Encryption

An encrypted entity is an entity of type system/encrypted whose data field carries a typed ciphertext. The inner entity ({type, data}) is encrypted as a whole; the type information lives inside the ciphertext, not in the outer envelope. To a peer without decryption capability, the inner type is opaque; to a peer with it, decryption produces the inner entity directly, with its native type and content hash recoverable.

The encrypted entity has its own content hash, derived from its ciphertext bytes. This means the encrypted form is itself addressable, transferable, and integrity-checkable without decryption: a relay peer can route or replicate an encrypted entity without ever seeing its plaintext. The same encrypted entity is the form on the wire, on disk, and in memory — no re-encryption at boundaries, no separate transport-encryption layer.

The decrypted inner entity carries its own (separate) content hash: the hash it had before encryption, derived from its own bytes. So an entity has two identities — the encrypted form’s hash and the plaintext form’s hash — and the two are independent. References can be made to either, depending on which view of the entity is intended.

5.2. Three Modes

Three encryption modes are distinguished by recipient pattern:

Peer mode (single-shot, to one recipient). A specific recipient peer. Hybrid encryption: the inner entity is encrypted under a fresh symmetric key, and the symmetric key is wrapped under the recipient’s encryption subkey via key agreement (X25519). Structurally this is a sealed box — the same shape as crypto_box or age, with sender authentication added. The sender’s ephemeral key is discarded after encryption, so a sender cannot decrypt their own past sends.

It does not provide forward secrecy, and the distinction is worth stating precisely because the mechanism invites the opposite reading. Discarding the sender’s ephemeral key is not forward secrecy against compromise of the recipient. The recipient’s decryption key is long-lived by construction, and the wire carries the sender’s ephemeral public key alongside the ciphertext; anyone who later obtains the recipient’s private half and has kept that pair can recover the shared secret and decrypt. The threat model peer mode actually addresses is passive observation of the relay and storage path — an intermediary that carries the bytes without reading them — not later compromise of the endpoint that received them. Interactive forward secrecy of the kind a ratchet provides belongs to the session work named above, and is not available here.

Self mode (storage). Encryption for one’s own future access. The symmetric key is derived from a long-lived local secret; the same key encrypts and decrypts the entity across sessions. No forward secrecy: a key compromise reveals all past and future self-encrypted entities. The trade-off is intentional: archival storage requires that the holder be able to decrypt old data without preserving ephemeral keys.

Group mode (shared, static). A set of recipients sharing access. A random symmetric key encrypts the entity; the key is wrapped separately for each group member (using peer-mode wrapping). Group membership is then a key-distribution question: adding a member means wrapping the key for them; removing one means re-keying and re-wrapping. Two limits are structural rather than incidental. Re-keying protects future entities only — a removed member keeps the old key and can still decrypt anything they could read before, so removal is not retroactive. And the member set is not hidden: each wrapped key names its recipient, so anyone holding the entity can see who the group is. The cost is linear in group size, and the mode is built for small, stable groups; membership that churns wants the tree-based key agreement of MLS, which is the session work’s territory, not this one’s.

The three modes share the entity-level encrypted-wrapper structure; they differ in how the symmetric encryption key is established. The substrate is neutral: any keying mechanism that produces an authenticated ciphertext fits.

5.3. Recoverability Is the Axis, Not Secrecy

There is a real tension between forward secrecy — communication should stop being decryptable — and durable storage, where data must stay recoverable for as long as its holder needs it. The three modes do not resolve that tension; they sit on one side of it. All three are built so that a holder of the right long-lived key can decrypt later, because all three exist to move or keep data rather than to hold a conversation. What they distinguish is who retains that ability and for how long: self mode for one holder indefinitely, peer mode for one recipient, group mode for a fixed set until the key is rotated forward.

Naming this plainly matters more than claiming the tension away. A design that keeps data recoverable is the right design for storage and transfer, and the wrong one for a conversation that should become unreadable. Resolving the other side needs ratcheting state between two live parties, which is the session work, and it is a different extension for that reason. A deployment chooses a mode per entity rather than per protocol — but every choice on offer here is a choice about recoverability, not about secrecy over time.

5.4. Authorization vs. Confidentiality

Capabilities and encryption are independent dimensions of access. The clearest case is a relay peer:

• The relay holds a capability authorizing it to route messages between named peers. It can read the message envelopes, see source and destination, and forward the message.
• The relay does not hold the decryption key for the messages’ contents. The encrypted inner entity is opaque to it.

This is defense in depth: a relay compromise leaks routing metadata (who is talking to whom) but not message content. A capability compromise allows unauthorized actions but does not reveal encrypted content the attacker lacks keys for. The two compromise classes are independent; an attacker needs both to fully read encrypted communication.

The substrate does not couple the two. A peer can route encrypted entities it cannot read; a peer can decrypt entities it is not authorized to act on. This separation is what lets the capability layer and the encryption layer evolve independently — and what lets deployments mix and match (e.g., authenticated-but-unencrypted internal traffic plus encrypted-for-recipient external traffic) without compounding mechanism.

5.5. What Is Not Yet Settled

The encrypted-wrapper shape, the three-mode framing, the algorithm registries, and the authorization-confidentiality split are settled: algorithms are selected by a versioned byte under a documented registry rather than hardcoded, which is the same discipline the protocol applies to hashes and keys, and a floor suite is mandatory so that two peers always share one. What remains open is genuinely open, and most of it is about what the encrypted form reveals rather than whether it can be read:

• Metadata. Recipient-hiding and size-hiding are identified as work and are not specified. Today an encrypted entity discloses who it is for and roughly how large it is, and group membership is visible on its face. For some deployments that is the more important leak than the plaintext.
• Post-quantum key agreement. A hybrid slot is reserved so the discipline holds and a first implementation has a target, but the construction is not yet realized.
• Distributed key custody. Splitting a backup key across several holders is designed and not built, which leaves key loss a sharper operational risk than the cryptography suggests.
• The session half. Everything interactive — ratcheting, streaming, chat, dynamic groups — sits in the sibling work described at the top of this section. It is the larger unknown of the two, and no part of it is available yet.

Above all of it sits the plainest limitation: none of this has met a real adversary. The mechanisms are specified and checked against conformance vectors, which establishes that implementations agree with each other, not that the design survives contact with use. Cryptographic constructions earn their reputations by being deployed, attacked, and revised. This one has not started.

We describe the structure rather than the choices because the structure is the load-bearing claim: entity-level encryption with three modes, authorization-confidentiality separation, and same-bytes-everywhere. The choices will settle through implementation; the structure already fits the substrate.

6. Deployment Patterns

The substrate provides mechanism. Deployments compose mechanism into patterns. This section describes the patterns that recur across deployment scenarios, organized by the question they answer.

6.1. Identity Presentation

A peer’s identity in deployment is rarely just its peer ID. The standard presentation is a mini-tree envelope:

• The peer keypair entity at the root (system/peer).
• The public key it hashes, in the envelope’s included map.
• When the identity extension is installed: the relevant agent cert plus the cert chain back to the trusted quorum (per EXTENSION-IDENTITY’s peer graph). When it is not: nothing further at the identity layer; recognition is by raw peer ID.
• A starting capability the peer is bringing into the connection.
• Optional metadata: display name, organization, contact path.

The envelope is what the peer sends in HELLO. The counterparty verifies the peer keypair entity’s hash, checks the public key matches, validates the cert chain (if present) against its cached quorum-publish for the identity, and accepts the capability if it traces to a root the counterparty trusts.

Human-readable aliases are entities. A directory service is a peer that holds entries of the form alias/{name} → identity_hash, signed by an authority the consumers trust. Aliases are not part of the substrate; they are an application pattern built on the substrate’s primitives.

6.2. Delegation

A capability holder can delegate by issuing a child capability to another peer. The child must be a strict subset of the parent on all four dimensions. Common patterns:

• Sharing for collaboration. The owner of a subtree delegates read access to a collaborator, scoped to the subtree and with a finite TTL. The collaborator’s capability includes the owner’s as its parent and adds caveats (e.g., no_delegation to prevent further re-sharing).
• Time-boxed access. A short-TTL delegation that auto-expires; useful for temporary consultants, audits, or one-off tasks. The token’s expires_at field carries the explicit window.
• Capability request flow. The connecting peer sends an EXECUTE to a capability-issuing handler with a request for the scope it needs. The handler evaluates the request against the connecting peer’s identity, the existing trust relationships, and the deployment’s authorization policy, and issues the capability if the policy allows. The request flow is itself an EXECUTE; there is no separate channel.
• Re-delegation chains. Alice delegates to Bob; Bob, holding a delegate-able capability, further delegates to Charlie. Each link must attenuate; the chain depth is bounded by the max_delegation_depth caveat. Verifiers walk the full chain.

The patterns share the same mechanism (capability issuance with attenuation) and differ only in the policy that drives them.

6.3. Role-Based Configurations

Different peer roles need different default capability shapes. Concrete patterns:

• IoT sensor. Minimal grant: write access to a specific subtree (the device’s reporting path) and no other handler invocation rights. Identity is a long-lived peer key; capability is renewed periodically (short TTL, ~hours).
• Storage node. Read and write to sync paths shared with replication peers; no execute rights on application handlers. Replicates encrypted content without decrypting it.
• Relay peer. Routing rights only: dispatch operations on system/relay/*, capability-scoped visibility into which peers it may serve. No content-decryption capability.
• Service peer. Handler-focused: implements specific handlers, has a grant that lets it read its configuration subtree and the operational state it needs, and is authorized to invoke a defined set of upstream operations.
• Admin. Broad grant within a cluster boundary, with full audit logging (audit lives on the IM axis; admin actions are entities like any other). Often gated through a quorum of admin peers rather than a single admin peer.

Each is a configuration of capability, encryption, and tree shape. None requires special protocol support; each is composition of substrate features.

6.4. Cluster and Group Patterns

Cluster and group are different concepts in this architecture; the security model treats them differently.

A group is an identity-level concept (per EXTENSION-GROUP). A group is itself an identity — it has its own quorum, its own controller, its own agents, all built from the identity-stack primitives described above. What distinguishes a group from a single-user identity is that its quorum constituents are drawn from members or admins rather than from personal backup keys, and the group’s lifecycle (form, dissolve, merge, split, add/remove member, add/remove subgroup) is exposed through the group handler at system/group. Security-wise, every property of an individual identity — recovery via K-of-N, controller rotation without disturbing contacts, fail-closed validation against cached quorum-publish — applies to a group identity unchanged. Members may act as themselves (their own identity stack) or on behalf of the group (via an acting-on-behalf-of attestation that the group has issued); the two surfaces are distinct.

A cluster is an infrastructure-level concept (the planned system/cluster extension). A cluster coordinates peers at the runtime layer — high-availability, replication, leader election, generation-pool sharing within a trust boundary. Cluster peers typically share a generation pool, and revoking the pool revokes all cluster-internal access in a single tree write. The cluster extension is not yet specified at the same level of detail as identity or group; we treat it as a deployment pattern here rather than as a normative mechanism.

The two compose: a group’s members may run their daily work through a cluster (the user’s laptop, phone, and personal server forming a cluster of agents under the user’s individual identity, all of which are members of the group). The group’s identity manages the recognition surface; the cluster manages the operational shared state.

Trust boundaries are explicit at both levels: a cluster’s pool revocation does not affect another cluster’s pool; a group’s controller revocation does not affect another group’s controller; external delegations from a cluster’s peers do not implicitly cascade through the cluster pool; an agent’s authority within a group is scoped by the group’s role assignments, not by membership alone.

6.5. Information Disclosure

Authorization controls what a peer may do; it also controls what a peer may see. The two are connected through the tree.

• Handler manifest exposure. What a connecting peer can learn about available handlers depends on its initial capability. A minimal initial grant exposes only the connection handler and a request-capability handler; deeper grants expose more of the manifest. The minimum initial grant is by design: a peer with an unknown intent should see only enough to ask for what it needs.
• Capability-scoped views. Reads against the tree are scoped to what the requester’s capability allows. A peer that holds read rights on data/projects/alpha/* cannot enumerate data/projects/beta/* — not because the latter is hidden by convention, but because the read attempt fails the resource-scope check.
• Metadata leaks. Even with content encrypted, routing metadata (source, destination, timing) is visible to relays. Deployments concerned about metadata exposure use mix-network patterns or onion routing on top of the substrate; the substrate does not provide metadata privacy by itself.

6.6. Incident Response

When something goes wrong, the substrate provides several response patterns:

• Key compromise. Rotate the affected key through the IDENTITY extension’s rotation ceremony — identity-rotation-handoff (dual-signed) for graceful roll, identity-rotation-recovery (K-of-N quorum signed) when the old key is unavailable. The cert chain advances; predecessor attestations remain in the content store for audit, but the binding moves to the successor cert. If the compromised key was used to sign capability tokens, the relevant generation pool is incremented.
• Unauthorized access. Revoke the specific capability via tree unbind, increment the relevant pool, audit the trail via the content store (every action is an emit; every emit is content-addressed; the audit is cryptographic).
• Relay compromise. The encrypted content remains safe. Revoke the relay’s routing grant; rotate any cluster pools the relay had access to; reconfigure routing to other relays. The relay’s content store is forensically preserved; what it routed but could not decrypt is not at risk.
• Cluster compromise. Severity depends on whether internal-trust assumptions broke. The cluster pool is incremented (revokes all cluster-internal access); peer attestations are reviewed; the cluster is rebuilt from the surviving attestation graph if a recovery quorum is available.

Incident response in the entity system uses the same mechanisms as normal operation: tree writes, capability issuance and revocation, attestation updates. There is no separate “break-glass” interface, because break-glass is a generation-pool increment with the right authority.

7. Comparison and Analysis

This section places the entity system’s security model in context: against existing capability systems, against the security philosophies of high-primitive systems, and against the broader landscape analyzed in Convergent Evolution.

7.1. Comparison to Existing Capability Systems

We compare against four systems that represent different stable points in the capability-system design space.

Macaroons (Birgisson et al. 2014) use a contextual-caveat model: a Macaroon is a bearer token plus a chain of caveats, each restricting the bearer’s authority. Caveats are opaque to the protocol — their interpretation lives in the service that issues them. Strengths: flexible attenuation, no central authority for caveat interpretation. Gaps: no four-dimensional grant structure (caveats are general but unstructured), per-service granularity (no handler dimension across services), no peer dimension, no integrated content addressing.

UCAN (Zelenka et al. 2022) is a JWT-based capability format for decentralized contexts: a UCAN has a subject (DID), an ability (operation), a resource (URI), and a proof chain back to a root issuance. UCANs are signed and chainable. Strengths: decentralized issuance, structured delegation, DID-based identity. Gaps: no handler dimension (the resource URI encodes both routing and content), no peer dimension (URIs are location-independent), no content-addressed identity for the tokens themselves (UCANs are referenced by JWT identifier, not content hash).

Biscuit (Couprie et al. 2021) combines Macaroons-style attenuation with a Datalog policy layer: each token can carry a small Datalog program that participates in authorization decisions. Strengths: rich expressiveness for policy, structured attenuation. Gaps: the policy layer is per-token and per-service, not integrated with a substrate; no handler or peer dimensions in the base model; no content addressing.

Zanzibar (Pang et al. 2019) is Google’s centralized authorization system based on relation tuples. Authorization is computed by traversing a relation graph: a subject has a relation to an object via a path through groups, roles, and explicit grants. Strengths: enormous scale, strong consistency guarantees, sophisticated relation algebra. Gaps: centralized (a Zanzibar deployment has authoritative servers); not capability-based (no transferable tokens); no peer dimension (single-domain assumption); no content addressing.

The entity system’s distinctive structural contributions are Handler and Peer as first-class grant dimensions, and content-addressed identity for the tokens themselves. The handler dimension lets a capability carry mechanism scoping (“you may invoke this handler”) separate from operation scoping (“you may perform this action”), which existing systems collapse into a single resource-or-service axis. The peer dimension lets a capability carry topology scoping (“you may act on this peer’s tree”), which existing systems treat as a property of the deployment topology rather than as part of the authorization. Content-addressed identity lets the tokens themselves be entities — inspectable, composable, verifiable by hash equality.

7.2. Security Philosophy: What Do You Trust?

Different systems answer the question “what is the unit of trust?” differently. The answers are not feature-level differences; they are philosophical commitments about how security is supposed to work.

“Trust the code.” Holochain’s model: every peer runs identical validation code (the DNA), and security comes from code identity. If you and I run the same DNA, we follow the same rules, and the rules are themselves the guarantee. Capabilities in Holochain are per-function, non-delegatable, secret-based: they exist within a DNA’s runtime, not across DNA boundaries. The DNA wall structurally prevents capability migration; capability tokens cannot escape the DNA context that issued them. The model is internally coherent but architecturally incompatible with delegable capability-based authorization: a delegable capability would need to be meaningful across DNAs, which requires content addressing of the capability tokens, which Holochain does not have.

“Trust the steward.” Plan 9 and Inferno’s model: a single trusted operator administers the namespace, and authority flows from the operator’s configuration. Capabilities are not the primary mechanism; access control lives in the file-server’s per-mount permissions. The model works for the deployment context Plan 9 was designed for (research labs and small organizations) and breaks down at scales where no single steward can be globally trusted. The mechanism class is distinct from Holochain’s: Holochain’s wall is architectural (DNA-determinism), Plan 9’s is organizational (centralized stewardship).

“Trust the identity.” The entity system’s model: capability tokens prove what you are authorized to do, regardless of what code you run, by tracing a cryptographic chain to a root capability issued by a peer that owns the relevant resources. Verification is local, per-message, and content-addressed. Identity is content-derived, capability tokens are content-addressed, and the chain is verifiable by anyone with the public keys of the granters. The model rests on the IXP capability triangle, which requires Full I (content-derived identity); a system at I1 cannot host it.

These are not “better” or “worse” relative to each other. They are different architectural commitments about where security lives. Trust-the-code (Holochain) gives strong determinism at the cost of capability migration. Trust-the-steward (Plan 9) gives simple administration at the cost of decentralization. Trust-the-identity (the entity system) gives decentralized capability-based authorization at the cost of requiring Full I and a tree-walk-based revocation mechanism.

7.3. The IXP Triangle as Structurally Privileged Surface

Of the systems analyzed in Convergent Evolution, the entity system is the only one that activates all three pairs of the IXP triangle simultaneously at full strength. The structural reason is the conjunction of three requirements:

• IX active requires capability tokens to be content-addressed entities, so that convergence verification (same hash = same capability) is a structural fact.
• XP active requires cross-peer dispatch to carry capabilities as part of the message, so that authorization is per-message and not session-bound.
• IP active requires peer identity to be content-derived, so that the chain’s references to granter peer IDs are themselves verifiable hashes.

Adjacent systems each have part of the triangle and are missing a critical pair:

• Holochain has IX (DNA-bound capabilities are content-addressed within the DNA) and XP (zome calls carry capabilities), but its IP is degraded: peer IDs do not escape DNA context, so the cross-DNA capability-meaning that the triangle requires cannot exist.
• Urbit has XP (scry and poke dispatch cross-peer) and IP (self-addressed peer IDs), but lacks I in the entity-system sense: no content-addressed entities, so IX cannot activate. Capabilities, if added, would have to be rebuilt on path-rooted identity rather than content-rooted.
• AT Protocol has IP (DIDs) and partial structure for cross-peer trust, but lacks X (no protocol-level dispatch), so the XP pair is latent: handler authority lives in PDS implementations, not in the protocol’s authorization model.
• Bitcoin has IP (content-addressed addresses) and an economic XP analog, but lacks general-purpose X, so its capability model is bounded to economic operations.

The pair-coverage view makes the gap precise. “Capability-based security” is not a single thing; it is the activation of a specific pair-bundle (IX + XP + IP). Systems that have one or two of the pairs implement portions of capability-based security; systems that have all three implement it in full. The entity system’s distinction is not a feature; it is the unique landscape position where the triangle activates simultaneously.

7.4. Security Properties from Content Addressing

Content addressing provides several security properties as structural consequences, not as added features:

• Tamper evidence. Any modification to an entity changes its content hash, which breaks every reference to the original. There is no way to silently modify a content-addressed entity; modification is structurally visible.
• Verifiable delegation. A capability chain is a sequence of content-addressed entities, each referencing its parent by hash. The chain cannot be modified (insert, delete, swap intermediates) without breaking hash references; the verifier reconstructs the chain from the references and checks every link.
• Self-authenticating messages. A signed content-addressed entity is verifiable by anyone with the granter’s public key. The verifier needs no live connection to the granter, no shared session state, no out-of-band coordination. The token is its own proof.
• Cryptographic audit. The content store is append-only along the IM axis. Past actions are reconstructable from their content-addressed records; nothing is silently deleted; revocation is a binding change, not a content deletion.

These properties are not bolted on. They are what content addressing is: identity derived from bytes, with no separate identity-assignment authority. The security model inherits them by being built on the same substrate.

7.5. Algorithm Agility

Three independent format-code namespaces support cryptographic evolution:

• The content-hash format code (0x00 for ECFv1-SHA-256) selects the hash algorithm used in content addressing.
• The peer-ID hash format code selects the hash algorithm used in deriving peer IDs from public keys.
• The peer-ID key format code selects the signature algorithm.

A new algorithm can be introduced in any one of these namespaces without changing the others. Connection negotiation determines the per-connection set: each peer presents its supported algorithms in HELLO; the intersection is the active set. New algorithms enter through extension agreement (new format-code allocations); old algorithms phase out through deprecation in the connection-negotiation policy.

The agility is not unbounded. The hash function used for content addressing is a category-(b) structural instantiation (see The Entity System): changing it changes every content-addressed identity, which is a massive coordination event. Adding a new hash algorithm alongside the existing one is straightforward; replacing the existing one is not. The same holds for the peer-ID hash. Signature algorithms are easier to evolve because signatures are per-message and not retroactively re-keyed.

7.6. Limitations

Several limitations are worth naming explicitly.

• No formal security proofs. The argument that attenuation is enforced, that delegation chains are unforgeable, and that the tree-based revocation mechanism is sound rests on the cryptographic properties of the underlying primitives (Ed25519, SHA-256) plus the structural properties of content addressing. We have not constructed formal proofs in a proof system; this is an open direction.
• Clock skew affects TTL-based revocation. TTL bounds rely on synchronized clocks across peers. Clock skew beyond the TTL window can produce premature acceptance or premature rejection. Deployments tighten this with NTP or with overlap windows in their TTL policies.
• Offline peers cannot receive revocation updates. A peer that cannot reach the granter cannot observe a new revocation. Until reconnection, the peer’s stale view may accept revoked capabilities. TTL bounds the exposure window; the substrate does not eliminate it.
• Selective intermediate revocation requires Tier 2+. The substrate provides root-capability revocation cheaply; revoking a specific intermediate in a chain (without revoking the root) requires per-token tracking, which is Tier 2 work. Deployments that need fine-grained intermediate revocation accept the per-token cost.
• Encryption is specified but untried, and half of it is not specified at all. As the encryption section sets out, what exists covers stateless single-shot use; interactive session encryption is separate, later work. Within what exists, metadata protection (recipient-hiding, size-hiding) and distributed key custody are open, and none of it has deployment experience. Peer mode in particular does not provide forward secrecy against compromise of the recipient’s key, and should not be read as end-to-end encryption in the sense a messaging application means it.
• The role extension is still settling. EXTENSION-ROLE is specified but has not yet been through a cross-implementation green round. The role-based authority patterns described in this paper depend on its root-cap shape, and that shape may change before it stabilizes.
• No production-scale deployment data. The capability mechanism is implemented across three implementations (Go, Python, Rust) and has been exercised in conformance tests, but no large production deployment has been observed long enough to surface scaling or operational issues at scale.
• 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.

8. Related Work

8.1. Capability Systems

The object-capability model originates with Dennis and Van Horn (Dennis and Van Horn 1966); modern treatments include KeyKOS (Hardy 1985), EROS (Shapiro et al. 1999), and seL4 (Klein et al. 2009) at the OS level. The entity system’s tokens-as-content-addressed-entities is a different specialization: tokens are transferable across the wire and across peer boundaries, while object capabilities (in the KeyKOS lineage) are bound to a particular kernel’s object table. Hardware capabilities are explored in CHERI (Watson et al. 2015), with ARM Morello (Arm Ltd. 2022) as a production prototype; CHERI capabilities are per-pointer bounds enforced in hardware, structurally distinct from semantic dispatch-level capabilities but using compatible techniques (tag bits, capability caches, bounds checking).

Decentralized capability tokens have a recent literature. Macaroons (Birgisson et al. 2014) established the contextual-caveat pattern. UCAN (Zelenka et al. 2022) adapted JWT for decentralized capability delegation with DID-based identity. Biscuit (Couprie et al. 2021) added a Datalog policy layer. ZCAP-LD (Sporny and Longley 2022) is a JSON-LD format for chained authorization. The entity system’s contribution to this lineage is the four-dimensional grant (handler, operation, resource, peer) and the content-addressed token, both of which are absent from the existing decentralized-capability literature.

8.2. Authorization Models

The role-based access control literature (RBAC (Sandhu et al. 1996)), attribute-based (ABAC (Hu et al. 2014)), and relationship-based (ReBAC (Fong 2011)) frameworks describe authorization policy at the application level. The entity system’s four grant dimensions map to ABAC attribute classes with finer granularity: Action attributes split into Handler and Operation, Environment attributes split into Peer and Time. The entity system implements something close to ReBAC at the substrate level: capability delegation chains are the relationship graph, and capability-derivation patterns (group membership, role assignment) are relationship-derived authority.

Zanzibar (Pang et al. 2019) represents the high-scale centralized branch of relation-based authorization: a single authoritative system maintains the relation graph and answers authorization queries. The entity system represents the decentralized branch: relations are content-addressed capability chains, and verification is local.

8.3. Decentralized Identity

The W3C Decentralized Identifiers (DID) specification (W3C 2022a) and Verifiable Credentials (W3C 2022b) provide a framework for content-or-key-derived identity in distributed contexts. AT Protocol’s identity model (Kleppmann et al. 2024) uses DIDs in a federated setting. The entity system’s peer-ID format is structurally similar (content-derived from a public key) but more minimal: a 46-character Base58 string rather than a URI. The identity entity layer above peer IDs — self-describing records with controller-cert chains and quorum attestations — is closer in spirit to W3C’s “DID Document” pattern.

8.4. Encryption Protocols

Modern messaging encryption is dominated by Signal Protocol (Perrin and Marlinspike 2016) and its successor Messaging Layer Security (MLS (Barnes et al. 2023)) for group messaging. The Noise framework (Perrin 2018) provides composable encrypted-transport patterns. The entity system’s encryption is structurally simpler than these, and the comparison is only fair once the scopes are lined up: what exists here is same-bytes-everywhere single-shot encryption in three modes, with no separate transport-encryption layer, and the simplicity comes from the substrate — encrypted entities are entities, and the same wrapper works on wire and in storage. Signal and MLS solve the problem this deliberately does not: ratcheting state between live parties, which buys forward and future secrecy and dynamic group membership. That is the sibling session work, not a weaker version of it delivered here, and until that work lands the honest comparison is between a sealed box and a session protocol rather than between two session protocols.

8.5. Tagged and Capability Hardware

The Burroughs B5000 (1961) introduced tagged memory with hardware-enforced type checks. KeyKOS (Hardy 1985) and EROS (Shapiro et al. 1999) are software predecessors of modern capability OSes. seL4 (Klein et al. 2009) is formally verified and provides strong isolation guarantees. CHERI (Watson et al. 2015) brings capability hardware to general-purpose computing; ARM Morello and University of Cambridge research prototypes demonstrate the approach. The entity system’s capability model operates at a higher semantic level (per-dispatch authorization rather than per-pointer bounds), but the hardware techniques (capability caches, tag bits, bounds checking) are directly applicable for hardware acceleration; The Entity Machine Boundary sketches how an entity-native processor would integrate capability verification into the dispatch pipeline.

8.6. Content-Addressed Security

Git (Torvalds 2005) provides signed commits over a content-addressed object store. IPFS (Benet 2014) uses content identifiers (CIDs) for distributed content addressing. Nix store paths (Dolstra et al. 2004) are content-addressed build outputs. None of these systems integrates content addressing with capability-based authorization at the protocol level; they provide content addressing as a storage / distribution primitive and leave authorization to other layers.

8.7. Limitations of Coverage

This related-work survey is selective. Deeper engagement with the formal capability literature (Drossopoulou and Noble’s reasoning frameworks, the type-systems treatment of capabilities), the MLS draft and its predecessors, the CHERI security model in detail, and the wider decentralized-identity ecosystem would strengthen the comparison. The selections here aim at the structurally closest systems; a fuller survey would expand the comparison without changing the structural argument.

9. Conclusion

The entity system’s security architecture is built from the same six primitives that define the system. Capabilities are entities; identities are entities; revocation is a binding change; encryption wraps entities and preserves their identity. There is no separate security substance because the substrate is the security substrate.

The architecture is structurally distinctive in several ways:

• Four-dimensional grants (handler, operation, resource, peer) cover the per-grant scope axis with uniform pattern matching. They sit inside an eight-primitive authorization structure (the four per-grant scopes plus four per-token primitives: subject, authority, attenuation, and context-temporal, with revocation as a separate lifecycle mechanism). The decomposition is derived in Dimensional Completeness from analysis of the attribute structure of distributed-system requests; the four per-grant axes are a principled subset, not an arbitrary count.
• Attenuation by construction: child capabilities are provably subsets of parents on all four dimensions. Cryptographic chain references prevent amplification without forging an intermediate granter’s signature.
• Tree-based revocation: revoking a capability is unbinding it from the active set. No blacklist accumulation; the IM/TM split keeps audit and revocation on independent emit axes. Generation pools give O(1) scoped mass revocation.
• Self-describing identities: peer IDs are content-derived; peer keypair entities and (when the identity extension is installed) cert chains compose into mini-trees that travel with the peer; algorithm agility is built into three independent format-code namespaces.
• Entity-level encryption: the same encrypted entity on wire, disk, and in memory, with three modes (self, peer, group) covering storage, single-recipient transfer, and shared archives. Authorization and confidentiality are independent dimensions. Interactive session encryption is separate work and is not part of this.

Structurally, security in the entity system lives at the IXP capability triangle (see The Entity System). The triangle’s three pairs (IX, XP, IP) carry the substrate of capability-based security: content-addressed tokens (IX), cross-peer dispatch carrying tokens (XP), content-addressed peer identity (IP). Two of these are phase-transition pairs that require Full I to activate: capability-based security in the entity-system sense is impossible without content-derived identity, regardless of how richly a grant structure is specified. Of the systems analyzed in Convergent Evolution, the entity system is the only one that activates the full triangle simultaneously.

Three open invitations to refute the closure claims sit alongside the model. An authorization need that requires a fifth grant dimension — a request attribute that is not subject, handler, operation, resource, peer, time, or delegation, and that is not expressible through the existing four-dimensional grant plus the token-level fields — would mean the dimensionality is wrong. A revocation scenario that tree-based revocation plus generation pools plus TTL does not cover at acceptable cost would expose a trade-off envelope the mechanism cannot reach; the trade-offs (online vs offline, selective vs mass, immediate vs eventual) are real, and a scenario outside the envelope would be informative. An attenuation attack that amplifies without forging an intermediate granter’s signature would invalidate the cryptographic construction. None has been identified.

Open questions remain. Formal security proofs of attenuation and chain unforgeability are an obvious next step; the discrete, finite structures of the capability model are well-suited to a proof system like Coq or Lean. Production-scale deployment data is the other major gap: the model has been validated in implementations and conformance tests but not in long-running production environments. The encryption work needs implementation experience on the half that exists and a specification for the interactive half that does not. The role extension’s shape needs cross-implementation green-round confirmation. Each of these is in motion; none is a blocker for the substrate-level claims this paper makes.

The security model has been under reduction throughout the protocol’s evolution. The wire format has not changed; the four-dimensional grant has not changed; the tree-based revocation mechanism has not changed. What has changed is the type system around them — new caveat types, new attestation formats, new role-derivation patterns. The pattern matches the broader system’s pattern (see The Entity System; The Entity Core Protocol): the protocol shrinks, the type system grows. Security is no exception.

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.