QPC-HTD-20Q — Quantum Polycontextural HPC Threat Detection executed on every line of IQM’s 20-qubit Garnet processor. Not a toy benchmark: a structured, real-world-scale workload with named infrastructure roles, multi-layer security contexts, and verifiable Resonance job identity.
✓ 20 / 20 QUBITS — GARNET CAPACITY ✓ PRODUCTION JSON + JOB UUID
QPC-HTD-20Q maps a credible HPC / cyber-resilience story onto Garnet’s full quantum register — one qubit per named node, one Hamiltonian, four polycontextural prelude layers, then QAOA.
qpc_htd_garnet_20q_fixed.json.For IQM customers and partners, the point is not a single gate count — it is breadth, semantics, and auditability on Nordic superconducting hardware.
QPC is not limited to abstract random circuits: it can express domain-structured workloads that look like what enterprises actually argue about — cascades, correlated failures, tiered infrastructure — and run them at the top of your advertised qubit count.
Figures below are taken from the canonical run saved as qpc_htd_garnet_20q_fixed.json (provider: IQM, quantum computer: garnet).
Each shot samples a 20-bit stress pattern across the facility map. We compute classical energy H from that pattern under the threat model. θ is the 90th percentile of H across all 1,024 samples — a high-stress “cascade band” for this model. The fraction of samples with H ≥ θ is therefore ≈ 10% by construction — a sanity check that the distribution is well-formed, not a literal “10% chance of cyberattack.”
R (systemic threat index) aggregates weighted co-stress on high-risk edges — how often critical pairs (compute–storage, gateway–login, etc.) light up together in the data. It is the hook for ranking hot spots and comparing scenarios, runs, or mitigation strategies — the kind of output an IQM sales engineer can place in front of an HPC or national-lab stakeholder.
When samples land in the top energy decile, these nodes appear most often — the quantum run is telling a coherent infrastructure story, not noise.
| Field | Value |
|---|---|
| Experiment | QPC-HTD-20Q |
| Backend | IQMBackend (Garnet) |
| Job ID | 019d779f-de19-7da3-b178-42f760654c8c |
| Qubits | 20 (full width) |
| Shots | 1024 |
| QAOA layers p | 2 |
| θ (90th percentile H) | 19.091 |
| P(H ≥ θ) | 0.100586 |
| R | 6.503379 |
| H mean (sampled) | 12.038 |
| Wall time (s) | 5.874 |
| Artifact | qpc_htd_garnet_20q_fixed.json |
Queue latency varies by Resonance load; execution time in the JSON is wall-clock for that submission. Earlier long-queue runs are equally valid hardware outcomes — the job UUID is what ties results to IQM’s ledger.
Same stack IQM developers already document — Qiskit + qiskit-iqm + Resonance token.
pip install qiskit qiskit-iqm qiskit-aer numpy (e.g. Python 3.11 venv)export IQM_TOKEN="$(tr -d '\n\r' < ~/.iqm_token)" or paste token oncepython3 qpc_htd_iqm_garnet.py -o qpc_htd_garnet_20q_fixed.jsonpython3 iqm_verify_resonance.pyThe main goal of this page is platform compatibility: QPC workloads execute on IQM’s cloud and silicon the same way your customers already run Qiskit jobs — with a concrete, checkable run (HTD-20Q) rather than claims alone. The sections below separate technical proof from why that matters commercially; both are needed, but they are not the same thing.
qiskit-iqm, backend selection for Garnet — no parallel “QPC runtime” that bypasses your stack.qpc_htd_iqm_garnet.py and written to JSON (same metrics shape as the artifact referenced on this page).COMPATIBILITY ON GARNET — TECHNICAL + STRATEGIC
Cross-platform runs are the practical definition of “compatible”: the same algorithmic ideas must compile and execute wherever the customer’s contract points.
Quantum Polycontextural Computing is intended as a universal computation layer across these families — with IQM providing the Nordic superconducting reference implementation alongside global peers.