Quantum Configuration Baselines and Digital Thread

A quantum platform fails quietly when its configuration story fragments. The circuit may be correct, the runtime may be available, and the QPU may be online, but the result becomes weak if no one can reconstruct which calibration, compiler target, pulse policy, queue policy, mitigation setting, and data contract were in force at execution time.

Security-focused configuration management treats configuration as an operational control, not clerical inventory [R205]. Quantum operations need the same discipline with more physical context: every run should attach to a baseline, and every baseline should attach to a digital thread that spans design, fabrication, calibration, execution, interpretation, and claim review. NIST describes digital-thread work as connecting product and lifecycle information across design, manufacturing, and support processes [R207]. The same idea applies to quantum systems: the operational artifact must connect hardware state, software state, evidence, and decision state.

flowchart LR
    Design[Device design] --> Fab[Fabrication lot]
    Fab --> Characterization[Characterization]
    Characterization --> Calibration[Calibration baseline]
    Calibration --> Target[Compiler target]
    Target --> Runtime[Runtime configuration]
    Runtime --> Execution[Experiment execution]
    Execution --> Evidence[Evidence package]
    Evidence --> Claim[Bounded claim]

The baseline is the unit of trust

A baseline is not one file. It is a signed bundle of state.

flowchart TB
    Baseline[Quantum configuration baseline] --> Hardware[Hardware state]
    Baseline --> Calibration[Calibration state]
    Baseline --> Compiler[Compiler target]
    Baseline --> Runtime[Runtime settings]
    Baseline --> Schema[Data schema]
    Baseline --> Access[Access policy]
    Baseline --> Evidence[Evidence policy]

The error pattern is familiar: teams record the circuit and the result counts, but not the execution environment. That is equivalent to recording application logs without recording the deployed version, feature flags, database schema, or infrastructure state.

Baseline lifecycle

A baseline should move through explicit states.

stateDiagram-v2
    [*] --> Draft
    Draft --> Candidate: assembled
    Candidate --> Validated: tests pass
    Validated --> Active: approved
    Active --> Superseded: new baseline active
    Active --> Quarantined: defect found
    Quarantined --> Retired: no longer trusted
    Superseded --> Retired

Draft baselines are local and mutable. Candidate baselines are complete but not trusted. Validated baselines passed release checks. Active baselines may be used for production or claim-bearing work. Quarantined baselines remain available for forensics but cannot be used for new claims.

Baseline comparison

Every quantum result should be explainable as a delta from the previous accepted baseline.

flowchart LR
    B1[Baseline N] --> Diff[Baseline diff]
    B2[Baseline N plus 1] --> Diff
    Diff --> Risk[Risk assessment]
    Risk --> Tests[Validation tests]
    Tests --> Decision{Promote?}
    Decision -- yes --> Active[Activate]
    Decision -- no --> Reject[Reject or revise]

Important diffs include topology change, readout drift, new two-qubit error distribution, compiler pass change, mitigation setting change, queue-priority change, and schema migration.

Digital-thread IDs

A digital thread needs stable identifiers.

thread_id: qdt-2026-04-20-alpha-019
qpu_id: ibm_kyiv_like_system
processor_family: superconducting_transmon
fabrication_lot: lot-91b
calibration_baseline_id: cal-2026-04-20T0900Z
compiler_target_id: target-2026-04-20T1015Z
runtime_contract_id: runtime-sampler-v2-prod-42
schema_version: qevidence.v7
claim_id: claim-materials-vqe-118

The identifiers do not need to disclose sensitive vendor details to every reader. They do need to be resolvable by authorized reviewers.

Baseline ownership

flowchart TB
    PlatformOwner[Platform owner] --> Owns[Owns baseline policy]
    HardwareLead[Hardware lead] --> ApprovesHW[Approves hardware state]
    CalibrationLead[Calibration lead] --> ApprovesCal[Approves calibration state]
    CompilerLead[Compiler lead] --> ApprovesTarget[Approves compiler target]
    SecurityLead[Security lead] --> ApprovesAccess[Approves access policy]
    EvidenceLead[Evidence lead] --> ApprovesEvidence[Approves evidence policy]
    Owns --> ReleaseBoard[Baseline release board]
    ApprovesHW --> ReleaseBoard
    ApprovesCal --> ReleaseBoard
    ApprovesTarget --> ReleaseBoard
    ApprovesAccess --> ReleaseBoard
    ApprovesEvidence --> ReleaseBoard

No single engineer should be able to silently mutate the full baseline used for claim-bearing results. That does not mean every change requires bureaucracy. It means the promotion path is explicit and evidence-backed.

Configuration drift

Quantum configuration drift is broader than software drift.

flowchart LR
    Drift[Drift] --> Physical[Physical drift]
    Drift --> Software[Software drift]
    Drift --> Policy[Policy drift]
    Drift --> Data[Data drift]
    Physical --> Cal[Calibration no longer representative]
    Software --> Compiler[Compiler assumptions changed]
    Policy --> Access[Access or retention changed]
    Data --> Schema[Schema or interpretation changed]

Drift detection should compare actual state against the active baseline. For example, the platform can block a production job when the active calibration is older than the policy allows, when the compiler target no longer matches backend properties, or when mitigation settings changed without an associated review.

Practical rule

Do not ask, “Which QPU did we run on?” Ask, “Which baseline produced this claim?” The first question is inventory. The second is operational trust.

Additional technical sources: [R280].