Skip to main content

Core and edge

System9's core and edge are one product, not a full platform and a degraded client of it. "Core" and "edge" name locations, not two different builds. The same cell (the complete System9 stack) runs in a core data center or edge-racked at a sovereign, air-gapped, on-premises, or on-device site. The edge is the deployment the product is built for, so a capability that is weaker at the edge is weaker exactly where it matters most. What is genuinely a second runtime is the Edge Agent: a small tentacle that reaches where even an edge-racked cell cannot, and reads from and ingests to a cell without being one.

Two runtimes, one contract​

The product is delivered as two runtimes that implement the same concepts. The split is by role, not by location, a cell is the same stack whether it sits in the core or on an edge rack:

  • A cell: the full System9 stack, implemented in Python: every service, every database, the data platform, the agent system, and the security plane. A cell owns the data plane, it serves data, runs the lakehouse and catalog, and makes placement decisions. The same cell runs in a core data center or edge-racked on a sovereign site, an on-prem rack, or a device; an edge-racked cell is a location choice, not a lesser build. See the cell model.
  • The Edge Agent: a small, statically-linked, signed binary implemented in Rust, for field devices, workstations, IoT gateways, and tactical kits where even an edge-racked cell cannot run. It is a tentacle, not a cell: it holds a delegated identity from a parent entity, reads from and ingests to a cell, and carries a cryptographically-verifiable chain of custody on everything that leaves the device. It runs no lakehouse, no catalog, and no data placement of its own, those belong to the cell it serves.

Both are first-class. Neither is a subset of the other by accident, where they share a concept, they are held to the same contract on purpose (see parity below).

The pieces​

  • A cell: a complete System9 instance: the full data platform, agent system, and security plane. A cell is the thing that serves data. See the cell model.
  • The Edge Agent: the on-device agent that reads from a cell. It identifies itself cryptographically, sends telemetry, receives commands, executes workflow steps, and does local intelligence work, document extraction, entity extraction, offline authorization, against data a cell serves. It is a consumer and verifier, not a data-serving plane of its own.
  • A cell at the edge site: an edge deployment can run one or more cells at the site, in the same rack or zone as the devices, so the complete platform is present locally rather than across a link. A cell does not run on the device itself.

How they relate​

The distinction that makes the positioning precise:

  • The Edge Agent reads from a cell; it does not serve data. On its own it verifies signed attestations offline, pins peer keys with validity windows, and operates on data a cell provides. That cell may be remote, or in the next rack.
  • A cell at the site provides the whole platform locally. When a cell is deployed at the edge site, the Edge Agent's data plane is a short hop away rather than across a contested link, and serving, governance and settlement run at the site with no cloud in the loop.
  • Every cell runs the node service, which is the front door. So an Edge Agent connects to a node, and which node, and where it sits, is a deployment choice rather than a fixed topology.

Figure B1: core and edge. In both pictures the outlined box is the same Edge Agent (a consumer and verifier) and the filled box is a cell (what serves data). What changes is how far away the cell it reads from is: across a link on the left, in the same rack or zone on the right, where a cell at the site makes the edge a complete sovereign stack. A cell never runs on the device itself. The edge is not a degraded client; a capability weaker here is weaker exactly where it matters most.

Table equivalent

FormEdge Agent roleCell locationWhat runs locally
Thin edgeVerify and operate; delegated identityA remote cell, across a linkVerification, offline authorization, journaling: not data serving
Full sovereign stack at the siteVerify-and-operate layer on the deviceOne or more cells at the site, same rack or zoneThe whole platform: serving, governance and settlement, sovereign and air-gap-capable

The Edge Agent is the same in both pictures. What changes is how far away the cell it reads from is, and whether the whole data platform is present at the site.

A cell does not run on the device

It is worth being exact, because the shorthand "a cell at the edge" invites the wrong reading. The cell codebase does not run on the same device as an Edge Agent. A cell and an Edge Agent can share a rack or a zone, not a host.

A cell deployed at a site is simply a cell presence at that location for devices to connect to. It can replicate back to the core and stay in sync, or it can be its own node, a local core in its own right. Both are supported, and which one you choose is a deployment decision rather than a product difference.

What the Edge Agent does on-device​

