Long-Term Evidence Preservation and Reanalysis

Quantum evidence ages. A result that looked persuasive in 2026 may need reanalysis in 2027 after a better classical baseline appears, a compiler bug is found, a mitigation method is deprecated, or a device vendor revises calibration metadata. The platform should preserve enough information to rerun the interpretation, not merely the final plot.

FAIR data principles emphasize findability, accessibility, interoperability, and reusability. W3C PROV provides a domain-agnostic provenance model. DataCite defines metadata patterns for citable research objects. These are useful building blocks for long-term quantum evidence management. [R143]

flowchart LR
    Result[Raw result] --> Metadata[Rich metadata]
    Metadata --> Provenance[Provenance graph]
    Provenance --> Archive[Archive]
    Archive --> Reanalysis[Future reanalysis]
    Reanalysis --> UpdatedClaim[Updated claim]

Preserve the raw and the interpreted

A quantum result has multiple layers:

flowchart TB
    Raw[Raw shots or detector events] --> Processed[Processed counts]
    Processed --> Mitigated[Mitigated estimates]
    Mitigated --> Statistical[Statistical inference]
    Statistical --> Narrative[Narrative claim]

    Metadata[Metadata and provenance] --> Raw
    Metadata --> Processed
    Metadata --> Mitigated
    Metadata --> Statistical
    Metadata --> Narrative

Preserving only the final estimate destroys future optionality. Reanalysis often starts by asking whether the original mitigation, filtering, and baseline choices were appropriate.

Evidence package retention levels

Not every exploratory job deserves permanent preservation. Retention should depend on claim intent and downstream reliance.

flowchart LR
    Job[Job result] --> Intent{Claim intent}
    Intent -- scratch --> Short[Short retention]
    Intent -- internal decision --> Medium[Medium retention]
    Intent -- customer or public --> Long[Long retention]
    Intent -- regulatory or patent --> Legal[Legal hold]

The reanalysis contract

A preserved result should include a contract that tells future teams how it may be reinterpreted.

flowchart TB
    Contract[Reanalysis contract] --> Inputs[Required inputs]
    Contract --> Assumptions[Original assumptions]
    Contract --> Baselines[Baseline dependencies]
    Contract --> Code[Reanalysis code]
    Contract --> Limits[Known limits]
    Contract --> Review[Review process]

Example:

reanalysis_contract:
  raw_data: s3://warehouse/results/qexp-001/raw
  compiled_circuit: artifacts/qexp-001/circuit.qpy
  calibration_snapshot: cal-2026-04-19-001
  baseline_version: classical-baseline-2026-04
  mitigation_version: meas-mitigation-1.8.2
  assumptions:
    - backend connectivity matched target model at compile time
    - shots were independent for analysis purposes
  review_required_if:
    - mitigation_version deprecated
    - baseline_version superseded
    - public_claim_reference present

Provenance graph design

flowchart LR
    Person[Researcher] --> Activity[Experiment activity]
    Algorithm[Algorithm source] --> Activity
    Device[Device state] --> Activity
    Calibration[Calibration snapshot] --> Activity
    Activity --> Dataset[Raw dataset]
    Dataset --> Analysis[Analysis activity]
    Analysis --> Figure[Figure]
    Figure --> Claim[Claim]

The graph should represent people, activities, entities, and derivations. A future reviewer should be able to start from a claim and walk backward to every material input.

Storage tiering

Evidence storage should distinguish hot operational data from cold archival data.

flowchart TB
    Hot[Hot warehouse] --> Warm[Warm object storage]
    Warm --> Cold[Cold archive]
    Cold --> Restore[Restore workflow]
    Restore --> Rehydrate[Rehydrate evidence package]
    Rehydrate --> Reanalyze[Run reanalysis]

Do not move an evidence package to cold storage unless the restore process has been tested. An archive that cannot be restored is deletion with extra ceremony.

Schema evolution

Quantum metadata schemas will change. The archive must preserve old records and provide migration paths.

stateDiagram-v2
    [*] --> SchemaV1
    SchemaV1 --> SchemaV2: add target model hash
    SchemaV2 --> SchemaV3: add policy decision record
    SchemaV1 --> LegacyReadable
    SchemaV2 --> LegacyReadable
    SchemaV3 --> Current

Recommended practices:

• include schema version in every record;
• publish migration code;
• maintain backwards readers;
• do not overwrite original records;
• store validation reports with migrated views.

Claim retraction and correction

Long-term preservation is not only for confidence. It is also for correction.

flowchart LR
    NewInfo[New information] --> Impact[Impact analysis]
    Impact --> Affected[Find affected claims]
    Affected --> Decision{Material?}
    Decision -- no --> Note[Record no material impact]
    Decision -- yes --> Correct[Correct or retract]
    Correct --> Notify[Notify consumers]

Triggers for reanalysis:

• compiler bug;
• calibration data correction;
• better classical baseline;
• mitigation-method deprecation;
• statistical-method defect;
• vendor target model revision;
• reviewer challenge.

Citation and publication objects

When results become public or customer-facing, they should receive stable identifiers and structured metadata.

flowchart TB
    Evidence[Evidence package] --> DOI[Persistent identifier]
    DOI --> Metadata[Discovery metadata]
    Metadata --> Repository[Repository or archive]
    Repository --> Reuse[Reuse and reanalysis]

This does not imply all data is open. Sensitive data can have restricted access while metadata remains discoverable.

Operating rule

A quantum result is not preserved unless a future team can find it, understand it, verify its provenance, and reinterpret it under improved methods.