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

1. Introduction

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

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

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

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

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

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

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

2. The Compilation Gradient

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

2.1. Stage 1: Entity Compute Graph

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

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

Every expression entity has a content hash. Two independently constructed but structurally identical compute graphs produce the same hash. Identical graphs share a hash as a consequence of content addressing, not as a cache layered on top. The identity of the computation is intrinsic to its structure.

2.2. Stage 2: Partial Compilation

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

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

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

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

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

2.3. Stage 3: Compiled Handler

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

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

2.4. Stage 4: Machine Code

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

2.5. Properties Across the Gradient

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

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

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

2.6. What Cannot Be Optimized Away

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

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

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

2.7. The Purity Boundary and Cross-Compilation

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

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

3. The Bootstrap Evaluator

The bootstrap evaluator is the minimal mechanism that can read a conforming entity tree and begin evaluation. It is the answer to: what is the least a machine must be able to do before the tree can run?

3.1. Design Specification

The bootstrap evaluator is specified by what it must do. The eight operations below are the whole of the obligation, and they are what the rest of this paper means when it refers to the evaluator.

The bootstrap evaluator performs eight core operations:

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

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

1. Byte manipulation: read, write, compare byte sequences
2. Content hashing: SHA-256 at the baseline format code. Whether the function must be cryptographic depends on what the evaluator is for. A bootstrap that reads a tree other peers also address must reproduce their names, so it inherits their choice. A bootstrap producing and consuming a tree only it will ever read needs a function that distinguishes distinct content, which is a weaker and much cheaper requirement. The specification above assumes the first case; the second is discussed below
3. CBOR encode/decode: parse and produce deterministic binary encoding
4. String comparison: match type names and path segments
5. Integer arithmetic: basic operations for expression evaluation
6. Memory allocation: dynamic allocation for entities, scopes, and intermediate results
7. I/O: read from storage (to load the initial tree), write results

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

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

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

3.2. What the Evaluator Is Made Of

Read the eight obligations again and a proportion stands out. Three of them — dispatching on type, reducing expressions, maintaining scope — are evaluation in the ordinary sense. The other five are the substrate’s admission fee: you cannot read an entity without decoding it, cannot name one without hashing it, cannot find one without walking an index, cannot begin without reading the tree off a disk. The bootstrap evaluator is mostly not an evaluator, and that majority does not shrink as the compute language settles, because none of it is about compute.

What bears on the cost is the cohort of complete core-protocol peers generated from the one specification — peers held at core-profile conformance, with the tally and its oracle pin carried by the published conformance matrix rather than here. What stands out is the spread. Across languages that share almost nothing — a stack language, an array language, a logic language, a dependent-type language, hand-written assembly for several instruction sets, and the mainstream set — a complete conforming peer lands between roughly four thousand and fifteen thousand lines, most of the cohort between four and ten. Paradigm moves the figure by about a factor of three among the high-level languages, with assembly at the top. It does not move it by an order of magnitude.

Two things follow, and the first is not about size at all. The convergence of that band is evidence about the specification rather than about any peer: one document, re-derived into dozens of languages, costs about the same everywhere it is built. That is what a tight specification looks like; an under-specified one produces implementations whose size is set by how much each implementer had to invent. The claim needs its scope stated precisely, because it is easy to round up: these peers share a generation lineage, so what the band shows is one specification expressed across radically different languages, not many independent readings of it converging. The languages are genuinely unrelated; the derivations are not.

The second is that the band is a ceiling for this section’s question and not an answer to it. A complete core peer does far more than boot a tree — the wire protocol, the connection handshake, capability verification, the full handler surface, the concurrency and resource-bound floor — and a bootstrap evaluator needs none of it. Where the cost sits inside one of those peers is worth a single figure: in the C member of the cohort, the canonical-form codec and the content store together run to about fifteen hundred lines, with hashing delegated to an audited cryptographic library rather than written. That is the admission fee alone, in a peer that contains no evaluator at all. The compute extension, which a core peer does not carry, exists in all three independent reference implementations and in several of the generated languages besides, each running to several thousand lines in its host language.

