Application Architecture on Content-Addressed Typed Data: A Design Space

1. Introduction

An application on the entity system does not have one shape. A content site is a body of typed entities a peer serves, and another peer can verify and re-host it without asking anyone’s permission. A version-control tool is a command-line program that boots a peer, runs its commands against the substrate, and exits — the person using it need never know a peer was involved. A collaborative workspace is several peers wired together, one of them holding the durable record the others never see directly. These are not three variations on a template. They are three points in a space, and the coordinates a developer chooses are the architecture.

The questions that fix a coordinate are few. How much of the substrate does the application stand on — the bare core protocol, or the core plus some chosen extensions? What is the application: entities the substrate runs directly, a binary in a host language that wraps a peer, a composition of several peers, or direct use of the system’s services the way one uses a filesystem? How is it deployed, how long does it live, how much identity does it need, and in which language is it written? Each answer carries consequences — in inspectability, in distribution, in what the application has to build versus what it gets for free — and a finished application is the conjunction of all of them. The work of application architecture here is choosing a location and knowing what that location gives you.

The starting point is higher than it sounds. A bare core-protocol peer is already an application: it has a typed, content-addressed store, capability-based access control, and a cryptographic identity, reachable through one dispatch operation. You do not assemble those; you start with them. Adding an extension does not wire in a subsystem so much as raise the floor — the revision extension gives the application a version history, the subscription extension gives it reactivity, and the application’s own code never implements either. Most of what a conventional application spends its effort integrating is, here, inherited from where it stands.

The system is not only peer-to-peer, and reading it as “a distributed-systems thing” mistakes one region of the space for the whole. A developer can run a single peer on one machine and never open a socket, because the programming model is reason enough to use it. Another can build an ordinary web application whose backend is a database peer and whose frontend talks to it — the familiar three-tier shape, with the tiers happening to be peers. A third can federate across administrative boundaries. All three install and run the same substrate; what differs is how many peers there are and how they are wired. The peer is the unit you deploy, and the topologies it composes into are the ones enterprise architecture already has names for.

Two properties make building here different from building on a conventional stack, and both recur through the paper. The first is inheritance: at a given depth in the substrate, an application is handed capabilities it would otherwise stitch together from separate tools — content-addressed storage with automatic deduplication, versioning, audit, reactivity, durable workflows, fine-grained authorization — so the developer writes domain logic and not the integration between a version-control system, a message queue, a cache, and an authorization service. The second is that the contract is the protocol itself, not a language or a runtime. A peer is anything that speaks the wire format correctly; the Keystone effort has generated conformant core-protocol peers in six more languages — from a managed-runtime actor store to no-garbage-collector systems code — each checked byte-for-byte against the specification by a conformance oracle rather than by sharing code. An application architect picks the language; peers written in different ones interoperate exactly.

We are honest about where this stands. The substrate is real and the patterns in this paper are drawn from working code, but the developer tooling and the SDKs are still in motion, and where the ergonomic layer will finally land is not settled. The reference applications named throughout — a content-site format, a version-control tool, an interactive workbench — are how the patterns were found and proof that they hold; they are reference implementations, not products, and whether they are the best way to build on the substrate is a question the paper leaves open on purpose. The system is offered as something to build on, and the shape of what gets built on it is, deliberately, not yet decided.

1.1. The Boundary with the Operating-System View

There are two ways to look at the same standard peer, and this paper takes one of them. Viewed as an operating system — kernel services, the shell, deployment across a network — the standard peer is the subject of DEOS, which calls that view DEOS. That is the system you run on: what coordination it provides, how its services map to the ones an operating system provides, how it scales. This paper is the complement: the application you build on it. The two share a vocabulary — peers, compositions, the extension set — but ask different questions. Paper 7 asks what the environment is; this one asks what shapes an application takes within it, and how a developer chooses among them.

The core protocol itself, the substrate both views rest on, is The Entity Core Protocol; the six primitives that generate it are The Entity System. A point worth keeping in view from the start, developed in those papers and sharpened as the protocol settled: the core is a substrate, not a system. It ships a small set of live hooks — register a handler, dispatch outward, observe the emit pathway, check a capability, connect — and does not dictate what is layered on top. The extensions this paper leans on are one coherent set of choices over that substrate, the set the architecture ships; they are not privileged by the core, and a community could build a different set. That is the deepest reason application architecture here is a space rather than a single stack: the substrate is designed to be built on in more than one way, and choosing how is the architect’s job.

