Isolated tenancy. Protected storage. Compliance evidence. The orbital region built for governments, enterprise resilience programs, and protected-data workloads.
Create a secure operating model for government, enterprise resilience, protected storage, and critical workloads that need strong isolation.
For a class of customers sovereign defense, regulated finance, critical infrastructure resilience the question isn’t whether STELLAR can run their workload. It is whether STELLAR can prove the workload was physically isolated, controlled, and auditable from job submission through delivery. Node-4 is the architecture answer.
Node-4 introduces a dedicated cluster lane: isolated compute, isolated storage, controlled command authorization, and a separate operations workflow. Tenant boundaries are enforced in hardware, not just software. Every action tasking, execution, delivery, key handling emits audit-grade evidence the customer can reproduce.
Beyond defense, Node-4 unlocks enterprise resilience: continuity escrow, out-of-region backup, sealed-storage delivery to a destination of the customer’s choosing. The operating model is "physically separated infrastructure with verifiable evidence", not "more cloud regions on Earth".
The profile is the mission’s physical truth every architectural choice descends from these numbers.
The mission is the sum of these subsystems and the way they constrain each other.
| System | Specification | Design note |
|---|---|---|
| Tenant isolation | Hardware-enforced compute + storage lanes | Sovereign tenancy is partitioned at the hardware layer, not just software. No shared state, no shared scheduler queues, no shared key material with the commercial tenant. |
| Cryptographic services | On-orbit HSM, customer-key sealed storage | Customer-controlled keys live in a hardware security module. Storage is sealed to those keys; delivery requires customer-side unsealing. |
| Authorized command path | Dual-control command authorization, restricted ground sites | Two-person command rules, restricted ground-station list, rate-limited command channel, and full operator-action audit log. |
| Compliance evidence | Replayable audit log + signed mission record | Every job, command, key operation, and delivery is hash-chained and signed. The customer receives a sealed mission record after every operational period. |
| Continuity profile | Out-of-region escrow, secure handoff to customer storage | Sovereign products can be staged to alternate ground sites, alternate cloud regions, or sealed offline media depending on the customer’s continuity policy. |
Each mission is justified by a specific new capability not just a larger payload.
Tenant isolation and zero-trust access model
Protected orbital storage region with controlled handoff
Dedicated mission operations and compliance evidence
Resilience architecture for continuity and secure escrow
Cryptographic key handling with HSM-backed signing
Audit-grade replayable evidence for every operator action
The plan is broken into reviewable phases. Each phase ends in a deliverable a stakeholder can read.
Tenancy model, key model, evidence format, and ground-segment scope reviewed with lead sovereign customer.
System design + accreditation evidence reviewed by customer’s authorizing official.
HSM integration, isolated-lane qualification, restricted ground-segment integration.
Either as a Node-3 cluster partition or a dedicated launch, depending on customer policy.
Steady-state operation under the lead sovereign customer with formal compliance evidence delivered each cycle.
A serious mission tracks risks honestly. Closed, mitigated, in design, and open items are listed without softening.
| Risk | State | Description |
|---|---|---|
| Regulatory framing | In design | Jurisdictional posture, export control, and data-residency framing are non-trivial and customer-specific. Engaged early in mission design. |
| Operations cognitive load under dual tenancy | In design | Sovereign and commercial operations cannot blur. Dedicated operator workflow + restricted-access tooling close this risk. |
| Key escrow / customer key management | In design | Customer-managed keys, on-orbit HSM, and recovery scenarios are an architectural item closed at PDR with the lead customer. |
| Counter-resilience tradeoffs | Open | Some sovereign customers will require operational changes (restricted sites, dual-control command) that lower availability. Documented as policy, not bug. |
The right way to read a mission page: claim → evidence → state. If a row is in the wrong state, the page is what is broken not the program.
| Claim | Evidence | State |
|---|---|---|
| Tenant isolation holds under hostile-tenant simulation. | Penetration testing + isolation-evidence audit | Planned |
| Customer-controlled keys never leave authorized boundary. | HSM operations log + customer-side unseal trace | Planned |
| Sealed mission record is independently reproducible. | Customer-side replay against signed audit log | Planned |
| Restricted ground-segment behaves as specified under degraded availability. | Restricted-site failover drill + audit | Open |
Each mission is a step on a single staircase. These bridges spell out what comes from the prior step and what becomes possible after.
Node-4 builds on the Node-3 cluster scheduler and replication model but adds hardware-enforced tenancy, customer-controlled keys, and audit-grade evidence as first-class platform features.
← Open Node-3Node-4 stabilises the security and compliance model. Node-5 turns the entire fabric into a distributed orbital cloud network optical relay, autonomy, and Earth-cloud interoperability across every node.
Open Node-5 →