Skip to content

SCPN/FIM repeated IBM follow-up protocol

Date: 2026-05-05

Purpose: replace the first descriptive SCPN/FIM IBM pilot with a smaller but replicated design that can test whether the pilot's negative direction is stable.

Background

The first SCPN/FIM n=4 IBM pilot on ibm_kingston completed as job ibm-run-4c0bd60c3fc2c532. It returned complete raw counts, but it had one hardware sample per lambda/depth/state condition. The analysis therefore blocks formal p-values and blocks any claim that the FIM term improves hardware coherence.

The observed pilot direction was also not favourable to a protection claim:

  • lambda = 4 versus lambda = 0 mean magnetisation-leakage delta: +0.11559244791666666
  • Higher magnetisation leakage: 15 / 15 matched comparisons

Follow-up design

Generated by:

env PYTHONPATH=src /home/anulum/.local/bin/python scripts/prepare_fim_ibm_repeated_followup.py

Default design:

  • Backend target: selected later by live readiness
  • Qubits: n = 4
  • Lambdas: 0, 4
  • Depths: 2, 4, 6
  • Initial states: 0000, 0001, 0011, 0111, 1111
  • Magnetisation sectors: +4, +2, 0, -2, -4
  • Replicates per lambda/depth/state condition: 5
  • Main circuits: 150
  • Readout baseline circuits: 16
  • Total circuits: 166
  • Shots per circuit: 2048
  • Total shots: 339,968
  • Randomization seed: 2026050503

Artefacts:

  • scripts/prepare_fim_ibm_repeated_followup.py
  • data/scpn_fim_hamiltonian/fim_ibm_repeated_followup_protocol_2026-05-05.json
  • JSON SHA256: d153d00c2298722b2b13cdec050aca81632b3bb47be8aeb7116826bda8cf528c
  • data/scpn_fim_hamiltonian/fim_ibm_repeated_followup_protocol_2026-05-05.csv
  • CSV SHA256: 9c8998b57aa3cc65bb499c99c80d2eac38381e1e73ce72792d461fc3d52ece94

Primary test

Compare lambda = 4 against lambda = 0 within matched initial state and depth.

Primary observables:

  • Magnetisation leakage
  • Exact-state retention
  • Parity leakage after state-specific readout-flip correction

The analysis should report uncertainty across the five replicate samples per condition. Welch tests and permutation tests are allowed after the repeated campaign returns, but only if the live submission preserves the planned randomization and all count dictionaries are complete.

Claim boundary

Allowed if the follow-up is run:

  • The protocol tests whether the first pilot's negative direction is reproducible.
  • The protocol can support descriptive uncertainty estimates and limited inferential tests.

Blocked until raw counts are collected and analysed:

  • Any claim that FIM improves hardware coherence.
  • Any claim of hardware many-body localisation.
  • Any backend-general claim.
  • Any claim based on uncorrected readout alone.

Live gate before submission

Before spending more QPU time:

  1. Run live backend transpilation on the exact repeated protocol.
  2. Reject if live depth or two-qubit gate count increases materially beyond the first pilot.
  3. Confirm queue/runtime estimate.
  4. Confirm the run fits the remaining QPU budget.
  5. Submit only after explicit approval.

2026-05-05 live readiness result

Live readiness was run against ibm_kingston through IBM Cloud credentials from the vault. No QPU job was submitted.

Command:

env PYTHONPATH=src /home/anulum/.local/bin/python scripts/prepare_fim_ibm_live_readiness.py --protocol data/scpn_fim_hamiltonian/fim_ibm_repeated_followup_protocol_2026-05-05.json --backend ibm_kingston --channel ibm_cloud --vault-token-kind api_key

Artefacts:

  • data/scpn_fim_hamiltonian/fim_ibm_repeated_followup_live_readiness_2026-05-05.json
  • JSON SHA256: 1ee5a4ac76352f93fb804b72138f04b5f5bf6eaf4ad94bff6a8b1c52e6a00e8c
  • data/scpn_fim_hamiltonian/fim_ibm_repeated_followup_live_readiness_2026-05-05.csv
  • CSV SHA256: f024cbe4289a1efe04d1e645158cab710a0d3ecfd20b418ff0320db1365009d5

Readiness summary:

  • Backend: ibm_kingston
  • Backend status: operational, active
  • Pending jobs at readiness check: 14
  • Total circuits: 166
  • Total shots: 339,968
  • Maximum live transpiled depth: 540
  • Maximum live two-qubit gates: 169
  • Submission status: not_submitted

Decision: technically runnable, but it should only be submitted if the QPU budget can absorb a 166-circuit, 339,968-shot replicated follow-up. The scientific value is replication of the first pilot's negative direction; it is not a broad exploratory run.

Scientific decision rule

If lambda = 4 again increases leakage consistently, or if the sign is unstable after readout correction, the SCPN/FIM paper must report no hardware evidence for FIM coherence protection on this backend/circuit family.

2026-05-05 repeated run outcome

The repeated follow-up was submitted and completed as IBM job ibm-run-cf4835290f607387.

Analysis:

  • scripts/analyse_fim_ibm_repeated_followup.py
  • data/scpn_fim_hamiltonian/fim_ibm_repeated_followup_analysis_2026-05-05_ibm-run-cf4835290f607387.json
  • docs/campaigns/scpn_fim_repeated_followup_analysis_2026-05-05.md

Outcome: the run falsifies the simple FIM hardware-protection interpretation for this backend/circuit family.

For lambda = 4 relative to lambda = 0:

  • Mean magnetisation-leakage delta: +0.08955729166666666
  • Fisher p for magnetisation leakage: 7.488374675730006e-55
  • Positive magnetisation-leakage deltas: 14 / 15
  • Mean state-retention delta: -0.0796875

The paper must not claim hardware coherence improvement from this tested FIM implementation.