Convergent Evolution of Information Systems on Content-Addressed Typed Data

1. Introduction

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

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

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

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

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

1.1. A note on corpus and method

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

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

2. The Primitive Combinatorial Space

2.1. Six Primitives as Analytical Basis

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

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

2.2. Partial Primitive Levels

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

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

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

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

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

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

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

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

2.3. Coverage Properties

Fourteen system-level properties emerge from specific primitive compositions:

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

Three composition thresholds mark qualitative transitions:

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

2.4. Pair-Coverage as a Second Analytical Axis

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

Heavy pair-coverage across sample systems:

Several patterns emerge from this scoring:

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

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

2.5. The Coherent Sub-Lattice and the Ridge

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

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

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

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

3. Internal Substructure

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

3.1. Entity: Three Dimensions

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

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

3.2. Identity: Two Dimensions

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

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

3.3. Tree: Three Dimensions

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

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

3.4. Emit: Three Dimensions

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

3.5. Execution: Four Dimensions

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

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

3.6. Peer: Four Dimensions

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

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

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

4. Phase Transitions and Thresholds

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

4.1. Tier 1: Phase Transitions

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

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

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

4.2. Tier 2: Significant Transitions

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

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

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

5. Attractor States

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

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

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

Why attractors are stable:

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

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

5.1. The Layering Trap

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

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

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

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

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

6. The Landscape: Where Systems Stop

6.1. Two-Primitive Systems

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

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

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

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

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

6.2. Three-Primitive Systems

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

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

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

6.3. The Pattern

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

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

6.4. The Composite: What the Standard Stack Leaves Out

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

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

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

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

7. High-Primitive Systems

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

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

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

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

This framing makes the seven engineering walls precise:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.5. Walls Versus Fences

The four high-primitive systems divide into two categories:

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

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

Fences — additive changes, technically feasible without deconstruction:

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

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

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

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

8. The Seed Crystal and the Wall

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

8.1. The Seed Crystal: The EI Pair

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

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

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

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

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

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

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

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

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

8.3. The Wall: Types-as-Data

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

A systematic survey across nine systems confirms the pattern:

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

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

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

9. Why Systems Stop

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

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

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

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

9.2. Force 2: Emergent Property Invisibility

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

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

9.3. Force 3: Social Convergence Friction

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

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

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

9.4. Connection to Reduction

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

10. Composition Patterns: The Named Structural Triangles

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

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

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

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

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

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

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

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

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

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

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

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

11. Reduction Versus Construction

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

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

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

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

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

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

12. Git to Entity System: A Worked Composition Path

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

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

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

12.1. Setup: The Application-Architecture Surface

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

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

12.2. Git’s Application-Architecture Position

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

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

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

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

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

12.3. The Entity System’s Application-Architecture Position

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

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

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

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

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

12.4. The 34-Move Path

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

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

Grouping the 34 moves by primitive:

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

12.5. What the Computation Shows

Three observations follow from the path structure.

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

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

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

12.6. Caveats

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

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

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

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

13. Discussion

13.1. The Pattern

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

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

13.2. The Three Walls

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

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

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

13.3. Connections to Companion Papers

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

13.4. Continued Analysis as the Corpus Grows

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

13.5. Open Questions

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

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

14. Conclusion

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

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

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

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

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

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

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

15. References