1.2. What This Paper Covers

The paper is organized around the design space and the choices it offers:

1. The space and its axes. The dimensions a developer chooses along, and how the entity-system-shaped ones (substrate depth, form, topology, deployment mode, lifetime, identity depth, language) sit against the universal concerns every application has (where it runs, how it displays, how a user interacts with it) — including an honest account of which of those the substrate does not yet address.
2. What a location inherits. The properties an application gets for free at a given substrate depth, and how different locations lean on different ones.
3. The forms of an application. Entities the substrate runs, a binary that wraps a peer, a composition of peers, and direct service use — the four embodiments, how they combine, and how their topologies map to client-server, N-tier, and service-oriented shapes.
4. The application lifecycle. Boot, load, run, and exit for a peer that is a program; one-shot, long-lived, and persistent-restartable lifetimes; how identity depth is chosen.
5. The programming model, and language agnosticism. Writing application logic as content-addressed computation, the gradient from inspectable to compiled, and the protocol-as-contract property that lets a peer be written in any language.

1.3. What This Paper Does Not Cover

The six primitives and the build-up sequence are in The Entity System; the protocol wire format, dispatch, and capability mechanics in The Entity Core Protocol; the computational model in The Entity Church Architecture; the compilation gradient and machine boundary in The Entity Machine Boundary; the landscape of existing systems in Convergent Evolution; the operating-system view of the standard peer in DEOS; and the security architecture in Entity System Security Architecture. We assume the primitives and the extension set from those papers and do not re-derive them.

1.4. Scope Discipline

The core protocol is stable; the substrate-bridge extensions are the architecture-supplied set over it, with three reference implementations (Go, Python, Rust) at conformance parity on the core surface, and the broader multi-language realization is the Keystone effort. The operational tier a multi-peer deployment needs — identity, attestation, network, and others — is partly mature and partly still specified, and we mark which is which where it matters. The application-level conventions this paper draws on — a content-site format, the peer-composition catalog, an HTTP bridge — are mostly recent and still in draft; we cite them as drafts, not as settled standards. The aim is to be useful to a developer deciding how to build, with the maturity of each piece stated plainly rather than smoothed over.

2. The Design Space

Every application, on any platform, has to answer a few questions that have nothing to do with the entity system. Where does it run — a server, a laptop, a phone, a browser tab? How does it show itself — a window, a terminal, a web page, no surface at all? How does a person act on it — a click, a keystroke, a request, a command? These are the universal questions, and they are answered the same way they have always been answered, because the substrate has no opinion about most of them.

It is worth saying plainly which of these the entity system does not yet address. It does not provide a display layer. There is no entity-native windowing, no standard way to draw a button. The reference applications that have a graphical surface — the workbench discussed later — built that surface themselves, in the host platform’s UI toolkit, and an application that wants a screen does the same or falls back to whatever its language already offers. The substrate shapes where an application’s data and computation live and how its parts coordinate; the pixels are still the developer’s problem, and a paper that pretended otherwise would mislead.

What the substrate does shape is a smaller, sharper set of choices, and those are the axes of the design space. They are independent: a choice along one does not fix the others, and an application is a point across all of them.

The rest of the paper walks these axes. The form axis carries the most weight for a reader new to the system, because it answers the question that confuses people first — what is an application here, concretely? — so it gets its own section. The others are developed where they do the most work: substrate depth in the discussion of inheritance, lifetime and identity depth in the lifecycle, language in the programming model.

2.1. Where the Familiar Shapes Sit

A developer coming from conventional practice already has a vocabulary for arranging an application: a LAMP server, a client and a server, three tiers, a fleet of microservices, a service-oriented architecture with a bus in the middle. None of that vocabulary is wrong here, and none of it is replaced. It maps onto the topology axis directly, because the entity system’s unit of deployment — the peer — plays the role those architectures give to a process, a service, or a tier.

The mapping is close enough to use as a guide. A single peer on one machine is the local application, the desktop tool, the thing with no network at all. A frontend talking to a backend database peer is client-server, and adding an application-logic peer between them is the classic three tier. A set of interchangeable peers behind a router is a service pool, which is what a horizontally scaled service or a microservice deployment is. A federation across administrative boundaries is the wide-area, multi-organization case. What the entity system changes is not the shape but the seams: where those architectures wire their tiers together with REST, a message bus, and a database protocol — each its own format, each its own authorization story — the peers in an entity-system deployment speak one protocol, carry one kind of typed content, and authorize every operation the same way. The arrangement is familiar; the integration between the parts is not there to build, because the parts already share a substrate.

