Every orbital data center starts in software. GroundLab is where the operating model, control loop, and customer workflow are proven in code before funded flight hardware.
Build the mission simulator, software-in-the-loop control path, hardware-interface emulator, thermal duty-cycle model, and customer workflow emulator that every later orbital node depends on.
Orbital data centers operate inside a strict envelope of power, thermal, contact, radiation, and propellant. A mistake in any of those domains compounds a dropped command becomes a missed pass, becomes a thermal excursion, becomes a safe-mode lockout. GroundLab exists to discover and retire those mistakes in executable software before any flight hardware is committed.
GroundLab is a permanent mission rehearsal environment that mirrors the planned Node-1 payload behavior without claiming funded hardware access: compute lanes, storage queues, command authority, thermal limits, contact windows, eclipse cycles, radiation-like resets, and operator commands are all emulated through strict interfaces. Every payload software build runs against this twin before it can become a flight-candidate baseline.
GroundLab’s output is not a paper it is a frozen, testable software baseline plus a working operations model: tasking workflow, command authorization rules, pass scheduling, fault response, downlink reconciliation, and customer delivery evidence. Hardware qualification and flight heritage remain later gates, but the software proof can be real now.
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 |
|---|---|---|
| Mission simulator | Real-time orbit + contact + eclipse model | Generates realistic mission state pass timing, link availability, sun vector, eclipse, battery state-of-charge, radiation events and injects it into the payload software stack at the same cadence the bus would. |
| Compute payload emulator | FPGA-lane + management-CPU behavior model | Software model of the planned compute path: workload lanes, watchdog behavior, reset recovery, checkpointing, and resource limits. Real board selection and qualification remain future funding and partner gates. |
| Storage and receipt emulator | Integrity-checked queue + replayable product ledger | Persistent product queue with hash-chain integrity, priority ranking, and replayable delivery receipts. Tested against contact-gap, storage-pressure, and simulated corruption scenarios. |
| Thermal model | Coupled compute load → heat path → radiator sizing | Closed-loop simulation: a compute burst raises waste heat, which is rejected through cold-plate / loop-heat-pipe / radiator paths and capped by orbital hot/cold case envelopes. Drives duty-cycle policy. |
| Operations console | Tasking, scheduling, command authorization, delivery | The same UI and command path that mission ops will use in flight. Every action is logged and reconciled against the simulator’s expected behavior. |
| Customer-API prototype | Job submission, policy, receipt, callback | A documented HTTP API + customer SDK that submits jobs into the queue, returns receipts, and reconciles delivery. Used to onboard early design partners against the simulator. |
Each mission is justified by a specific new capability not just a larger payload.
Node digital twin for orbit, power, thermal, and contact windows
Software-in-the-loop workload execution and restart tests
Hardware-interface emulation for bus, comms, storage, and command boundaries
Mission operations rehearsal for tasking, downlink, and delivery
Ground-cloud API prototype for early customer workflow testing
Flight-candidate software baseline used by every later mission gate
Repeatable thermal duty-cycle simulation tied to compute load
The plan is broken into reviewable phases. Each phase ends in a deliverable a stakeholder can read.
Stand up mission simulator, interface emulators, digital-twin assumptions registry, operations console, and customer API contract.
Run a synthetic 30-day orbital cycle end-to-end: tasking → execution → storage → downlink → delivery receipt.
Two design partners run real workloads against the customer API. Feedback drives the Node-1 service contract.
Software, operations procedures, interface contracts, and customer API are version-locked. Hardware qualification remains a separate funded gate.
A serious mission tracks risks honestly. Closed, mitigated, in design, and open items are listed without softening.
| Risk | State | Description |
|---|---|---|
| Simulator fidelity vs. real orbital state | In design | The simulator must remain measurably faithful to expected orbital behavior drift introduced by Node-1 telemetry is the calibration loop. |
| Software baseline drift | Mitigated | Every Node-1+ software build branches from the frozen GroundLab baseline. Regression and mission-rehearsal suites gate every cherry-pick. |
| Customer-workflow assumptions | Open | API ergonomics, policy model, delivery format are validated only through design-partner usage. Closed when first paying customer signs. |
| Thermal model conservatism | In design | Thermal margins driven by model assumptions will be re-baselined against later lab, partner, and flight telemetry as funding unlocks hardware access. |
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 |
|---|---|---|
| The flight software model recovers from simulated compute-lane reset without losing mission state. | SIL fault-injection campaign with deterministic reset/restart evidence | Closed |
| Priority products remain deliverable across modeled AOS, marginal-link, and LOS windows. | Executable degraded-link campaign with queue integrity and delivery receipt evidence | Closed |
| Safe-hold freezes nonessential work while preserving customer data. | Executable safe-hold recovery campaign with checkpoint preservation and operator recovery path | Closed |
| Modeled mission behavior stays inside release-gate limits across bounded variance. | Seeded Monte Carlo mission-assurance campaign with explicit hardware limitations | Closed |
| Storage queue survives 24-hour contact gap without product loss. | Simulated 48-orbit no-contact scenario | Draft |
| Customer job → execution → delivery receipt loop closes in under 90 minutes. | Design-partner end-to-end run, ground-cloud telemetry | Planned |
| Thermal duty-cycle policy keeps simulated payload inside modeled hot-case margin. | Model assumptions, sensitivity report, and thermal-duty scenario outputs | Draft |
Each mission is a step on a single staircase. These bridges spell out what comes from the prior step and what becomes possible after.
