Cross-Institution Data Sharing and Federated Evidence Rooms

Quantum programs increasingly cross organizational boundaries: universities, national labs, cloud providers, startups, hardware vendors, customers, auditors, and government funders. The operational problem is not merely sharing files. It is sharing enough evidence for independent review without leaking sensitive workloads, credentials, export-controlled details, or proprietary calibration data.

Diagram loads as you read

Cross-Institution Data Sharing and Federated Evidence Rooms · Figure 1

View diagram source

flowchart LR
    Producer[Evidence producer] --> Room[Federated evidence room]
    Reviewer[Reviewer] --> Room
    Auditor[Auditor] --> Room
    Room --> Decision[Shared decision]

Evidence-room goals

Goal	Meaning
selective disclosure	reveal only necessary fields
chain of custody	preserve who created, changed, and approved artifacts
reproducibility	enable rerun or reanalysis where permitted
policy enforcement	respect residency, export, privacy, and IP rules
revocation	remove access without rewriting history
cross-reference	connect runs, claims, datasets, and approvals

Diagram loads as you read

Evidence-room goals · Figure 2

View diagram source

mindmap
  root((Federated evidence room))
    Selective disclosure
    Chain of custody
    Reproducibility
    Policy enforcement
    Revocation
    Cross-reference

Evidence levels

Diagram loads as you read

Evidence levels · Figure 3

View diagram source

flowchart TB
    L0[Level 0: claim summary] --> L1[Level 1: aggregate metrics]
    L1 --> L2[Level 2: execution metadata]
    L2 --> L3[Level 3: raw shots or traces]
    L3 --> L4[Level 4: sensitive calibration or pulse details]

Not every reviewer needs every level. A public benchmark may expose aggregate metrics and target metadata. A regulator or customer auditor may require signed execution records. A hardware partner may need calibration details under stricter controls.

Trustable exchange

Remote attestation patterns help relying parties gain confidence in the trustworthiness of remote peers and components. IETF RATS defines an architecture for evidence, attesters, verifiers, and relying parties. [R185] For evidence exchange over APIs, HTTP Message Signatures provide a standard mechanism for signing selected components of HTTP messages. [R186]

Diagram loads as you read

Trustable exchange · Figure 4

View diagram source

sequenceDiagram
    participant Attester
    participant Verifier
    participant Room
    participant Reviewer
    Attester->>Verifier: Evidence about platform state
    Verifier-->>Room: Verification result
    Room->>Reviewer: Signed artifact and verification status
    Reviewer->>Room: Access decision or query

Credentialed claims

W3C Verifiable Credential Data Integrity defines mechanisms for cryptographic proofs over verifiable credentials and similar constrained digital documents. [R187] Quantum evidence rooms can use this pattern for provider attestations, reviewer qualifications, calibration attestations, benchmark witness statements, and training records.

Diagram loads as you read

Credentialed claims · Figure 5

View diagram source

flowchart LR
    Issuer[Issuer] --> Credential[Credential with proof]
    Credential --> Holder[Holder]
    Holder --> Verifier[Verifier]
    Verifier --> Decision[Trust decision]

Data minimization

The NIST Privacy Framework is a voluntary tool for managing privacy risk. [R188] Even when a quantum workload does not contain personal data, privacy-style minimization is still useful: do not collect, expose, or retain more sensitive material than the review purpose requires.

Diagram loads as you read

Data minimization · Figure 6

View diagram source

flowchart LR
    Purpose[Review purpose] --> Fields[Minimum fields]
    Fields --> Policy[Disclosure policy]
    Policy --> Export[Evidence export]
    Export --> Audit[Access audit]

Room architecture

Diagram loads as you read

Room architecture · Figure 7

View diagram source

flowchart TB
    Identity[Identity and roles] --> Policy[Policy engine]
    Artifact[Artifact store] --> Policy
    Index[Evidence index] --> Policy
    Policy --> View[Reviewer-specific view]
    View --> Watermark[Disclosure watermark]
    View --> Log[Access log]

A federated room can be implemented as a controlled data product: immutable artifact storage, access-scoped views, signed manifests, query logs, retention rules, and revocation lists.

Cross-institution workflow

Diagram loads as you read

Cross-institution workflow · Figure 8

View diagram source

sequenceDiagram
    participant Lab
    participant Provider
    participant Customer
    participant Auditor
    Lab->>Provider: Run workload
    Provider->>Lab: Execution evidence
    Lab->>Customer: Share bounded evidence view
    Customer->>Auditor: Delegate review access
    Auditor->>Lab: Request missing artifact
    Lab->>Auditor: Provide redacted signed artifact

The evidence room should distinguish between missing evidence, intentionally redacted evidence, and unavailable evidence. These are different conditions.

Operational rule

A shared quantum claim should travel with a signed evidence manifest, access policy, redaction statement, and reviewer log.

Diagram loads as you read

Operational rule · Figure 9

View diagram source

flowchart LR
    Claim[Shared claim] --> Manifest[Signed manifest]
    Manifest --> Policy[Access policy]
    Policy --> Redaction[Redaction statement]
    Redaction --> Log[Reviewer log]