SuperconducTED

Qiskit Aer accepts crisp numbers for noise. Real superconducting qubits drift between every IBM calibration. We close the gap with a Takagi·Sugeno·Kang fuzzy inference layer that turns calibration snapshots into an ensemble of NoiseModel instances, then aggregates simulations into interval-valued predictions that bracket real hardware across calibration cycles.

Crisp calibration-based noise models match real hardware tightly on the snapshot they were tuned on and degrade silently once that snapshot goes stale. Transferability across calibration cycles is the rope we're trying to climb past that limit · the fuzzy envelope is what gives the ensemble somewhere to go when the calibration moves.

flowchart LR
    A[IBM<br/>Calibration<br/>Snapshot] --> B[Feature<br/>Extraction]
    B --> C[Fuzzification<br/>+ TSK Rules]
    C --> D[Defuzzification]
    D --> E[Squashing]
    E --> F[Channel<br/>Projection]
    F --> G[Aer<br/>NoiseModel<br/>Ensemble]
    G --> H((Interval<br/>Prediction))

    classDef stage fill:#1e1b4b,stroke:#06b6d4,stroke-width:1px,color:#fff;
    classDef io fill:#0b0d17,stroke:#7f5af0,stroke-width:1.5px,color:#fff;
    class A,H io;
    class B,C,D,E,F,G stage;

_{Six stages, one Factory · Ensemble at the seam with Aer. The no-per-shot-Python-hook constraint is respected by realising epistemic uncertainty at ensemble construction time, not at simulation time.}

Architecture detail: docs/architecture.md · Decision ledger (ADRs): docs/decisions.md

A crisp T1 = 142 µs is what Aer wants. A real backend that just got recalibrated wants a range of plausible values weighted by membership. We fuzzify the snapshot through the TSK rule base, sample N concrete NoiseModel instances from the resulting envelope, run each through Aer in parallel, and report [p_lo, p_hi] instead of a single fidelity number. The win is that the real IBM datapoint lives inside the interval the next time the backend gets recalibrated, which is what crisp baselines stop doing the moment the snapshot they were tuned on goes stale.

A Type-1 TSK rule asks for the membership of a calibration value and gets back a single number: μ(T1 = 142 µs) = 0.85. The curve commits to an exact membership grade at every point, and it commits to an exact T1 where that membership peaks. We don't have that much confidence: calibration drift moves not just the parameter, but our belief about the parameter, including where the "prototypical" value sits.

Interval Type-2 (IT2) loosens both at once. Membership at each calibration value becomes an interval: μ(T1 = 142 µs) ∈ [0.55, 0.85]. The peak becomes a plateau rather than a point, because we're not sure exactly where the membership function tops out either. The band between the upper membership function (UMF) and the lower membership function (LMF) is the footprint of uncertainty · it says "the membership function lives somewhere in here, and we don't insist on which curve, or on where exactly it peaks."

The ensemble we sample from an IT2-TSK rule base is correspondingly richer than what a Type-1 base could produce. That extra richness is exactly why the interval prediction in the previous diagram brackets real hardware across cycles instead of just the snapshot it was tuned on. T1 is the noise channel; T2 is how unsure we're allowed to be about it.

Phase	Milestone	Status
0	Calibration polling pipeline	superconducted-poll · cron · idempotent
1	≥ 630 snapshot dataset	accumulating via hourly CI · floor projected for mid-July 2026
2	TSK rule base · fuzzy uncertainty envelope
3	Whitepaper · benchmark against published calibration-based baselines

Phase 0 deliverable is live. superconducted-poll archives IBM backend calibration snapshots, driven by a GitHub Actions workflow that fires hourly against ibm_fez. Phase 1 is dataset accumulation: targeting ~24 snapshots/day, with the ≥ 630 ANFIS-training floor projected for mid-July 2026.

The lab log. Most recent on top. Each entry links to the issue, PR, or ADR it came from.

• Phase 0 · shipped. Calibration polling pipeline went live with the superconducted-poll console script. Cron-friendly, idempotent, one invocation per round. → flagship repo
• ADR · Factory · Ensemble pattern adopted. Aer's no-per-shot-Python-hook constraint forced the design hand: epistemic uncertainty has to be realised at ensemble construction time, not per shot. → docs/decisions.md
• Hourly polling, in CI. The Calibration Polling GitHub Actions workflow fires at HH:05 every hour, runs superconducted-poll --backend ibm_fez, and verifies the poller produced files before committing. Concurrency control keeps overlapping runs from racing each other.
• Git as the calibration database. Snapshots are committed to a dedicated calibration-data branch, organised as snapshots/YYYY-MM/ibm_fez/*.json. Keeps main clean; provenance is just git log. Historical backfill remains capped at 30 days via SUPERCONDUCTED_HISTORICAL_MAX_DAYS.
• Audit · first ADR cycle closed. 22 ADRs reviewed, 2 patched in place, 6 new drafts, 8 follow-up issues filed. The full synthesis lives under docs/state-of-the-project/. → audit report

_{Want to write the next entry? See the open issues on the flagship.}

git clone https://github.com/SuperconducTED/superconducted-noise-engine.git
cd superconducted-noise-engine
python -m venv .venv
# Windows:  .venv\Scripts\activate
# POSIX:    source .venv/bin/activate
pip install -r requirements.txt -r requirements-dev.txt
pip install -e . --no-deps
pytest

_{Made in Ankara · powered by curiosity, caffeine, and Cooper pairs.}