So the estimate is a bracket with one end measured and the other open: a bootstrap evaluator is smaller than a complete conforming peer, by an amount nobody has measured, because none has been built. We name no floor. The obligation list above is what a reader can check, and it is what the rest of this paper means when it refers to the evaluator.

3.3. The Components That Cannot Be Entities

Two of the eight obligations resist the treatment the rest of the system gets, and the reason is structural rather than a matter of cost.

The entity system’s general answer to “where should this logic live” is: in the tree, as entity data, so that any conforming peer can execute it. Apply that answer to canonical encoding and it fails immediately. To evaluate a compute expression describing the encoder, the evaluator must first read that expression — which means decoding it from canonical form, which is the thing the expression describes. The same loop closes around hashing: the expression has to be fetched by content hash before it can be evaluated, so hashing is required to reach the description of hashing. These are not extensions that happen to be implemented natively for speed. They are the operations by which the tree becomes readable at all, and nothing inside the tree can supply them.

That argument rests on one load-bearing assumption: that the encoder’s description is fetched and decoded the way any other entity is. Suppose instead that the core carries a small closed namespace of names bound directly to functions rather than to tree entities. Then hash resolves by lookup inside the core, nothing is fetched, and no circularity arises — the function is opaque to the system that calls it. It is a foreign function: addressable by name, opaque to the tree, and outside the evaluator. So the invariant is weaker than “encoding and hashing cannot be entities,” and more useful: some small set of names must resolve without consulting the tree. What those names are bound to is a separate question, and the answers can differ between peers without any of them being wrong.

This is the floor the transferability framework (see The Entity System) marks with its class of spec-fixed natives — algorithms every peer implements identically rather than receiving as data. The classification is load-bearing rather than bookkeeping: it is where “express it as an entity” stops being a move that is available.

A peer built largely from entity-native computation still needs a small native core that speaks encoding and hashing. Whether that core sits inside the system’s boundary or beside it is unsettled, and the cohort has already made the second choice: the C peer delegates hashing to an audited cryptographic library. So not expressible as an entity and must live inside the peer are separate claims, and only the first is argued here — hashing is irreducible as a role, but in production it is a foreign function, not part of the peer. What the core/library interface should be — a privileged handler, a distinct inner evaluator, or an engulfed component that keeps its own machinery while serving the host — is unresolved, and likely matters more to a minimal peer than the size of any one component does.

What is irreducible here is the role, not the algorithm, and the protocol already says so: the hash is selected by a format code, with SHA-256 as the baseline and other digests reachable through the same field. The algorithm is a choice the wire format holds open. The sharper question is one layer down. Content addressing needs an identity function whose output distinguishes distinct content; it needs a cryptographic one because the system is distributed and adversarial, so that no peer can forge a name. Remove the distribution and the adversary — a single-machine entity system used only to compute — and the cryptographic requirement leaves with them while the identity requirement stays. How much of the core protocol is load-bearing for entity computation, as against load-bearing for computation that is also distributed, verifiable and secure, is open, and it bears directly on this section: the two obligations that cannot become entities are also the two where the distributed system’s requirements are doing the work.

The move generalizes past the hash. Stated as roles instead of components — something must make the tree readable, something must give content a name — the obligation list stops naming a particular codec and a particular digest, and it becomes possible to ask of each role whether a given deployment carries it at all. Asked that way, the answers group, and they group in one place. Signing and peer-ID derivation exist to make an assertion checkable by another peer. Capability verification exists to constrain a caller. The compute language’s totality guarantee exists so that an expression arriving from elsewhere cannot fail to terminate here. And the hash’s cryptographic strength exists so that no one can forge a name. Each is an answer to someone else. A machine reducing a tree it wrote for itself has no one else, and the obligations that answer to a second party leave together — which leaves canonical encoding, path resolution, structural traversal, evaluation, and binding, with no cryptographic primitive anywhere in the remainder. That remainder is a question about what a system must carry rather than what a machine must provide, and The Universal Computational Genome takes it up as the genome’s minimal representation.

