What is the entity system?

The entity system is a substrate for distributed information: a small core protocol, a set of extensions, and the conventions that let independent peers work together. With it you can keep your own data, sync it between your own machines, and build applications that don't depend on anyone else's servers --- up to a distributed operating system.

Most software keeps your data on someone else's computer, under someone else's terms; moving it, or building on it, means asking permission. That follows from how those systems were built, and it can be built otherwise. The entity system is built so that independent peers, run by different people with no prior arrangement, genuinely interoperate: the data has a definite form, anyone can hold it, and no single party sits in the middle.

None of which requires anyone else to show up. One person running it on their own machines is a complete use case, not a waiting room — connecting to other peers adds to it rather than being the point of it.

The six primitives

The whole system is built from six primitives, which divide into three domains:

• Informational — Entity (typed data, {type, data}), Identity (a content-derived hash, intrinsic rather than assigned), Tree (a path → hash namespace over an immutable content store).
• Temporal — Emit (the atomic state crossing: store content, bind a path), Execution (typed dispatch — every operation is an EXECUTE against a handler in the tree).
• Spatial — Peer (identity + capabilities + connection; the participant that holds a tree and exchanges entities with others).

The temporal primitives depend on the informational ones; the spatial primitive depends on both. Everything above is composition of these six.

How it is built up

The system is a layered stack. Two peers that agree on the core protocol (L1) interoperate at the substrate; everything above it is optional and composes.

Entity Core Protocol — the floor

The mandatory layer every peer speaks. Its surface is small: content-addressed typed data as the unit; a mutable named tree over an immutable content store; universal addressing (peer/path); two message types (EXECUTE and its response, with query/subscribe/update all expressed as EXECUTE against handlers); four-dimensional capability grants (handlers, operations, resources, peers) with cryptographic attenuation; and peer-to-peer communication between content-identified peers. The core protocol has been re-derived across more than forty languages — a cohort of peers generated from the spec, alongside three independently-written reference implementations (Go, Rust, Python): spec-forced convergence across languages, not many separate codebases independently agreeing, since the generated peers share a generation lineage. Conformance is a tracked, moving state — the current cohort-wide measurement, and each peer's known gaps, are published in the conformance matrix rather than summarized as a badge.

→ The full specification

Entity System Extensions — the capability layer

Everything above core is optional and opted into: each extension is a contract a peer adds without changing the core. The real structure is a dependency topology, not the folder layout — a foundational tier (continuation, subscription, revision, inbox, history, query), an identity stack (identity, attestation, quorum, role, group), and the converging network/resolution frontier (network, relay, route, registry, discovery).

The distinction matters more than the list. The core is what is left after reduction — the part that cannot be removed and still have two strangers interoperate. What sits above it is design space, and the set described here is one traversal of it: the extensions we found we needed, in the order the work demanded them. A peer that adopts a different set, or writes its own, is not a fork and is not less conformant — it still meets every other peer at the substrate, because agreement is required at the floor and divergence is expected above it. That is the property the conformance gate measures, and the reason it measures the core rather than the whole stack.

→ The architecture, in full

The Distributed Entity Operating System

An operating system coordinates state, dispatch, processes, events, and authorization. The standard peer — the core protocol plus the architecture-supplied substrate-bridge extensions — provides each of these from the same six primitives, in the same typed, content-addressed substrate. The unit is not the machine but the fleet: all of a person's or an organization's peers, run as one coordinated system. The kernel services map across cleanly — the tree is the filesystem, EXECUTE the system call, a continuation a process, the inbox IPC, a subscription a signal, capabilities the permission system.

The framing is deliberate: the core is a substrate, not a system, so this is one operating system the substrate can host — the reference build — not the only one it could. The posture is exploratory: a map of what the substrate can carry, not a claim that this is the way to build one.

Stewardship and where it stands

A standard people can rely on has to be owned by everyone and beholden to no one. The Entity Church Foundation is the neutral steward of the protocol: it keeps the standard open, documented, and free to build on, and governs the process, not the asset. That stewardship has a shape worth stating plainly:

• Proven by running code, not by decree. The standard is what conforming peers actually agree on; independently built peers interoperate, and the design is machine-checked.
• Converge, don't fragment. There is a real process for bringing changes back, so the canonical spec stays one thing.
• Where it stands. The protocol is at version 0.8 — a preview, not 1.0. It is real and already implemented, but it isn't frozen. Locking 1.0 happens with the community, once the full system has been read, implemented, and challenged in the open. The roadmap publishes the project's own tracking for all four domains, unfinished parts included.
• Settled and exploratory parts are marked. The specification, the design rationale and the measured results are all published, so the state of any individual piece can be checked directly rather than taken from a summary. Where something is still being worked out, it says so at the point where you would rely on it.
• Before 1.0, corrections can move things. A change can affect something built early, and the roadmap and the change process are how that happens in the open rather than by surprise. If you find something broken or think a decision is wrong, how the project works is where that goes — it is the fastest way to get it fixed.

Explore the system

• Applications — what the substrate is for: the forms an application can take, from using it as a library inside ordinary software to an application that is data the substrate runs; what has been built, and what is still only a direction.
• Publishing on ordinary hosting — a peer publishes a signed, content-addressed tree, so commodity static hosting serves it and the publishing peer need not stay online. What that costs, why the host is trusted for nothing, and what a verified page does and does not prove.
• Entity System Architecture — extensions, SDK, applications, and the cross-spec dependency map.
• Roadmap — where each of the four domains stands, how maturity is tracked, and what is still moving. The project's own planning documents, as they are written.
• How the project works — how the specification, the implementations and the conformance evidence fit together, and where each lives.
• The specification — the core protocol in full.
• Support the Foundation — how to help keep the standard open.

Where this comes from

A closing note on stance, because it shapes everything above.

The entity system is an exploratory research project, and we believe it was found, not invented. It came out of analysing how existing information systems already work; the six primitives are a structure that was there to be noticed. It is also a dependent technology — an arrangement of cryptography, encoding and distributed-systems work done by other people. It would not exist without the committed work of scientists and practitioners over decades.

That is why these pages describe rather than sell, and why the gaps are stated as plainly as the results: overclaiming would break the same promise the technology makes. The goal is a common shared resource for distributed computing and data exchange, and that requires a community to work with the technology and share the ownership of its future.

1.0 gets reached with the community, not declared at it. You're a peer here, not a prospect — there's nothing to buy. Read the ideas, build a peer and try it, disagree with us in public, or help steward the standard, as you like.