ADR-0002: Brand and vocabulary hierarchy

Status

Accepted

Date

2026-06-24

Context

The architecture pack introduced a fresh, opinionated vocabulary (Reality Kernel, Universe, Realm, Statement, Authority, Projection) but left three things ambiguous:

Who the vocabulary is for — is “Universe / Realm” buyer-facing brand or internal engineering language?
An overloaded word — “Reality” is used for the kernel, the serving store, and the request context (“Reality Context”), plus the slogans (“operational reality,” “no private reality”). One noun, many referents, in code and docs.
A platform-name collision — the pack calls the umbrella “NetworkAccess,” while the company is “Lepton” and a prior umbrella was “Lepton Infrastructure Cloud.”

Telecom/utility buyers may hear “Universe/Realm” as gimmicky next to “Tenant/Domain,” but the team also wants a differentiated, future-facing identity rather than enterprise-beige.

Decision

Brand hierarchy:

Lepton — the company.
NetworkAccess — the Suite; the primary product brand over the whole application layer.
Reality Kernel — the horizontal, multi-component kernel beneath the suite. Internal + partner/extender-facing, not a buyer-facing brand.
SmartInventory / SmartPlanner / SmartOps / … — vertical modules built on the kernel.

Vocabulary split:

Kernel vocabulary (Universe, Realm, Statement, Action, Authority, Projection, Working Set, Branch, Scenario, Value Type) is internal and extender-facing. The team and extension authors speak it fluently; it is the language of the SDK, the docs for partners, and the code.
Product-surface language is chosen to match user expectations and to project a differentiated, agentic, reality-grounded, future-facing identity. The internal terms map to familiar surface terms where helpful (e.g. Universe → Tenant, Realm → Domain) but the product is not required to expose kernel nouns.

De-overload “Reality”: “Reality” is the kernel’s thematic banner, used once — for the Reality Kernel itself. Its components get distinct names. Specifically, the “Reality Store” is renamed Serving Store (a.k.a. Projection Store). “Reality Context” may stay as a kernel term but no component shares the bare word “Reality.”

Alternatives Considered

Take Universe/Realm/Reality Kernel to market as the brand

Pros: maximally differentiated, Palantir-style opinionated vocabulary.
Cons: risks reading as gimmicky to infrastructure buyers; couples brand to internal model churn.
Rejected in part: we keep the differentiated identity but express it on the product surface, not by shipping kernel nouns to buyers.

Rename everything to enterprise-neutral terms (Tenant/Domain/Ontology Core)

Pros: sounds like serious infrastructure software.
Cons: throws away a future-facing identity the team wants, and erases a coherent internal language.
Rejected: keep the opinionated internal vocabulary; choose the surface separately.

Defer naming as placeholder

Rejected: names calcify in code and SDKs regardless of intent; the “Reality” overload would harden into the partner API.

Consequences

“Serving Store” replaces “Reality Store” throughout code, ADRs, and partner docs. (Where other ADRs say “Serving Store,” that is the same component the pack called “Reality Store.”)
Marketing/product naming for the surface is an open, separate workstream — not gated by kernel terms.
The NetworkAccess-vs-Lepton ambiguity is resolved: Lepton is the company, NetworkAccess is the suite brand.
Sensitive to: a future decision to expose kernel concepts directly to buyers would supersede the vocabulary split.