Preprint ·cs.DC - Distributed Computing ·arXiv:2605.04052

Constraint-Aware Execution Planning for Hybrid Space-Ground Compute Workloads

Subhadip Mitra¹

¹Rota, Inc. · Submitted March 2026 · Deployed in production as the CAE API

PDF arXiv Dataset

Abstract

The cloud was built on assumptions that do not hold in orbit. Networks are intermittent, power is governed by illumination, hardware is subject to radiation-induced faults, and there is no operator to intervene. We present a planning system that produces feasible execution plans for compute workloads distributed across space and ground, subject to power, thermal, communication, and orbital-window constraints.

Given a workload and a target satellite, the planner returns a schedule that satisfies every constraint, defers steps that cannot be placed, and reports an explicit infeasibility verdict when no plan exists - typically in under two seconds. The system is deployed in production and serves the CAE API.

1Introduction

For fifty years, distributed systems have asked a single question: where should a workload run? Orbital compute forces a different one. A satellite is not an always-on server in a temperature-controlled rack - it is a power-budgeted, intermittently-connected machine moving at 7.6 km/s through an environment that periodically removes its sunlight and flips its memory.1

Treating these conditions as exceptions, the way terrestrial schedulers do, produces plans that strand hardware mid-job. We argue instead that the constraints must be first-class inputs to the planner. Table 1 summarizes the assumptions that fail and what replaces them.

Figure 1. Constraint windows over a single orbital period for a 550 km, 53° orbit. Compute is feasible only where sufficient power and (for I/O steps) ground contact coincide; the eclipse interval removes roughly a third of each period.

The remainder of the paper formalizes the constraint model (§2), describes the four-phase planning pipeline (§3), and reports latency and feasibility results from production traffic (§4).

2The constraint model

We model each orbit as a set of time-varying resource envelopes. Power follows illumination; thermal margin follows duty cycle and attitude; communication follows ground-station and inter-satellite-link geometry. A plan is feasible iff every step is placed within a window where all of its required envelopes are simultaneously satisfied.

Table 1. Cloud assumptions and the orbital realities that violate them.

Cloud assumption	Orbital reality
Always-on network	Intermittent - eclipses, orbital motion, and ground-station handovers interrupt the link on a fixed schedule.
Stable power	Budgeted - solar flux, eclipse, and battery limits cap available power to 180-340 W.
Predictable latency	LEO 5-40 ms, GEO 240 ms+; ISL hops add variability.
Reliable hardware	Single-event upsets are nominal operating conditions, not exceptions.
Manual intervention	None available. The system must recover autonomously.

3The planning pipeline

Plans are built in four phases. Orbital environment propagates the satellite with SGP4 and resolves illumination, eclipse, thermal margin, and ground-station and inter-satellite-link geometry into the time-varying envelopes above. Placement assigns each workload step to a node - on-satellite, ground, or deferred - given its compute, memory, and I/O requirements. Data transfer schedules uploads and downloads into contact windows under the link budget. Scheduling lays the steps onto a timeline that satisfies every envelope simultaneously, or returns the first constraint that cannot be met.

The phases are ordered so that cheaper, more constraining checks run first: a step that cannot be placed at all never reaches the scheduler, and a workload that cannot close its data budget is rejected before any timeline is searched.

4Results in production

The planner returns a verdict in < 2 s for the overwhelming majority of requests, including SGP4 propagation, window resolution, placement, and scheduling. When no feasible plan exists it says so explicitly and names the binding constraint, rather than returning a partial schedule that would strand the workload mid-job. The same planner serves every request to the CAE API.

rotastellar-cae

$ curl https://api.rotastellar.com/v1/plan \
    -H "Content-Type: application/json" \
    -d '{
      "satellite_id": "25544",
      "preset_id": "onboard-ml-inference"
    }'

# CAE returns a constraint-aware plan
{
  "satellite": { "name": "ISS (ZARYA)", "altitude_km": 408 },
  "preset": { "id": "onboard-ml-inference", "steps": 4 },
  "orbital_environment": { "eclipse_fraction": 0.35 },
  "plan": { "total_duration_s": 2700, "windows_used": 8, "status": "scheduled" },
  "error_budget": { "delivery_confidence": 0.98 }
}

Listing 1. A plan request and the constraint-aware response served by the CAE API. Hover any field for what it means.

References

1. Rota Research. Inside CAE: how a feasible plan gets built in under two seconds. Engineering report, 2026.
2. Rota Research. The Operator Protocol: on-satellite execution under power and radiation constraints. 2026.
3. Vallado, D. A. Fundamentals of Astrodynamics and Applications. 4th ed.
4. Rota Research. A hybrid space-ground dataset for orbital workload scheduling. 2026.