So the design space is not exotic. It is the application-architecture decisions a developer already makes — how to structure the thing, how to scale it, how the pieces talk — with a different and smaller set of consequences attached to each decision, because the substrate underneath every region of the space is the same.

3. What a Location Inherits

The single property that most distinguishes building an application on the entity system is that a location inherits. Stand at a given depth in the substrate, and the application is handed capabilities that, on a conventional stack, it would assemble from separate tools and wire together by hand. The bare core protocol already gives every application a typed, content-addressed store and capability-based access control. Each extension installed above it raises the floor again, and the raising is the point: the extension is a service the application uses, through the same dispatch as everything else, not a component the application contains.

What this collapses is the integration layer. A conventional application of any size assembles a version-control system for history, a message queue for events, a cache, a database, an authorization service, and a sync mechanism, and then spends much of its engineering on the wiring between them — the part where the formats disagree, the authorization models don’t compose, and the operational complexity accumulates. On the entity system those concerns are properties of where the application stands:

• Content-addressed storage with deduplication. An entity’s identity is derived from its bytes, so two identical things are the same thing, stored once. The application gets a cache whose invalidation is structural — the content hash is the key — without a caching layer.
• Versioning and audit. The store is immutable underneath a mutable namespace, so every prior state remains addressable. The revision extension turns that into a version history with three-way merge; the history extension turns it into a per-path log. Undo, audit, and provenance are not features the application builds.
• Reactivity. The subscription extension delivers an event when a path changes; the compute extension lets a value be defined as an expression over other values and re-evaluated when they change. Together they are a spreadsheet over content-addressed data: the application states a relationship once, and the substrate maintains it. A live view, a running metric, a cache that refreshes itself — each is an expression, not a pipeline.
• Durable workflows. The continuation extension records a multi-step process as entities in the tree, so a workflow survives a restart without a workflow engine.
• Asynchronous messaging. The inbox extension delivers a message to a peer that may be offline, so coordination between parts does not need a separate broker.
• Authorization. Every operation carries its own capability, checked before the handler runs; access is granted by handing out attenuable, revocable tokens rather than by maintaining an access-control list. The authorization model is the substrate’s, not a service bolted beside it.

Different locations lean on different parts of this. A collaborative editor lives on reactivity and versioning; a data pipeline on durable workflows and content-addressed computation; a content site on chunked storage and the embed format built over it. The substrate supplies all of it, and the application’s character is partly which inherited properties its handlers actually drive — a point the worked locations later make concrete.

Inheriting is not the same as having the problem solved, and it would be dishonest to suggest otherwise. The properties are there, but composing them into a particular application still takes design judgment: which extensions, wired how, with what capability boundaries. The reactivity has limits on how far a change cascades; the workflows have failure modes; the merge has cases a domain has to resolve. And the layer that would make all of this ergonomic — the SDKs, the higher-level patterns, the tooling — is in development, so a developer today works closer to the substrate than they eventually will. What the location gives you is a high floor. What you do from there is still architecture.

4. The Forms of an Application

Ask a developer from any background what an application is, and they have a ready answer — a process, a service, a binary, a page. On the entity system the question has four answers, and choosing among them is the most consequential coordinate in the space. They are not exclusive; a real application usually combines them. But they are genuinely different kinds of thing, with different inspectability, different visibility to their users, and different ways of shipping.

4.1. Entity-Native: The Application Is Data the Substrate Runs

The purest form has no binary of its own. The application is a body of entities, and the substrate already knows how to run them. A content site is the clearest example: a site is a manifest entity, a set of page entities, and a signed root that pins the whole subtree to its publisher’s identity, with media carried by a generic embed format layered over content storage. There is no server to deploy. A peer holds the entities; another peer fetches them, verifies the signature and the hashes, and re-hosts the site without coordinating with anyone, because the bytes carry their own identity. A repository of version-controlled files is the same kind of thing — typed entities under the revision extension — and so is a shared space.

What makes this form possible is that the substrate dispatches by what an entity is, not by where it sits. A handler is found through the system’s handler registry against an entity’s type, not against a path, so where an application puts things is a convention rather than a mandated location: paths are a convenience, and the entity graph is what carries coherence. An entity-native application is therefore defined by its types and the handlers registered for them, and a developer reads it the way they read data, because that is what it is. The cost is that this form reaches exactly as far as the substrate’s own evaluation: pure entity-native applications are maximally inspectable and transferable precisely because there is nothing in them but substrate. The conventions that standardize these forms — the content-site format, the embed format — are recent and still in draft, and we treat them as such; what is settled is that the form exists and the substrate runs it.

