What kind of system this is
System9 is a distributed intelligence platform. The unit of scale is an intelligence rather than a cluster: a cell is one, a node is an intelligence composed over cells, an organization is one composed over nodes. Each level has its own view, its own budget and its own ability to refuse.
It carries a full data platform because an intelligence needs memory, senses and a record, the storage is in service of the reasoning, not the other way round. Under the covers it stands on proven embedded engines (SQLite and DuckDB) inside a multi-model database engine; System9 adds the scale-out layer and the intelligence on top.
Which means it is not a low-latency transactional store and not a cache, by design. It speaks the PostgreSQL wire and the Redis protocol so the systems that are excellent at those jobs participate under the same governance, and it federates a warehouse in place rather than asking you to move it.
Benchmarking a reasoning substrate on a warehouse benchmark measures the wrong thing. We publish no performance figure in either direction, and we would treat a vendor who did with the same scepticism.
We work with them too
How we fit alongside your stack
You do not have to move to us to get value from us. System9 connects to and federates the data platforms you already run, and it can sit over them as an assessment and governance layer. Its Data Security assessment reads the effective-access graph of Snowflake, Unity Catalog, BigQuery and Microsoft Fabric; the estate assessment reaches across clouds, on-premises storage and air-gapped sites at once and signs every finding. Where you run Databricks, Palantir Foundry or a warehouse of your own, we assess and report on it rather than ask you to rip it out.
At the category level, not a dated, named-vendor grid
| Feature | SYSTEM9 | Warehouse-first platform | Security-first platform |
|---|---|---|---|
| Sovereign, air-gap-capable by default | Default mode | Cloud-first | Cloud-first |
| One substrate for data + AI + security + mission | All four, one spine | Data & AI | Detection & response |
| Agents as accountable directory entities | API keys | API keys | |
| Governance compiled into the engine, not a catalog service | In the query plan | Catalog service | |
| Runs on your premises, on your keys | Mostly managed | Mostly managed | |
| Connects to and assesses the platforms you already run | — | Partial |
A category comparison, on purpose. A vendor’s feature set moves quarterly, so we do not publish an undated tick grid against a named product. We will put a dated one, against your actual stack, in writing.
Five claims, each with the test that settles it
A claim you cannot test is a claim you should not buy on. Each of these carries the question to ask, of us first, then of everyone else in your evaluation.
Sovereign and disconnected as the default mode
Not a deployment SKU. Nothing phones home to start, proven for every startup entrypoint by a test that installs a socket guard before any application import. Licensing verifies entirely offline. A cut-off cell holds last-known-good signed policy, issues its own certificates from a subordinate authority, and reasons on a local model.
How to test it
Ask what starts without egress, what licenses without a call home, what enforces policy with the link cut, and what answers an estate-level question with half the estate unreachable.
One substrate under data, AI, security and mission work
Assembled stacks need an integration at every boundary, and every boundary is a second audit trail and a place where a classification label gets lost in translation. One identity model, one classification ladder, one audit chain and one isolation model is a structural property, not a feature.
How to test it
Ask how many identity models are involved in answering “who accessed this record, and under what clearance”, and how many queries it takes.
Agents governed as accountable entities, not as API keys
Most platforms govern models and data access. This governs the agent: an entity in the same directory as people, holding a bounded delegation of a named person's authority, with a budget checked before execution and a gate at the action boundary that can refuse.
How to test it
Ask what the agent's identity is, whose authority it is acting under, what its budget is, and what would have stopped it.
Clean rooms as a structural partition rather than a filter
Aliasing so a kernel never sees source table names, code signed by several reviewers before it can run, and an egress gate that terminates a run on its first failure. The concept exists elsewhere; running it on your own premises, air-gap-capable, does not.
How to test it
Ask where the clean room runs, and what happens to the room if the vendor's cloud is unavailable.
Mission and industrial workloads on the same governed substrate
Radar, sonar, LiDAR, RF and satellite sensing, tactical networking, plant protocols and prognostics, inheriting the same identity, classification and audit model as the finance data. Very few vendors hold both ends of that.
How to test it
Ask whether the plant data and the enterprise data are governed by the same policy engine, or by two.
| Element | What it is |
|---|---|
| The assembled stack | Five products (data platform, security stack, identity system, AI governance and edge estate) each with its own model of who a user is and what a label means. |
| The seams | Four boundaries between the five products. Each is a second audit trail and a place a classification label is lost in translation, where the incident happens. |
| One governed substrate | One identity, one classification ladder, one audit chain, one isolation model and one refusal path underneath all of it, because it was built as one substrate rather than assembled. |
| The consequence | A whole class of seam incident becomes structurally impossible rather than merely monitored. |
The one question
Can you run your data platform, your AI, your security operations and your mission workloads on one governed substrate, with a cryptographic identity and a tamper-evident record for every actor, including agents, fully disconnected from the internet, with no vendor holding your keys?
If the answer from every vendor on your list is yes, the axis is not decisive and you should choose on something else. In our experience it is not.
Proof you can run in the room
A demonstration beats a reference
A reference tells you a platform worked for someone whose constraints you cannot inspect. A demonstration tells you what it does under yours. So the central claims are built to be shown, not attested: watch the gate refuse an action, and verify a signed receipt with no service running.
Propose an action
Read a masked sales view to build a quarterly report
Analyst agent · delegated by a named person
The logic is real: the reflex scores the effect on others; foresight can only make a permit more cautious. Inputs are illustrative, not a live system, no customer data.
$ s9 verify report.sig --key node.pub --artifact findings.json
✓ signature valid. Ed25519
✓ artifact digest matches receipt
✓ audit chain intact, no gap events
no network used · verified fully offline