Even the thin form is not a dumb pipe. Because field-time realities are first-class in the protocol, the Edge Agent carries real capability locally:

  • Cryptographic device identity. Each device generates its own keypair, sends a certificate-signing request over a one-time bootstrap channel, and is issued a short-lived certificate bound to a delegation token. The private key never traverses the wire.
  • Schema-pinned, mutually-authenticated calls. Every request is mutually-authenticated and stamps the wire-schema version, so a peer speaking a different version is rejected with a typed error rather than silently corrupting data, the same version-skew discipline the cell model applies across cells.
  • A durable, hash-chained journal. Work done offline is recorded tamper-evidently and drained to a cell when a link returns.
  • Offline authorization. Delegated grants are evaluated locally, so policy decisions do not require a round trip to a cell.
  • Local or governed cloud inference. On-device reasoning can use a local model or a hosted provider, admitted through the same governed interface, so a hosted model inherits the platform's governance rather than bypassing it. The agent runtime itself is covered under the Agent Platform.

The edge ↔ cell seam: identity, transport, and the sealed envelope​

The link between an Edge Agent and its cell is a governed seam, not a plain socket. Four disciplines hold it:

  • SPIFFE identity over mutual TLS. Every operational call runs over mutual TLS, and the Edge Agent's certificate carries a SPIFFE identity that binds its node and device into the certificate itself. A peer is what its verified certificate says it is, identity is never trusted from a claimed header. The device's private key is generated on-device and never traverses the wire.
  • Per-message signatures. Beyond the transport handshake, messages carry their own JSON Web Signature (JWS), so a message's authenticity survives independent of the channel it rode, including a store-and-forward hop.
  • Typed, specification-aligned error codes. Agent-to-agent calls return A2A-specification error codes, so a version-skewed or refused call fails with an actionable typed error rather than corrupting data silently, the same refuse-don't-fake-success discipline the transport ladder applies end to end.
  • A signed sync envelope that is transport-agnostic. What the Edge Agent sends home is a signed sync envelope, sealed at origin on the live heartbeat drain. Because it is sealed independently of the wire, it rides any carrier, a live mutual-TLS link, a courier, or sneakernet, and verifies on arrival regardless of how it travelled. On a heartbeat that just proved the cell reachable, the daemon drains the spool over the live mutual-TLS transport and hands each envelope to the cell; on any refusal or an unreachable cell it stays spooled for next time, so a link that comes and goes never loses data.

*Figure B2: the sealed sync envelope. The envelope is originated and sealed at the heartbeat drain and held in a durable spool, so it survives disconnection. When a link exists, the daemon drains the spool over the live mutual-TLS transport; when the device is dark, the same sealed envelope rides a courier or sneakernet. Either way it verifies on arrival by its own signature.

Table equivalent

StageWhat happensStatus
Originate + sealEnvelope sealed at origin on the heartbeat drainLive
SpoolHeld durably, survives disconnectionLive
Live-transport transmitSpool drained over live mutual-TLS on a good heartbeatLive
Courier / sneakernet rideSealed envelope carried and verified on arrival when darkLive
Cross-site / WAN pullPulling home partials not yet ridden backPlanned (network boundary)

Two-runtime parity: one decision, two runtimes​

When the core and the edge both implement one concept, they tend to drift, and a capability that is weaker at the edge undermines the whole positioning. So parity is an explicit engineering discipline, not a hope:

  • State the contract once, and hold both runtimes to it. The definition of a decision lives in one place; both runtimes are measured against it.
  • Check whether the other side already does it better before building. The goal is one best implementation reflected on both sides, not two half-answers.
  • Pin the parity with cross-language fixtures. Shared test fixtures assert that both runtimes make the same decision for the same input, so a divergence fails a test rather than shipping quietly.
  • Record owed work explicitly. Where a capability can land on only one runtime first, the other side is recorded as owed work rather than left to drift silently.

This discipline is why "core and edge are one product" is a property you can rely on rather than a slogan.

What is at parity today, and what is owed

Parity is measured. The edge matches the core on the topology selector and resolve path, the deny-closed egress-URL sentry, governed inference egress, and a per-peer attested reachability map, which it answers from peer-signed observations verified against each peer's member identity rather than from the core's countersignature. Same property, different mechanism; see the fabric.

Two are recorded as owed work on the edge rather than narrated as live: cross-cell enactment, where the handoff envelope and its signing purpose exist but nothing on the device enacts a received handoff, and edge egress-origin selection, where the topology module states that selecting an origin from a resolved set is not built. Where a capability can land on only one runtime first, the other side is tracked, not quietly narrowed.