Decommissioning, Data Sunset, and Hardware Retirement

Quantum platforms accumulate artifacts quickly: source programs, compiled circuits, pulse schedules, calibration records, raw shots, processed results, notebook outputs, benchmark scores, provider invoices, incident tickets, and external claims. Some must be preserved. Some must expire. Some must be destroyed. A mature platform knows the difference.

NIST SP 800-88 Rev. 2 frames media sanitization as a program for making access to stored information infeasible at the required level of effort. Quantum decommissioning extends that idea from storage media to workloads, evidence, provider accounts, reserved capacity, hardware targets, control systems, and claims that depend on retired assumptions. [R155]

Diagram loads as you read

Decommissioning, Data Sunset, and Hardware Retirement · Figure 1

View diagram source

flowchart LR
    Asset[Quantum asset] --> Classify[Classify]
    Classify --> Retain[Retain]
    Classify --> Archive[Archive]
    Classify --> Sanitize[Sanitize]
    Classify --> Destroy[Destroy]
    Retain --> Evidence[Evidence store]
    Sanitize --> Certificate[Sanitization certificate]
    Destroy --> Certificate

What gets decommissioned

Diagram loads as you read

What gets decommissioned · Figure 2

View diagram source

mindmap
  root((Decommissioning scope))
    Data
      raw shots
      processed results
      optimizer traces
      evidence packages
    Software
      SDK baselines
      compiler images
      runtime connectors
    Accounts
      provider credentials
      lab users
      service identities
    Hardware
      QPUs
      control electronics
      sensors
      storage media
    Claims
      benchmark pages
      customer reports
      papers

A quantum asset is anything that can affect execution, interpretation, reproducibility, cost, safety, or external representation.

Data lifecycle states

Diagram loads as you read

Data lifecycle states · Figure 3

View diagram source

stateDiagram-v2
    [*] --> Active
    Active --> Preserved
    Active --> Expiring
    Preserved --> Reanalyzed
    Preserved --> Archived
    Expiring --> Review
    Review --> Deleted
    Review --> Extended
    Archived --> Restored
    Deleted --> [*]

The lifecycle must include a review state. Deleting raw shots before a paper, customer report, or incident investigation is resolved can destroy the ability to validate a claim.

Retention classes

Class	Examples	Default action
ephemeral	failed toy runs, local simulator scratch	short retention, no archival
reproducibility	benchmark runs, research experiments	preserve evidence and environment
contractual	customer-facing pilots, SLA evidence	retain per contract
regulated	export, privacy, safety, audit-sensitive artifacts	retain and sanitize per policy
obsolete	superseded toolchains, retired target profiles	archive minimal metadata, remove active use

Diagram loads as you read

Retention classes · Figure 4

View diagram source

flowchart TB
    Artifact[Artifact] --> Evidence{Supports claim?}
    Evidence -- yes --> Preserve[Preserve with lineage]
    Evidence -- no --> Contract{Contractual or regulated?}
    Contract -- yes --> Retain[Retain by policy]
    Contract -- no --> Expire[Expire on schedule]

Hardware retirement

A retired target is not just removed from a dropdown.

Diagram loads as you read

Hardware retirement · Figure 5

View diagram source

flowchart LR
    Retire[Retirement decision] --> Freeze[Freeze target profile]
    Freeze --> FinalCal[Record final calibration state]
    FinalCal --> Evidence[Link dependent evidence]
    Evidence --> Disable[Disable new submissions]
    Disable --> Export[Export records]
    Export --> Sanitize[Sanitize local media]
    Sanitize --> Close[Close asset]

Retirement checklist:

freeze the final target profile;
record final topology, instruction set, calibration metadata, and known limitations;
identify evidence packages that depend on the target;
block new production submissions;
preserve the minimum reproducibility record;
sanitize local control, storage, and credential media;
revoke provider and lab access;
update public/internal benchmark records.

Provider exit

Provider relationships end. The exit plan should exist before first production use.

Diagram loads as you read

Provider exit · Figure 6

View diagram source

sequenceDiagram
    participant Owner
    participant Broker
    participant Provider
    participant Store
    Owner->>Broker: initiate provider exit
    Broker->>Provider: export job metadata and invoices
    Provider-->>Broker: export package
    Broker->>Store: preserve evidence and mapping
    Broker->>Provider: revoke credentials and reservations
    Broker-->>Owner: exit certificate

Exit evidence should include:

provider account identifiers;
project mappings;
job identifiers;
target identifiers;
retention decisions;
outstanding claims;
revoked credentials;
unresolved incidents;
invoices and reservations.

Data sunset is not data loss

Sunset means controlled reduction.

Diagram loads as you read

Data sunset is not data loss · Figure 7

View diagram source

flowchart TB
    Raw[Raw shots] --> Aggregate[Aggregated distributions]
    Raw --> Hash[Cryptographic hash]
    Raw --> Sample[Representative retained sample]
    Aggregate --> Preserve[Preserved summary]
    Hash --> Preserve
    Sample --> Preserve
    Raw --> Delete[Delete bulk data after review]

For some workloads, raw shots must be preserved. For others, a summary plus hashes, environment metadata, and statistical review may be enough. Decide by evidence class, not storage pressure alone.

Claim dependency graph

Before removing artifacts, trace dependent claims.

Diagram loads as you read

Claim dependency graph · Figure 8

View diagram source

erDiagram
    ARTIFACT ||--o{ RESULT : produced
    RESULT ||--o{ EVIDENCE_PACKAGE : supports
    EVIDENCE_PACKAGE ||--o{ CLAIM : substantiates
    CLAIM ||--o{ PUBLICATION : appears_in
    CLAIM ||--o{ CUSTOMER_REPORT : appears_in

A stale claim can be more dangerous than a stale dataset. It may continue to circulate after the evidence has been deleted or superseded.

Sanitization workflow

Diagram loads as you read

Sanitization workflow · Figure 9

View diagram source

flowchart LR
    Inventory[Inventory media and stores] --> Decide[Choose method]
    Decide --> Execute[Execute sanitization]
    Execute --> Verify[Verify outcome]
    Verify --> Certify[Issue certificate]
    Certify --> Archive[Archive certificate]

Sanitization applies to:

lab workstations;
FPGA/controller storage;
data acquisition systems;
removable media;
object stores;
backup snapshots;
provider exports;
secrets stores;
temporary analysis environments.

Decommissioning incident classes

Diagram loads as you read

Decommissioning incident classes · Figure 10

View diagram source

flowchart TB
    Incident[Decommissioning incident] --> DeletedTooSoon[Deleted before review]
    Incident --> NotDeleted[Retained beyond policy]
    Incident --> OrphanClaim[Claim without evidence]
    Incident --> SecretLeft[Credential not revoked]
    Incident --> MediaGap[No sanitization proof]

Every incident should feed policy updates. Decommissioning is part of production reliability.

Sunset manifest

Illustrative listing · yaml

sunset_manifest:
  asset_id: target-profile-qpu-alpha-v4
  owner: quantum-platform
  decision: retire
  effective_date: 2026-04-30
  dependent_claims:
    - benchmark-report-2026-q1
    - customer-pilot-a-evidence
  preserve:
    - final_target_profile
    - final_calibration_summary
    - evidence_package_index
  sanitize:
    - temporary_provider_exports
    - retired_service_tokens
  approval:
    owner: platform-director
    reviewer: security-governance

A platform that cannot decommission cannot govern its own memory.