Tamper-Evident Logs and Quantum Transparency Services

Quantum platforms need ordinary logs, but ordinary logs are not enough for high-assurance claims. Operators need a way to prove that critical evidence was recorded at a given time and has not been silently rewritten. This is the role of tamper-evident logs and transparency services.

Certificate Transparency demonstrates a general pattern: append-only logs, Merkle-tree proofs, and independent monitors can make issued facts visible and auditable [R222]. The same pattern can be adapted to quantum evidence: calibration summaries, provider attestations, result digests, compiler releases, policy decisions, and claim approvals.

flowchart LR
    Event[Quantum evidence event] --> Canonicalize[Canonicalize]
    Canonicalize --> Digest[Hash digest]
    Digest --> Append[Append to transparency log]
    Append --> Proof[Inclusion proof]
    Proof --> Evidence[Evidence package]
    Evidence --> Verifier[Verifier]

What belongs in the log

Do not put raw measurement data, sensitive circuits, or confidential formulas into a transparency log unless the risk has been explicitly accepted. Put commitments, digests, envelopes, and metadata that allow later verification.

flowchart TB
    RawData[Raw data] --> Sensitive{Sensitive?}
    Sensitive -- yes --> HashOnly[Protected commitment and minimal metadata]
    Sensitive -- no --> Redacted[Redacted event]
    HashOnly --> Log[Transparency log]
    Redacted --> Log

Transparency-service architecture

A transparency service can be internal at first. It should still use externalizable patterns: append-only sequencing, signed tree heads, inclusion proofs, consistency proofs, and monitorable endpoints.

flowchart TB
    Producers[Platform producers] --> Intake[Log intake API]
    Intake --> Validate[Schema and policy validation]
    Validate --> Sequencer[Append-only sequencer]
    Sequencer --> Merkle[Merkle tree]
    Merkle --> SignedHead[Signed tree head]
    SignedHead --> Monitor[Independent monitor]
    Merkle --> ProofAPI[Proof API]
    ProofAPI --> EvidencePkg[Evidence packages]

An inclusion proof establishes that a commitment belongs to a particular tree head. Authenticating that head and checking consistency with independently observed checkpoints supports tamper detection. A log does not prove scientific correctness or the actual execution time; a timestamp chosen by the producer or log is not independent time evidence. [R222]

Integration with attestations

Supply-chain attestation formats such as in-toto define a pattern for authenticated statements about artifacts and processes [R223]. Quantum evidence can use the same split: a subject, a predicate type, and a signed statement.

classDiagram
    class Statement {
      subject_digest
      predicate_type
      issued_at
      signer
    }
    class Predicate {
      workload_id
      backend_id
      calibration_digest
      result_digest
      policy_decision
    }
    class TransparencyEntry {
      log_index
      tree_size
      inclusion_proof
    }
    Statement --> Predicate
    Statement --> TransparencyEntry

A result package can therefore contain both signed attestations and transparency proofs.

Monitors and witnesses

A transparency log is only useful if someone watches it. Monitors should look for unexpected provider changes, retroactive evidence, suspicious policy bypasses, unusual signer activity, and claims published without matching evidence.

sequenceDiagram
    participant Log as Transparency log
    participant Monitor as Monitor
    participant Policy as Policy engine
    participant Ops as Operations
    Log-->>Monitor: new signed tree head
    Monitor->>Log: fetch entries
    Monitor->>Policy: evaluate anomalies
    Policy-->>Monitor: findings
    Monitor->>Ops: open review tasks

Independent witnesses strengthen the system. They periodically observe signed tree heads and make equivocation harder.

Handling confidentiality

Quantum workloads may include sensitive molecular structures, optimization objectives, customer data, or proprietary algorithms. A transparency service must not become a disclosure channel.

flowchart LR
    Artifact[Artifact] --> Classify[Classify]
    Classify --> Public{Public enough?}
    Public -- yes --> StoreMetadata[Store metadata]
    Public -- no --> StoreCommitment[Store commitment only]
    StoreMetadata --> Log
    StoreCommitment --> Log

Log commitments by default, but review their disclosure properties. Plain digests can reveal low-entropy or guessable artifacts, and identifiers or URIs can leak metadata. Sensitive entries need access controls or a reviewed hiding-commitment scheme; a public hash alone is insufficient. See RFC 9901, section 9.3.

Failure modes

flowchart TB
    Evidence[Evidence] --> Signed{Signed?}
    Signed -- no --> Reject[Reject high-assurance use]
    Signed -- yes --> Logged{Logged?}
    Logged -- no --> Hold[Hold pending transparency entry]
    Logged -- yes --> Proof{Proof verified?}
    Proof -- yes --> Accept[Accept evidence object]
    Proof -- no --> Escalate[Escalate integrity issue]

Operating rule

Any artifact that supports an external claim, regulated workflow, vendor acceptance test, or executive investment decision should have a digest, signer, and transparency-log proof. Otherwise the organization is relying on trust in storage rather than evidence integrity.