Signed Evidence, Attestations, and Chain of Custody

Quantum results become valuable when someone is willing to rely on them. Reliance requires chain of custody. A reviewer must know that the circuit, compiled artifact, calibration reference, execution result, mitigation output, and final claim were not silently altered after the run.

Sigstore provides tooling for signing and verifying software artifacts and records signing events in a transparency log [R217]. SLSA provenance describes build provenance for software artifacts [R206]. Quantum evidence packages need the same pattern: sign the artifacts, record provenance, verify before claim acceptance.

flowchart LR
    Circuit[Circuit artifact] --> Sign1[Sign]
    Compiled[Compiled artifact] --> Sign2[Sign]
    Result[Result dataset] --> Sign3[Sign]
    Mitigation[Mitigation output] --> Sign4[Sign]
    Claim[Claim document] --> Sign5[Sign]
    Sign1 --> Evidence[Evidence package]
    Sign2 --> Evidence
    Sign3 --> Evidence
    Sign4 --> Evidence
    Sign5 --> Evidence

What must be signed

Signing only the final PDF or notebook is insufficient.

flowchart TB
    Evidence[Evidence package] --> Intent[Signed intent]
    Evidence --> Program[Signed circuit]
    Evidence --> Compile[Signed compiled artifact]
    Evidence --> Execution[Signed result]
    Evidence --> Analysis[Signed analysis]
    Evidence --> Claim[Signed claim]

Attestation flow

Attestations should be generated by the systems that create artifacts, not by a human after the fact.

sequenceDiagram
    participant C as Compiler
    participant R as Runtime
    participant M as Mitigation service
    participant E as Evidence service
    C->>E: compiled artifact plus attestation
    R->>E: raw result plus attestation
    M->>E: transformed result plus attestation
    E->>E: verify signatures and hashes
    E-->>Reviewer: signed evidence bundle

Each attestation should name the producer identity, input hashes, output hashes, environment, timestamp, and policy version.

Chain-of-custody states

stateDiagram-v2
    [*] --> Created
    Created --> Signed
    Signed --> Verified
    Verified --> Accepted
    Verified --> Rejected
    Accepted --> Archived
    Rejected --> Quarantined
    Archived --> Reanalyzed

A rejected artifact is not deleted immediately. It is quarantined so investigators can inspect whether the problem was corruption, signature failure, schema mismatch, or policy violation.

Verification gate

No claim-bearing workflow should skip verification.

flowchart LR
    Bundle[Evidence bundle] --> Hash[Hash verification]
    Hash --> Sig[Signature verification]
    Sig --> Provenance[Provenance verification]
    Provenance --> Policy[Policy verification]
    Policy --> Decision{Accept?}
    Decision -- yes --> Claim[Release claim]
    Decision -- no --> Quarantine[Quarantine]

Automate integrity checks against a versioned trust policy, including expected signer identities, trusted keys, and signing-time evidence. A valid signature establishes integrity and attribution under those trust assumptions; it does not prove that the producer executed the stated process correctly or that a scientific claim is true.

Transparency and confidentiality

Transparency logs and sensitive quantum evidence can coexist if the platform logs public commitments rather than private contents.

flowchart TB
    PrivateArtifact[Private artifact] --> Hash[Reviewed commitment]
    Hash --> PublicLog[Disclosure-controlled transparency or audit log]
    PrivateArtifact --> SecureStore[Controlled evidence store]
    PublicLog --> Verifier[Verifier checks inclusion]
    SecureStore --> Verifier

For sensitive workloads, keep the artifact in controlled storage. A plain hash can reveal a guessable input by candidate matching, so do not assume that hashing provides confidentiality. Use an access-controlled log or a reviewed hiding-commitment scheme with protected opening material, and minimize identifying metadata. RFC 9901, section 9.3 explains why undisclosed high-entropy randomness matters for hash-based hiding.

Tamper response

flowchart LR
    Verify[Verification failure] --> Scope[Identify impacted artifacts]
    Scope --> Freeze[Freeze claims]
    Freeze --> Recompute[Recompute if possible]
    Recompute --> RCA[Root-cause analysis]
    RCA --> Reissue[Reissue evidence or retract]

Tamper evidence is only useful if it triggers operational action. The platform should freeze dependent claims, identify consumers, and publish a corrective record where appropriate.

Additional technical sources: [R285], [R286].