Application Evidence Levels
A simulator result and a paying customer are both "evidence," and confusing them is how money gets lost. This chapter gives you a ladder of evidence levels and the habit of asking, for every claim, which rung it actually stands on.
Most bad quantum decisions are category errors: the evidence was real, but it was evidence for a weaker claim than the one that got funded.
This chapter gives you the working standard: label every application claim — theory, simulation, toy demo, benchmark, customer pilot, production utility — and match each decision to the rung the evidence actually reached.
Core concepts: quantum utility, application baselines, assessment evidence.
Same word, six meanings
"There is evidence for this quantum application" can mean a mathematical proof under fault-tolerant assumptions, a classical simulation of a quantum method, a demonstration on a handful of noisy qubits, a controlled benchmark, a customer pilot, or a production deployment. These are not shades of the same thing. They are different objects that support different decisions.
Labeling levels is not a way of sneering at early work. A theory result guides research direction. A simulator result informs resource estimates. A toy hardware demo validates tooling. A pilot tests workflow fit. Production utility supports a business. Each level is valuable as what it is. The disaster is letting one level borrow the authority of another.
Two scores that enforce the labels
The baseline score makes evidence strength explicit:
application_score = evidence_strength - baseline_gap - integration_risk - hardware_risk
Evidence strength rises only as results become more relevant to the target workflow and baseline — not as they become more numerous. Ten toy demos are still a toy demo.
And the decision score ties evidence to action:
decision_score = claim_quality + proof_progress - risk - kill_criteria_pressure
Proof gates are the mechanism: they define, in advance, what evidence must appear before a decision label improves. Without them, evidence levels become decorations on a decision that was made for other reasons.
Worked example: three claims, three rungs
Three claims arrive in the same week. One: a theoretical speedup for a chemistry problem, proven under fault-tolerant assumptions. Two: a small hardware demonstration of an optimization method on a toy instance. Three: a customer pilot where a hybrid quantum-classical pipeline improved a narrow logistics metric, with heavy classical preprocessing doing much of the work.
Rank them by excitement and you will misallocate attention. Instead label each: evidence level, relevance to the target baseline, hardware assumption, and decision implication. The theory result supports monitoring algorithm progress. The toy demo supports tooling validation, nothing more. The pilot supports a narrow workflow claim — and raises a new question about how much of the win was classical. Each claim also gets a next gate: the evidence that would move it up one rung.
Evidence laundering and negative results
The signature failure is evidence laundering: a result valid in one category presented as proof of a stronger one. The toy demo becomes "demonstrated on quantum hardware." The pilot with heavy classical preprocessing becomes "quantum solution in production." The resource estimate becomes "roadmap to commercial advantage." Each hop launders a real result into a false claim.
The quieter failure is ignoring negative evidence. Failed reproductions, weak baselines, high integration costs, and customer disinterest all exist, and all of them should move the label down. An evidence system that only ratchets up is marketing.
The engineering view
You already use this system. Unit tests, integration tests, staging, canaries, and production telemetry are evidence levels, and no competent engineer treats a passing unit test as proof of production reliability. Quantum applications need the same ladder: a simulator run checks one layer, a hardware experiment checks another, a customer workflow checks integration, a deployment checks reliability and economics.
The label should name the layer actually tested. When someone resists labeling — when "it works" is the whole sentence — that resistance is itself diagnostic.
What each rung buys a decision-maker
An investment memo should not ask only whether a claim is true. It should ask what kind of true it is: mathematical, simulated, experimentally demonstrated, operationally validated, or commercially proven. Each kind supports a different decision and a different risk posture, and each is priced differently.
Build decisions, especially, should target a specific rung: the cheapest evidence you can produce that would change someone's label. That framing turns strategy from argument into experiment design.
Exercise
Label three claims. Collect three real quantum application claims — a paper, a vendor page, a news story will do.
- For each, write the baseline being challenged before assigning any label.
- Assign an evidence level: theory, simulation, toy demo, benchmark, customer pilot, production utility, or roadmap claim.
- Write one sentence on what the evidence proves and one on what it does not prove.
- Define the next evidence level needed, then score each claim with the application baseline score and the decision score.
End with a decision label for each claim. If any label exceeds its evidence — a build justified by a toy demo — say so explicitly; catching that mismatch is the exercise.
Check your understanding
Without notes: assign evidence levels to three quantum application claims and justify each label by what was actually tested.
A passing answer distinguishes what was shown from what was claimed, names the baseline for each, includes negative evidence where it exists, and defines a proof gate rather than a vague "wait for more."
Oral defense: take a claim you personally find exciting and argue for its lowest defensible label.
If you get stuck
If your labels drift above the evidence, or a narrow benchmark keeps becoming broad utility, revisit Chapter 42 (Benchmarking Quantum Programs) for what a fair result looks like and Chapter 64 (What Makes a Problem Quantum-Suitable?) for how baselines anchor claims. Evidence levels are those two ideas applied to decision-making.