The question "should I process on orbit or on the ground?" is asked as if it has a single correct answer. It doesn't. It's a mission architecture question, and the right answer is specific to the use case, the latency requirements, the data volume, the power budget, and the available engineering resources to build and validate an onboard pipeline. There are missions where onboard processing is clearly the right choice, missions where it's clearly the wrong choice, and a large middle ground where the decision requires careful trade analysis.
What this means in practice is that the question shouldn't be "edge or ground?" but "which workloads belong where?" The answer is almost always both — a split architecture where time-critical, latency-sensitive tasks run on orbit and volume-intensive, accuracy-critical, or context-dependent tasks run on the ground. The engineering work is in drawing that boundary correctly for each mission.
Workloads That Belong on Orbit
The workloads where onboard processing has the clearest value proposition share a common characteristic: the time cost of waiting for a ground pass exceeds the time value of the result. Three categories stand out.
First, event detection and triage. If the satellite's mission includes identifying whether a specific event occurred during a pass — a vessel departure, a facility activation, a change in a monitored area — running that detection on orbit allows the satellite to flag the result immediately rather than waiting for the full image to downlink and be processed. The detection result, a few kilobytes of structured data, can be transmitted in the first seconds of the next contact window. The full image follows later for verification or archival.
Second, sensor data filtering and prioritization. For satellites with solid-state recorders that cannot store everything, onboard scoring can determine which frames to retain and which to overwrite. A cloud detection pass that flags imagery as unusable before it occupies recorder space is a simple example; a more sophisticated version uses an onboard scene quality assessment to prioritize high-value imagery for priority downlink. This doesn't require full inference capability — a lightweight classifier that scores frame quality is sufficient and draws minimal power.
Third, alert triggering for time-critical applications. If a mission has defined alert thresholds — detect above a certain confidence score, trigger a downlink priority flag and optionally initiate an emergency contact — that trigger logic belongs onboard. Waiting for a ground pass to make the alert decision defeats the purpose of near-real-time alerting.
Workloads That Belong on the Ground
Just as clearly, there are workloads that should not run on orbit, at least not in the current state of onboard compute hardware.
Large-scale model inference with complex architectures benefits from the performance available in ground-based GPU infrastructure. A model that performs significantly better with larger weights, more context, or higher numerical precision than the orbit-native runtime can support should run on the ground. The on-orbit version might serve as a fast first pass to triage which images get priority processing, but the high-accuracy result comes from the ground system.
Multi-pass temporal analysis — comparing imagery across multiple orbits, detecting slow changes, reconstructing 3D structure from stereo passes — requires data from multiple passes and is inherently a ground task. The compute required is not the issue; the data assembly is. The ground system has access to the full history of collected imagery; the satellite only has access to what's in its recorder buffer right now.
Training and model development absolutely stays on the ground. Active learning pipelines, model retraining on newly labeled data, architecture search — these are cloud compute tasks. The orbit is a deployment environment, not a training environment.
Drawing the Boundary: A Concrete Example
Consider a growing constellation operator running a maritime domain awareness mission — 15 satellites monitoring ocean shipping lanes, tasked with detecting vessel presence and estimating vessel count and position from optical imagery. The end customers need near-real-time alerts when vessel density at monitored waypoints changes significantly.
A pure ground-processing architecture means that imagery from each pass flows through the downlink pipeline, is processed in the cloud, and produces an alert that might arrive two to four hours after the imaging event. For most maritime intelligence purposes, two to four hours is acceptable. For some use cases — monitoring a specific corridor where transits are brief — it may not be.
A split architecture runs a lightweight vessel presence detection model on orbit, producing a vessel count estimate and position flag per pass. That structured result is downlinked in the next contact window, potentially within 30–60 minutes of the pass. The full imagery is downlinked on a lower-priority schedule and processed on the ground for higher-accuracy analysis, archival, and training data. The customer gets near-real-time alerts from the onboard pipeline and receives higher-fidelity analysis from the ground pipeline on a delayed basis.
This architecture requires that the operator develop and validate an onboard detection model — a real engineering investment. We're not saying it's free. We're saying the latency benefit for this specific use case may justify that investment, and the operator should evaluate it explicitly rather than defaulting to a ground-centric architecture without analysis.
The Latency-Accuracy Tradeoff Is Real
One honest complexity in the split architecture: onboard inference on power-constrained hardware with quantized models will generally produce lower accuracy results than ground-based inference with full-precision models on high-performance hardware. This is not a fatal flaw — it's an engineering reality that must be built into the mission architecture explicitly.
The onboard result is a first-pass triage: fast, lower-fidelity, latency-optimized. The ground result is the authoritative analysis: slower, higher-fidelity, accuracy-optimized. For applications where a fast approximate result followed by a confirmed precise result is acceptable, the split architecture works well. For applications where the first result must be the accurate result — where an incorrect on-orbit triage decision causes a harm that cannot be corrected by the subsequent ground analysis — the split architecture requires more careful calibration of acceptable false positive and false negative rates.
That calibration is a mission requirements question, not a hardware question. It starts with the operator defining what accuracy level is required for each type of decision the system makes, and working backward to determine whether onboard inference can meet that requirement or whether ground processing is needed for that specific decision. Most missions that have done this analysis find that onboard processing is appropriate for a meaningful subset of their pipeline, and that the latency gains from that subset justify the engineering investment.
The split is not a compromise. It's the correct architecture for missions that need both speed and accuracy from the same satellite data — delivering each where the physics and the engineering favor it most.
