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.