What Makes a Problem Quantum-Suitable?
Most proposed quantum use cases fail for reasons that have nothing to do with physics: the bottleneck is data loading, integration, or a classical method that is already excellent. This chapter gives you a screen to apply before anyone books a pilot.
Quantum suitability is a property of a whole workflow — problem structure, baseline gap, hardware assumptions, buyer economics — and no amount of cleverness in one of those terms rescues a zero in any other.
By the end of this chapter you will be able to score a proposed use case on structure, evidence, hardware dependence, and integration burden, and to say "monitor" with the same confidence others reserve for "yes."
Core concepts: problem structure, evidence levels, classical baselines, integration cost, suitability screening.
A property of workflows, not problems
"Is this problem quantum-suitable?" sounds like a question about a mathematical object. It is really a question about a situation. A problem is quantum-suitable only when four things line up at once: the structure of the problem maps onto something quantum computers do well; the evidence says a quantum method actually helps at realistic scale; the hardware the method needs exists or credibly will on a relevant timescale; and the buyer's workflow can absorb the method at a cost below the benefit.
Adding a quantum algorithm to an ordinary business process creates none of these. Suitability is discovered by screening, not asserted by enthusiasm. And the first screen is always the baseline: what classical, operational, or scientific workflow must the quantum method beat or usefully complement? Until that question has a concrete answer — a named method, a named metric, a named data distribution — there is nothing to evaluate, only a logo to place on a slide.
Good candidates tend to have structure that maps naturally onto quantum mechanics, linear algebra, sampling, search, or special algebraic problems. Weak candidates tend to hide their difficulty in data loading, noisy objectives, integration cost, or the vague promise that a quantum method will be faster someday. The expert move is to score suitability before proposing a pilot, because the screen is cheap and the pilot is not.
The screen, written down
Two compact formulas keep the screening honest. The first scores the application: . Its value is structural, not numerical — it forces the memo to name evidence, baseline, integration burden, and hardware dependence as separate terms, so a strong story in one cannot silently cover a hole in another.
The second prices timing: . This is what stops a possible future from masquerading as a present decision. "Monitor" is often the correct output of this formula: the structure is promising, the value would be real, but the probability term has not yet earned a commitment. Monitoring with named triggers is a decision, not a failure to make one.
Worked example: the route-optimization mirage
Suppose a team proposes a quantum pilot for route optimization — a use case that appears in pitch decks with remarkable consistency. The weak note starts with the quantum optimizer. The strong note starts with the buyer's workflow: fleet size, constraint types, objective function, data freshness, the solver in production today, acceptable runtime, and the dollar value of a one-percent improvement.
Now screen it. Baseline: modern classical solvers for vehicle routing are mature, fast, and constantly improved — the gap a quantum method must clear is high and moving. Evidence: label what exists honestly — theory, toy demonstration, simulation, hardware run, customer pilot, or production result — and list what is missing at realistic instance sizes. Integration: routing decisions feed dispatch systems with hard latency requirements; a method that needs a remote quantum queue may be disqualified before its quality is even measured.
The proof gate that would change minds is specific: an experiment on realistic instances, against the best available classical heuristic, under the buyer's real constraints, with total workflow cost reported. Anything weaker — a small benchmark, a favorable synthetic instance — tells you the idea is alive, not that it is suitable.
Three ways screenings fail
The first failure is starting from the method. "We have a quantum optimizer; what can it solve?" reverses the diligence order and guarantees that every problem looks plausible, because the search stops at the first superficial fit. The second failure is accepting benchmarks that do not resemble the buyer's data, constraints, or latency budget. A benchmark is evidence about the benchmark.
The third failure is skipping integration. A technically interesting method can still be a poor application when data access, validation, security review, workflow adoption, or verification cost dominates the benefit. Integration is where quantum pilots go to die quietly, and it belongs in the first screen, not the post-mortem.
The systems view
For a computer scientist, suitability screening is a requirements exercise with extra honesty. Define the input distribution, output metric, cost model, latency budget, verification plan, and the baseline implementation. Then ask whether the quantum component changes the end-to-end system — not whether it runs, but whether the system is better with it.
The analogy is accelerator adoption. Nobody buys a GPU because GPUs are fast; they buy one because their workload is parallel, their data movement is tolerable, and the integration cost clears the benefit. Quantum methods carry the same burden with a heavier handicap: the hardware assumptions are often immature and the evidence levels thin. The screen does not get softer because the technology is exciting.
What this buys you in diligence
A build decision should require, in writing: a problem owner, a real data path, a named baseline, a metric, and a proof gate. An investment decision should require evidence that the application wedge is more than a generic story taped to uncertain hardware. And when the structure is promising but the proof gates are not ready, monitor is a position you can defend — with the triggers named that would convert it.
The screen also protects your time. Most use cases fail it, and they fail it early and cheaply if you run the filters in the right order. That is not pessimism. It is how you find the few problems where quantum methods genuinely belong — the subject of the rest of this part.
Exercise
Score one proposed use case. Pick a real quantum application claim and run the full screen.
- Baseline first: write the buyer workflow, current method, metric, and failure mode before naming any quantum method.
- Evidence: assign an evidence level — theory, toy demo, simulation, hardware result, customer pilot, production — and list what is missing.
- Gate: define the smallest realistic test that would change your confidence.
- Decide: choose build, partner, invest, monitor, wait, or avoid, and state what evidence would change the label.
Check your understanding
Answer without notes: why must suitability screening start with the baseline rather than the quantum method?
A passing answer explains that the baseline defines the gap any method must clear, that method-first screening rationalizes weak fits, and that integration cost belongs in the first pass. Oral defense: take a use case you personally find exciting and argue it through the three filters without special pleading.
If you get stuck
If your scorecard starts with the quantum method, or lacks a strong classical baseline, an evidence level, a data-loading cost, or kill criteria, revisit Chapter 63, Quantum-Centric Supercomputing and Hybrid Workflows. That chapter builds the workflow-first frame; this one turns it into a screen. The repair is to rewrite the memo with the buyer and the baseline on page one.