Optical relay. Autonomous operations. Distributed compute and storage fabrics. The orbital data infrastructure layer, complete.
Operate a space-native infrastructure layer that behaves like a distributed cloud region spanning orbital assets and terrestrial cloud endpoints.
Node-5 is the architecture STELLAR has been building toward. A constellation of coordinated data-center nodes connected by optical inter-satellite links, scheduled and replicated automatically, integrated with terrestrial cloud regions through documented APIs. Customers route jobs to "STELLAR / orbital region" the same way they route to a hyperscaler region today.
A mesh of compute and storage assets needs a backbone that scales with throughput, not bandwidth caps. Optical inter-satellite links replace the RF ISL used in Node-3 order-of-magnitude more capacity, lower latency, fewer regulatory constraints. Autonomy fills the gaps where ground contact is brief: nodes negotiate replication, failover, and customer policy among themselves between passes.
STELLAR Mesh exposes the orbital fabric to terrestrial customers as a documented cloud region: tasking, IAM, network policy, observability, billing. Workloads cross the boundary because the boundary is a routing decision, not a launch campaign. Earth and orbit become one delivery surface.
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 |
|---|---|---|
| Optical inter-satellite link | ~10 Gbps class optical ISL between nodes | Replaces the Node-3 RF ISL. Carries replication, autonomy state, customer traffic. Multiple links per node form the mesh fabric. |
| Mesh scheduler | Autonomous workload + replication routing | Each node negotiates job placement and replication policy with peers between ground contacts. Customer policy (locality, residency, durability) is honored without ground in the loop. |
| Distributed compute fabric | Heterogeneous compute lanes across mesh | Different node generations (Node-2/3/4 lineage) serve different workload classes. Customer jobs route to lanes that match SLA, locality, and policy. |
| Orbital storage fabric | Geo-aware replication, routing, policy controls | Storage is addressable across the mesh. Customers specify residency, durability, and replication factor; the fabric places objects accordingly. |
| Cloud handoff | Documented region API + IAM + observability | STELLAR exposes the mesh to Earth-side cloud customers as a region same primitives as a terrestrial cloud region, with the orbital fabric on the other side. |
| Refresh / sustainment | Scheduled mesh-member replacement campaigns | Nodes have finite operational lives. Sustainment campaigns add new nodes and retire old ones without service interruption. |
Each mission is justified by a specific new capability not just a larger payload.
Distributed compute fabric for space-native and Earth-facing workloads
Orbital storage fabric with routing, replication, and customer policy controls
Optical relay and autonomous operations across the network
Ground-cloud interoperability for enterprise-grade service delivery
Continuous, latency-aware customer routing across the mesh
Programmatic onboarding for new mission and cloud customers
The plan is broken into reviewable phases. Each phase ends in a deliverable a stakeholder can read.
Optical ISL contract, autonomy protocols, region-handoff API, and sustainment plan locked.
First four-node optical mesh demonstrates ISL, autonomy, and Earth-region handoff in operational service.
Scheduled launches expand mesh coverage and capacity. Sustainment campaigns retire and refresh nodes.
STELLAR / orbital region operates as a documented cloud region with continuous customer service and scheduled refresh.
A serious mission tracks risks honestly. Closed, mitigated, in design, and open items are listed without softening.
| Risk | State | Description |
|---|---|---|
| Optical ISL acquisition + maintenance | In design | Optical ISL is the highest-risk Node-5 subsystem. Vendor selection, pointing/tracking budget, and acquisition rituals are mission-defining. |
| Autonomy correctness at scale | In design | Mesh autonomy must be correct under partial failures, partial connectivity, and customer-policy conflicts. Validated against GroundLab mesh-twin and prior-mission telemetry. |
| Sustainment + retirement cadence | Open | A real region requires planned replacement. Sustainment cadence is built into the mesh operating model rather than improvised. |
| Hyperscaler integration scope | Open | Cloud-region handoff is partner-specific. Scope and contract negotiated as Node-5 nears operational state. |
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 |
|---|---|---|
| Optical ISL meets contracted throughput across pointing envelope. | On-orbit ISL link telemetry + acquisition statistics | Planned |
| Mesh autonomy honors customer policy without ground intervention. | Replay of customer-policy enforcement across pass-gap windows | Planned |
| Region API parity with documented terrestrial-cloud primitives. | Independent cloud-region certification suite | Planned |
| Sustainment cadence sustains contracted service availability. | Sustainment plan execution + availability telemetry | Planned |
Each mission is a step on a single staircase. These bridges spell out what comes from the prior step and what becomes possible after.
