Start Here

Infrastructure inventory software has a problem. Every major telecom, utility, and pipeline operator runs a different bespoke system — brittle, single-domain, built for one network type. When a carrier adds a gas distribution grid alongside their fiber plant, they buy a second product. When they try to model interdependency between the two, they write custom glue. When the glue breaks, the truth about what is physically in the ground lives in three systems that disagree. This is the status quo. It is bad and it is expensive.

Lepton NetworkAccess is the bet against that status quo.

What we are building

NetworkAccess is the Lepton suite for infrastructure inventory, planning, and operations. It is a clean-start, multi-utility platform — fiber today, oil and gas next, industrial networks and power grids on the same foundation. It replaces the prior Lepton architecture (Entity-Trait-Link, the Sanjaya plane, “one kernel, many definitions”) with a single, coherent model: the Reality Kernel (ADR-0001).

The brand hierarchy is precise (ADR-0002):

Lepton — the company.
NetworkAccess — the product suite; what buyers see.
Reality Kernel — the horizontal engineering platform beneath the suite; what builders and extenders speak.
SmartInventory / SmartPlanner / SmartOps / … — vertical modules built on the kernel.

Buyers never learn the kernel vocabulary. Engineers, extension authors, and agents speak it fluently.

The bet: one kernel, many domains, no private reality

The Reality Kernel is Palantir-Foundry-inspired: a horizontal operational kernel that any number of domain modules can extend — without each module running its own private truth.

The doctrine is: one kernel, many modules, no private reality. Every module contributes its domain facts across a governed contribution boundary into a shared kernel. There is no side database. There is no “fiber store” and “gas store.” There is a kernel, and every realm writes to it through the same contract.

The kernel is built around these concepts:

Universe / Realm — Universe is the top-level container (roughly: a tenant). Realms are lightweight namespaces within it — domain partitions, environment tiers, integration sources. They contribute reality to the kernel without owning a private store. (ADR-0008)
Statement / Evidence / Authority — every fact in the kernel is a Statement, stamped with who asserted it and with what evidence. Conflicting statements from different sources are not silently resolved; the kernel carries them and surfaces the conflict. (ADR-0004)
Action → Event → Projection — all writes are Actions. Actions produce Events. Events drive Projections into the Serving Store (the read surface). The flow is unidirectional and auditable. (ADR-0010)
Value Types — the type-safety atom. Every attribute has a Value Type: its shape, validation rules, and unit semantics. Value Types are what make Actions and reads generatable, type-safe contracts. (ADR-0007)
Branch / Scenario — change isolation; modelling “what if” without touching operational truth. (ADR-0005)

How the kernel is shaped: spine first, separation second

The kernel is domain-agnostic by construction. No kernel engine branches on a domain type. No kernel source file names a domain concept. This is not a convention — it is a hard guardrail enforced by a grep check in slice-1 acceptance (ADR-0015).

The build is sequenced deliberately:

Slice 1 — prove the spine. End-to-end: write → event → projection → read on a concrete domain (projects). Discharges the two architecture freeze gates (truth model, kernel language). Domain content lives in realms/ as definition objects, hand-registered into kernel registries at boot. The domain-agnostic guardrail is in force from day one.

Slice 2 — prove the separation. Introduce a v0 realm compiler and the install-into-a-Universe path. At this point, adding a second domain realm is a relocation — moving definitions from hand-registration to a compiled package — not a re-architecture of the engines. The guardrail is what makes slice 2 additive rather than expensive.

The legacy relationship

Lepton already runs SmartInventory — a live .NET 4.8 / Postgres product with real customers, ~1626 branches, a production database, and known security debt. The kernel doctrine says “no private reality.” That cannot mean “rewrite the live product before the kernel has earned trust” for a 2–3 person team. That is the platform-rewrite grave.

The decision (ADR-0009) is: greenfield kernel; legacy coexists as an external connector. SmartInventory is not migrated on day one. It runs untouched and becomes just another import source into the kernel’s Data Plane, and a writeback target via the integration realm. The kernel earns trust on net-new capability first. The migration path stays open; it is not closed, and it is not rushed.

AI-native operation

“Agentic” is not an add-on feature. It is a first-class identity pillar for NetworkAccess. The design constraint is: governance outside the prompt, not inside it. Authority enforcement lives inside tool execution, at the Action/SDK boundary, not in the agent’s system prompt. An agent that writes code against the typed SDK gets the same governed surface as a human using the UI.

The primary agent substrate is code-mode over the generated typed SDK (ADR-0012): the agent writes code that invokes Actions and reads, wraps loops and branching around them, and the kernel enforces authority at every SDK call. High-risk or irreversible Actions throw DENY_REQUESTABLE — the agent’s code catches it and emits an approval request; human approval becomes control flow. The whole run is logged as a single ToolTrace.

This is why the Action/read layer must be clean, typed, and generatable from day one — the agent is built last (proof Phase 5) as a thin demonstrator, but the surface it depends on is designed for it from the start.

How we work

The engineering practice runs on the Book — the single source of truth in docs/, organized by Diátaxis register. The Book has strict canon/scratch discipline: scratch goes in notes/ (gitignored, never committed); canon lives in docs/ and only enters via a deliberate promotion PR, reviewed and lint-checked. Architecture decisions are recorded as ADRs and are immutable once accepted — to change a decision, you write a new ADR that supersedes the old one.

Read How the Book Works before editing anything in docs/. Read ADR-0000 before filing an ADR.

The current architecture freeze is gated on two Proposed ADRs:

ADR-0003 (truth model) — resolved by the slice-1 POC spike.
ADR-0006 (kernel language) — resolved by a one-week TS-vs-Java build-off.

Neither may be marked Accepted until its gate runs and its result is recorded.