ZKSF logo, a neon quantum brainZKSF
← All applications

Space and satellites

Satellite tasking: the operations problem that fits a quantum computer

An imaging satellite has more observation requests than it can serve. Each request has a time window and a value, windows overlap, and overlapping observations cannot both be taken. Choose the schedule of maximum total value.

The ZKSF console job history, each row naming the engine a tasking run used and what it cost

Tasking maps to an analog sequence, not a circuit. Open the console

The short version

  • Request selection under conflicts is maximum independent set. Neutral-atom hardware solves it natively rather than by encoding
  • The blockade IS the constraint. Two atoms inside the radius cannot both be excited, which is the independent-set rule itself
  • No penalty terms and no qubit overhead. The geometry is the problem, so there is nothing to encode

Run on our engines

Satellite observation tasking at 14 requests, seed 20260902, whose exact optimum is value 32.5128. On 25 September the same instance ran on exact.tpu, a Google TPU, which returned 31.2164 and the smallest gap on the table. Submitted to each kind of compute we offer, on 16 and 25 September 2026 at 500 shots. Every figure below is a real job on the service, priced as any customer would be priced.

DeviceEngineKindQubitsResultCost
CPUmps.quimb.cpuCPU1425.1546, gap 7.36 certificate$0.0001
CPUexact.cpuCPU1420.0569, gap 12.46 certificate$0.0001
NVIDIAexact.gpuGPU1425.1546, gap 7.36 certificate$0.0001
IQMqpu.iqm.garnetQPU1426.8778, gap 5.64 certificate$1.025
Rigettiqpu.rigettiQPU1427.0176, gap 5.49 * certificate$0.5125
IQMqpu.iqm.emeraldQPU1426.9421, gap 5.57 certificate$1.100
Google Cloud TPUexact.tpuTPU1431.2164, gap 1.30 certificatebest outcome$0.0776
Google Cloud TPUneural.tpuTPU—the tasking QUBO is diagonal, which is not the shape a neural ansatz is for—

IQM Emerald, a 54-qubit superconducting processor, returned the highest value of the five for this satellite tasking problem at 26.9421, with the 20-qubit IQM Garnet at 26.8778, against an exhaustive optimum of 32.5128. Both quantum devices also returned more feasible observation schedules than the classical simulators did, 48 and 36 of 500 against 14 to 20 for the tensor-network and NVIDIA GPU statevector engines.

The variational parameters were fixed rather than optimised, so every engine sampled the same distribution and the differences between them are one draw against another. The same two IQM devices place differently on the logistics and manufacturing pages, which is what that variation looks like across problems.

* The Rigetti row is a separate sample of ours on this same instance, with the QAOA angles re-optimised for it. The steps are in the docs.

A note on the hardware certificates: they state Hellinger fidelity against the exact distribution. For an optimisation circuit that distribution is spread across many outcomes rather than concentrated on one, so the figure is low by construction and is not a measure of whether the device found a good answer. The result column above is.

The same problem is yours to run: every instance here is seeded, so it rebuilds exactly. Open the console and a cost estimate is free before anything executes.

Open in Colab

Run these tasking instances yourself. The notebook rebuilds the exact seeded instance behind every figure on this page, in a browser tab, with nothing to install and no account. Read it on GitHub

Then run it on our engines

The notebook proves the numbers on free public packages. This is the step it does not cover: the same circuit on a certified engine, with a public certificate you can cite instead of citing ours.

pip install qsim-sdk

import qsim_sdk
client = qsim_sdk.Client(token="...")     # free account at app.zksf.org

client.estimate(circuit, shots=512)       # free, before you spend anything
job = client.run(circuit, shots=512)      # $0.0001 on CPU
job.certificate()                         # a public, verifiable URL

Here is one we ran, so you can see what comes back before signing up: 4001976d4c8e4b38. It opens without an account. Note what it does and does not assert: it certifies that the simulation was exact and only shot noise applies, which is a statement about the engine. Whether the method found a good answer is settled by the comparison against enumeration above, not by the certificate.

What you can run here

Request selection under conflicts is maximum independent set, and neutral-atom hardware solves it natively rather than by encoding. The blockade already forbids two atoms within a radius from both being excited. Choose Optimisation problem, then Maximum independent set, and give one x, y per request, laid out so that conflicting pairs fall inside the blockade radius. Check it on analog.pulser.cpu to 14 requests, then run the real instance on qpu.quera.aquila to 256. Conflicts that are already geometric map straight across; an arbitrary conflict graph needs a layout step this does not do for you.

Why this one is different

Every problem on the neighbouring logistics and manufacturing pages fails on encoding cost before it fails on anything else. A 20-stop route needs 400 binary variables and a 10 by 10 job shop needs tens of thousands. Satellite tasking does not have that problem.

