Retention, Privacy, and Data Disposition — Operating Quantum Computers

Quantum operations create more data than teams expect: circuits, Hamiltonians, calibration streams, pulse schedules, measurement counts, optimizer trajectories, notebooks, job logs, telemetry, provider metadata, cost records, approvals, and evidence packages. Retaining everything forever is expensive and risky. Deleting too aggressively destroys reproducibility.

The platform needs explicit retention classes.

Diagram loads as you read

Retention, Privacy, and Data Disposition · Figure 1

View diagram source

flowchart TB
    Data[Quantum data object] --> Classify[Classify]
    Classify --> Retain[Retention policy]
    Retain --> Protect[Protection controls]
    Retain --> Dispose[Disposition rule]
    Protect --> Access[Access review]
    Dispose --> Certificate[Disposition certificate]

Data classes

Class	Examples	Default posture
raw experimental data	shots, traces, waveforms	preserve for reproducibility
derived results	expectations, fitted parameters	preserve with lineage
calibration telemetry	T1/T2, fidelities, drift metrics	retain by operational value
sensitive workload inputs	molecule, objective, customer data	minimize and protect
evidence package	signed claims, reviews, hashes	long retention
operational logs	scheduler, broker, adapter logs	retain for incident window
cost records	reservations, usage allocation	retain for finance period

Diagram loads as you read

Data classes · Figure 2

View diagram source

flowchart LR
    QuantumData[Quantum data] --> Raw[Raw]
    QuantumData --> Derived[Derived]
    QuantumData --> Calibration[Calibration]
    QuantumData --> Evidence[Evidence]
    QuantumData --> Logs[Logs]
    QuantumData --> Finance[Finance]

Privacy and minimization

Quantum data is not automatically private, but some workloads encode sensitive business or personal facts. A logistics optimization objective may reveal customer flows. A chemistry workload may reveal proprietary materials. A security workflow may reveal cryptographic inventory.

The NIST Privacy Framework provides a risk-management vocabulary for identifying and managing privacy risk in products and services [R230]. Quantum platforms should apply the same discipline to workload inputs, metadata, and shared evidence rooms.

Diagram loads as you read

Privacy and minimization · Figure 3

View diagram source

flowchart TB
    WorkloadInput[Workload input] --> Sensitivity[Privacy and business sensitivity review]
    Sensitivity --> Minimize[Minimize fields]
    Minimize --> Tokenize[Tokenize or abstract]
    Tokenize --> Execute[Execute]
    Execute --> Evidence[Evidence with protected references]

Retention matrix

A retention matrix should separate scientific reproducibility from operational troubleshooting.

Data	Short retention	Long retention	Deletion trigger
scheduler logs	incident analysis	aggregated metrics	log window expires
raw shots	reproducibility	selected reference runs	claim superseded or policy expires
calibration streams	drift analysis	summaries and anomalies	hardware retirement
evidence package	audit and claims	durable record	legal or policy horizon
notebooks	research trace	frozen release artifact	superseded and archived

Diagram loads as you read

Retention matrix · Figure 4

View diagram source

flowchart LR
    Create[Create data] --> Active[Active retention]
    Active --> Archive[Archive]
    Archive --> Review[Retention review]
    Review --> Extend[Extend]
    Review --> Dispose[Dispose]
    Dispose --> Proof[Disposition proof]

Disposition and sanitization

Data deletion must be controlled. NIST media-sanitization guidance defines sanitization as making access to target data infeasible for a given level of effort and gives practical decision patterns for media and data disposition [R155]. Quantum platforms should adapt those ideas for cloud objects, provider exports, local storage, notebooks, and evidence archives.

Diagram loads as you read

Disposition and sanitization · Figure 5

View diagram source

sequenceDiagram
    participant Owner as Data owner
    participant Policy as Retention policy
    participant Store as Storage service
    participant Evidence as Evidence log
    Owner->>Policy: request disposition
    Policy->>Store: authorize deletion or archive
    Store-->>Policy: disposition result
    Policy->>Evidence: record certificate and digest

A disposition certificate should record the object identifier, policy basis, approval, method, timestamp, and any residual references.

Records management

Public-sector or regulated organizations may have formal electronic-record requirements. NARA’s universal electronic records management material organizes requirements around capture, maintenance and use, disposal, transfer, metadata, and reporting [R231]. Those lifecycle categories map well to quantum evidence operations.

Diagram loads as you read

Records management · Figure 6

View diagram source

flowchart LR
    Capture[Capture] --> Maintain[Maintain and use]
    Maintain --> Dispose[Dispose]
    Maintain --> Transfer[Transfer]
    Capture --> Metadata[Metadata]
    Metadata --> Reporting[Reporting]

Anti-patterns

Anti-pattern	Impact
retaining raw data without classification	unnecessary exposure
deleting notebooks but keeping claims	irreproducible publications
preserving hashes without access policy	unverifiable evidence
provider exports outside catalog	hidden retention exposure
no disposition certificate	audit uncertainty

Diagram loads as you read

Anti-patterns · Figure 7

View diagram source

flowchart TB
    DataSprawl[Data sprawl] --> Exposure[Exposure]
    DataSprawl --> Cost[Cost growth]
    DataSprawl --> Confusion[Unclear source of truth]
    OverDeletion[Over deletion] --> Irreproducible[Irreproducible claim]

Operating rule

Every quantum data object should have an owner, classification, retention class, access policy, lineage link, and disposition rule. If the platform cannot say when an object may be deleted, it also cannot say why it is being retained.