Application Evidence Dossier
Most quantum application write-ups start with an algorithm and go hunting for a problem. The evidence dossier runs the other way — buyer, workflow, and classical baseline first, quantum method last — and this capstone produces one.
The strength of a quantum application case is set by the classical baseline it must beat, not by the elegance of the quantum method.
This capstone produces an application evidence dossier: buyer, workflow, pain, baseline, and metric first — quantum mechanism, hardware assumptions, and decision label second. You will end with a document a technical reader can audit and a business reader can act on.
Core concepts: capstone synthesis, application baselines, quantum utility.
Start with the buyer, not the qubit
The dossier is the capstone of baseline-first judgment. Its opening sections name the buyer, the workflow, the pain, the current solution, and the metric the buyer is graded on. Only then does it discuss the quantum mechanism, the hardware assumptions, the resource requirements, and the risks. The order is the discipline: if the quantum method appears before the baseline, you are writing advocacy.
The dossier ends in a decision label — build, partner, monitor, wait, or avoid — with the evidence chain that produces it visible on the page.
Scoring without fooling yourself
Three small scores structure the analysis. The application baseline score: . The opportunity value: . And the teaching mastery check — correct explanation, worked check, transfer prompt, stated limitation — so the dossier can be handed to someone else.
These are scaffolding for honesty, not precision instruments. Their job is to make the trade-offs visible enough to argue with.
Each term earns its place. Evidence strength asks what has actually been demonstrated, by whom, and whether anyone reproduced it. Baseline gap asks how far the quantum method sits from the best classical result today — not from a strawman. Integration risk prices the unglamorous work of getting data in and answers out inside a real workflow. Hardware risk prices the gap between the machine the method assumes and the machines that exist. A dossier that can name its largest subtraction is already better than most of the genre.
Worked example: one claim, dossiered
Take a representative claim: a quantum optimization method said to outperform classical solvers on a logistics problem. Buyer first — who owns this workflow, what do they pay for, what solver do they run today, and what improvement would change their budget? Baseline next — the best classical heuristic on their actual data, with instance sizes named.
Then the evidence: is there a peer-reviewed comparison, a vendor benchmark, a reproduced result? Then the quantum side: which algorithm, what resource estimate, what hardware maturity does it assume, and when could that hardware plausibly exist? Finally the label. For a claim like this the honest answer is often monitor — with named proof gates, such as a reproduced benchmark on industrially sized instances, that would move it.
The dossier closes with its negative case: the evidence that would make the application less attractive — a stronger classical baseline, no data access, hardware delay, failed reproduction, buyer indifference. A decision that cannot move is not a decision.
How dossiers go wrong
The common failure is the use-case essay: a pleasant tour of an industry with the word quantum sprinkled in and no metric anywhere. The second is treating a benchmark as a customer result — a number on a synthetic instance says nothing about a buyer's workflow until someone maps it there.
Overclaiming is the third failure, and it cuts both directions: an enthusiastic build on thin evidence, or a reflexive avoid with no analysis. A monitor with named things to watch, or a wait with clear proof gates, can be the strongest label in the room.
The engineer's analogy
This is a requirements-and-benchmark document: input data, output metric, baseline implementation, resource constraints, reproducibility path, validation plan. The quantum component is evaluated like any other system component — if integration, data movement, or verification dominates the cost, the score must show it. When the mechanism is structurally right but the hardware is years away, the dossier separates long-term promise from near-term action instead of blending them into a fog of maybe.
What the dossier buys you
A builder uses it to pick a prototype — or to kill a weak use case before it eats a year. An investor or partner uses it to check whether customer evidence and technical evidence point the same direction; when the two disagree, that disagreement is the finding. For public teaching, include a compact scorecard and one paragraph of rationale, so the reader sees the label follow from evidence rather than taste.
Keep the two audiences in different seats. The technical reader checks the resource estimate and the baseline; the business reader checks the buyer and the metric. A dossier that serves both without blurring them is the capstone's proof of expertise.
Exercise
Write the dossier. Choose one application claim — chemistry, optimization, security, sensing, or quantum machine learning — and produce the full document.
- Submit: the dossier with scorecard, failure modes, evidence labels, and a build, partner, monitor, wait, or avoid recommendation.
- Check: verify the baseline appears before the quantum method, then compute the application score and the EV.
- Transfer: apply the same structure to a second application and note which sections change.
- Repair: if the draft starts from the quantum method or hides dated claims, rebuild the decision discipline after Chapter 72, When to Build, Partner, Wait, or Avoid.
Check your understanding
Defend the dossier orally.
A passing defense states the buyer's metric without notes, explains why the label follows from the evidence, and names the single observation that would most change the score.
If you get stuck
If the dossier reads like advocacy, treats benchmarks as customer value, or cannot name its negative case, revisit Chapter 72 (When to Build, Partner, Wait, or Avoid) for the decision framework before rewriting.