Skip to content
Network/Access THE DEFINITIVE GUIDE

Reality Kernel

Status: ✅ Decided — grounded in ADR-0001 and ADR-0015

The Reality Kernel is the horizontal engineering platform beneath the NetworkAccess suite. It provides a governed operational kernel that any number of domain modules can extend — without each module maintaining its own private store of truth. It is Lepton’s answer to the fragmented-truth problem: multiple systems that disagree about what is physically in the ground.

The doctrine: one kernel, no private reality

Every module that extends the kernel contributes its domain facts across a contribution boundary into a shared kernel. There is no side database. There is no “fiber store” running separately from a “gas store.” A Realm contributes reality to the kernel — it does not own a private truth. This is what “no private reality” means in practice.

The doctrine is enforced structurally: no kernel engine branches on a domain type, and no kernel source file names a domain concept. This is not a convention — it is a hard guardrail, checked by a grep in slice-1 acceptance. Violating it turns Slice 2 (realm compiler, install path) from a relocation into a rewrite.

The spine

The Spine is the write→event→projection→read path that every domain operation traverses:

  1. A caller invokes an Action — a coarse semantic intent (e.g. projects.CreateWorkPackage).
  2. The kernel validates it against policy (Authority) and executes it.
  3. The Action produces one or more Events, persisted to the event log.
  4. The Projection Engine reads events and maintains the Serving Store — the read surface.
  5. Reads are served from the Serving Store.

This flow is unidirectional and auditable. The Serving Store is not the sole source of truth; it is a projection, and its current-state behavior is the subject of the consistency spike (see Consistency).

Spine vs. realms

The spine is the kernel’s machinery. Realms are the kernel’s namespaces — they partition domain content (network., projects., evidence.) without owning separate runtime boundaries. Realm definitions (Entity types, Trait schemas, Action contracts) are registered into kernel registries at boot. The kernel’s engines (action executor, event log, projection engine, serving store, authority) operate on those definitions without knowing what domain they represent.

This split — spine machinery agnostic to content, realms as content namespaces — is what makes the contribution boundary real. It is the difference between a multi-domain kernel and a bespoke app with multiple subsystems.

Build sequencing

The kernel is built in two slices (ADR-0015, ADR-0014):

Slice 1 — prove the spine. End-to-end write→event→projection→read on the projects domain. Domain definitions are hand-registered into kernel registries at boot. No realm compiler, no install-into-Universe path. The domain-agnostic guardrail is in force. This slice also discharges the two architecture freeze gates: the truth-model spike (ADR-0003) and the kernel-language build-off (ADR-0006).

Slice 2 — prove the separation. Introduce the v0 realm compiler and the install-into-Universe path. At this point, adding a second domain realm is a relocation of how definitions arrive (compiled package vs. hand-registration), not a re-architecture of any engine. The guardrail is what makes slice 2 additive.

What the kernel is not

The Reality Kernel is not a database. It is not an ORM. It is not a product. It is the governed operational substrate that NetworkAccess modules — SmartInventory, SmartPlanner, SmartOps — are built on. Buyers see the product modules; engineers and extension authors speak the kernel vocabulary.

See also

← Architecture