Concepts

How kal thinks

Five ideas, five drawings. Understand these and you understand the whole system. Throughout, amber marks agent work and teal marks human trust — the same language azmx.ai uses.

1 · A snapshot is what + why + who

git stores a tree of files and a message. A kal snapshot stores the tree plus a structured intent and a structured author. History stops being a pile of diffs and becomes a narrative you can query.

scaffold service why: start payments svc dev [human] add retry helper why: IdP rate-limits bursts claude-code [ai · opus-5] friendlier greeting why: UX review feedback dev [human] tune backoff why: p95 still spiky azmx-coder [ai · v0.3]
The timeline kal log walks — each point carries its message, its intent, and who authored it.

2 · Immutable history, revisable notes

Facts known when you snapshot — message, intent, author, files — are sealed inside a content-addressed object: change one byte and the identifier changes. Facts learned later — test results, reviews, approvals — attach as notes keyed to that identifier. You can re-test, re-review and re-index forever without ever rewriting history.

SNAPSHOT a3f2c19d · immutable message "add retry helper" intent "IdP rate-limits bursts" author claude-code [ai · opus-5] tree 4 files · parents · time id = sha-256(everything above) keyed by id note · verification — pytest passed added after the fact, history untouched note · review — "looks correct", jo appendable, revisable note · approval — human sign-off promotes the trust tier
Enrichment never rewrites history — which is why kal can re-index and re-score forever.

3 · The operation log behind undo

Commands don't merely move refs: every mutation appends an entry recording the complete state of every branch and tag before and after. Undo restores the “before”. Snapshots are never deleted, so undoing is just another logged operation — press it twice and you are back where you started.

#7 snap "tune backoff" #8 merge feature #9 reset --hard kal undo #10 undo #9 — refs restored, nothing lost every entry stores refs-before and refs-after gc keeps anything any entry can still reach …so the safety net has no holes
git's reflog covers some operations, sometimes. kal's log covers all of them, always.

4 · The trust ladder

AI work is not trusted by default — it earns trust. Verification stamps and human approvals promote a snapshot up the ladder, and kal stats aggregates those promotions into per-model scorecards. This is the mechanism that makes autonomous commits acceptable to a team.

unverified — as committed tested — kal verify passed approved — human
Safety features are adoption features: this ladder is what lets a team permit agent commits at all.

5 · The git bridge — coexist, don't convert

.kal/ and .git/ share one working directory. Sync mirrors snapshots into git commits whose trailers carry the kal metadata, and imports git commits back by parsing those same trailers. GitHub, CI, review tools and IDEs keep working — now with provenance attached.

.kal/ intents · provenance · trust operation log · lessons kal git sync .git/ Kal-Intent: … Kal-Model: … (trailers) GitHub · PRs IDEs · Cursor · CI any git GUI
Adopt kal today without asking your team, your CI or your tools for permission.
Underneath it all, kal keeps git's proven core: a content-addressed object store on SHA-256, whole-tree snapshots, and branches as simple pointers. Everything above is layered on that foundation rather than replacing it.