Skip to main content

Deployment topology

A System9 deployment is chosen along a few independent axes, and every capability is designed to hold across the full grid they form, not a corner of it. The same code runs in every shape; there is no separate edition and no re-architecture between them.

The deployment matrix​

Two axes define the core matrix, and all four corners are first-class:

Single-cellMulti-cell (elastic in and out)
Sovereign / air-gappedSupportedSupported
Cloud-enabledSupportedSupported

A capability exercised only in a single networked cell says nothing about the others. That corner is the one that hides three assumptions at once: an assumption of connectivity (which fails sovereign), an assumption of a single cell (which fails at elastic scale-out), and an assumption of a coordinator (which fails across an air gap). The design states how it behaves in each corner first.

Axis 1: scale​

A single cell is already a complete platform. Scaling is a matter of composing cells, not of turning on a distributed mode.

  • Single cell. One machine, all services, all databases. The development configuration, the small sovereign site, and the edge configuration are all this shape.
  • Service group. Several cells grouped for durability and policy, erasure sets, replica placement, replication groups, and workload boundaries. A service group can span availability zones, regions, and clouds.
  • Federated estate. Many cells across many service groups, coordinated as peers by the fabric, with cross-cell singletons elected through leases and replication declared per table.

Elastic fleets are a supported shape. Roughly a hundred ephemeral cells can be launched for a single job, each a complete instance, which is why per-cell startup cost is treated as a scaling concern. Cells self-register into the fabric, coordinate, and drain cleanly when the job is done. See the cell model for the coordination mechanics.

The physical topology: region, zone, rack, cell​

Underneath the scaling shapes is a single physical topology model, and it is a first-class, editable, API-addressable object, not a tag on a resource. It is a strict four-level containment hierarchy, with the cloud provider as an orthogonal dimension rather than a level in the tree:

Figure A14: the physical topology. Region contains zone contains rack contains cell (the filled boxes) in a strict hierarchy. The cloud provider is drawn apart and connected by dotted edges because it is an orthogonal dimension: a cell is tagged with its provider independently of where it sits in the tree, so "which region" and "which cloud" are separate constraints. This one model is what placement, residency, egress ownership and replication scope all resolve against, one answer to "where does this run, and where may it go," instead of five.

Table equivalent

ElementKindContainsRole
Regiontree level (1)zonesCoarsest boundary; typically a jurisdiction
Zonetree level (2)racksAvailability boundary within a region
Racktree level (3)cellsFailure domain; what an erasure or replica set can be required to span
Celltree level (4, leaf)The unit of deployment; a whole-platform instance
Cloud providerorthogonal dimensionTags a cell independently of its tree position; not a level in the hierarchy

Because every placement question resolves against this one model, it is consumed rather than merely displayed: storage shards, agent workflow steps, database shards, egress ownership, and replication scope all resolve against the same topology. A cost matrix over it makes moving data or work between any two points an economic decision, not merely a topological one.

Axis 2: connectivity, sovereign by default​

Most platforms are a cloud service first, with on-premises and disconnected operation offered as a port or an exception. System9 inverts that: sovereign and air-gapped operation is the default mode, and the cloud is the option.

Concretely, a cell needs no vendor control plane, no external database licence, and no call home to start, to license itself, or to enforce policy. The supporting design choices:

  • Nothing needs the network to start a cell. Startup is designed to complete with no outbound connection to a vendor.
  • Offline, signed licensing. Licences are signed files with no phone-home on the enforcement path.
  • Local models. Inference can run entirely on local models, supplied as signed offline bundles rather than pulled from a model vendor at run time.
  • Assisted-support telemetry is off by default and deny-by-default on consent . There is no implicit opt-in, and it gates the observability plane only, never startup.
Where the boundary sits

Sovereign, air-gapped operation is the design's load-bearing differentiator, no mainstream cloud data platform offers it as a first-class mode. It is described here as a designed capability. The right way to evaluate it is to test it: ask what starts without egress, what licenses without a call home, and what enforces policy with the link cut.