There is a further question underneath, and it is the one we find most interesting. If a genuinely reduced evaluator exists — something materially smaller than a conforming peer that can nonetheless read the tree and reduce what it finds, and so reconstruct the rest of the system from data — then there is something smaller than the entity system that is as capable as the entity system at the primitive level, since it can represent it. That is the same shape as the relationship this paper’s companion draws between the ribosome and the genome (see The Universal Computational Genome): a small fixed mechanism that the description it reads is sufficient to specify. Whether such a reduction exists for entity computation, and what it would look like, is not something we can settle from the architecture. It is what a first implementation would begin to answer.

3.4. What a Bootstrap Evaluator Alone Gets You

Suppose the evaluator exists and the tree is complete. What then runs — every handler, every type check, every protocol operation — runs by graph reduction, each step decoding entities and walking an index, through an evaluator specialized for none of it. Against a compiled peer doing the same work in native code, that is not a modest penalty. It is the gap between interpreting a description of a computation and performing the computation.

How much content addressing adds on top depends on a boundary no implementation has settled. If every intermediate result must be encoded and hashed into an addressable entity before the next step can refer to it, the penalty compounds sharply. If only results that cross into the tree take that path — the reading the three-region memory model below already implies, where the majority of reductions write to ephemeral state that is never named — the cost tracks the rate of state change rather than the rate of reduction. The two readings differ by a large constant and the paper cannot pick between them; where the emit boundary falls is listed among the open questions for that reason.

The direction is not in doubt even without the factor, and the claim for pure interpretation is correspondingly narrow: it demonstrates that the tree is portable — that a conforming evaluator anywhere reproduces the system’s behavior from data alone. It does not demonstrate that the result is usable. A deployment reaches usable speed by leaving pure interpretation, through the compilation gradient described above. That is why the gradient is part of the architecture rather than an optimization to be considered later.

The same reasoning prices the self-hosting loop. Compiling the system’s own evaluator is work the interpreter must perform interpreted, before any compiled output exists to accelerate it. The first pass through the loop is the slowest thing the system will ever do.

A note on units, since this section has spent its length on quantities it does not supply. “Lines of C” is the wrong unit for everything except the native core, and even there it is a poor one: the same evaluator compiled for a different architecture, or written against a standard library that already supplies half the work, produces a different count for an unchanged design. For the part of the system that is entity data, the unit is not lines at all — a tree is counted in entities, in distinct compute subgraphs, or in bytes of content store, and none of those converts to the others. Of the two, the tree is the larger, and it belongs to The Universal Computational Genome, where it is the genome.

3.5. The Opcode Question

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

The distinction matters: the expression-constructing types are what the programmer writes and the compiler processes; the operational types are intermediate representations the evaluator manufactures, not source-level constructs. An entity-native instruction set would likely need an opcode per expression-constructing type and microcode or internal operations for the operational ones. The size of the expression set is a property of the compute extension and moves with it, so this paper describes the structure of the mapping and leaves the inventory to the extension specification, which is where a reader should look for it.

3.6. Connection to the Fixed Evaluator Insight

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

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

3.7. The Self-Hosting Loop

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

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

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

Hash-based verification changes what replication correctness costs to check. Deterministic compilation means same source entities plus same compiler entities produce the same output hash, so checking a replica is a hash comparison rather than a test-suite run — for the property that the bytes match, which is not the property that the bytes are right.

The self-hosting loop also supports a defense against Thompson’s “trusting trust” attack (Thompson 1984) through diverse double-compilation (Wheeler 2009): compile with Implementation A to produce hash $H_a$, with B to produce $H_b$, with C to produce $H_c$, and compare. The entity system’s three implementations (Go, Python, Rust) are independently written code bases and can serve this role. What their agreement buys is narrower than it sounds. It rules out a backdoor introduced by any one of the three, since the other two would have to reproduce it byte for byte. It does not rule out a defect the three share. They read one specification, and a sentence all three implementers read the same wrong way produces identical output everywhere; they may also delegate hashing or signing to the same audited library, which makes that library one common input rather than three independent ones. Agreement across diverse implementations is strong evidence about the implementations and much weaker evidence about the specification they agree on.

