Model Output Is Not Proof

A CISO sat through a quantum risk assessment. The deliverable looked clean: heatmaps, exposure scores, and a migration roadmap. The CISO asked one question: did you actually prove anything?

That question is becoming common. Security teams are starting to notice the gap between what quantum vendors describe and what those vendors actually do. The gap is the line between model output and demonstration. Once you see it, it becomes easier to separate planning material from audit-ready evidence.

Three Layers, One Honest Question

Modeling has a role in quantum risk planning. It can estimate timelines, rank assets, and model migration scenarios. Demonstration has a different role. It produces primary evidence that a quantum system executed a defined cryptographic workload under real hardware conditions. Production-scale compromise of RSA-2048 or P-256 is not currently demonstrated by any public quantum system. Three layers answer three different questions. The mistake is treating the first layer as a substitute for the second, and treating either as proof of the third.

Boards, regulators, insurers, and CISOs need audit trails. A model can describe hypothetical exposure. It cannot produce primary evidence that a system did what the model said it would do. Model-only products may be useful, but they are not the same product as evidence.

The Physics Argument Is Real

A leading estimate by Gidney and Ekera found that factoring RSA-2048 in about eight hours would require roughly 20 million noisy physical qubits under specific surface-code assumptions. Even before fault-tolerance overhead, the associated quantum state space is far beyond classical storage. The relevant state space grows exponentially with the number of logical qubits.

That is why model output alone cannot validate quantum exposure at production cryptanalytic scale. The reason quantum computing matters is precisely that classical modeling of certain quantum circuits becomes intractable. If production-scale Shor execution could be cheaply modeled, the post-quantum migration problem would look very different.

Why Models Favor Models

A model-based product gives the buyer output from a model the vendor built. That model includes assumptions about noise, gate fidelity, error-correction overhead, decoherence, qubit connectivity, and circuit depth. Each assumption can be reasonable. The structural problem is that the vendor controls the variables that determine the answer.

The vendor controls every variable that determines the answer. The buyer pays for the answer. The model becomes the auditor, the witness, and the beneficiary at once.

This is not an accusation against any specific firm. It is a description of what happens when a category is built on outputs the buyer cannot independently audit. Serious people can build serious models and the structural conflict still remains.

The Asymmetry of Evidence

A model output produces a number. A demonstration produces logs, measurement statistics, error rates, calibration data, and raw circuit output. The model output can be replicated only by running the same model with the same assumptions. The demonstration can be replicated by running the same circuit on the same hardware, subject to platform availability and queue conditions, and comparing the outputs.

This is the difference between a forecast and an audit trail. Both can be useful. Only one gives the buyer evidence that can be reviewed without depending on the original vendor's model.

Where Intelligence Models Help And Where They Stop

Intelligence Models are powerful inside the quantum risk workflow. They can help inventory cryptographic assets, parse SBOMs, map dependencies, and accelerate migration planning. Neural-network quantum-state methods and tensor-network methods also do real work in structured physics regimes.

None of that establishes production-scale cryptanalytic validation. Shor-class cryptanalytic circuits are not known to admit the kind of efficient classical approximation that would make production RSA-2048 or P-256 attacks classically testable. Intelligence Models are excellent at risk inventory and prioritization. They do not prove that a production key has been broken by a quantum system.

How QScout And QStrike Fit Together

QScout starts with discovery. It finds external cryptographic exposure, HNDL risk, certificate posture, cipher posture, and evidence gaps that justify deeper validation. QStrike is the proof layer. It executes defined cryptographic workloads on supported quantum hardware profiles, subject to platform availability, engagement scope, and approved test design. QSolve is the remediation path after the evidence is understood.

The point is not to claim that today's quantum machines can break production RSA-2048 or P-256. They cannot. The point is to build a buyer-held evidence trail: what was found, what was tested, what hardware behavior was observed, which assumptions survived contact with the machine, and where migration capital should go next.

That is the operational meaning of vendor-neutral evidence. The hardware is not Qtonic Quantum's. The evidence layer is produced through independent quantum platforms, not by a model whose assumptions we control.

What CISOs Should Demand

Three questions cut through the noise. First, show the hardware logs or the QScout evidence trail behind the score. If the answer is only a heatmap, the buyer has been told, not shown.

Second, identify who owns the ground truth. If the vendor controls the model that produced the answer, the vendor controls the answer. Third, ask whether the work can be independently replicated: which platforms, which circuits, which target, and which constraints.

If a migration plan rests on modeled exposure data alone, it can overspend on the wrong assets and underspend on the right ones. Evidence matters because misallocated migration capital cannot be recovered after the budget is gone.

What To Do Next

If your quantum risk program depends on modeled exposure scores, the next step is not to discard the model. The next step is to add an evidence layer. Start with QScout to identify cryptographic exposure and scope the estate. Use QStrike where hardware-backed validation changes the board, audit, or procurement decision. Use QSolve to sequence remediation against the evidence that survives review.

Find. Prove. Fix. In that order. The middle step is the one buyers should insist on before committing migration budget.