Orbital computing needs a measure of work delivered on time

On October 30, 2026, Google reported a first AI response from its Suncatcher prototype in orbit. The satellite launched October 1; the response occurred that week, without an exact date. Google announcement

Following a job all the way back

Open Market Notes analysis. A sensible next question for orbital computing is how to define a completed job. The following is an evaluation framework, not a description of Google's implementation or a claim about its commercial performance.

A user experiences a chain: submitting input, waiting for acceptance, execution, returning output and checking that output. Timing only the processor leaves much of this chain outside the measurement. A technically correct result can arrive after the decision it was meant to support. Conversely, a long wait may be perfectly acceptable for an archive task whose deadline is tomorrow. Useful capacity depends on which promises the service makes.

This suggests a practical unit of comparison: accepted results delivered within a declared deadline and quality threshold. The denominator should include all unique admitted jobs, including jobs that expired, failed or required a retry; execution attempts should be counted separately. Otherwise a system can improve its apparent success rate simply by reporting only successful returns. Reporting rejected requests separately is equally important: admission control can protect reliability while quietly reducing the amount of demand served.

The definition need not punish an experiment for lacking a production service. It makes successive experiments comparable. A single successful path answers a narrow question; repeated jobs with disclosed waiting times can address a broader one. Neither observation should be silently promoted into evidence of continuous availability.

Waiting can be designed into a workload

NASA describes delay-tolerant networking as storing data until forwarding becomes possible when links are disrupted. This is general communications context, not evidence of Suncatcher's protocol choices. NASA explanation

Our inference is that application deadlines deserve to be designed alongside the computing task. Consider two hypothetical customers. One wants an overnight classification of a fixed collection. Another needs an answer before taking an immediate operational action. Identical model execution time would not give those customers equivalent service. The first might tolerate a queue and scheduled retrieval; the second might need a ground fallback before an orbital result returns. No latency or performance figure is assumed in this example.

The comparison also changes with the origin and size of data. If input must first be uploaded, transmission is part of the service being purchased. If data already exists near the processor, a different comparison becomes relevant: returning selected findings versus returning the underlying data for ground processing. This is a conditional design choice, not a claim that either route is cheaper or that a particular mission uses it.

Sending fewer bytes can create a verification problem. A compact answer is valuable only if the recipient can judge its fitness for the task. A trial could therefore retain sample inputs, record model and software versions, and compare selected outputs against an agreed reference. These are proposed controls. They should not be presented as features already demonstrated by the project.

Count recovery without counting the same job twice

Retries deserve a separate ledger. If an output is late, the customer may request it again or move the job elsewhere. Both executions consume resources, but the customer still has only one problem to solve. A useful report would distinguish unique accepted results from execution attempts and show when a late duplicate was discarded.

Fallback has a similarly mixed meaning. It may improve the customer's experience while masking the orbital path's limitations. That does not make fallback undesirable. It means a trial should report the combined service and the orbital contribution separately. Otherwise the ground system can end up carrying the reliability promise while the space system receives the performance credit.

A fair ground comparison would use the same input, quality requirement, deadline and accounting boundary. It should include waiting and recovery on both sides. Comparing an orbital accelerator's execution interval with an entire ground workflow, or reversing those boundaries, would produce an impressive but unhelpful number. Cost and energy comparisons additionally need disclosed system boundaries; this article makes neither calculation.

An informative next result

A modest, well-described workload could teach more than a larger demonstration with an opaque denominator. Publish how many jobs were admitted, how many arrived in time, how long the oldest unfinished job waited, and what happened after interruption. Include the distribution of completion times rather than only a favorable average. Readers can then see whether delay is predictable enough for a particular application.

There are competing interpretations to preserve. Some workloads may accommodate substantial waiting; others may require continuity that this architecture cannot economically provide. An early experiment cannot settle that range. Nor does the absence of a public service-level record establish failure. The constructive standard is narrower: each new test should make it easier to identify the tasks for which useful results can be delivered reliably, with the remaining uncertainty visible.