3.8. The Cosmopolitan Pattern

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

[Multi-architecture bootstrap selector]
[x86_64 bootstrap evaluator]
[ARM64 bootstrap evaluator]
[RISC-V bootstrap evaluator]
[Entity tree / content store]                (the actual system)

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

The intuition about such a bundle’s proportions runs the wrong way. The native part multiplies with the number of architectures but is bounded by the obligation list; the entity part does not multiply and is not bounded by anything. A tree carrying the compiler, the type system, the handlers, the protocol, the extensions, and a description of every target architecture is where the bulk of a self-replicating bundle lives, and it grows as the system does. The architecture-specific surface is the small, fixed share. The claim is about ratio and growth, not about either quantity, and neither is measured.

3.9. The Abiogenesis Connection

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

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

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

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

4. Machine Boundary Profiles

Five profiles describe the continuum from pure entity computation to entity-native hardware. Each is independently viable — a valid deployment target with specific tradeoffs between entity-native control and reuse of existing infrastructure.

One question orders them: how much of the machine must the peer provide for itself? Everything a host supplies is machinery the peer does not write and does not control; everything it cannot get from a host is machinery it must write natively, once per platform. The native surface grows down the list and each profile’s surface contains the one above it, which is the structure of the spectrum and what the profiles are for.

This is not the same as asking how much the peer takes from a host, which does not vary monotonically: a compute-only peer takes very little because it does very little, an OS-hosted peer takes a great deal, and a bare-metal peer takes nothing because there is nothing to take it from. The native surface is the axis that orders cleanly, and it is the one that matters for portability. The profiles are described by what they must write, not by how large it comes out.

4.1. Profile 1: Compute-Only Peer

Taken from the host: memory allocation, and a hash implementation to link against. Written natively: the evaluator’s obligations, less I/O. Use cases: embedded systems, WebAssembly targets, formal analysis, testing.

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

4.2. Profile 2: Storage Peer

Taken from the host: the above, plus file or block I/O. Written natively: Profile 1, plus persistence of the tree and content store. Use cases: single-machine entity stores, embedded devices with persistent storage.

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

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

Taken from the host: a full operating system — POSIX syscalls or an equivalent, giving scheduling, memory protection, sockets, the filesystem. Written natively: Profile 2, plus the transport and connection layer. Use cases: the current entity-core implementations (Go, Python, Rust).

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

4.4. Profile 4: Hybrid Kernel

Taken from the host: a kernel interface — the Linux syscall ABI or an equivalent — and the hardware beneath it. Written natively: Profile 3, plus the services a user-space peer would have asked the host operating system for. Use cases: dedicated entity servers, entity-native host environments.

The peer runs as a kernel-level service rather than a user-space application, so work that Profile 3 delegates comes back in-house. A device is reached through a handler instead of through a driver the host owns. Isolation between running work is expressed as capabilities instead of as host process boundaries. The tree is the durable namespace instead of a structure kept inside a filesystem the host manages. These are substitutions rather than translations: the entity mechanism takes over the job the host mechanism was doing, and does that job differently.

This is a deployment profile, not an operating system. It is worth separating from the distributed operating system of DEOS, because the two are often read as the same move and are on different axes. That paper’s subject is a coordination layer — state, dispatch, processes, events, authorization — and it is explicit that it does not abstract hardware: scheduling, memory protection and interrupts stay the host’s job, and its peers run as ordinary user-space processes, which is Profile 3. The profile axis asks a different question: how much of the host does a peer displace. A peer can run that coordination layer at any profile on this list. Moving it to Profile 4 does not make it more of an operating system; it makes it responsible for more of the machine.

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

Taken from the host: nothing. There is no host — only a CPU architecture and the hardware interfaces it exposes. Written natively: everything, up to the limit case where the hardware’s instruction set is entity computation and there is nothing left to translate. Use cases: dedicated entity hardware, FPGA prototypes, entity-native silicon.

