IPLD and provenance

Each commit mirrored as an IPLD block with its own CID, for provenance you can check outside zev.

What IPLD is used for here

Each commit is mirrored into an IPLD block, and a mapping from the commit's own hash to its IPLD CID is kept locally under .zev/ipld_commits/. This is deliberately scoped: it is not a full distributed filesystem or a replacement for zev's own object store, but a separate, content-addressed layer specifically for provenance and pinning workflows.

Provenance pinning

An artifact — a build output, a trained model file — can be pinned to a CID on the server, and that CID recorded against a specific commit, owner, repository, and branch. This produces an auditable link: given an artifact, you can trace it back to the exact commit that produced it, with the association itself cryptographically tied to a CID rather than a mutable filename or path.

Server-side transparency log

Pinned provenance records are backed by a transparency log on the server, giving the mapping between artifacts and commits an append-only, verifiable history — the same category of guarantee that certificate transparency logs provide for TLS certificates, applied here to build provenance instead.

Honest scope

This is intentionally narrower than the fuller IPLD-based visions sometimes proposed for content-addressed version control — a complete AST-as-IPLD graph, or a fully peer-to-peer IPFS-backed object store. What's built and running is the specific, useful slice of that idea: commits get real CIDs, and artifacts can be provably tied to the commit that produced them.

Alongside its primary commit format, zev maintains an IPLD-based (InterPlanetary Linked Data) representation of commits, giving each one a content-addressed CID and enabling commit-level provenance tracking independent of the main object store. ## What IPLD is used for here Each commit is mirrored into an IPLD block, and a mapping from the commit's own hash to its IPLD CID is kept locally under `.zev/ipld_commits/`. This is deliberately scoped: it is not a full distributed filesystem or a replacement for zev's own object store, but a separate, content-addressed layer specifically for provenance and pinning workflows. ## Provenance pinning An artifact — a build output, a trained model file — can be pinned to a CID on the server, and that CID recorded against a specific commit, owner, repository, and branch. This produces an auditable link: given an artifact, you can trace it back to the exact commit that produced it, with the association itself cryptographically tied to a CID rather than a mutable filename or path. ## Server-side transparency log Pinned provenance records are backed by a transparency log on the server, giving the mapping between artifacts and commits an append-only, verifiable history — the same category of guarantee that certificate transparency logs provide for TLS certificates, applied here to build provenance instead. ## Honest scope This is intentionally narrower than the fuller IPLD-based visions sometimes proposed for content-addressed version control — a complete AST-as-IPLD graph, or a fully peer-to-peer IPFS-backed object store. What's built and running is the specific, useful slice of that idea: commits get real CIDs, and artifacts can be provably tied to the commit that produced them.

Command Palette

IPLD and provenance