Topics · Protocol concept

Bridge artifacts

Reviewers verify the receipt and inspect bound external commitments — C2PA-compatible material, credentials, and identifiers — as part of one offline-valid path.

Concrete scenario

What this looks like in practice

A studio publishes C2PA credentials on a media asset while the automation pipeline stores agent decisions in a separate logging stack. After delivery to a distributor, the credentials and agent record are in different systems — reviewers cannot traverse one proof path.

Problem

What breaks today

Teams already issue C2PA manifests, Verifiable Credentials, and DIDs. If those artifacts float beside the workflow instead of inside the receipt path, provenance breaks at the first export or platform handoff.

Mechanism

How ZK-SNAP responds

External artifacts bind into ZK-SNAP receipts through deterministic commitments in ext_* fields. The receipt remains the portable kernel; bridge material rides inside the same signed object rather than replacing it or floating as disconnected badges beside the workflow.

Verifiable outcome

What a verifier can check

  • Bridge commitments hash to ext_* fields declared in the receipt profile.
  • Receipt signature covers the commitment structure as part of canonical bytes.
  • External artifact parsers validate independently, then match committed digests.
  • Missing bridge openings are visible — not silently treated as verified.

Related profiles and labels

C2PA-compatibleVerifiable CredentialsDecentralized Identifiers

Scope boundary

What a receipt does not replace

Bridge artifacts extend the receipt path; they do not merge C2PA, VC, or DID semantics into the kernel or eliminate the need for domain-specific validators.

Go deeper

Try the workflow, then read the spec.

Use Cases tells the story with cards. Proof Lab runs create and verify locally. Protocol holds the normative reference.