Hardware designed to execute entity computation directly. At the extreme end, entity-native silicon would have no translation layer at all — the hardware’s instruction set would be entity computation. The machine boundary disappears because there is nothing to translate between.

4.6. Each Profile Is a Deployment Target

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

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

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

The layer model in DEOS — host OS, then the core protocol, the extensions, the SDK, and applications — is a stack of services, and it is orthogonal to this one. The profiles say where the bottom of that stack sits: at Profile 3 the host operating system is a real layer underneath it; at Profile 4 the peer has taken that layer over; at Profile 5 there is nothing under it but silicon. The stack itself does not change shape as you move down the profiles. The same coordination services sit on a different floor.

5. Entity-Native Hardware Architecture

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

5.1. Three Memory Regions

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

Content store (gigabytes to terabytes, immutable): hash $\to$ entity. Write-once, read-many. Content-addressable memory (CAM) is the natural hardware primitive — lookup by content rather than by address. Because content is immutable once written, lines from the content store are never write-shared: they enter a cache clean and stay clean, so multiple processors read them without coordination and they generate no invalidation traffic. They still occupy cache and are still tracked by the coherence protocol; the saving is in the invalidations that never happen, not in the protocol going away. In a workload where the content store constitutes most of total memory (a reasonable assumption for data-heavy applications), coherency traffic would be limited to the location index. The extent of the reduction depends on the content store/index ratio for the actual workload, which varies. This addresses a recognized bottleneck in conventional multi-core systems, where cache coherency protocols (MESI, MOESI) consume significant bus bandwidth.²

Immutability moves that cost rather than removing it, and the other end of the trade belongs in the same paragraph. Write-once is a property of each address, not of the store: a running system emits new entities continuously and overwrites nothing, so the store is append-heavy by construction and its write bandwidth scales with the rate of state change rather than with the size of the live set. Reclaiming what is no longer reachable is then a garbage-collection problem at main-memory scale, which is why GC policy stays in software in the mapping below. The trade is real: traffic leaves the coherence fabric and arrives at the allocator.

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

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

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

5.2. Why Content-Addressed Data Is Hardware-Friendly

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

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

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

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

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

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

5.3. Entity Instruction Pipeline

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

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

This differs from a von Neumann pipeline (fetch, decode, execute, memory, writeback) in two structural ways. Both need qualifying before they are believable as hardware.

First, type dispatch replaces instruction decoding: the processor routes on the entity’s type rather than on an opcode field. It is tempting to compress this to “the type is the opcode,” and that cannot be literally true. A type is a name, and in the general case a content hash; an opcode field is a few bits of a fixed-width instruction word. A real design needs a narrow tag, assigned to the expression-constructing types, resolved once as an expression enters the pipeline and carried with it thereafter; the table below lists the types such a tag would range over. What survives is the weaker claim: the encoding is derived from the type system rather than designed independently of it, so there is no instruction-set design separate from the data model — but an encoding layer does exist.

Second, the final stage is emit — store the content, bind the path, raise the events — rather than memory writeback. Taken literally this sinks the design. Emit hashes its content, and hashing is on the order of a hundred cycles per block even with a dedicated pipeline, not one. A machine that emitted at every reduction step would spend nearly all of its time hashing intermediate results that nothing will ever address. The workable reading is the one the three-region memory model already implies: the great majority of reductions write to ephemeral evaluation state, which is core-local, unhashed, and discarded, and only results that cross into the tree take the emit path. Emit is the pipeline’s exit into the entity model, not the retirement stage of every instruction. Where that boundary falls — which results are tree-crossing and which stay ephemeral — is a design question the compute extension’s purity model bears on and that no implementation has settled.

There is a third objection that arrives before either of those, and calling it a pipeline invites it: the stages do not have fixed or equal latency. FETCH and OPERAND_FETCH both resolve content by hash, and what that costs depends on where the entity is — a hit in an associative cache, a DRAM round-trip, or a miss that reaches storage. A classical pipeline earns its throughput by keeping every stage busy every cycle, and this one cannot. Whatever the real design turns out to be, it is closer to a scheduler over variable-latency operand fetches than to a fixed six-stage march, and the six stages name the logical sequence an expression passes through rather than a cycle budget. What that costs in scheduling hardware, and whether the structural prefetch described above recovers enough of it to matter, is exactly the kind of question an FPGA prototype exists to answer and architectural reasoning cannot.

