Field Notes

Five questions to ask when someone presents a quantum solution

A practical framework for examining the problem, comparison, evidence, system requirements, and path from a quantum demonstration to real use.

Editorial illustration of precision photonics equipment and a red alignment beam in a dark laboratory
Editorial illustration. It does not depict equipment owned or operated by Quantum Insiders.

Quantum announcements can be difficult to judge because the same words describe theory, laboratory experiments, cloud access, supporting equipment, consulting, and finished products. The five questions below do not require a physics degree. They require the presenter to identify what was done and what remains unresolved.

1. What exact problem is the quantum system solving?

Ask for the input, the desired output, and the reason the problem matters. “Optimization,” “simulation,” and “artificial intelligence” are broad categories. A useful explanation names the specific task and the decision the result supports.

This question also reveals whether quantum computing is central to the work. Some offerings use classical software to prepare data, orchestrate jobs, or interpret results from quantum hardware. Others use quantum-inspired mathematics on classical computers. Those may be legitimate tools, but they are not the same thing.

If the presenter cannot describe the problem without a long list of industries, the claim is not ready for evaluation.

2. What is the comparison baseline?

A speed or accuracy claim needs a comparison. Ask which classical algorithm, hardware, data set, and time budget were used. Ask whether the baseline reflects the strongest method available when the test was performed.

Comparisons can become misleading when a specialized quantum experiment is placed against a convenient but weak classical implementation. They can also omit time spent preparing data, calibrating hardware, repeating the quantum circuit, or processing the output.

The baseline does not have to settle every scientific question. It does have to be specific enough that another qualified team can understand the comparison.

3. What evidence supports the result?

Evidence comes in layers. A theoretical paper can prove something important about an algorithm without showing that current hardware can run it at a useful scale. A laboratory demonstration can show that a device works without showing that it improves a business process. A customer pilot can show operational learning without proving a general advantage.

Ask whether the result was peer reviewed, independently reproduced, or tested by a customer under realistic conditions. Ask which measurements were selected before the test and which were chosen afterward.

NIST’s assessment of quantum computing benefits and risks separates near-term techniques from the capabilities expected of fault-tolerant systems. That distinction is important whenever a claim moves from research evidence to commercial language.

4. What does the complete system require?

A quantum processor does not operate alone. Depending on the hardware, the system may need cryogenic cooling, vacuum equipment, lasers, control electronics, shielding, networking, calibration, software, and specialist staff.

Ask whether the stated cost and runtime include those parts. If the processor is accessed through the cloud, ask what work happens before and after the quantum job. If the claim concerns energy use, ask which equipment is inside the measurement boundary.

The same principle applies to performance figures. Qubit count, gate speed, or coherence time can describe an important property without showing how the complete machine performs on the stated problem. NIST’s quantum computing overview explains why qubit type, error behavior, and control requirements differ across hardware approaches.

5. What remains between this result and routine use?

Ask for the next engineering step, not a distant vision. Does the work need lower error rates, more reliable fabrication, a larger device, better data access, regulatory review, cheaper operation, or independent validation?

A responsible answer names the dependencies and gives a reason for the proposed sequence. It separates a research milestone from a product release and a product release from a proven operational outcome.

Timelines deserve the same discipline. A roadmap is a statement of intent. It becomes evidence only as milestones are met and the results can be examined.

How should the five answers fit together?

The answers should tell one consistent story:

  • The problem explains why the work matters.
  • The baseline shows what the quantum approach must improve.
  • The evidence shows what has actually been demonstrated.
  • The system boundary reveals the resources required.
  • The remaining path shows how far the result is from routine use.

Contradictions are informative. A claim of immediate readiness does not fit with a system that still needs an undefined hardware breakthrough. A claim of advantage does not fit with an absent classical baseline. A precise performance number does not compensate for a vague problem.

What this means

You do not have to decide whether the entire quantum field will succeed before evaluating one offering. Keep the discussion at the scale of the claim. Ask what happened, compared with what, under which conditions, and what must happen next.

Good answers will not always be simple. They will be specific. They will help a technical reader inspect the evidence and help a nontechnical reader understand the decision. That is enough to move a conversation from excitement toward judgment.

Editorial disclosure: This Field Note is educational. It is not an endorsement, procurement recommendation, legal advice, or investment recommendation.