4.2. Wrapped Binary: A Program That Happens to Be a Peer

The second form is a program in an ordinary host language that uses the substrate as a library. From the outside it is a command-line tool, or a desktop application, or a service — something with a normal surface that does a normal job. Inside, it boots a peer, does its work as dispatches against the substrate, and presents the result through whatever interface it offers. A person using a version-control tool of this shape runs the commands they expect; they need never learn that a peer was created, that their files became content-addressed entities, that the history is a revision DAG. The peer is an implementation detail.

This shape was not designed so much as discovered. Two reference tools — one that publishes a peer’s content to a static origin, one that puts a version-control workflow over the revision extension — were built independently, and they turned out to be the same program with different verbs. Both boot a peer pointed at local resources; both reach the outside world through bridge handlers for the standard streams; both root their authority in a keypair on disk and attenuate from it; both render their output by dispatching through that bridge and translate a typed error into an exit code. The recurring skeleton — boot, bridge, identity, capability root, output convention, error-to-exit — is the wrapped-binary form, and finding the same skeleton in two tools built for different jobs is the evidence that it is a real pattern rather than one program’s accident.

4.3. Peer Composition: The Application Is Several Peers

The third form is more than one peer, wired together. A peer here is a full configuration — an identity, the handlers and extensions it has installed, the capabilities it holds and has issued, its tree, its live continuations and subscriptions, its operational state — and a composition is a family of such peers, coupled by capability grants and by who is subscribed to whom, that together produce something no single peer does. The architecture catalogs seven recurring ones: an operational peer that holds durable state outside the peer doing the work; an observer that watches without being able to interfere; a service pool for scale; a hub-and-spoke for coordination; a recovery cluster for identity that survives key loss; a bridge between two domains that do not trust each other; and a compute pool that isolates expensive work. Each is a configuration of the existing primitives, not a protocol feature, and each is named so that teams converge on the same vocabulary.

A composition can be deployed in either of two modes, and the mode is a property of the deployment, not of the composition. In the flat mode, every peer is equally visible — a federation, a public mesh. In the other, one peer presents a single identity to the outside while the supporting peers are invisible infrastructure: an external client sees one application, and the durable-state peer or the compute pool inside it is not on the public surface at all. The architecture borrows the cell for the picture — one organism outside, a cooperative interior — and the reference workbench is the existence proof: you inhabit one peer, and the operational peer keeping its durable record is not something its users ever address.

What keeps a composition alive rather than deadlocked is a property the catalog rests on: no single component can stall a peer indefinitely — a saturated path surfaces an error to the caller, never an unbounded block. Compositions that would otherwise form a reactive cycle, where two peers each wait on the other’s changes, are kept safe by a design rule on how the coupling is wired rather than by a runtime check. Both of these are recent, and the liveness property is not yet in the normative specification; we present the catalog as the draft guidance it is, sound in the implementations that hold the property in practice.

4.4. Raw Service Use: The Substrate as a Tool

The fourth form is barely an application in the usual sense, and naming it is mostly to bound the space. A developer can use the substrate’s services directly — list a tree, fetch an entity, run a query — the way one uses a filesystem from a shell. One does not usually call a program that navigates a filesystem an “application”; these are the system services that the operating-system view (see DEOS) provides, and a tool that simply exercises them sits at the floor of the design space. It matters because it is where the other forms begin: every wrapped binary and every composition is, underneath, raw service use with structure built on top.

4.5. How the Forms Combine

The forms are axes, not boxes. The wrapped version-control binary operates on an entity-native repository: a program in the second form whose data is in the first. A peer composition can present as a wrapped binary: an internal mesh behind one command-line surface. A content site is entity-native data that a wrapped publishing tool put in place and a wrapped browser reads back. A real application picks a value on this axis for each of its parts, and the interesting ones usually pick more than one. The worked locations later in the paper read several reference applications as exactly these combinations.

5. The Application Lifecycle

The operating-system view assumes a peer is a daemon: it starts, holds its subscriptions, reacts forever. That is the right default for a distributed substrate, but it leaves out the shape most developers reach for first — write a program, run it, get output, exit. Supplying that shape is its own coordinate, and it is one the OS view does not address.