It is a maximum weighted independent set on the conflict graph, which takes exactly one binary variable per observation request. Sixteen requests means sixteen qubits. That linear encoding is what makes it the rare operations problem you can actually put on a quantum computer today, and it is the reason this page has a benchmark at all rather than an explanation of why one is impossible.

The setup

Observation windows generated from seed 20260902 with random start times, durations and values, giving a realistic conflict density. Two classical baselines: exhaustive search over all 2^n subsets, which proves the optimum, and OR-Tools CP-SAT, which is what a mission planner would actually use. QAOA at depth 2, 512 shots, COBYLA with three restarts of 150 iterations, with every circuit evaluation counted.

Results

Measured 2 September 2026. Higher total value is better.

RequestsQubitsExhaustiveTimeCP-SATTimeQAOATimeEvalsOptimal
121232.3050.010 s32.3060.0078 s28.3529.7 s110no
141432.5130.081 s32.5140.0105 s32.51310.4 s111yes
161634.6680.210 s34.6670.0116 s33.40311.8 s118no

CP-SAT and exhaustive search differ in the third decimal because CP-SAT optimises integer-scaled values (multiplied by 1,000 and rounded). Both select the same schedule; the gap is rounding, not disagreement.

What the numbers say

QAOA matched the proven optimum once in three runs, at 14 requests. At 12 requests it came in 12 percent below the best schedule and at 16 requests 3.6 percent below. As a heuristic it is respectable and it is not reliable.

CP-SAT solved every instance in around 10 milliseconds, roughly a thousand times faster than QAOA, and its solve time barely moved as the problem grew. Exhaustive search rose from 0.010 to 0.210 seconds across the same range, which is the exponential curve becoming visible. CP-SAT's flatness is the point: constraint solvers prune, so they do not follow that curve.

At the sizes a quantum computer can address, the classical solver is not merely winning. It is finishing before the quantum optimiser has evaluated its first circuit.

Where this could go

The linear encoding is genuinely favourable, so the interesting extrapolation is real rather than rhetorical. A constellation-scale tasking problem with a few thousand candidate observations would need a few thousand qubits, which is a plausible hardware target in a way that 40,000 for a delivery route is not.

Two things would have to hold for that to matter. Error rates would have to fall far enough that a depth-2 QAOA circuit on thousands of qubits returns signal, and QAOA's solution quality would have to stop degrading as the instance grows, which our three data points already show it doing. Neither is settled, and the second is a software question that could be answered long before the hardware exists.

The roadmaps make the first condition concrete. Hundreds of logical qubits by 2029, which IBM and Quantinuum both target, would cover a few hundred candidate observations. That is a real constellation planning problem rather than a toy, and it is reachable precisely because the encoding is linear.

Meanwhile CP-SAT will also have improved, and it currently solves these instances in around 10 milliseconds with room to spare. A fair projection has to beat where the classical solver will be, not where it is now, and on this problem it is not close today.

For context: where the hardware actually is

Gaps on this page are quoted against the processors ZKSF can run. That is not the frontier. Quantinuum, IBM, Atom Computing and QuEra’s newest systems are not available through us, and those machines are considerably further along. As of September 2026:

Physical qubits built

Infleqtion Sqale1,600Neutral atom
Atom Computing1,180Neutral atom, 1,225 sites
IBM Condor1,121Superconducting, 2023
IBM Heron R2156Superconducting, ~99.5% two-qubit fidelity
Rigetti Cepheus108The largest available through ZKSF

Two-qubit gate fidelity

The number that actually governs what a circuit can do.

IonQ99.99%Trapped ion, first past four nines
Silicon Quantum Computing99.99%Silicon spin
Quantinuum99.97%Trapped ion, all-to-all
IQM99.91%Superconducting, available through ZKSF

Logical qubits demonstrated

Published results, not roadmap targets.

QuEra96 logical / 448 physicalNeutral atom
Quantinuum48 logical / 98 physicalTrapped ion, iceberg code
Atom Computing24 logicalOn the 1,180-qubit system
Google1 logical / 105 physicalSurface code, below threshold

Announced roadmap

Targets. Roadmaps slip, and these are not results.

Quantinuum Sol, 2027192 physical, ~100 logicalIceberg code, distance 2. Error detection with postselection, not correction
IBM Starling, 2029~200 logicalBivariate bicycle qLDPC, 100 million gates
Quantinuum Apollo, 2029hundreds of logicalThousands of physical, logical error 1e-6 or better

Run a tasking instance yourself.

The QAOA template is the same machinery with a different conflict graph. Load it, substitute your own observation windows and values, and export a certificate for your own run.