The tag assignment takes the shape below on the core expression types (see “The Opcode Question” above for the distinction from the operational types the evaluator produces during reduction). This illustrates the mapping’s structure on the types every program uses; it is not the extension’s full inventory, which also covers array and collection operations and is carried by the specification rather than by this table:

5.4. Capability Verification in Hardware

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

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

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

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

5.5. Layer-by-Layer Hardware Mapping

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

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

Garbage collection sits on the line rather than on one side of it, and the distinction is between policy and mechanism. Choosing what to reclaim is heuristic and belongs in software. Performing the reclamation does not: the Reduceron places garbage collection in the FPGA fabric alongside the reduction hardware (Naylor and Runciman 2012), and later work in the same line implements a concurrent collector for non-strict languages directly in hardware. A design that assumed the whole of GC stays in software would be assuming more than the evidence supports.

5.6. Performance Inversion Hypothesis

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

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

Potentially von Neumann still wins: sequential arithmetic on large arrays (conventional ALUs optimized for this), large contiguous memory scans (DRAM burst mode), execution of legacy code (by definition), workloads that are purely sequential with no content-addressing benefit, and write-heavy workloads with high churn — where immutability turns each update into an allocation plus a hash, against a mutable store’s overwrite in place.

The hypothesis is bounded: for workloads matching the entity computational model — content-addressed data, typed dispatch, capability-scoped operations, reactive cascades — translation overhead on von Neumann hardware may be the dominant cost, and removing that translation could recover significant performance.

The hypothesis is older than this paper and has been partly tested. Naylor and Runciman’s Reduceron widened the von Neumann bottleneck for graph reduction on an FPGA and measured the result, finding the gain came from parallel and wide memories rather than from clock rate (Naylor and Runciman 2012). More recently, Heron performs several times more reductions per cycle than a mature software runtime on a processor clocked more than twenty times faster, and reaches competitive wall-clock performance at substantially lower energy (Ramsay and Stewart 2023). Graph reduction is what the bootstrap evaluator does, so this is the closest available evidence and it points the way the hypothesis predicts.

It is also narrower than the hypothesis. Those results concern the reduction engine; they say nothing about the content store, and that is where the counter-evidence sits. Three independent systems converge on the same finding, and it is not the one this paper has been treating as the risk: the cost of content-addressed operation at scale falls on the index, not on the hash. The Manchester dataflow machine matched every token against a global associative store and that store was its bottleneck (Gurd et al. 1985); Venti reports random-access index lookups, rather than its sequential data log, dominating cost (Quinlan and Dorward 2002); and the hash-indexed memory substrates proposed as CAM’s replacement carry bucket overflow and re-hashing as their characteristic overhead (Cho et al. 2007). Foundation matched Venti’s storage efficiency on far cheaper hardware primarily by avoiding index lookups rather than by accelerating them (Rhea et al. 2008).

That convergence sharpens the emit-boundary question from a design detail into the question the memory architecture turns on. The dataflow machines matched every intermediate; a design that hashes and indexes only what crosses into the tree is making exactly the choice their history argues for. Whether this hypothesis holds is what implementation and benchmarking would determine, and the three memory regions are where the doubt should be concentrated.

5.7. Feasibility Path

An incremental approach to entity-native hardware:

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

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

6. Machine Architecture as Entity Domain

At Profile 4 and above, the machine architecture itself is described as entity types in the tree. This is not a convenience. Without it, the system’s self-description stops short of the machine it runs on.

6.1. Architecture as Type Definitions

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

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

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

6.2. Multi-Architecture Compilation

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

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

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

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

6.3. The Entity ABI

Traditional operating system concepts map to entity equivalents:

This mapping is not metaphorical — it is operational. The entity ABI replaces the traditional OS ABI. A “process” is a peer. A “file” is an entity at a tree path. An “open” is a tree get. A “write” is an emit. The entity system does not simulate these concepts; the six primitives provide them directly, typed and content-addressed like everything else.

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