A program, in this setting, needs no new machinery. It is an entity subgraph: an entry-point entity at a known path that the runtime knows how to dispatch, the code it runs (a compute expression, a handler, or a chain), any static data it reads, and the capabilities it needs to touch what it touches. That is the same shape as everything else in the tree; a program is just an entity subgraph with an entry-point convention and a capability story. What a run-mode adds is an execution convention over that data: a peer that boots, loads the program subgraph into its store, dispatches the entry point, bridges whatever the program produces to the outside, and exits when the program is done — rather than staying up and reacting. Boot, load, dispatch, output, exit.

Two more coordinates sit on this lifecycle. The first is lifetime. A one-shot peer runs a program and exits; it may not even want a durable identity, minting an ephemeral keypair for the run and discarding it. A long-lived service stays up and reacts. A persistent, restartable peer stops and starts again with behavior equivalent to one that never stopped, which is what a deployed application that must survive a crash requires. The second is identity depth, and it is a real choice rather than a default. A peer always materializes a root authority over its own namespace at startup, but how much identity it builds on top is up to the application: a bare keypair gives the full capability system, rooted in that one key, and nothing more; the full identity stack adds recovery, attestation, and quorum, at the cost of the machinery to run them. Many applications want the keypair and stop there. The capability system does not depend on the rest; the rest is for the applications that need to survive a lost key or prove who they are to a stranger.

The smallest example that exercises the whole substrate is deliberately not the hardest one. It is a one-way mirror. One peer holds a program; a second peer, with no copy of it, pulls the program subgraph across using the ordinary revision mechanism, dispatches its entry point, prints the result, and exits. No shared mutable state, no merge, no convergence to negotiate — just clone and run. It touches identity, transport, the content store, evaluation, the output bridge, and the exit condition, all on primitives that already exist, and it is the closest thing the system has to a hello-world that shows what it is for: a program is content, content moves between peers by identity, and a peer that receives it can run it.

6. The Programming Model, and Language Agnosticism

Underneath the forms is the question of how an application’s logic is actually written. The substrate’s answer is that computation is data: a program fragment is a content-addressed expression, an entity like any other, and the compute extension is its intermediate representation. Authoring is a stack of rungs over that representation. At the bottom a developer can write the expression entities by hand. Above that, a builder in the host language assembles them with the types checked. Above that, a lowering toolkit turns higher-level constructs into the canonical expression shape; and a surface syntax over all of it is deferred until the lower rungs show what it should target. The honest state is that the lower rungs work and the upper ones are in progress.

A handler’s logic is realized in one of three ways, and the choice is the application architect’s. It can be a precompiled service the system ships; it can be host-language code registered through the SDK, which is the common case and the pragmatic one; or it can be an entity-native expression the substrate evaluates directly. These line up with a gradient from fully inspectable to fully compiled. An entity-native expression is data — every intermediate step is an addressable entity, so the computation can be walked, replayed, and content-addressed — and it pays for that visibility in speed, since the substrate interprets it. A host-language handler is opaque to the entity model but fast, and the dominant idiom in practice is to drop down to it for the parts that need speed while keeping the rest as expressions. A developer can place each component where it needs to be on this gradient, and move a component along it later without changing how the rest of the application calls it, because the interface is the same typed dispatch at every stage. Much of the gradient beyond the inspectable end is designed rather than built; the compute representation is foundational and present, the compilation that would make it fast is largely future work, and we say so.

One more thing about surfaces. An application built on the substrate tends to grow several — a command line, a graphical panel, an embeddable library — and these are not separate programs. They are renders of one underlying shell, the way the shell is itself a render of the SDK and the SDK a render of the protocol. The logic lives once, in handlers and expressions; a surface is a presentation of it. This is why the reference workbench can offer a terminal interface and a graphical one over the same core without building the application twice, and it is the reason these are not, despite the name some of them carry, “just terminal apps.” It is also where the display gap from earlier returns: the substrate carries the surface down to the logic, but the logic up to the pixels — the actual drawing — is still the host platform’s job.

