JohnnyCode.ai

JohnnyCode.ai Blog

Commits Need Memory

AI Provenance as a First-Class Citizen

Published

Illustration for Commits Need Memory

Most teams still treat a commit like a tiny postcard:

  • what changed
  • maybe why
  • hopefully enough to not break prod

That model is already weak for human-only teams. With AI-first development, it is completely insufficient.

If an agent helped write, refactor, test, or decide, the commit should carry more than a session ID. It should carry provenance: conversation, tool calls, outputs, guardrails, approvals, and resulting patch lineage.

Not as a novelty, as a baseline for engineering integrity.

The problem with AI commits today

Right now, most AI-assisted workflows leave a paper trail that is:

  • fragmented across chat UIs, terminal logs, and cloud dashboards
  • mutable and hard to audit
  • disconnected from the exact commit that landed

Weeks later, you ask simple questions and get no reliable answer:

  • Why did we choose this approach?
  • Which tool call produced this migration script?
  • Was there human approval before this security-sensitive change?
  • Did the model see any sensitive context?
  • Can we reproduce this exact decision path?

If you cannot answer those quickly, you do not have traceability. You have vibes.

The idea: commit-level AI provenance

Every commit touched by AI should include an attached provenance capsule.

Not in the commit body itself. That is too noisy. Instead, commit references an immutable artifact that contains the full workflow history.

Think of it like a flight recorder for code changes.

Commit trailers (human-readable plus machine-parseable)

Example:

feat: add retry policy for payment webhooks

AI-Session-ID: a7c947b8-6d2a-4dea-8f42-13000a2bdf08
AI-Provenance-URI: s3://eng-provenance/prod/repo/abc123.jsonl
AI-Provenance-SHA256: 8b2f...e91a
AI-Model: openai-codex/gpt-5.3-codex
AI-Tools: exec,web_fetch,github
AI-Human-Approval: true

That keeps git history clean while giving you a deterministic pointer to the full story.

What belongs in the provenance artifact

At minimum:

  1. Session metadata - session id
  • actor identity
  • start/end times
  • model and runtime settings
  1. Conversation timeline - user requests
  • assistant responses
  • important system constraints in effect
  1. Tooling ledger - each tool call input
  • each tool output
  • error and retry paths
  1. Code lineage - files touched
  • patch sequence
  • base commit and resulting commit
  1. Governance events - policy checks
  • human approvals
  • blocked actions and overrides
  1. Integrity data - hash of artifact
  • signature or attestation metadata
  • retention class and redaction status

Why this matters more than people think

1) Debugging speed

When incidents happen, you stop guessing. You can replay decision context and see exact tool outputs that drove a bad change.

2) Security and compliance

You can prove what the agent did and did not do. That is critical for regulated environments and vendor risk reviews.

3) Engineering trust

Teams adopt AI faster when changes are attributable and inspectable. Provenance turns black-box anxiety into reviewable evidence.

4) Reproducibility

Good ideas become reusable when the full path is preserved. Prompt fragments and tribal memory do not scale.

5) Accountability without blame theater

You get clear ownership boundaries between human decisions and agent execution.

Design principles for a practical implementation

  • Keep commit message small, store detail off-commit
  • Make artifacts immutable once referenced
  • Hash and verify in CI
  • Redact secrets before persistence
  • Support local development and cloud-backed storage
  • Make retrieval one command away

If engineers cannot access provenance in under 10 seconds, adoption will die.

Common objection: “This is too much overhead”

It is only overhead if it is manual.

Automate it:

  • agent runtime emits structured logs by default
  • pre-commit or prepare-commit-msg injects trailers
  • CI verifies artifact hash and required fields
  • PR template shows provenance summary card

Now the burden is on tooling, not developers.

Another objection: “A session ID is enough”

It is not.

A session ID is an index key, not evidence. If the session storage changes, expires, or is inaccessible, the ID is useless. If the session is editable, the ID is dangerous.

Provenance should be content-addressed and integrity-checked. Otherwise you are writing references to mutable history.

A simple maturity model

Level 0: No AI metadata Level 1: Session ID in commit Level 2: Session ID plus external transcript link Level 3: Hashed provenance artifact plus CI verification Level 4: Signed attestations plus policy enforcement gates Level 5: Queryable org-wide provenance graph across repos and deployments

Most teams are at Level 0 or 1. AI-first teams should target Level 3 quickly.

What changes culturally

This is bigger than logging. It changes how teams think about code authorship.

A commit is no longer just code delta. It is a decision artifact with machine participation.

If AI is a real collaborator, then provenance is not optional documentation. It is source-of-truth infrastructure.

The 42 Insights takeaway

If your build pipeline is AI-first but your git history is pre-AI, you are missing the most important layer: memory.

Session IDs are a start. Provenance is the standard.

The winning teams will not be the ones with the fanciest models. They will be the ones who can answer, quickly and credibly:

  • what changed
  • why it changed
  • who approved it
  • what the agent actually did

That is how AI-assisted development grows up.

First published March 2, 2026 on 42 Insights.

← All posts