6.4. The C/Unix Co-Evolution Parallel

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

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

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

6.5. Entity-Native Virtualization

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

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

7. Related Work

7.1. High-Level Synthesis

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

7.2. Content-Addressable Memory

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

7.3. Tagged and Capability Architectures

The Burroughs large-systems line pioneered tagged memory. The B5000 (Lonergan and King 1961) carried tags on control words rather than on every word; a three-bit tag on each word arrives with the B6500 (Mayer 1982). The entity system’s type dispatch at the pipeline level is a descendant of this idea, extended from word-level tags to full structural types.

Two details of that line bear directly on the architecture proposed above. First, the hardware dispatched on data rather than on an opcode: a single ADD instruction, with the operand’s own tag selecting the variant (Mayer 1982). Type dispatch in place of instruction decoding is therefore not a novel arrangement — it shipped commercially. Second, and more useful, is what it cost. Tag-driven polymorphic operators required fewer opcode bits but made the hardware, in Mayer’s description, more like an interpreter, with less opportunity to pipeline the common cases. That is the same objection this paper reaches on architectural grounds when it observes that the six stages cannot hold a fixed cycle budget. The historical record confirms the derivation rather than merely illustrating it.

A third property of the line is a distinction the entity system draws in software. Tag parity partitioned memory into words a user program could modify and words the hardware owned, and the specification of the latter was free to change between implementations without recompiling user code (Mayer 1982) — the platform-native and transferable classes of The Entity System, enforced in 1960s silicon.

CHERI (Watson et al. 2015) (Capability Hardware Enhanced RISC Instructions) implements capability-based security in hardware, with the ARM Morello prototype demonstrating practical capability enforcement at pointer granularity. Entity-native capability verification operates at a higher semantic level — per-dispatch authorization over per-pointer bounds — but the hardware techniques (tag bits, capability caches, bounds checking) are directly applicable. Morello has since been characterized on real workloads, which puts a price on applicable: worst-case overhead reaches roughly 1.65×, and it is dominated by the doubled pointer width, not by the capability checks themselves, with store queues sized for 64-bit values a named bottleneck (Sun et al. 2025). Checking once per dispatch rather than once per pointer is what would keep that cost off the critical path — a difference in granularity, not in kind.

7.4. Self-Hosting and Bootstrapping

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

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

7.5. Virtual Machine Design

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

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

7.6. Smart NICs and DPUs

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

8. Discussion

8.1. The Gradient as Structure-to-Activity Transition

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

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

8.2. The Evaluator Regression and Physical Grounding

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

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

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

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

8.3. What Entity-Native Hardware Would Prove

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

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

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

8.4. Open Questions

Several questions bear on the claims in this paper:

• CAM scaling: The entity-native hardware analysis assumes content-addressable memory can scale to millions-to-billions of entries. Current TCAM scales to millions. Whether scaling breaks down due to power, density, or cost constraints is the primary open question for entity-native hardware. If it does, a different approach to content-store implementation (such as CAM-indexed DRAM) would be needed.
• Opcode completeness: The expression opcodes derive from the compute extension’s expression-constructing types. Whether that set is complete, or whether an additional primitive expression type would be needed for some class of programs, is a design question that implementation will settle.
• Where the emit boundary falls: which reduction results cross into the tree — taking the full store-bind-event path, and paying a hash — and which stay in ephemeral evaluation state and are discarded. This is the difference between a pipeline that hashes once per instruction and one that hashes at boundaries, and therefore between a design that cannot work and one that might. The compute extension’s purity model constrains the answer; no implementation has settled it.
• Write bandwidth under immutability: a store that is append-only by construction trades coherence traffic for allocation traffic. What the sustained write rate and reclamation cost look like at main-memory scale is unexamined, and it is the counterweight to the coherence argument rather than a detail beneath it.
• What the bootstrap actually costs: not only its size, but what a cold peer has to do before it is useful. A peer holding a bootstrap evaluator and a tree is an interpreter of a description of a peer; reaching ordinary operating speed means running the compilation gradient, and running it interpreted. Whether that settles in seconds or is a serious obstacle is unknown, and it is close to the first thing a prototype would report.
• The peer expressed in its own compute language: whether a core protocol peer can be written as compute subgraphs in the tree and hosted by an ordinary peer that carries the compute extension — a virtual peer whose handlers, dispatch and type checking are all entity data, running on a real one. This is the cheapest experiment on this list, because it needs no new native code: the host already exists, six times over. It would answer directly how much of a peer is expressible as data, which is the transferability claim stated as a build rather than as an argument. And it is the step that makes the reduction question askable — with a peer running as compute subgraphs, what the host underneath still has to provide is no longer a matter of decomposition but of deletion, one obligation at a time, until it stops working.
• Compilation gradient completeness: Whether the four stages form a complete gradient, or whether a distinct compilation level exists between the stages described, is an open structural question.