Then there is the language, and it is the property that most clearly separates the entity system from a framework. Rails is Ruby, Django is Python, Spring is Java; the framework and the language come together. Here the contract is the protocol, not a language and not a runtime. A peer is anything that produces and consumes the wire format correctly, and “correctly” is decided by a conformance oracle that checks bytes against the specification, not by sharing an implementation. The Keystone effort makes this concrete: from one specification it generates full core-protocol peers for a target language, and the cohort now spans dozens of them, alongside the three reference implementations in Go, Python, and Rust. The cohort deliberately reaches idioms that ordinarily share nothing — a managed-runtime actor store on one, no garbage collector and explicit allocation on another, a dynamic image-based system on a third. They converge to the same bytes against the same vectors. The generated peers share a generation lineage, so they are not independent implementations and are not counted alongside the three; what they establish is that the specification is precise enough to realize mechanically, which is the property an application architect is actually relying on here. Protocol convergence of this kind is decidable and has been demonstrated; it is the proven half of the system’s story. The other half — whether people adopt it, build on it, and converge socially — is the open one, and no amount of byte-level agreement settles it. For the application architect the consequence is plain: pick the language your team works in, and a peer written in it will interoperate, byte for byte, with peers written in any other.

7. Reaching the Outside World

A content-addressed substrate is, by itself, a closed world: it can talk to itself perfectly and to nothing else. An application that does anything useful has to reach outside it — to a filesystem, to the terminal’s standard streams, to an HTTP endpoint, to an existing database — and the way it reaches is a handler like any other, called a bridge. A bridge speaks the foreign protocol on one side and the entity protocol on the other; its authority, like every handler’s, is bounded by the capability it holds, so a bridge to one external system can do exactly what its grant permits and nothing more. Integration is not an escape from the model. It is a class of handler within it.

The architecture makes the boundary legible by convention: bridges to things the host owns live under a reserved namespace, so a filesystem bridge and a standard-streams bridge sit beside each other as obvious members of the same category, and future bridges — to a network socket, to audio, to the clock — follow the same pattern. The picture the project uses is a closed cell growing pseudopods to touch what is around it: the substrate stays content-addressed and verifiable inside, and the bridges are where it reaches out. The wrapped-binary form depends on exactly this — a command-line tool prints by dispatching through a standard-streams bridge, and reads files through a filesystem bridge — which is why the same small set of bridge handlers recurs across the reference tools.

The worked instance for the wider world is an HTTP bridge: a single handler that fetches a remote resource and returns it as a typed entity. Its load-bearing detail is verification — the caller can supply the hash it expects, and the handler refuses to persist a body that does not match, so a content-addressed system can pull bytes from an ordinary, untrusted origin and still know it got the bytes it asked for. The bridge is GET-only and egress-only in its first version, scoped by a capability that names which URLs it may reach, and it is a draft awaiting sign-off; bridges to databases and other protocols are named but not yet specified. We cite it as the concrete shape the abstract “bridge handler” takes, with its maturity marked.

8. Worked Locations

The way to read the space is to locate real applications in it and read their qualities off the coordinates. The reference applications that exist do exactly this, each landing at a different point.

A content site sits at entity-native form, standard-peer depth, flat deployment. Because it is entities and nothing else, it inherits the substrate’s verification and transfer directly: its qualities are that anyone can re-host it, anyone can check it, and it needs no running server. What it gives up is anything the substrate’s own evaluation cannot express — the form’s reach is the substrate’s reach, which for a document site is enough.

A version-control tool sits at wrapped-binary form over a revision-extension store, one-shot lifetime, keypair identity, command-line surface. Reading those coordinates: a user gets a familiar tool that shells in and out, with a full version history underneath that they never have to think about, an identity that is one key on disk, and no daemon left running. It is the same set of qualities a developer would choose for a small, sharp utility, arrived at by picking that corner of the space.

A web application backed by a database peer sits at client-server or three-tier topology — a frontend, an application-logic peer, a storage peer — and shows that the system is at home in the most conventional shape there is. The qualities it inherits over a normal three-tier stack are the ones from the inheritance section: the tiers speak one protocol, carry one kind of typed content, and authorize uniformly, so the integration between them is not the project.

An interactive workbench sits at peer-composition form in the endosymbiotic mode, full-peer depth, persistent lifetime, with several surfaces over one shell. Its coordinates read as the richest point: a single identity to its user, an operational peer keeping durable state inside, the full inherited property set, and a terminal and a graphical face over the same logic. It is the existence proof that the endosymbiotic mode and the multi-surface render model work, because it is built that way.

8.1. A Repository Whose Tree Is the Artifact

