Atomic Semantic Change Graph: the evolution of version control for the age of agents.

Why Git cannot preserve AI agent provenance

Git cannot reliably preserve AI agent provenance because routine operations change commit identity. A commit SHA includes its parent, so rebase, squash merge, and cherry-pick create new commits with new SHAs. Provenance keyed to the original SHA may still exist somewhere, but it no longer describes the canonical history a reviewer or auditor sees.

Atomic avoids this identity break by separating a change from its placement in history. Each change has a permanent, content-addressed identity and carries its signed provenance with it. Views can regroup changes without rewriting those changes or severing their provenance.

AI coding agents make the provenance gap more consequential because a change now needs to preserve not only who recorded it, but which agent turn produced it, what the human requested, and what evidence verified the result. New tools capture agent session data beside Git commits, but capturing the session does not fix the identity problem underneath it: checkpoints stored against Git history are only as reliable as Git history itself.

What happens to provenance after a squash, rebase, or cherry-pick?

Squash, rebase, and cherry-pick all replace or duplicate commit identity, which disconnects SHA-indexed provenance from the history people actually inspect.

Squash merge, the default pull request merge strategy on GitHub, combines N commits into one new commit with a new SHA. The original commit objects are discarded from the target branch history. Any system that recorded model identity, token cost, or decision chain against the original commit hashes now references objects that no longer appear in the canonical history. In prose: four agent-turn commits and their four provenance records become one new squash commit, while the original SHAs disappear from the target history.

Rebase replays commits onto a new base, producing new commit objects with new SHAs. Git's commit hash includes the parent hash. Changing the parent changes the identity. External provenance indexed to the original SHAs is orphaned regardless of whether the code content changed at all. In prose: the code patch may remain the same, but every replayed commit has a new parent and a new SHA.

Cherry-pick creates a duplicate commit with a different SHA and no structural link to the source by default. The -x flag appends a text note to the commit message, but this is a prose convention, not machine-readable structured metadata, and it does not survive further history rewriting.

The root cause is architectural. Git's identity model is the content hash of the commit object, which includes the parent hash. Any operation that changes the parent, combines commits, or replays patches produces a new identity. This is not an oversight. Git was designed for a world where commits are disposable intermediates that can be freely rewritten to produce clean history. Stable commit identity was never part of Git's contract.

Can Git notes or provenance refs solve the problem?

No. A provenance ref can preserve a record without preserving its relationship to the canonical history.

A common response to this problem is to propose a new Git ref type, a parallel namespace like refs/provenance/ or refs/notes/ai that stores attestation data alongside the commit graph rather than inside it. The approach is well-intentioned. It is also structurally insufficient for auditing purposes, and understanding why matters.

A ref in Git is a pointer. It can survive a rebase or a squash as a data object in the object store. What it cannot do is remain meaningful when the commit it points to has been removed from the canonical history of the branch being audited. An auditor reviewing the main branch after a squash merge does not see commit B, the one the provenance ref attests to. They see commit S, the squash. The provenance record for B exists. The history does not acknowledge B ever reached main. The ref and the canonical history have diverged, and there is no mechanism in Git that prevents this divergence or flags it when it occurs.

The deeper problem is that Git permits any developer or agent with write access to rewrite branch history at any time. Force push is not a restricted operation by default. Interactive rebase is a standard daily workflow. The moment history rewriting is permitted, any provenance system that depends on history stability is no longer structurally accurate for auditing purposes. It is accurate until someone rebases, and then it is not, and there is no audit log of the rewrite itself.

This is the distinction between a provenance record that is durable and a provenance system that has integrity. Durability means the record survives. Integrity means the record accurately describes the canonical history an auditor will inspect. An audit trail that might be accurate is not an audit trail.

How does Atomic preserve AI agent provenance?

Atomic binds provenance to a permanent change identity, then lets views reorganize references to that change without rewriting it.

Atomic is a semantic change graph built from the ground up for human and AI collaboration to extend what we have understood of legacy version control systems. It integrates with the agents teams already use (including Claude Code, Cursor, Codex, GitHub Copilot, OpenCode, Kilo and others) and does something none of them provide natively. Every agent turn is recorded as a cryptographically signed, content-addressed change that carries the full causal graph of how it was produced: what the human requested, what the agent explored, what it read, what it modified, and why.

That record is stored alongside the change itself, bound to an immutable identity that no subsequent workflow operation can alter. In Git, a squash merge or rebase produces a new commit SHA and silently orphans any provenance attached to the original. In Atomic, changes have permanent identities. Views are reorganized. Changes are not.

Under the hood, Atomic enriches every repository with AST analysis and tree-sitter entity extraction, building a semantic graph that operates at the function, class, and token level rather than the line level. That graph replaces traditional grep and find with structured graph traversal, giving agents a queryable index of what code means rather than what it contains. When two agents modify different tokens on the same line, Atomic resolves the merge automatically. The conflicts that surface are the ones that genuinely require human judgment.

The result is a direct chain of custody from the human request to the agent activity, the resulting change, and its verification evidence. That record is generated when the change is made rather than reconstructed later from a transcript.