8.5. Limitations

Several limitations should be noted:

• No implementation evidence. No bootstrap evaluator has been implemented. No architecture type definitions exist in any entity tree. No entity-native compiler handler exists. No FPGA prototype has been built. The paper describes a design specification, not measured results. It is classified as Tier 3 / Phase 3 specifically because it needs implementations.
• Hardware feasibility is unvalidated. CAM scaling, power consumption, pipeline stall analysis, and the economics of entity-native silicon are all open questions. The architectural analysis is sound, but architecture is not implementation.
• The opcode count is design-level. The gap between the expression-constructing types (which an opcode set would mirror) and the operational types the evaluator produces reflects a design distinction that implementation may collapse or expand; the compute extension’s type inventory is itself still settling.
• Performance claims are structural, not measured. The performance inversion hypothesis (entity-native potentially wins vs. von Neumann potentially still wins) is derived from architectural reasoning about the computational model’s properties, not from benchmarks or implementation experience.
• Related work gaps. The engagement with CHERI, TCAM specifications, functional hardware synthesis, and tagged architecture history is based on published descriptions rather than deep technical analysis. A fuller treatment would require implementation-level comparison.
• Generated under prompt-and-review. This paper, like the rest of the corpus, the supporting implementations, and the architectural specifications, is LLM-generated under direction from the author. The author provides prompts, evaluates outputs, redirects, and approves — text, code, and design refinements are generated rather than directly authored. The methodology this enables is described in The Entity Core Protocol.

9. Conclusion

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

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

Five machine boundary profiles describe the deployment continuum, ordered by how much of the machine the peer must provide for itself:

Each profile’s native surface contains the one above it. That containment is the structure; absolute sizes are not something the analysis can supply.

A bootstrap evaluator suffices to boot the full system from a conforming tree, performing eight core operations over seven irreducible machine-level primitives. Two of the eight — canonical encoding and content hashing — cannot be moved into the tree, because they are what makes the tree readable. The self-hosting loop, once completed, enables the system to compile its own evaluator, verify its output by hash, and replicate to new architectures.

Entity-native hardware would naturally separate into three memory regions, with the immutable content store particularly suited to content-addressable memory — though immutability moves the cost from the coherence fabric to the allocator rather than removing it. The six-stage instruction pipeline takes its opcodes from the compute extension’s expression-constructing types, distinct from the operational types (closure, scope, result, error) that arise during evaluation, and its emit stage is the exit into the entity model rather than the retirement stage of every instruction. The machine architecture itself, described as entity types in the tree, enables multi-architecture compilation from a single source and closes the self-description loop.

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

Open questions:

• Can the bootstrap evaluator be implemented and measured — both its size and the time a cold peer needs to become useful?
• Is CAM practical at content-store scale, or do hybrid approaches (CAM-indexed DRAM) prove necessary?
• What are the performance characteristics at each compilation stage? Where does the translation overhead dominate?
• Can the self-hosting loop be completed — the system compiling its own evaluator from entity-native source?
• Would an FPGA prototype validate or invalidate the performance inversion hypothesis — that translation overhead dominates for entity-matching workloads?