Case Study: Assembling the Portfolio into a Reproducible Report

Executive Summary

Eight working notebooks are not a portfolio. A portfolio is a document another person can read, evaluate, and reproduce — and assembling one forces exactly the discipline this book has been building toward.

This case study takes the eight capstone projects and produces the artifact: a report with consistent methodology, honest error analysis, verified results, and enough provenance that a reader can rerun it. The result is what you would show an employer, a reviewer, or your future self.

Skills applied

• Standardizing methodology across heterogeneous experiments (§33.11).
• Reporting statistical and systematic uncertainty (§33.13).
• Documenting provenance for reproducibility (Ch. 8).
• Stating scope and limitations precisely.

Phase 1: The results table

Every project, one row, same columns:

Three baselines per row — ideal, noiseless-simulated, and hardware — because each answers a different question: is the algorithm right, is the implementation right, and how much did the device cost you.

The pattern is immediately legible: hardware fidelity falls monotonically with two-qubit gate count, from 0.947 at one gate to 0.318 at 74. That single observation, visible only because the table is consistent, is the portfolio's most important result.

Phase 2: The error analysis

For each project, report both components:

$$\text{Result} = x \pm \sigma_{\text{stat}} \pm \sigma_{\text{sys}}$$

Statistical from shot noise: $\sigma_{\text{stat}} = \sqrt{p(1-p)/N}$. For Grover at $p = 0.702$, $N = 8192$: $\sigma = 0.005$.

Systematic from repeating each experiment across five calibration cycles and taking the spread of the means. For Grover: $\sigma_{\text{sys}} = 0.031$.

$$\text{Grover success} = 0.702 \pm 0.005\,(\text{stat}) \pm 0.031\,(\text{sys})$$

The systematic error is 6× the statistical error. Reporting only the shot-noise bar — the default in most tutorials and many papers — would understate the uncertainty by that factor. This is the single most common reporting failure in the field, and the portfolio should demonstrate that you avoid it.

Phase 3: Verification, project by project

Each project needs a verification independent of the quantum run:

Every project has an independent check. This is deliberate and is the reason the capstone uses classically trivial problems: you cannot learn to verify on problems you cannot verify.

Phase 4: Provenance

Each result carries:

{
  "project": "grover_n16",
  "backend": "ibm_brisbane",
  "backend_calibrated": "2026-07-24T06:12:00Z",
  "qiskit_version": "2.1.0",
  "transpiler_seed": 42,
  "optimization_level": 3,
  "initial_layout": [12, 13, 14, 15],
  "shots": 8192,
  "circuit_sha256": "7c3f9a2e...",
  "raw_counts": {"0110": 5751, "0000": 341, "...": "..."},
  "mitigation": "M3 readout mitigation, cal 2026-07-24T06:30Z"
}

Plus the transpiled circuit archived in QPY. Raw counts always — a reader must be able to recompute every derived number.

Phase 5: The scope statement

The most important paragraph in the report, and the one most often omitted:

Scope and limitations. All eight problems are classically trivial: the largest search space is 16 items and the largest factored integer is 15. No result in this portfolio demonstrates quantum advantage, and none is intended to. The purpose is to implement, execute, and independently verify the canonical quantum algorithms on real hardware, and to characterize how each degrades under realistic noise. The Shor implementation uses a general modular-exponentiation circuit rather than an answer-dependent compilation, though at $N=15$ this distinction has no practical consequence. Results were collected across five calibration cycles between 2026-07-20 and 2026-07-26; exact reproduction is not possible in principle, as device calibration drifts and prior calibration states cannot be restored.

Three things this paragraph does: it prevents a reader from over-reading the results, it demonstrates that you know what the results do and do not show, and it pre-empts the most obvious criticism. Reviewers and employers read it as competence, not as weakness.

Phase 6: What the portfolio demonstrates

Not quantum advantage. It demonstrates:

1. You can implement the canonical algorithms correctly, verified against classical references.
2. You can execute on hardware, handling transpilation, ISA circuits, primitives, and backend selection.
3. You understand noise — you predicted fidelity from gate counts and error rates, and your predictions match.
4. You report honestly — raw counts, both error components, explicit scope, full provenance.
5. You can verify — every claim has an independent check.

Item 5 is the one that matters most, and the one the field most needs. Quantum computing's methodological failures — strawman baselines, missing error bars, histogram-as-proof, mitigated-only reporting — are all failures of verification. A portfolio demonstrating that discipline at trivial scale is evidence you will maintain it at scales where verification is hard.

Discussion Questions

1. Systematic error was 6× statistical. Why is reporting only shot noise so common, and what does it hide?
2. Every project is classically verifiable by design. What is lost, and why is the trade correct for a capstone?
3. The scope statement is the most important paragraph. Why do so few reports include one?
4. Fidelity fell monotonically with two-qubit gate count. What single change to the portfolio would most improve the worst result?

Your Turn: Extensions

• Assemble your own eight-project table with all three baselines.
• Repeat one project across five calibration cycles and compute the systematic spread.
• Write the provenance record for one result and confirm a colleague can rerun it.
• Draft your own scope statement, then ask someone to try to over-read your results.

Key Takeaways

• Report three baselines — ideal, noiseless simulation, hardware — because each answers a different question.
• Systematic error from calibration drift typically exceeds shot noise several-fold; reporting only the statistical bar understates uncertainty.
• Every project needs an independent classical verification; this is why capstone problems are deliberately trivial.
• Archive raw counts, backend, calibration timestamp, seeds, and the transpiled circuit — derived numbers must be recomputable.
• An explicit scope statement, disclaiming advantage and stating what was actually shown, reads as competence rather than as weakness.