n-pxOS — White Paper & Master Ontology
A universal operating system for digital work. One runtime underneath; a different industry operating system on top. This document explains the idea, the architecture and the build — and contains the full machine-readable map of the economy that lets one runtime generate a thousand frontends.
§0Executive summary
Underneath every industry — law, insurance, commerce, healthcare, government — the same small set of moving parts repeats. Someone acts, on something; an event happens; a state changes; a decision is made; work flows; an artefact is produced; an outcome is reached; the system learns.
Those nine things are the whole backend of the economy. n-pxCore is that universal runtime. n-pxLabs dresses it as a specific industry's operating system — n-lawOS, n-insOS, n-commerceOS — each with its own buyer, vocabulary and screens, but all running on the same engine.
This white paper sets out the thesis, the two-layer architecture and how a real vertical (n-lawOS) is built on it. Attached is the Master Ontology: a structured, machine-readable map of 17 markets, 101 operating systems, 550 sectors and 7,591 vocabulary terms, every term tagged with the runtime primitive it maps to. That ontology is the bridge between market reality, customer language and the runtime — and the input that lets the system generate vocabulary, UI, workflows, data models and AI agents for any vertical.
§1The thesis
Every digital workflow, in every industry, reduces to the same shape. A claim and an order and a patient appointment and a trade are all the same kind of thing — an object with a lifecycle. "Submitted", "under review" and "approved" are states. "Settle", "dispatch" and "refund" are decisions that move an object from one state to the next.
If that is true, then the backend of the economy is finite and the frontends are infinite. You do not need to rebuild the engine for every industry — you build the runtime once, and generate the industry-specific operating system on top of it.
§2Architecture — two layers
n-pxOS has exactly two layers, and they must never be confused.
n-pxLabs — the design layer
n-pxLabs owns everything the customer sees and says: the market operating systems, the sector-specific UX, the customer vocabulary, the workflow experiences, the dashboards. Each vertical operating system is an independent frontend — but all are deployed onto the same runtime.
n-pxCore — the universal runtime
n-pxCore does not know about any industry. It only knows the nine runtime primitives. Everything else — every market, OS, sector, domain and word — is a frontend reality mapped down onto those primitives.
§3The nine runtime primitives
These nine concepts are the entire vocabulary of n-pxCore. Every customer term in the ontology — "claim", "policyholder", "shipment", "appointment" — maps to exactly one of them.
Who or what acts — a person, organisation, agent or machine.
What is acted upon — the core record with a lifecycle (a matter, claim, order, policy).
Something that happens at a point in time and moves things forward.
The current status of an object (draft, pending, approved, closed).
A choice that causes a transition (approve, settle, dispatch, refund).
The structured progression of states and actions toward an outcome.
A durable item produced, uploaded or relied on (a document, report, contract).
The result (won, settled, delivered, paid, certified).
What the system learns — rates, risk signals, bottlenecks, insight.
§4The ontology model
The ontology is a six-level hierarchy. The top four levels use the customer's own language; only the last level uses runtime words.
The OS test (what makes something an OS, not a sector)
An OS earns its name only if it has a distinct buyer, budget, frontend, state model, vocabulary and repeatable companies. If only the wording changes, it is a sector, not an OS. That discipline is what keeps the ontology a real asset rather than a marketing list — conveyancing and probate, for example, came through as sectors of n-lawOS, not separate operating systems.
The language rule
Customer-facing language everywhere except the runtime mapping. A user sees "Claimant", "SKU" or "Policyholder" — never "Actor" or "Object". The runtime words appear only when a term is mapped down to the engine.
§5How the ontology powers generation
The ontology is not documentation. It is the input to generation. Once a term is tagged with its runtime primitive, the system knows how to build it.
| If a term maps to… | …the generator produces |
|---|---|
| Object | a record with a lifecycle, a detail screen and an audit trail |
| Actor | a party with a role, permissions and a presence on the record |
| State | a status value in the object's state machine |
| Decision | a transition / approval action that moves the state |
| Event | a timestamped entry on the timeline + an automation hook |
| Artefact | a document/file surface with versioning and provenance |
| Workflow | a pipeline of states with gates and assignees |
| Outcome | a closing result + the metric it feeds |
| Learning | a dashboard signal / model input |
So a sector's vocabulary list is, in effect, a build order. From it the system can generate the data model, the screens, the workflow, the AI agents and the company-specific configuration — the same way n-lawOS was built by hand, but driven by the ontology.
§6The build — n-lawOS as the proof
The first vertical, n-lawOS, was built end-to-end and proves the model: its concrete data model is exactly an instance of the nine primitives.
| n-lawOS (real) | n-pxCore (primitive) |
|---|---|
| matter | Object |
| party / client | Actor |
| inbound call / email | Event |
| note state (draft → signed) | State |
| sign-off | Decision |
| the signed attendance note | Artefact |
| settlement / billed result | Outcome |
| edit-rate & usage metrics | Learning |
| the call → note pipeline | Workflow |
n-lawOS runs as one self-hostable instance inside each firm's own cloud; client data never leaves their walls; an AI workforce is present across every surface and is billed like a member of staff. The full build is documented separately — but the point here is that it is a single instance of the runtime the ontology generalises. Ship one vertical to prove it, then let n-pxLabs roll the rest out market by market.
§7Database schema
The ontology is built to be database-backed from day one. The tables mirror the hierarchy, with company-specific overrides layered on top.
The attached ontology.json and ontology.yaml load straight into this schema.
§8Roadmap
§9The Ontology
The full taxonomy — 17 markets, 101 operating systems, 550 sectors, 7,591 terms. Search anything, expand an OS to see its sectors, operating domains and vocabulary, and filter by runtime primitive.
Generated 14 Jun 2026 from the n-pxOS ontology workflow (17 market agents). Machine-readable: ontology.json · ontology.yaml. Customer language at every layer; runtime language only in the mapping.