Skip to content

UNENROLLED

DISCOVERED

ATTESTING

IDENTITY_ISSUED

POLICY_BOUND

PLAN_STAGED

LOCAL_READY

DEGRADED

QUARANTINED

REVOKED

Plan v2 · signed, immutable

Instrument · observing

Site · journal, lease

Fleet controller

10 km

20 km

30 km

40 km

Mast

Building the scene…

Software · Explainer

The node agent, at work.

A node agent that enrols, attests and updates every node. A fleet view that shows each node with its state, its plan and its evidence. Signed plans that roll out in waves and roll back on their own. A journal that keeps observing when the link drops.

Enrolment states
10
Transitions
42
Protocol flows
12
Standards drawn on
48

01 · Enrolment

No implicit trust. Ten states.

A node boots with nothing but its hardware. It is discovered, attests with measured boot evidence, receives an identity, binds a signed policy and stages a plan before it may run anything. Pick an outcome and run it; each move shows the guard that allowed it.

Outcome

Run

State
UNENROLLED
Last guard
–
Transitions in the machine
–

02 · Fleet

Every node, its state, its evidence.

The fleet view is a projection built from evidence, not from labels nodes report about themselves. Filter by state and watch nodes move as plans land and links come and go.

Show

03 · Signed plans

Waves, health gates, a way back.

A release is built from controlled source with an SBOM and provenance, signed, compiled into an immutable plan and rolled out in waves inside a blast-radius limit. Every node verifies the plan, applies it, checks health and keeps its last known-good state.

Nodes on the new plan
–
Rolled back
–
Nodes exposed to the fault
–

04 · Store and forward

The link drops. The site keeps observing.

When the central path is lost, the site keeps operating inside its authority lease, journaling events with their identities unchanged. On reconnect it sends a replay batch; dispositions come back per event and conflicts stay explicit.

Connectivity state
CONNECTED
Events journaled
–
State at reconnect
–

05 · the NXS Observatory app

Plan the site before a bolt is turned.

the NXS Observatory app models a site as a team: where the mast goes, what it can reach, which instruments fall inside the radio horizon. Over a smooth Earth with standard refraction the horizon is d = 3.57 (√(k·h₁) + √(k·h₂)) km, k = 4/3; over real terrain, line of sight decides.

Radio horizon
–
Instruments inside it
–

06 · Integrations

Typed contracts to the systems you run.

The runtime speaks the standards the observing world already uses, so SCADA, GIS and data platforms connect by contract, not by custom glue. Pick a standard to see the role the protocol gives it.

Standard
–
Standards the protocol draws on
–
Building the scene…
Software · Explainer

The node agent, at work.

A node agent that enrols, attests and updates every node. A fleet view that shows each node with its state, its plan and its evidence. Signed plans that roll out in waves and roll back on their own. A journal that keeps observing when the link drops.

01 · Enrolment

No implicit trust. Ten states.

A node boots with nothing but its hardware. It is discovered, attests with measured boot evidence, receives an identity, binds a signed policy and stages a plan before it may run anything. Pick an outcome and run it; each move shows the guard that allowed it.

Outcome
Run
    State
    UNENROLLED
    Last guard
    –
    Transitions in the machine
    –
    02 · Fleet

    Every node, its state, its evidence.

    The fleet view is a projection built from evidence, not from labels nodes report about themselves. Filter by state and watch nodes move as plans land and links come and go.

    Show
    03 · Signed plans

    Waves, health gates, a way back.

    A release is built from controlled source with an SBOM and provenance, signed, compiled into an immutable plan and rolled out in waves inside a blast-radius limit. Every node verifies the plan, applies it, checks health and keeps its last known-good state.

      Nodes on the new plan
      –
      Rolled back
      –
      Nodes exposed to the fault
      –
      04 · Store and forward

      The link drops. The site keeps observing.

      When the central path is lost, the site keeps operating inside its authority lease, journaling events with their identities unchanged. On reconnect it sends a replay batch; dispositions come back per event and conflicts stay explicit.

        Connectivity state
        CONNECTED
        Events journaled
        –
        State at reconnect
        –
        05 · the NXS Observatory app

        Plan the site before a bolt is turned.

        the NXS Observatory app models a site as a team: where the mast goes, what it can reach, which instruments fall inside the radio horizon. Over a smooth Earth with standard refraction the horizon is d = 3.57 (√(k·h₁) + √(k·h₂)) km, k = 4/3; over real terrain, line of sight decides.

        Radio horizon
        –
        Instruments inside it
        –
        06 · Integrations

        Typed contracts to the systems you run.

        The runtime speaks the standards the observing world already uses, so SCADA, GIS and data platforms connect by contract, not by custom glue. Pick a standard to see the role the protocol gives it.

        Standard
        –
        Standards the protocol draws on
        –

        07 · Scale

        One block, repeated from a node to the globe.

        The smallest unit is one node running one agent. A site is a few nodes sharing a journal and a clock; a cluster is several sites behind one controller; a region is clusters on a shared backbone; the global network is regions federated by contract. Each level reuses the same enrolment, plans and evidence, so growth adds copies of a known block rather than new kinds of system.

        Sources Verma et al., “Large-scale cluster management at Google with Borg”, EuroSys 2015

        08 · Telemetry

        Signals the fleet can reason about.

        Each agent emits metrics, logs and traces in the vendor-neutral OpenTelemetry format, tagged with the node’s identity and the plan it runs. A collector at the site batches and filters them before they cross the link, and the fleet keeps what operators actually query. Because the format is open, the same signals feed the console and any monitoring system a customer already runs.

        Sources OpenTelemetry specification; OpenTelemetry Collector

        09 · Supply chain

        Every artefact traces back to its source.

        A release comes from a scripted, hosted build that records what went in and how. Its provenance and a software bill of materials travel with the artefact, bound to it by the signature, and a node refuses anything that does not verify. The practice follows the secure software development framework and the SLSA levels for build integrity.

        Sources NIST SP 800-218, Secure Software Development Framework, version 1.1; SLSA specification, version 1.0

        10 · Operations

        A large fleet, run by exception.

        At fleet scale the console works by exception. Service level objectives define what healthy means; an error budget decides whether a rollout may continue or must pause; routine work that grows with the fleet is automated rather than staffed. A fault opens one work order with its evidence attached, so the technician arrives knowing which part and which plan were involved.

        Sources Beyer, Jones, Petoff and Murphy (eds.), Site Reliability Engineering, O’Reilly, 2016, “Service Level Objectives”; Beyer, Jones, Petoff and Murphy (eds.), Site Reliability Engineering, O’Reilly, 2016, “Eliminating Toil”

        11 · Lifecycle

        From first boot to retirement.

        A node’s software life has five moves: it enrols, runs its plan, takes signed updates, recovers to its last known-good state after a fault and is finally retired, its identity revoked and its keys destroyed. Platform firmware resiliency guidance describes the same arc underneath: protect the image, detect corruption and recover, so a bad update never becomes a permanent outage.

        Sources NIST SP 800-193, Platform Firmware Resiliency Guidelines

        12 · Buyers’ questions

        What buyers ask before they commit.

        Can we leave and take our data? Records stay in open formats behind typed contracts, so they export without translation. What happens offline? The site keeps observing inside its lease. Who can change a node? Only a signed plan within policy. What will an auditor see? Signed receipts per node and per release. Supply chain risk guidance frames these as questions every acquirer should ask.

        Sources NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations