One governed substrate for data, AI, security and mission work.
Five product areas, one spine, one identity model, one classification ladder, one audit chain, one isolation model. It runs on any hardware and every major cloud, and it stands on proven embedded engines with the scale-out and the intelligence built on top.
There is no second door
On most platforms, governance lives in a catalog service, and holds only for requests that go through it. Reach the engine another way and the policy is advisory. Here, row filters and column masks are compiled once and pushed into each engine as native predicates and projections, so the enforcement is beneath the query rather than in front of it.
| Stage | What happens |
|---|---|
| Request | From a BI tool on the PostgreSQL wire, a notebook or query kernel, an agent inside the cell, or a Redis-protocol client. |
| Security context | Built from the request: the entity, its grants, its clearance, and any purpose declared for the access. |
| Resolution | Policies resolved with deny taking precedence. |
| Compilation | Engine-native predicates and projections emitted; masks bound as functions. |
| Enforcement | Applied inside each engine type (SQL, OLAP, graph, document, key-value, search, stream and vector) beneath the query rather than in front of it. |
| Result | Masks applied to what remains, lineage captured into a per-cell tamper-evident chain, usage metered, and a read-audit event recording who looked. |
Honest about the foundation
Proven engines underneath, our intelligence on top
We do not pretend to have reinvented the storage engine. Each cell stands on proven embedded engines. SQLite for its transactional domains and DuckDB for analytics, inside a multi-model database engine. What System9 builds on top is the part that is genuinely ours: the scale-out layer, the one governance spine, and the executive-functioning engine. Boring foundations are a feature. They are the reason a cell runs on a laptop, a rack, or an air-gapped site with no change.
5 product areas
These are the groupings a buyer shops for. They are derived from shipped configuration rather than invented for a brochure, which is why each one maps to feature groups an operator can actually switch on.
Four surfaces that cross all five
Underneath: what actually runs in a cell
The product areas above are a commercial grouping. The runtime is a different cut, and the two deliberately do not line up, which is the point. Asking what System9 does for agents cannot be answered by reading one service, because the agent capability is spread across four of them.
| Service | What it owns |
|---|---|
| system | Identity, directory, licensing, setup, crypto provisioning, orchestration, knowledge, model serving, edge fleet, sensor intake |
| security | Crypto lifecycle, certificate authorities, policy enforcement, detection, response, compliance |
| storage | Object and block storage, erasure coding, tiering, integrity, replication |
| data | Database engines, catalog, lakehouse, streams, pipelines, ontology, scale-out, external protocols, clean rooms, data security |
| messaging | Durable publish/subscribe, streaming SQL, pipelines, transports, cross-cell replication |
| compute | Kernels, notebooks, sandboxes, source control, the coding agent, delivery pipelines, jobs, agent intelligence, functions, agent teams |
| metrics | Telemetry, metrics, alerting, health synthesis, cost analytics |
| node | The external gateway: public REST, GraphQL, the agent-tool server, SFTP, proxies, web application firewall, edge listeners |
| admin | Out-of-band control and diagnostics. Owns no database; attaches read-only |
The node service is the only front door
Every console, SDK, edge agent and external client authenticates and authorizes the same way, through one deny-by-default surface, before anything reaches a backend service.
The admin service owns nothing
It attaches read-only and aggregates. The separation is deliberate: the tool you reach for when things are broken cannot itself be the thing that breaks state.