Axis 3: the edge, and placing cells at a site​

This is the axis that is most often misread, so it gets stated precisely.

"The edge" is a deployment, not only a piece of software. A cell can run in the cloud, on-premises, or at an edge site, in a rack near the devices. That gives an edge deployment three forms:

(a) Edge Agent → remote/nearby cell     the agent reads from a cell elsewhere
(b) Full cell at the edge               a complete platform, on the device
(c) Edge Agent + cell at the site       same rack or zone, full stack, local
  1. Edge Agent reading from a cell. A small signed binary on the device holds a delegated identity and operates on data a cell serves, the cell may be nearby or remote. The Edge Agent is a consumer and verifier: it verifies signed attestations, enforces policy locally, and journals what it does. It is not itself a data-serving plane.
  2. A cell at the edge site. A complete System9 instance runs in a rack at the site, not on a device, so the entire data platform, catalog, engines, object storage and the exchange economy run locally, sovereign and air-gapped, with no cloud in the loop.
  3. Both. Devices running the Edge Agent, connecting over the local network to one or more cells at the same site. Serving, governance and settlement happen at the site rather than across a link. This is the full sovereign stack at the edge.

A site cell can be either of two things, and this is a real deployment choice rather than a product difference:

  • A satellite of the core, replicating back and staying in sync.
  • Its own node, a local core in its own right, which is the shape a genuinely disconnected site takes.

Every cell runs the node service, which is the front door, so an Edge Agent connects to a node and the question is only which one and where it sits. A device can reach a node at the core, a node at its own site, or a node somewhere in between, whichever makes sense for the deployment.

The cell does not run on the device

A cell and an Edge Agent can share a rack or a zone. They do not share a host. The cell codebase does not run on the same device as the Edge Agent, and a page that implies otherwise is wrong.

What a site cell provides is a cell presence at that location for devices to connect to, which is a different and more useful claim: it puts the data plane a short hop away instead of across a contested link.

The key positioning follows from the difference between form (1) and forms (2) and (3): the Edge Agent alone consumes and verifies, but a cell at the site provides the whole platform there. See Core and edge for how these pieces relate as one product.

An edge deployment plans for the network it actually has. Intermittent, contested, and absent links are modelled as states, and the Edge Agent selects a transport by environment rather than by preference:

TransportUse caseBandwidth profile
Managed network (mTLS)Standard connected sitesHigh, low latency
Message-queue over cellularConstrained devices, intermittent linksMedium, buffers
DNS-over-HTTPSRestricted-egress networksLow
Long-range low-power radioLong-range low-bandwidth tacticalVery low
Ad-hoc mesh radioTactical meshMedium, mesh-aware
SatelliteRemote, often degradedVariable
Physical media ("sneakernet")Air-gapped bundle transferOne-shot, batched

When a link is down, work is captured to a durable, hash-chained on-device journal and drained to a cell when connectivity returns. Air-gapped peers are modelled as absent edges, not failed peers.

Offline supply paths​

A sovereignty claim is only as good as the paths that could violate it, so the supply lines a deployment normally reaches the network for each have a signed, offline alternative:

ConcernOffline path
LicensingSigned licence files; no phone-home on the enforcement path
Model supplySigned model bundles, staged and installed without vendor egress
Certificate issuanceCell-local certificate authority: issuance, rotation, and revocation are cell-side operations
Edge provisioningSigned capability bundles delivered over any supported transport, including physical media
Data movementSigned manifest bundles over physical media and store-and-forward transports

Classified and export-controlled sites​

For the most restricted deployments the design adds a canonical five-level classification ladder (PUBLIC < INTERNAL < CONFIDENTIAL < SECRET < TOP_SECRET), export-control gating at the point a cell joins a restricted service group, and smart-card (mutual-TLS) authentication that the gateway can terminate itself, no external reverse proxy required. These controls are covered as capabilities under Security and Compliance.