One location is worth more than a coordinate reading, because it is where several of the system’s properties compound. Take the version-control case and push it: put the program itself under version control — its types, its handlers, its compute expressions, all entities in the tree. Then the repository is not a place where the program’s source is stored pending a build. The tree is the program, in the form the substrate runs. Build, package, deploy, and version control, which conventional practice keeps as four separate systems with glue between them, collapse into operations on one content-addressed tree: to ship a change is to move the entities that changed; to deploy is to sync them to a peer; to roll back is to bind an earlier hash.

The nearest prior idea is Unison, where code is identified by the hash of its content and a definition is the same definition everywhere its hash appears. The entity system reaches the same place by a more general route — it content-addresses everything, not only code — and gains two things a file-based version-control system structurally cannot give. The artifact is executable in place: there is no separate build step turning source into a runnable form, because the entities the tree holds are already the form the substrate evaluates. And the authority travels with the artifact: the capabilities a program needs are entities in its tree, so cloning the program clones its authorization story, not just its bytes. What a conventional repository hands you is the source; what this hands you is the running thing and the permission to run it.

These are reference implementations and worked sketches, not products. They are how the patterns in this paper were found, and they are evidence that the patterns hold. Whether they are the best way to occupy these points in the space — whether the version-control verbs are the right verbs, whether the workbench’s composition is the right composition — is exactly the kind of question the system is still early enough to leave open.

9. What Is Demonstrated, and What Is Not

It is worth separating what the reference applications establish from what they do not, because the difference is easy to blur and the corpus’s promise depends on not blurring it.

What they establish is that the patterns hold and the architecture supports what this paper claims it does. A program really can be a peer that boots, runs, and exits; a composition really can present one identity over an interior of supporting peers; a publish-and-fetch path really does move content-addressed bytes through an untrusted origin and verify them on arrival. The collaborative case is worth stating directly, because the temptation is to undersell it: the architecture supports collaborative editing. The pieces it needs — a version history that merges, reactive notification of change, derived values that recompute — are the inherited properties, and a multi-peer collaborative-edit path has been exercised end to end in the reference workbench. What is ahead is not the capability but the product: a polished collaborative editor is a thing to build, and the substrate is in place for one.

What the reference applications do not establish is equally important. They are reference implementations, not production software. The work of building reference architectures and reference applications is a deliberate one — to show what the substrate makes possible and to give a community something to start from — and whether a community adopts them, extends them, or builds its own instead is an outcome, not a claim the paper gets to make. They do not include a display layer; the graphical ones drew their own. And they do not establish behavior at production scale: the implementations have been validated for correctness, across languages and against the specification, not run as long-lived deployments under real load.

That line — correctness demonstrated, adoption and scale open — is the same line the whole system draws. The protocol’s convergence is the decidable, proven half: peers across dozens of languages agree on the bytes, and a conformance oracle settles it. Whether the thing gets used, built on, and chosen — the social convergence — is the genuine unknown, and it is not something a specification can force. Saying so is not hedging. It is the only honest way to offer a substrate to the people who would build on it.

10. Related Work

10.1. Application and Enterprise Architecture

The arrangements this paper’s topology axis maps to — client-server, N-tier, service-oriented architecture, microservices — are the standard vocabulary for structuring and scaling an application, and the entity system inherits the vocabulary rather than replacing it. The difference is at the seams. Each of these styles spends its design effort on the integration between components: the protocols, the message buses, the data formats, the authorization that has to be reconciled across boundaries. On a shared substrate the components already speak one protocol and authorize uniformly, so the architectural shapes survive while the integration between their parts largely does not. The styles describe how to arrange peers; what they no longer describe is glue.

10.2. Application Frameworks

Rails (Hansson 2004), Django (Django Software Foundation 2005), and Spring (Johnson 2002) bundle infrastructure with application code: the framework supplies persistence, routing, authentication, background jobs, and the application supplies domain logic. Two differences stand out. The framework’s infrastructure is the framework’s, incompatible with every other framework’s, where the standard peer’s is the protocol’s and shared. And a framework comes with its language — Rails is Ruby, Spring is Java — where a peer can be written in any language with a conformant implementation. A framework is a way to build one application well; the substrate is a way for applications to share a foundation.

10.3. Local-First Software and CRDTs

The local-first program (Kleppmann, Wiggins, Hardenberg, et al. 2019) and the CRDT libraries that support it (Jahns 2019; Kleppmann, Wiggins, van Hardenberg, et al. 2019) address conflict-free replication without committing to a substrate underneath. The entity system’s relation to them is that a CRDT is a merge strategy its revision extension can carry, and the rest of what a local-first application needs — history, reactivity, transfer, authorization — comes from the substrate in the same model, rather than being assembled around the CRDT.

