What Work Actually Belongs in Space?

Part 25 of 30 · Series date: September 8, 2026

The strongest orbital business may be built on knowing which jobs to accept—and which to refuse.

“Can this run in space?” is an engineering question. “Should it run in space?” adds economics, timing, reliability, and customer needs. A processor can perform a task successfully and still be the wrong place to perform it.

The useful starting point is to follow the data and the decision.

Start where the information begins

Onboard image filtering has a direct location advantage: the images already originate aboard the spacecraft. ESA's PhiSat work provides an example of AI applied to reducing unsuitable Earth-observation imagery before transmission. ESA: AI for Earth observation.

A similar principle can apply to scientific data reduction or local fault detection. If processing avoids an expensive or slow transfer, its value may exceed the added computing cost.

However, preserving original information can be essential for science, audit, or later reanalysis. “Send less” is useful only when the lost detail is genuinely expendable or remains recoverable.

Decisions that cannot wait for Earth

A spacecraft may need to react locally to protect itself or complete an operation. Its onboard controller is valuable because a distant response might be too slow or unavailable.

This does not automatically call for a large language model or an orbital data center. A smaller, well-tested controller may be the better solution. Local autonomy and large-scale AI computing should not be treated as synonyms.

The strongest technical design often uses only as much complexity as the task requires.

Independent work travels better

Consider a hypothetical scientific study that runs thousands of independent simulations. Each receives a compact set of parameters and returns a small result. If deadlines are flexible, the work can tolerate separate machines and interruptions more readily than a tightly synchronized job.

This makes it a plausible candidate for remote capacity. Whether orbit wins still depends on software compatibility, launch and operating costs, data transfer, and utilization. Being distributable is a necessary advantage for some designs, not sufficient proof of profitability.

Training is not one uniform activity

Large synchronized training runs can require rapid, repeated communication among processors. That can be difficult across an orbital network. But “training” also includes smaller experiments, adaptation of an existing model, and methods with different communication patterns.

It would therefore be inaccurate to say training is either universally suitable or universally impossible in space. The meaningful comparison specifies model, parallelization, network, memory, and performance target.

The same applies to inference. A single image classification and a complex interactive agent can have very different demands.

Storage has its own questions

An orbital backup might offer physical separation from particular Earth hazards. It also needs durable media, repair strategy, retrieval access, encryption, and a ground-side organization that remains trustworthy.

A backup is valuable when it can be restored. If recovery requires a connection unavailable during the very disaster it is meant to address, the design may not meet the customer's need.

“Sovereign” or “independent” storage claims should be examined through actual ownership, control, legal obligations, and failure dependencies—not orbital altitude alone.

A better suitability test

Instead of ranking all workloads with universal labels, ask six questions: where are the inputs, how much data moves, how tightly do processors communicate, how urgent is the result, how costly is an error, and what alternative already exists?

A terrestrial chat service often has little reason to move upward if a nearby ground system serves it well. A remote spacecraft may have a compelling reason for local processing. A batch job sits between those cases and needs arithmetic.

Specialized long-distance communications might someday benefit particular financial or commercial applications. That does not make high-frequency trading a generic orbital-compute opportunity; its exact paths and delays would need measurement.

A workload audition, not a popularity contest

The following comparison describes architectural tendencies, not measured market rankings. Any real application still needs a benchmark against a credible alternative.

This table is a starting point for asking better questions. It should not become a permanent label attached to an entire category.

A candidate should pass four practical trials

First, test the workflow with representative inputs. An image service should include clouds, confusing scenery, and imperfect observations, not only striking clear examples. A simulation service should include the memory and output requirements customers actually have.

Second, measure the complete journey. Include queueing, transfer, computation, verification, and delivery. The processor benchmark is only one portion of the stopwatch.

Third, introduce the interruptions the service expects to face. Can work pause? Does a restart preserve correctness? Is a missed deadline reported clearly? A healthy-run demonstration does not answer recovery questions.

Fourth, repeat the comparison with an improved ground option. If a modest change in software or data placement removes the orbital advantage, the business needs to know before purchasing a fleet.

These trials are an editorial screening framework, not an official qualification standard. Their purpose is to turn a broad idea into evidence a customer can use.

The rejected jobs are valuable information

A new provider may learn more from the work it cannot serve than from the easiest demonstration. A task might be unsuitable because its input is too large, its deadline too tight, or its software too dependent on a particular hardware system.

Recording those reasons reveals where improvement would matter. Better links could open one class of jobs. More memory could open another. Some workloads might remain poor fits even after several hardware improvements.

This prevents development from becoming a race to improve every specification equally. The valuable improvement is the one that opens a real market or makes existing service more dependable.

It also protects customers from being used as unpaid experiments. A provider should be able to decline unsuitable work clearly rather than accept it and hope that the unusual location will somehow produce an advantage.

Demand is not interchangeable

The existence of enormous worldwide AI demand does not guarantee enough suitable work for a particular orbital architecture. A large market can still contain only a small share of jobs matching its software, data, price, and timing limits.

The provider needs a path from general interest to actual repeatable tasks. That path is where a promising technology becomes a product.

The most successful orbital computer may be the one with a disciplined understanding of what it should refuse to run.

What would prove this?

Benchmark the whole workflow with representative data and failure conditions. Include transfer and waiting time, not just processor time. Require equal output quality and comparable reliability across alternatives.

The best early orbital workloads are likely to have a specific reason to be there. A successful industry will emerge from matching jobs to environments, not from attaching “space” to every application that already uses a computer.

Previous article · Next article