Digital Computing → Entity System Bridge: Canonical Analysis
Status: Canonical reference. The downward bridge — how the entity system is realized on digital computing. Source: methodology.md §6.2, ENTITY-CBOR-ENCODING.md, ENTITY-CORE-MACHINE-SPEC.md, implementation codebases.
1. What the bridge does
Translates entity system substrate primitives {E,I,T,M,X,P} into digital computing primitives {Wd,Mm,In,Cy,Ch,Pr}. How typed entities, content-addressed identity, tree namespaces, emit events, dispatch handlers, and peer capabilities are implemented as binary data, memory operations, executable code, and network communication.
2. Bridge primitives
| # | Primitive | What it translates | Entity → Computing |
|---|---|---|---|
| 1 | Encoding (Enc) | Entities ↔ byte sequences | E (typed entity) → Wd (binary words via CBOR canonical encoding) |
| 2 | Hash (Hsh) | Content → identifier | I (content identity) → Wd (hash value computed by In over Mm) |
| 3 | Protocol (Prt) | Messages ↔ wire format | M (emit events) + X (dispatch) → Ch (network packets) |
| 4 | Persistence (Prs) | Entities ↔ durable storage | T (tree state) → Mm (persistent memory — disk, database) |
| 5 | Scheduler (Sch) | Handlers ↔ execution | X (handler dispatch) → Pr+In (process executing instructions) |
| 6 | Network (Net) | Peers ↔ network connections | P (peer identity + capabilities) → Ch (network channels + Pr processes) |
2.1 Partial levels
Encoding (Enc):
| Level | Description | Instance |
|---|---|---|
| Enc0 | No encoding | Entities exist as in-memory objects only, no serialization |
| Enc1 | Ad-hoc encoding | Custom binary/JSON format, non-canonical |
| Enc2 | Canonical deterministic | CBOR canonical encoding — same entity always produces same bytes |
| Enc3 | Self-describing | ECF (Entity Canonical Form) — encoding includes type information |
| Enc4 | Compressible | Encoding optimized for compression — structural sharing, deduplication |
| Full Enc | Versioned hierarchical | Encoding supports schema evolution, backward/forward compatibility |
Phase transition: Enc1→Enc2 (Canonical). Below: encoding is arbitrary — same entity may produce different byte sequences. Above: encoding is DETERMINISTIC — same entity always produces identical bytes. This enables content-addressing (Hash depends on canonical encoding).
Hash (Hsh):
| Level | Description | Instance |
|---|---|---|
| Hsh0 | No hashing | Address-based identity — entities identified by location |
| Hsh1 | Checksums | CRC, simple hash — integrity checking but not identity |
| Hsh2 | Cryptographic hash | SHA-256 — strong identity, collision-resistant |
| Hsh3 | Content hash over canonical | hash(canonical(entity)) — deterministic content-addressed identity |
| Hsh4 | Merkle tree | Hash tree — tree structure itself is content-addressed |
| Full Hsh | Multi-hash + partial | Multiple hash algorithms, partial tree hashing for efficiency |
Phase transition: Hsh2→Hsh3 (Content addressing). Below: hash verifies integrity. Above: hash IS identity — the entity is DEFINED by its content hash. This is where I (identity) becomes fully realized.
Protocol (Prt):
| Level | Description | Instance |
|---|---|---|
| Prt0 | No protocol | Direct function calls only — no wire format |
| Prt1 | Simple framing | Length-prefixed messages, no versioning |
| Prt2 | Versioned protocol | Protocol version negotiation, backward compatibility |
| Prt3 | Capability-gated | Messages carry capability tokens — authorized dispatch |
| Prt4 | Multi-protocol | Multiple protocol variants for different use cases |
| Full Prt | Self-describing evolving | Protocol describes itself, supports extension without breaking |
Phase transition: Prt1→Prt2 (Versioned). Below: protocol is fixed — all peers must match exactly. Above: protocol versions coexist — peers negotiate compatible version. Enables evolution without breaking existing peers.
Persistence (Prs):
| Level | Description | Instance |
|---|---|---|
| Prs0 | No persistence | In-memory only — state lost on restart |
| Prs1 | File-based | Entities written to files — simple but no indexing |
| Prs2 | Key-value store | Content-addressed storage — hash→entity lookup (BoltDB, RocksDB) |
| Prs3 | Transactional | ACID guarantees on entity storage — atomic tree mutations |
| Prs4 | Distributed replicated | Storage replicated across machines — durability, availability |
| Full Prs | Self-replicating with history | Storage maintains full version history and syncs automatically |
Phase transition: Prs1→Prs2 (Key-value). Below: entities stored as files — O(n) lookup. Above: content-addressed key-value — O(1) lookup by hash. Enables practical content-addressing at scale.
Scheduler (Sch):
| Level | Description | Instance |
|---|---|---|
| Sch0 | No scheduler | Single-threaded, synchronous — one handler at a time |
| Sch1 | Event loop | Async single-threaded — handlers dispatched from event queue |
| Sch2 | Thread pool | Concurrent handler execution — multiple handlers simultaneously |
| Sch3 | Resource-aware | Scheduling considers CPU, memory, I/O budgets |
| Sch4 | Distributed | Handlers dispatched across machines — distributed execution |
| Full Sch | Self-organizing | Scheduler adapts to load, migrates handlers, auto-scales |
Phase transition: Sch0→Sch1 (Event loop). Below: blocking — one handler blocks everything. Above: async — handlers yield, other work proceeds. Enables responsive systems.
Network (Net):
| Level | Description | Instance |
|---|---|---|
| Net0 | No networking | Single peer — local only |
| Net1 | Point-to-point | Direct connection to one other peer |
| Net2 | Client-server | Multiple clients connect to central server |
| Net3 | Peer-to-peer | Direct peer connections, no central server |
| Net4 | Overlay network | DHT, relay routing — peers reachable through intermediaries |
| Full Net | Adaptive multi-protocol | Multiple network transports, protocol negotiation, NAT traversal |
Phase transition: Net2→Net3 (P2P). Below: centralized topology. Above: decentralized — any peer can connect to any other. Fundamental architecture change.
3. Dependencies
Enc → (nothing; foundation — encoding is the base translation)
Hsh → Enc (hash requires canonical encoding to hash)
Prt → Enc (protocol carries encoded messages)
Prs → Enc (persistence stores encoded entities)
Sch → (nothing; independent — scheduling doesn't require specific encoding)
Net → Prt (networking requires wire protocol)
DAG:
Enc (root 1) Sch (root 2)
├── Hsh
├── Prt → Net
└── Prs
Two roots: Enc (data encoding) and Sch (execution scheduling). Encoding and scheduling are independent — you can encode entities without scheduling handlers, and schedule handlers without entity encoding.
4. Pair Analysis
C(6,2) = 15 pairs.
Heavy pairs
| # | Pair | Content | Why heavy |
|---|---|---|---|
| 1 | Enc-Hsh | Canonical encoding for hashing | THE constitutive pair — hash(canonical(entity)) IS content-addressing |
| 2 | Enc-Prs | Encoded persistence | Entities stored in encoded form — serialization for storage |
| 3 | Enc-Prt | Encoded protocol | Messages carry encoded entities — serialization for wire |
| 4 | Prt-Net | Protocol over network | Wire protocol carried by network connections |
| 5 | Hsh-Prs | Content-addressed storage | Store by hash, retrieve by hash — the content store |
| 6 | Prt-Sch | Protocol dispatches to handlers | Incoming protocol messages dispatched by scheduler |
| 7 | Sch-Net | Networked handler dispatch | Handlers executing across network — distributed execution |
Medium pairs
| Pair | Why medium |
|---|---|
| Enc-Sch | Scheduler operates on encoded entities — but mediated through Prt |
| Hsh-Prt | Hashes in protocol messages — content verification |
| Hsh-Net | Content-addressed networking — fetch by hash from peers |
| Prs-Sch | Scheduler reads/writes persistent store |
| Prs-Net | Persistent data synced over network — revision extension (absorbs former sync extension's role) |
Light pairs
| Pair | Why light |
|---|---|
| Enc-Net | Encoding and network — indirect through Prt |
| Hsh-Sch | Hash and scheduling — independent concerns |
| Prs-Prt | Persistence and protocol — indirect (both mediated by Enc) |
7 heavy of 15 (47%). Consistent with all other bridges in the chain.
5. Coherent Sub-lattice
Enc and Sch are independent roots. Hsh→Enc. Prt→Enc. Prs→Enc. Net→Prt.
Enc absent: Hsh, Prt, Prs, Net all absent. Free: {Sch}. Combos: 2 ({}, {Sch}).
Enc present: Hsh, Prt, Prs each independent (all need only Enc). Net needs Prt. Sch independent.
Sub-cases by Prt:
- Prt absent: Net absent. Free: {Hsh, Prs, Sch}. Combos: 8.
- Prt present: Net free. Free: {Hsh, Prs, Sch, Net}. Combos: 16.
Enc present total: 8 + 16 = 24.
Total: 2 (Enc absent) + 24 (Enc present) = 26. Plus {}: already counted.
Actually — can {Sch} exist without Enc? Yes — a scheduler dispatching handlers doesn't strictly NEED entity encoding (handlers could operate on raw data). So {Sch} alone is valid. It's in the Enc-absent count.
26 coherent subsets of 64. Filter: 26/64 = 40.6%. Moderate-to-loose — the two-root structure and limited dependencies create less filtering.
6. Build-up Sequence
Path α — Content-first (how entity system implementations typically build)
{} → {Enc} → {Enc,Hsh} → {Enc,Hsh,Prs} → {Enc,Hsh,Prs,Sch} → {Enc,Hsh,Prs,Prt,Sch} → Full
Encoding → hashing → persistence → scheduling → protocol → networking.
Build the content store first (encode, hash, persist), then add execution (schedule), then add distribution (protocol, network). This IS how the Go implementation progresses.
Path β — Network-first (protocol implementation)
{} → {Enc} → {Enc,Prt} → {Enc,Prt,Net} → {Enc,Prt,Net,Sch} → {Enc,Hsh,Prt,Net,Sch,Prs}
Build network communication first, then add content addressing and persistence. Starting from the wire format.
Phase transitions
| Transition | What changes |
|---|---|
| +Enc (Enc2, canonical) | Deterministic encoding — same entity always produces same bytes |
| +Hsh (Hsh3, content-addressing) | Identity IS content — entities defined by their hash. I becomes real. |
| +Prs (Prs2, key-value) | Content-addressed storage — practical entity persistence |
| +Sch (Sch1, event loop) | Async handler dispatch — entity system becomes responsive |
| +Net (Net3, P2P) | Peer-to-peer — entity system becomes distributed |
7. Compositions
Core triad
{Enc, Hsh, Prs} — Encoding, Hash, Persistence.
"What is a content-addressed entity store?" → Entities ENCODED canonically, HASHED for identity, PERSISTED by hash. The data layer.
All three pairs heavy: Enc-Hsh ✓, Enc-Prs ✓, Hsh-Prs ✓.
This directly implements the entity system's core triad {E, I, T} at the computing level: E is encoded (Enc), I is hashed (Hsh), T is persisted (Prs).
Secondary triad
{Prt, Sch, Net} — Protocol, Scheduler, Network.
"What is a distributed dispatch system?" → Protocol messages DISPATCHED by scheduler over NETWORK. The execution layer.
This implements {M, X, P} at the computing level: M events carried by Prt, X dispatched by Sch, P connected by Net.
Quad
{Enc, Hsh, Prs, Net} — Content-addressed distributed storage. The sync core — entities encoded, hashed, persisted, and synced over network. Implements the ITM+P substrate combination.
Higher / full set
{Enc, Hsh, Prt, Prs, Sch, Net} — Complete entity system implementation. All six bridge primitives realized: the full realization of {E,I,T,M,X,P} on the computing substrate. Peaks at the most-complete implementations. Carried as an explicit higher composition for full-set coverage, consistent with the entity-system complete-substrate composition.
Emergent reconciliation note: the secondary triad {Prt, Sch, Net} (execution layer, implements {M,X,P}) carries an emergent activation in the data even though the Step 8 emergent table omits it. Step 7 here and the cross-lattice constraints both make {Prt,Sch,Net} a load-bearing triad symmetric to the {Enc,Hsh,Prs} data triad ({E,I,T}); the Step 8 omission is an incompleteness of that table, not an absence of activation.
8. Emergent Properties
| Composition | Regime | Emergent Property |
|---|---|---|
| {Enc} | Enc2+ | Deterministic serialization — entities have canonical byte representation |
| {Enc, Hsh} | Hsh3+ | Content addressing — identity = hash of canonical encoding |
| {Enc, Hsh, Prs} | Prs2+ | Content-addressed store — persist and retrieve by content hash |
| {Enc, Prt} | Prt2+ | Versioned wire protocol — entities transmittable across peers |
| {Prt, Sch} | Sch1+ | Handler dispatch — incoming messages routed to handlers |
| {Enc, Hsh, Prs, Net} | Net3+ | Distributed content store — entities synced across P2P network |
| Full set | All high | Complete entity system implementation — all primitives realized on computing substrate |
9. Manifestation Landscape
| Implementation | Enc | Hsh | Prt | Prs | Sch | Net |
|---|---|---|---|---|---|---|
| entity-core-go | 3 (CBOR+ECF) | 3 (SHA-256 content) | 2 (versioned) | 2 (BoltDB) | 1 (event loop) | 1 (basic) |
| entity-core-py | 2 (CBOR) | 2 (SHA-256) | 1 (simple) | 1 (file-based) | 0 (synchronous) | 0 (local only) |
| entity-core-rs | 1 (rebuilding) | 1 (rebuilding) | 0 | 0 | 0 | 0 |
| Git (analogy) | 3 (packfile format) | Full (SHA-1/256 content) | 2 (pack protocol) | Full (object store) | 0 (no dispatch) | 2 (remote protocol) |
| IPFS (analogy) | 3 (CBOR-DAG) | Full (multihash CID) | 3 (libp2p) | 3 (datastore) | 1 (go routines) | Full (DHT, bitswap) |
Go implementation is progressing along the content-first path (α): Enc and Hsh most advanced, Prs moderate, Sch and Net early.
Git is extreme on Hsh and Prs (content-addressed storage) but has NO dispatch (Sch0) — it's a store, not a computation system.
IPFS is extreme on Hsh, Prt, Net (distributed content-addressed networking) but moderate on Sch — it distributes content but doesn't dispatch handlers.
Summary
| Property | Value |
|---|---|
| Bridge | Digital computing → Entity system (downward realization) |
| Primitives | 6: {Enc, Hsh, Prt, Prs, Sch, Net} |
| Roots | 2: Enc (data encoding) + Sch (execution scheduling) |
| Core triad | {Enc, Hsh, Prs} — content-addressed entity store |
| Secondary triad | {Prt, Sch, Net} — distributed dispatch system |
| Filter | 26/64 = 40.6% |
| Heavy pairs | 7/15 = 47% |
| Depth | 2 |
| Key transition | Hsh3 (content addressing) — identity becomes content-defined |
| Two-triad structure | Data triad {Enc,Hsh,Prs} implements {E,I,T}. Execution triad {Prt,Sch,Net} implements {M,X,P}. |
Referenced by the model
Cited as a source by 1 model record (browse the model census):
- computing-to-entity-bridge —
bridgeentity/sc1