Steven GellerQuantum Computing, End to End

Book contents

Current section

Part VIII. Applications and Strategy

  1. What Makes a Problem Quantum-Suitable?
  2. Quantum Simulation and Chemistry
  3. Materials, Energy, and Industrial Science
  4. Optimization: Where Caution Is Required
  5. Cryptography, PQC, QKD, and Security Migration
  6. Quantum Machine Learning and Benchmark Discipline
  7. Sensing, Navigation, and Adjacent Quantum Technologies
  8. Application Evidence Levels
  9. When to Build, Partner, Wait, or Avoid

Part VIII. Applications and Strategy · Chapter 64

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.

Artifact
In this chapter 9 sections

A workflow is quantum-suitable only when a quantum-accessible kernel, an explicit input model, a credible resource path, and an end-to-end advantage target survive comparison with the best classical operating baseline.

Suitability screening is a refusal to start with the attractive part. The screen begins in the operating system around the proposed calculation: who makes the decision, which records arrive, how soon an answer is useful, what error is tolerable, and what process already produces that answer. Only then is there a well-formed question about a quantum kernel.

Quantum-suitability gate record Four narrowing filters for a quantum-suitability decision. Quantum-suitability gate record workflowbaselineresources integration testonly after the screen
Figure 64.1. A candidate enters at workflow definition. The aperture narrows at the classical baseline and resource account before integration is worth testing.

Start at the decision boundary, not the algorithm

The four gates used here are structure, baseline, resources, and integration. Structure asks whether an identified kernel has a defensible quantum formulation. Baseline names the incumbent at equal task quality. Resources translate the method into qubits, operations, samples, and error assumptions. Integration follows data, validation, latency, security, and adoption to the owner’s outcome.

  1. Structure: name the quantum-accessible kernel and its input contract.
  2. Baseline: reproduce the incumbent at equal task quality.
  3. Resources: expose qubits, operations, samples, errors, and sensitivity.
  4. Integration: trace data, validation, latency, security, and ownership.

The four-gate suitability dossier

Feynman and Lloyd establish why quantum simulation is structurally interesting; VQE and QAOA establish particular method families under stated contracts. They do not establish that an arbitrary enterprise workflow benefits. The National Academies and GAO provide dated system context, while the benchmarking review supplies the comparison discipline. OpenQASM is used only to make the circuit boundary inspectable.

A screening record that can reject its own candidate

Consider a molecular-energy calculation proposed for catalyst screening. The research owner can name a target observable and a difficult active space, but the proposal supplies neither the selected classical solver nor a fault-tolerant resource estimate. It passes the structure gate and stops at the baseline and resource gates. A ten-qubit demonstration would test implementation competence; it would not repair either missing record. The artifact encodes that exact distinction.

Quantum-suitability gate record: inspected record
GateRecordObserved stateDecision effect
Structureelectronic-energy kernelpresentcontinue
Baselinenamed solver and resultabsentstop
Resourcesfault-tolerant sensitivityabsentstop
Integrationlaboratory validation ownerpresentno repair of prior gaps

Artifact contract. A dated eight-field decision table plus executable gate evaluator. The evaluator rejects any case missing a workflow owner, baseline, metric, resource bound, validation route, or integration boundary.

REQUIRED = {"scenario": str, "source_ids": list, "workflow_owner": str,
            "baseline": str, "metric": dict, "resource_bound": dict,
            "validation_route": str, "integration_boundary": str, "gates": dict}
GATE_NAMES = {"structure", "input", "baseline", "metric", "resources", "integration"}
def evaluate(case):
    errors = [name for name, kind in REQUIRED.items()
              if name not in case or type(case[name]) is not kind]
    for name in ("metric", "resource_bound"):
        item = case.get(name, {})
        if type(item.get("value")) not in (int, float) or not item.get("unit"):
            errors.append(name + "_value_or_unit")
    if not case.get("source_ids") or set(case.get("gates", {})) != GATE_NAMES:
        errors.append("sources_or_gate_schema")
    if any(type(value) is not bool for value in case.get("gates", {}).values()):
        errors.append("gate_type")
    decision = "invalid" if errors else ("monitor" if all(case["gates"].values()) else "reject-now")
    return {"decision": decision, "errors": sorted(set(errors)),
            "failed_gates": sorted(k for k, value in case.get("gates", {}).items() if not value)}
