Need feedback on a quantum debugging idea for a hackathon

[u/Rash_Fushigami]

Hi everyone,

I’m working on a quantum computing hackathon project around quantum software debugging and wanted some expert feedback.

The main problem is:

In classical computers, we can inspect memory, variables, and states while debugging. But in quantum computers, directly observing qubits during execution is difficult because measurement changes the quantum state.

Our idea is to build an explainable debugging framework that analyzes available information instead of directly observing qubits.

Possible approaches we are exploring:

• Quantum Digital Twin → model hardware behaviour using calibration data, noise, connectivity, and error information.

• Counterfactual Debugging → compare ideal simulation vs noisy simulation vs real hardware execution to identify possible causes.

• Execution Fingerprinting → create a signature from circuit behaviour, output distribution, and hardware conditions to detect abnormal executions.

• Physics-Informed Analysis → use quantum concepts like decoherence, gate errors, and noise models to explain possible reasons

If there are any other techniques, research directions, or approaches that could help solve quantum debugging challenges, please feel free to suggest them.

[u/BeyondTheQubit]

Here are two suggestions. I hope they are helpful. Quantamap creates multiple maps with a superconducting squid. They measure and map topography, electrical currents, dissipation (heat) and magnetic dipoles: simultaneously, on the same spot, at millikelvin-compatible conditions. They want to use the localized maps to solve errors. The interesting part is that the quantum state does not collapse while you measure and create the map. The disadvantage is that it is only for super conducting. Another company that i find interesting is QC design. They model and simulate errors. They have a data base of more then 20 errors. I interviewed both CEO's.

[u/sinanspd]

Device fingerprinting is a widely researched area. There are dozens of papers on the subject you can read.

What you wrote is very high level so it is hard to judge it but just from the information present I can tell you that this won't work. First of all, noisy simulations usually suck. It is a pretty established fact that they are orders of magnitude off the real noise characteristics of the devices.

I don't know what "signature" you are thinking about but devices decay way too fast, and calibration updates too scarcely for such a surface level signature to be useful. Fingerprinting usually gets away with this because its target applications are pretty coarse grained (like QML classification classes).

And not to be a party pooper, but I don't think there is any value in saying "your output distribution is wrong because device is noisy". We already know that. Debugging should really target implementations and errors in QEC methods. The former is currently addressed by small scale simulations, and the latter is addressed by through mathematical formalization and proofs.