// Background

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

AI coding agents produce changes faster than the version control layer underneath them can preserve why those changes were made.

// 01 · the identity problem

Why Git cannot preserve AI agent provenance

// The short answer
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.

Squash merge
What changes

Many commits become one new commit

Provenance consequence

Original agent-turn SHAs disappear from the target history

Rebase
What changes

Each replayed commit gets a new parent and SHA

Provenance consequence

Records keyed to the old SHAs no longer identify the rebased commits

Cherry-pick
What changes

The patch becomes a separate commit with a new SHA

Provenance consequence

Git creates no durable structural link to the source commit by default

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.

// 02 · the mechanics

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.

a1 ─ a2 ─ a3 ─ a4   4 agent turns
│    │    │    │    4 provenance records
└────┴────┴────┘
▼
S1          1 squash commit
0 original SHAs on main

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.

before   M ─ a1 ─ a2
after    M ─ x ─ a1' ─ a2'


patch(a1) == patch(a1')
sha(a1)   != sha(a1')

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.

feature  ─ a1
main     ─ a1''   (new SHA)


link: "(cherry picked from a1)"
↑ free text, not structure

// Root cause

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.

// 03 · the obvious fix that isn't

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.

Durable

The record survives.

A ref still exists in the object store after the rewrite.

Integrity

The record accurately describes the canonical history an auditor will inspect.

This is what Git cannot guarantee once history is rewritable.

An audit trail that might be accurate is not an audit trail.

// 04 · the atomic model

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.

Request

What the human asked for

Activity

What the agent explored and read

Change

The signed, content-addressed patch

Evidence

What verified the result

Custody

Generated at change time, not reconstructed later

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.

Full architecture & requirements → See what Atomic does

// common questions

Common questions

Why does Git lose AI agent provenance?

Git's identity is the commit's content hash, which includes its parent hash. Squash merge, rebase, and cherry-pick all produce new SHAs, so any provenance indexed to the original commit hashes is orphaned by routine operations, not dramatic failures. Stable commit identity was never part of Git's contract.

Can a new Git ref type like refs/provenance solve this?

No. A ref can survive a rebase or squash as a data object, but it stops being meaningful when the commit it points to is no longer in the canonical history an auditor inspects. After a squash, the auditor sees the squash commit, not the original the ref attests to. Git also permits force push and interactive rebase by default, with no audit log of the rewrite, so provenance that depends on history stability lacks integrity.

What is Atomic?

Atomic is a semantic change graph built for human and AI collaboration. Every agent turn is recorded as a cryptographically signed, content-addressed change carrying the full causal graph of how it was produced, bound to a permanent identity no workflow operation can alter. In Atomic, views are reorganized; changes are not.

Does Atomic work with the AI coding agents we already use?

Yes. Atomic integrates with Claude Code, Cursor, Codex, GitHub Copilot, OpenCode, Kilo, and others. Developers keep their preferred editor and agents while a shared skills layer keeps provenance and attestations intact across the whole graph.

Why does AI code provenance matter?

Agent-generated changes need a durable chain of custody from the human request through the resulting code and its verification. Without that record, reviewers and auditors must reconstruct intent from logs after the fact, and routine Git history rewrites can break the link between those logs and the code that shipped.

Build on a foundation that remembers.

Install the CLI and start recording from the next agent turn. No account required.

Install Atomic → Read the docs