10.4. Content-Addressed Code

Unison (Chiusano and Bjarnason 2019) identifies code by the hash of its content, so a definition is the same definition wherever its hash appears, and renaming or moving it does not change what it is. This is the idea the repository-as-artifact location rests on, reached more generally: the entity system content-addresses every entity, not only code, so the property Unison gives definitions — identity from content, sameness by hash — it gives data, types, and capability tokens alike. The added step is that the addressed artifact is executable in place and carries its own authority.

10.5. Entity-Component Systems, Reactivity, and Notebooks

Entity-component systems (Unity Technologies 2019; Bevy contributors 2020) use a structural data model — entities as identifiers with attached components — inside a single process; the structural resemblance is real, but the entity system is the distributed generalization, with content-addressed identity and references that cross peers. Reactive programming (RxJS contributors 2012; Pivotal 2013) and the spreadsheet provide the reactive-evaluation model the compute and subscription extensions implement over content-addressed data. Computation notebooks (Kluyver et al. 2016; Bostock et al. 2017) make computation inspectable within a host environment; the substrate’s inspectability is structural and cross-implementation instead, since an expression is an entity any peer can read. The survey is selective by intent — the closest structural neighbors, not an exhaustive map.

11. Discussion

11.1. What the Paper Is and Is Not

This paper is a map of a design space, written for a developer deciding how to build on the substrate. It is not a manual and not a finished account of best practice, because best practice is one of the things the system is too early to have settled. Where a choice in the space has a clear consequence, the paper states it; where the right choice is genuinely open, it says that instead of inventing one.

11.2. What Is Settled and What Is in Motion

Settled: the core protocol and the six primitives under it; the inheritance property, that depth in the substrate hands an application capabilities it would otherwise assemble; and the protocol-as-contract result, demonstrated by conformant peers across dozens of languages converging on the bytes. These are the load-bearing claims, and they rest on running code and a conformance oracle.

In motion: the application-level conventions — the content-site and embed formats, the peer-composition catalog, the HTTP bridge — are recent and mostly in draft, cited here as drafts. The ergonomic layer, the SDKs and the higher rungs of the authoring stack, is being built. The compilation gradient is designed well past where it is implemented. The display layer is not the substrate’s at all. And behavior at production scale is unestablished. None of this undercuts the design space; it sets the date on it.

11.3. A Note on Method

The patterns in this paper were not specified in advance and then implemented. They were found — by building reference applications and noticing that the same shapes recurred, that two tools written for different jobs were the same program, that three independent implementations converged on the same composition. That the patterns emerged from the work rather than being imposed on it is part of why they are offered with the confidence they are, and part of why the open questions are left open: the system is still telling us what it is, and the honest posture is to report what it has shown rather than to legislate what it should be.

11.4. Limitations

• The design space is the paper’s own framing — a useful way to organize the choices, not a structure the architecture defines; a developer may find a coordinate the paper did not name.
• The reference applications are partial and are reference implementations; the scale and adoption questions are open by the system’s own account.
• The application-level conventions cited are drafts and may change.
• 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.

12. Conclusion

An application on the entity system is a location in a design space, not an instance of a template. The coordinates a developer chooses — how much substrate to stand on, what the application is, how it is deployed, how long it lives, how deep its identity goes, and in which language it is written — determine what the application inherits and what it has to build. A bare peer is already an application; an extension raises the floor rather than adding a subsystem; a single local peer and a federated mesh are the same substrate installed as peers. The work of application architecture here is picking where to stand and knowing what that gives you.

Two properties make the picking worthwhile. A location inherits what a conventional application assembles — storage, versioning, reactivity, durable workflows, authorization — so the developer writes domain logic instead of integration. And the contract is the protocol, not a language, so the architect picks the language and the peers still agree. The familiar shapes of application and enterprise architecture survive the move; what does not survive is the glue between their parts.

Three things sit open alongside the model, by design. An application concern that maps to no axis and no form in this space would show the space is incomplete, and we would want to know which one. A form of application not reducible to the four named here — entities the substrate runs, a binary wrapping a peer, a composition of peers, raw service use — would extend the map. And the largest open question is not structural at all: whether people build on this. The protocol’s convergence is proven; the social convergence is not, and cannot be forced. The substrate is offered as a thing to build on, with its early state stated plainly, in the belief that the honest version is the one worth offering.