case = {"scenario": "Fe-S screening case", "source_ids": ["feynman-1982", "benchmarking-2025"],
        "workflow_owner": "catalysis lead", "baseline": "selected-CI on identical active space",
        "metric": {"value": 1.6, "unit": "millihartree"},
        "resource_bound": {"value": 30, "unit": "logical-qubit-days"},
        "validation_route": "blind energy comparison", "integration_boundary": "candidate ranking only",
        "gates": {name: name != "resources" for name in GATE_NAMES}}
base_result = evaluate(case)
bad_case = {key: value for key, value in case.items() if key != "workflow_owner"}
bad_result = evaluate(bad_case)
repaired = {**case, "gates": {**case["gates"], "resources": True}}
repaired_result = evaluate(repaired)
assert base_result["decision"] == "reject-now" and base_result["failed_gates"] == ["resources"]
assert bad_result["decision"] == "invalid" and "workflow_owner" in bad_result["errors"]
assert repaired_result["decision"] == "monitor"
print(f"PASS: 64 suitability dossier base={base_result['decision']} missing={bad_result['errors']} repaired={repaired_result['decision']}")

Exact validation command: python3 tools/validate_briefs.py --briefs data/editorial_briefs_64_87.json --from 64 --through 87 --check-rewritten-sources --execute-artifacts

Convert the screen into a next action

The immediate action is a bounded baseline-and-resource study, not a hardware pilot. Its owner must reproduce the best classical result on the same active space, specify the observable tolerance, and produce a sensitivity table over logical error and state-preparation assumptions. A later pilot becomes rational only if that record exposes a consequential gap that available hardware can test.

Test a candidate before funding a pilot

Prompt. Screen a candidate workflow using the four gates and cite the source for every empirical input.

Deliverable. A completed gate record, baseline contract, resource boundary, decision label, and reversal trigger.

Pass condition. Every gate is evidenced; a single zero blocks a build recommendation; the reversal trigger is measurable and dated.

Model answer: a molecular-energy screen

Format. Completed molecular-energy screening record with a reject-now/monitor decision.

The molecular-energy candidate receives gates structure=true, baseline=false, resources=false, integration=true. The evaluator therefore returns reject-now. That label does not say quantum chemistry is useless; it says this organization has not supplied the two records needed to spend pilot money. If a named baseline and resource account are later attached, the proper change is monitor, with a dated experimental trigger rather than an immediate build.

Verification. Recomputing its six Boolean gates returns reject, and changing only the documented resource gate changes the result to monitor.

Companion work

Artifacts for this chapter

These entries resolve to checked-in local source. Commands are reproduced exactly from the chapter manifest, and source-embedded fixtures are exported as direct downloads.

  1. Reproduce or test

    python3 tools/validate_briefs.py --briefs data/editorial_briefs_64_87.json --from 64 --through 87 --check-rewritten-sources --execute-artifacts

Provenance

Sources and review

  1. U.S. Government Accountability Office. Quantum Computing and Communications: Status and Prospects. GAO. 2021government technology assessment
  2. Richard P. Feynman. Simulating physics with computers. International Journal of Theoretical Physics. 1982primary paper
  3. Seth Lloyd. Universal quantum simulators. Science. 1996primary paper
  4. Alberto Peruzzo et al.. A variational eigenvalue solver on a photonic quantum processor. Nature Communications. 2014primary paper
  5. Edward Farhi, Jeffrey Goldstone, and Sam Gutmann. A Quantum Approximate Optimization Algorithm. arXiv. 2014primary preprint
  6. OpenQASM Technical Steering Committee. OpenQASM 3 specification. Linux Foundation Joint Development Foundation. 2026official technical specification
  7. Timothy Proctor et al.. Benchmarking quantum computers. Nature Reviews Physics. 2025peer-reviewed perspective
  8. National Academies of Sciences, Engineering, and Medicine. Quantum Computing: Progress and Prospects. National Academies Press. 2019consensus study report

The load-bearing claims in the chapter are mapped inline to this registered source set. A citation supports only the bounded claim beside it.

Cite this chapter