Concepts
This is the canonical glossary. Every core term used across the Architecture room is defined here exactly once. Architecture pages link to these definitions; they do not redefine them. If two pages describe a term differently, the definition here is authoritative and the other page is wrong.
The vocabulary below is the kernel’s internal and extender-facing language (ADR-0002). Buyers and product surfaces use different terms; this vocabulary is for engineers, extension authors, and agents.
Lepton and NetworkAccess
Lepton is the company. NetworkAccess is the product suite — the primary product brand over the whole application layer. The Reality Kernel is the horizontal engineering platform beneath the suite; it is internal and partner/extender-facing, not a buyer-facing brand. Vertical modules — SmartInventory, SmartPlanner, SmartOps — are built on the kernel and presented to buyers under the NetworkAccess brand.
This hierarchy is decided in ADR-0002 and is the resolution of the prior ambiguity between “Lepton,” “NetworkAccess,” and the kernel’s vocabulary.
See: Start Here for the full brand context.
Reality Kernel
The Reality Kernel is the horizontal, domain-agnostic operational kernel beneath NetworkAccess. It provides a governed contribution boundary — domain modules register their definitions into the kernel’s 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.
The kernel’s doctrine is: one kernel, many modules, no private reality. Every module contributes its domain facts across the contribution boundary into the kernel. There is no side database per domain. A Realm contributes reality; it does not own a private truth.
The kernel is domain-agnostic by construction — enforced by a grep check in slice-1 acceptance that fails if any kernel source file names a domain type.
See: Reality Kernel, ADR-0001
Spine
The Spine is the write→event→projection→read path that every domain operation traverses. An Action is invoked, the kernel validates and executes it, the Action produces Events, the Projection Engine consumes Events to maintain the Serving Store, and reads are served from the Serving Store. The flow is unidirectional and auditable.
“Spine-first” is the build sequencing principle: prove the spine on one domain thread before widening to multiple realms or modules.
See: Reality Kernel, ADR-0015
Realm
A Realm is a lightweight namespace within a Universe — a domain partition, environment tier, or integration source. Examples: network., projects., geo., evidence., integration.. Realms are prefixes plus declared dependencies/imports; they define which Entity types, Traits, and Actions belong to a domain concern.
A Realm contributes its definitions to the kernel at boot. It does not maintain a private store. Cross-realm links are allowed and lightly typed. Runtime governance (per-realm policy-fragment composition, cross-realm action-composition checks) is deferred until multiple extension authors exist (ADR-0008).
The top six Realms in the proof: core, geo, network, projects, evidence, workflow, integration, ops. Others (market, signal, campus, security) are added when their modules arrive.
Entity / Object
An Entity is a named, identity-bearing thing declared in a Realm — for example, network.FiberSpan or projects.WorkPackage. Every entity has a client-generated UUID as its stable, permanent identity. Client-generated identity is a non-negotiable kernel invariant: it enables offline action queuing and reconnect deduplication without server-sequence coordination.
An Object is an entity instance as it appears in the Serving Store — the current projected state of the entity, ready for reads. The distinction matters: an Entity is a schema declaration; an Object is a live instance in the read surface.
See: Data Model, Offline
Trait / Attribute
A Trait is a named set of Attributes — a reusable schema fragment that can be composed into multiple Entity types. A cross-cutting Trait like geo.Locatable or evidence.EvidenceBacked is defined once and applied wherever its semantics are needed.
An Attribute is a named field on a Trait. Every Attribute has exactly one Value Type that governs its shape, validation, storage mapping, and SDK codegen. Attributes are either plain (default) or statement-backed (opt-in per ADR-0004).
See: Data Model, ADR-0004
Statement
A Statement is the kernel’s representation of a fact asserted by a specific source, with full provenance: source, actor, evidence, confidence, validTime (when it was true in the world), transactionTime (when it was recorded), and authority (who can override it). Statements exist for facts that have multiple independent asserters and may disagree.
Statement-backing is opt-in per Attribute (ADR-0004). The default attribute is a plain value audited via the event log. Only source-reconciled, contested facts — geometry measured by GIS vs. geometry surveyed in the field, for example — are declared statement-backed. The Projection Engine resolves conflicts between statements using Authority rules to select the current serving value.
Statement-backing adds multi-source conflict resolution. It does not add auditability — all attributes are audited via the event log regardless.
See: Data Model, ADR-0004
Value Type
A Value Type is the type-safety atom of the kernel. Every Attribute, Action parameter, Event payload member, and Statement value has exactly one Value Type. Storage mapping, SDK codegen, validation, agent tool-schema generation, and (eventually) UI rendering all derive from it.
The MVP set is ~12 types: Text, Timestamp, EntityRef, Confidence, Distance, LineString, Point, Polygon, Status, Money, Capacity, FiberCount. All are authored using the full manifest schema (future-proof on-disk shape) but only validation, storage mapping, and SDK codegen are implemented in the MVP runtime. Versioning/upcasting, aggregation-safety, and per-type UI renderers are deferred (ADR-0007).
See: Data Model, ADR-0007
Action
An Action is the unit of write in the kernel — a coarse semantic intent declared as a contract (e.g. projects.CreateWorkPackage, evidence.SubmitSurvey). Actions are not field-level patches; they are named, typed operations with declared parameters (each carrying a Value Type). Every Action produces one or more Events.
Actions are coarse-grained by design: a queued offline action must replay meaningfully after a long gap, which requires semantic intent rather than column deltas. Actions carry client-minted idempotency keys so reconnect deduplication is exact.
Authority enforcement runs inside Action execution: every SDK→kernel call passes through AuthorityOperation. High-risk or irreversible Actions throw DENY_REQUESTABLE, requiring explicit approval.
See: Reality Kernel, Agent Runtime, Offline
Branch
A Branch is a definition/schema/code/policy overlay — “git for the ontology.” A Branch lets schema changes (new Entity types, new Attributes, updated Value Types) be tested off-main before merge, without affecting the operational read path.
Branch is in scope from the kernel skeleton. It is required for safe schema evolution and is the mechanism for testing Value Type version changes (ADR-0005).
Branch is not Scenario. See the next entry.
See: Branches and Scenarios, ADR-0005
Scenario
A Scenario is an operational-state overlay across entity instances — a “what if fiber-cut-sector-44 happens” simulation that branches the live operational state, not just the schema. Scenarios require copy-on-write delta storage and read-time merge of base + overlay under every RealityContext, taxing every read path.
Scenario is deferred past the first proof lifecycle (ADR-0005). The first operational loop has no need for it. Scenario is a SmartOps blast-radius simulation feature. Its mechanism may be validated in isolation (POC 9) but must not gate the operational loop or tax the operational read paths in the proof.
See: Branches and Scenarios, ADR-0005
Source of Truth / Consistency
The consistency model governs where current state lives and how read-your-write is guaranteed. The proposed hypothesis (ADR-0003, Proposed, spike-gated): an Action commits the event/statement log and the authoritative current-state row in one Postgres transaction. Read-your-write is served immediately from current state. Only secondary indexes — search, topology materializations, spatial, scenario overlays — are asynchronous projections.
This is not decided yet. The hypothesis is falsified if synchronous dual-write cannot hold p95 < 250 ms at 1M entities and 1K actions/min, in which case the fallback is CQRS with session-pinned read-your-write.
The Serving Store (previously called “Reality Store” — renamed per ADR-0002 to de-overload “Reality”) is the read surface maintained by the Projection Engine.
See: Consistency, ADR-0003
Writeback
Writeback is the kernel’s mechanism for propagating approved changes back to external systems — GIS, ERP, OSS. The kernel models the writeback as a first-class WritebackIntent with a full state machine (pending → dispatched → confirmed / failed → compensated), saga semantics, idempotency keys, and dead-letter handling.
The dispatch layer — the actual call to the external system — is stubbed in the proof, targeting legacy SmartInventory as the initial “real” connector. Real customer GIS/ERP/OSS connectors are post-proof (ADR-0010).
Topology / Blast-radius
Topology in the kernel means the connectivity graph of infrastructure — which spans connect where, which services depend on which spans, which customers are reachable through which paths. The kernel implements topology as Postgres adjacency tables with recursive CTEs for bounded traversals (trace path, k-hop continuity) and a precomputed service-dependency projection for blast-radius queries.
Blast-radius is the set of services, sites, and customers affected by a failure at a given point. It is served as a lookup against a maintained projection, not as a live deep traversal — the projection is maintained by the Projection Engine and is bounded by projection lag (ADR-0011).
Agent / Code-mode
An Agent in the kernel is a principal — an AgentPrincipal bound by a delegation envelope (allowed actions/realms, max risk class, rate and blast-radius caps). The primary agent substrate is code-mode: the agent writes code in the kernel’s typed SDK language that invokes Actions and reads, wrapping loops, branching, and batching around them.
MCP tools are thin single-shot wrappers over the same SDK for conversational use. Authority is enforced per SDK call, not in the prompt. High-risk or irreversible Actions throw DENY_REQUESTABLE; the agent’s code catches it and emits an approval request. The whole run is logged as a ToolTrace (ADR-0012).
Code-mode is the presentation type on AuthorityOperation from the source pack. The agent is built last in the proof (Phase 5) as a thin demonstrator, but the Action/read surface it depends on is designed for agent use from day one.
See: Agent Runtime, ADR-0012
Connector
A Connector is an external system that the kernel treats as an import source into the Data Plane or a writeback target via the integration realm. Legacy SmartInventory is the canonical connector — it is not migrated into the kernel; it runs untouched and connects in through the integration realm boundary (ADR-0009).
The connector model is how the “no private reality” doctrine applies to an existing running product: legacy reality is surfaced through a connector, not moved in bulk.
See: Legacy Connector, ADR-0009
Offline-first
Offline-first means the kernel is designed so that a field worker who loses connectivity can still queue Actions and sync when reconnected — without data loss or silent duplication. The kernel invariants that make this possible: client-minted IDs (no server-sequence), idempotency keys on every Action, expected-version optimistic concurrency, and conflict-as-first-class-outcome (a stale edit surfaces as a modeled reconciliation result, not a raw error).
The offline client stack (local cache, action queue, local evidence vault, offline maps, conflict inbox) is deferred post-proof. The kernel invariants that make it possible are non-negotiable from day one because they are expensive to retrofit (ADR-0013).