What Version History Actually Gives You

Last spring, I was reviewing a document I'd written about a hiring decision. The document existed — full of observations, a final recommendation. But I had no idea why I'd written two of the things I'd written. One paragraph argued against a candidate for reasons I couldn't reconstruct. The fact was there. The context was gone.

That's a subtly different problem from losing data. The file was fine. What was missing was the version from three edits earlier — the draft where I'd written the reasoning before I cleaned it up into something that sounded more decisive.

Most people think of version history as a safety net. A fallback. Something you reach for when something goes wrong.

But that's actually the least interesting thing it does.

What undo is, and isn't

Undo is local. It lives in memory. Hit Command-Z, the last action reverses. Most undo systems don't even survive closing the document, and none of them know why you did what you did, who else touched the file, or what state things were in at 9am on a Tuesday three weeks ago.

Version history is different in kind, not degree. It's a persistent record of every state a thing has been in, indexed by time. The question "what did this look like last Thursday?" becomes answerable. So does "what changed between last Thursday and Friday?" And: "who changed it?"

Software developers understood this distinction early. In April 2005, Linus Torvalds built Git in a few days, and one of his explicit design goals was that history should be immutable — you can add to it, but not silently rewrite it. The history is the product, not just a side effect of the product. That's why git blame exists: not to assign fault, but to surface the origin of decisions. Who wrote this? When? What else changed in that same commit?

The practice of reading that history to understand why something exists — not just what it is — has a name in developer culture: archaeology. You're not reading code, exactly. You're reading a compressed record of someone's thinking.

The question "what did I know when?"

Knowledge changes. You update a person's contact details. You mark a project abandoned. You revise an opinion you held six months ago about how to handle a recurring problem.

The current state of your knowledge base tells you where things are now. But if you're trying to understand a decision you made, or what you'd told someone, or what your thinking was at a particular moment — the current state is the wrong document.

What you actually want is a temporal snapshot. Not "what does my knowledge base say?" but "what did my knowledge base say on March 8th, before I updated it?"

This is what bitemporal databases are designed for, though they've mostly lived inside enterprise systems where auditors ask things like: "what did we report, and what did we know at the time of reporting?" The principle scales down. It applies to a personal knowledge base as directly as it applies to a regulated financial ledger. The useful thing about this kind of history isn't recovery. It's the ability to ask retrospective questions.

When the AI is also writing

Here's where this gets sharper. If you're the only one writing to your knowledge base, version history is useful but optional. You can usually reconstruct your own reasoning, at least roughly.

But AI agents are writing to knowledge bases now. They're adding tasks, updating person records, tagging documents, marking things resolved. The more capable the agent, the more often this happens.

That creates a new kind of question: not just "what changed?" but "why did that change happen, and did I want it to?"

An audit log that records every AI write — with a timestamp, the agent that made the change, the context that triggered it, and the diff of what actually changed — turns out to be different from version history as traditionally conceived. It's not just a snapshot of states. It's a provenance record. You can trace a specific fact back to the action that created it, and from there to the reasoning that justified the action.

Without that, you have a knowledge base where the current state looks fine but you have no way to explain why it is the way it is. Some piece of information looks authoritative, and you can't tell whether you wrote it, or an AI wrote it, or an AI updated something you wrote and the original is gone. The diff becomes the thing. Not the document.

A different kind of search

I've started thinking of version history less as a safety net and more as a second index — a way to search the past rather than just the present.

Full-text search tells you where a word appears now. Version history lets you ask: when did this concept first appear? When did I stop mentioning this person? What changed in my notes on this project between the week before I made a decision and the week after?

These are investigative questions, not retrieval questions. They're only answerable if the history exists — which means capturing it continuously, from every write, including the AI writes, including the writes that seemed too small to matter.

Undo assumes you know what you want to undo. Audit history assumes you don't yet know what question you're going to want to ask.

---

Asgeir Albretsen is the founder of Harbor.