Quantum backend selection: choose for the circuit, not a universal leaderboard.

A backend can have more qubits, a shorter visible queue, or a strong calibration metric and still be a poor route for a particular circuit. The circuit may map badly to its coupling graph, use an unsupported operation, require an execution mode unavailable to the account, or exceed the experiment's time and usage budget after transpilation.

Treat backend selection as a versioned decision rather than a leaderboard. The decision should name the workload, eligible routes, data timestamp, comparison rule, reason for selection, and the condition that triggers a new selection pass.

Begin with hard constraints: accessible provider account, region or workspace, operational target, supported program format, qubit requirement, native instruction support, control-flow requirements, and payload limits. A route that fails one of these gates is not a candidate regardless of headline performance.

QFlow's public matrix deliberately separates submit-capable beta, validation, preflight, credential-test, local-simulator, and planned states. That status is product evidence, not proof that a particular user has provider entitlement, quota, queue priority, pricing approval, or device access.

Backend properties such as two-qubit operation error, readout error, qubit lifetime, topology, and calibration time provide context. They do not collapse into one universally valid quality score. A sparse circuit may care about a small high-quality connected subgraph; a deeper circuit may be dominated by routing overhead and two-qubit layers.

Calibration is also time-bound. Preserve the timestamp and, where available, historical properties used for the decision. If the experiment runs after a long queue or a new calibration, the selection rationale may need to be re-evaluated rather than silently reused.

Pending jobs can help estimate near-term delay, but wall-clock completion also depends on compilation, shots, requested precision, mitigation overhead, job packaging, and whether the workload uses job, batch, or session behavior. The least-busy eligible backend is a convenience heuristic, not a scientific selection rule.

For iterative workloads, execution mode can affect drift and total elapsed time. For independent comparisons, a batch can keep related jobs closer together. For a single small request, job mode may be simplest. Provider documentation and account terms remain authoritative because access and usage models change.

A simulator-first pass catches source, parameter, bit-ordering, measurement, and expected-output errors before hardware routing. It also provides a reference distribution or expectation value that helps the team distinguish an implementation failure from hardware behavior.

Simulation is not a promise of hardware fidelity. The workflow should say which simulator and noise assumptions were used and which hardware-specific question justifies leaving the simulator route.

For a backend decision, use QFlow's documented source, provider-route, run, trace, result, and reviewer-note fields as the core record. Attach the mapped-circuit summary, candidate routes, access check, calibration timestamp, topology fit, queue observation, execution mode, shots or precision, usage boundary, chosen route, and fallback when those details affect the decision; the public manifest does not present every one of these as a dedicated first-class field. Credentials and billing details stay outside reviewer-safe evidence.

Rejected candidates matter. They show whether a later result came from a deliberate tradeoff or from selecting the first visible device. They also make future rerouting faster when access, calibration, queues, or provider support changes.

Selection expires when the circuit changes materially, the target becomes unavailable, calibration becomes stale for the experiment, the queue breaches the time window, the usage estimate crosses budget, or the account's execution options change. The workflow should name these triggers before submission.

A backend result supports only the declared experiment under its recorded conditions. It does not establish provider superiority, universal device ranking, production readiness, or quantum advantage.