Why zev exists

The problems zev was built to solve, and how it differs from git.

Large files change the economics of syncing

Treating every file as an opaque blob means a single byte changed in a large file forces a full re-transfer of that file. For source code this is rarely a problem — most edits are small and the files themselves are small. For large text, data, or model files it becomes expensive fast.

zev's content-defined chunking addresses this directly. When a file is chunked, an edit near the start of a 1.7 MB file was measured, on real data, to require re-transferring only about 1% of the file's total chunks — the rest were already present on both sides and were skipped entirely, both on push and on pull. This is described in full, with the actual measurements, in Content-defined chunking.

A text diff doesn't tell you what actually changed

Line-based diffs show which lines changed. They don't tell you that a function was renamed rather than deleted and a different one added, or that only a function's signature changed while its body stayed identical. A human reading the diff can often infer this, but an automated tool cannot, not reliably.

zev's semantic diff parses Zig source with a real AST parser and reports structural changes directly: signature_changed, body_changed, likely_rename, added, removed — computed from the actual parsed structure of the code, not guessed from text patterns. See Semantic (AST) diffing.

CI time is dominated by unchanged work

Most CI runs re-execute steps whose inputs — the exact source content, the container image, the command — are identical to a previous, already-successful run. zev's CI can detect this and skip the step entirely, serving the previous result instead of re-running Docker. In a real, measured test this took step execution from 0.53 seconds (a genuine run) to 0.01 seconds (served from cache) for an unchanged step. See Memoized CI.

A model's history is more than its commits

An ML model's real history includes the dataset it was trained on, the shard split it used, every experiment that shaped its architecture, and every checkpoint merge that combined it with another run. zev tracks all of this as first-class, content-addressed data: zev dataset and zev lineage for provenance, zev experiment for hypotheses and outcomes, zev drift and zev threshold for catching regressions automatically, and zev merge-weights for combining checkpoints with real tensor-level strategies (averaging, weighted interpolation, SLERP, TIES-merging) — not just merging text files that happen to contain numbers.

Built to grow into more than version control

zev's object model, content addressing, and IPLD-based provenance graph were designed as a general-purpose foundation, not a fixed feature set. zev context already tracks which changes came from a human and which came from an AI model, with what prompt; zev notarize anchors results on-chain; zev fedmerge merges work peer-to-peer with no central server. Each of these was added on top of the same engine that stores your first commit — the intent is for that pattern to continue, as an engine for code, data, and AI-driven work generally, not a version control system with extras attached.

zev exists to answer a specific set of questions directly: how large files and models should actually be stored and synced, what a diff should tell you about code that changed structurally, why CI so often re-does work it already did, and how to track a model's full lineage from raw data through every experiment to a published result — all inside one engine, addressed by content hashes throughout. ## Large files change the economics of syncing Treating every file as an opaque blob means a single byte changed in a large file forces a full re-transfer of that file. For source code this is rarely a problem — most edits are small and the files themselves are small. For large text, data, or model files it becomes expensive fast. zev's content-defined chunking addresses this directly. When a file is chunked, an edit near the start of a 1.7 MB file was measured, on real data, to require re-transferring only about 1% of the file's total chunks — the rest were already present on both sides and were skipped entirely, both on push and on pull. This is described in full, with the actual measurements, in [Content-defined chunking](/docs/en/chunking). ## A text diff doesn't tell you what actually changed Line-based diffs show which lines changed. They don't tell you that a function was renamed rather than deleted and a different one added, or that only a function's signature changed while its body stayed identical. A human reading the diff can often infer this, but an automated tool cannot, not reliably. zev's semantic diff parses Zig source with a real AST parser and reports structural changes directly: `signature_changed`, `body_changed`, `likely_rename`, `added`, `removed` — computed from the actual parsed structure of the code, not guessed from text patterns. See [Semantic (AST) diffing](/docs/en/semantic-diff). ## CI time is dominated by unchanged work Most CI runs re-execute steps whose inputs — the exact source content, the container image, the command — are identical to a previous, already-successful run. zev's CI can detect this and skip the step entirely, serving the previous result instead of re-running Docker. In a real, measured test this took step execution from 0.53 seconds (a genuine run) to 0.01 seconds (served from cache) for an unchanged step. See [Memoized CI](/docs/en/memoized-ci). ## A model's history is more than its commits An ML model's real history includes the dataset it was trained on, the shard split it used, every experiment that shaped its architecture, and every checkpoint merge that combined it with another run. zev tracks all of this as first-class, content-addressed data: `zev dataset` and `zev lineage` for provenance, `zev experiment` for hypotheses and outcomes, `zev drift` and `zev threshold` for catching regressions automatically, and `zev merge-weights` for combining checkpoints with real tensor-level strategies (averaging, weighted interpolation, SLERP, TIES-merging) — not just merging text files that happen to contain numbers. ## Built to grow into more than version control zev's object model, content addressing, and IPLD-based provenance graph were designed as a general-purpose foundation, not a fixed feature set. `zev context` already tracks which changes came from a human and which came from an AI model, with what prompt; `zev notarize` anchors results on-chain; `zev fedmerge` merges work peer-to-peer with no central server. Each of these was added on top of the same engine that stores your first commit — the intent is for that pattern to continue, as an engine for code, data, and AI-driven work generally, not a version control system with extras attached.