Short answer: it's the first product off the line — and the line is now built. For the last stretch we've been forging the loom (the Vinxi kernel). None of it looked like NetworkAccess because a loom doesn't look like a garment. Here's how, week by week, the garment appears — and why every new screen, data model, and workflow after that takes days, not quarters.
"Ports, verbs, adapters, a commit path… none of this looks like the app we sell."
Correct. That's the engine, not the car.
NetworkAccess = the kernel, dressed. The hard part — trustworthy state, ontology, actions, replay — is done once.
Every NetworkAccess feature from here is an assembly, not an invention.
This is the payoff of building a kernel first. Every request your PMs and sales will ever make — "add a screen," "track a new thing," "automate that step" — is one of these five moves. None of them require touching the engine. That's what "keep growing" means, concretely.
Each week ships something a salesperson can put on screen and a customer can touch. Every headline is the outcome the business sees; the ◆ chips underneath are the kernel parts that made it cheap.
Kernel core, 14 ports, memory + Postgres backends, the ontology, governed Acts, a surface runtime, and a working fault → correlation → ticket engine are all in. Fiber/PON is already modelled.
The app has a face. The OS shell becomes NetworkAccess; the first surfaces show real inventory — OLTs, ONTs, splitters, fiber routes — read straight from the ontology. A customer sees their network.
The hero screen. A geographic / topology map over the fiber graph, alarms lighting up in real time. This is the demo that sells NetworkAccess in the first 30 seconds.
The "wow". The 214 alarms above collapse into one ticket, pinned to the true fault — the Sector-7 splitter — with a confidence score and a one-click Confirm. That click is a governed Act: logged, attributable, replayable.
From reactive to predictive. Series data + derivations run as background jobs and forecast degradation — "this link will breach in ~6 days." Sales story flips from "we fix faster" to "we fix before the customer notices."
An operator just asks. The agent's "tools" are the exact same syscalls the UI uses, so it can query, correlate, and draft a ticket — and every answer cites the evidence it read. No hallucinated network state.
For the technician up a pole. Voice front-end on the same agent. "Raise a ticket for OLT-12 and assign the north crew." Because the action is a governed Act, a spoken command is as auditable as a click.
Beyond faults. Provisioning drives, rollouts, and maintenance become projects — entities with stages, where every transition is an Act and every persona (planner, field engineer, System Owner) sees their slice.
The compounding week. A new customer needs a bespoke screen, a new asset type, a new approval flow? It's an install of a document + a surface declaration — shipped in a day, by a solutions engineer, without a kernel release. This is the moat: every subsequent product feature gets cheaper, not more expensive.
Everything on the wish-list is an assembly of kernel parts that already exist or are one small addition away. Here's each one, what it's made of, and the week it becomes demo-able.