Skip to content
Vinxi/Kernel THE BOOK OF RECORD

Start Here

What this is

Vinxi is a kernel for building operating systems over reality. Infrastructure operators run on fragmented truth — the GIS says one thing, the field crew another, the billing system a third, and every application keeps its own private copy of the world. Vinxi exists to end that: one governed, time-and-branch-aware model of reality, and one governed path for every read and write to it.

The names

Lepton (the company) builds vertical operating systems on Vinxi (the kernel). The products — NetworkAccess (network system-of-record-and-action, the pilot), Trafficure, SmartMarket, SmartBuild — are built on it: “NetworkAccess is powered by Vinxi.” The full naming law and retired-terms table: Naming.

The one resource, and the law

The kernel manages exactly one scarce thing: coherent truth about a slice of reality, plus the right to change it. The law that generates every boundary decision: the kernel owns a small closed set of mechanisms; userland composes open meaning on top; the seam between them is the governed path. If a feature doesn’t touch coherent truth or the right to change it, it is userland.

The shape, in five sentences

  1. Everything interacts through six verbs — Query · Act · Assert · Call · Subscribe · Schedule — the governed seam (The Seam).
  2. Kernel mechanisms project onto five planes — Process, Truth, World, Serving, Materialization (ADR-0002).
  3. The kernel owns ports (permanent contracts, P0–P26); technology lives in swappable adapters behind them (Ports & Adapters).
  4. The control plane is privileged userland on the same seam — never in the hot path.
  5. Everything external is a governed Resource, bound to the ontology through kernel-owned BindingPlans (ADR-0006).

The acceptance test

Four scenarios, each maxing out a different axis. If the kernel survives all four, it survives the domain — they are the acceptance suite:

ScenarioWhat it isAxis it maxes out
TrafficureMirror a live physical system from external feeds, then fork it to simulate interventionsStreaming flux + counterfactual branching
NetworkAccessThe daily system-of-record and system-of-action for a Jio-scale operator — every screen, query, automationScale + transactional correctness + being the whole OS
Company IT opsSync bidirectionally with systems that are themselves the source of truth, stay consistent, drive them backBidirectional sync + HTAP + consistency under external ownership
SmartMarketInstantiate a new custom reality per customer on the fly, when Varun Beverages and Cashify share almost nothing structurallySchema plasticity

What exists today

  • The Rust workspace: 18 vinxi-* crates (foundation → kernel → planes → registries → ports → adapters → services), shipping vinxi-kernel-server, vinxi-worker, vinxi-cli.
  • The NetworkAccess pilot program — the approved 6-month program on amplified demo data.
  • The M1 walking-skeleton plan — the golden thread: schema Act → entity Act → outbox → DecisionLog → materializer → ResolvedValue → Query → generated SDK.

Reading arc

  1. The Seam — the physics. Read this first, slowly.
  2. Ports & Adapters — the architecture contract.
  3. Low-Level Design — port-by-port depth.
  4. Data Plane — the read side.
  5. Surface Platform — the UI stack.

Then the Decisions and the Products. Whenever a word is unfamiliar, it is defined once in Concepts. The interactive explainers are a gentler on-ramp: the story · the board · the journeys.

Editing the Book

Canon lives in docs/ and builds into this site. Decisions follow the ADR discipline (ADR-0000); words follow the naming canon — one word per concept, because one wrong word here is a thousand mistakes later. How the Book works: How We Work.