Project Memory Is Not Chat History

Early on, when the problem that became Spine was still just a recurring annoyance rather than a product, the obvious first fix was better search. If the pain was "I can't find the conversation where we decided this," then surely a good full-text search over every chat transcript would solve it. We tried something close to that. It helped a little and solved almost nothing, and understanding why took longer than building the search feature did.

What a transcript actually contains

A chat transcript is a record of an exchange. It has the shape of a conversation: someone asks something, the assistant responds, there's back-and-forth, eventually a piece of code changes or a document gets written. If you search that transcript later, you can usually find the moment something was discussed. What you often can't find, even with perfect search, is the answer to the only question that actually matters six weeks later: what did we decide, and why?

That's because a decision isn't the same object as the conversation that produced it. A decision is a distillation — the conclusion, stripped of the exploratory back-and-forth, the false starts, the tangents about something unrelated that came up halfway through. A transcript preserves all of that undifferentiated. Finding the decision inside it means re-reading the whole exchange and doing the distillation work again, by hand, every single time you need the answer. Searchable doesn't mean usable. It just means the haystack is indexed.

The four things a transcript doesn't separate

Working through this problem for real, I found that a useful project memory needs to hold at least four different kinds of thing, and a chat transcript smears them all together into one undifferentiated stream:

Decisions, with the reasoning attached — not just "we chose X" but "we chose X over Y because Z," since the reasoning is what lets you evaluate later whether the decision still holds given new information.

Requirements, tracked as their own objects with their own lifecycle, not just mentioned in passing during a conversation about something else.

Evidence, the specific facts or test results or user feedback that a decision was actually based on — distinct from opinion or assumption, and worth being able to tell apart from it later.

Open questions, the things nobody has decided yet, which are just as important to preserve as the things that have been decided, because an open question that quietly gets forgotten is a decision made by default, without anyone choosing it.

A chat log has none of these as distinct objects. It has one undifferentiated stream of text, and extracting any of the four categories from it requires a human to read, interpret and re-derive structure that was never captured in the first place.

What changes when memory is structured instead of transcribed

The shift that actually solved the original problem wasn't better search over conversations. It was treating decisions, requirements, evidence and open questions as first-class things a project keeps track of on their own terms — captured deliberately, not reconstructed after the fact from a transcript. When a decision gets made, it gets recorded as a decision, with its reasoning, not left to be inferred later from an exchange that also happened to contain three unrelated topics.

This sounds like a small distinction — "record structured decisions" versus "keep good chat logs" — but the practical difference is large. Six weeks after a decision, the question "why did we do it this way" gets answered by reading one recorded decision with its stated reasoning, not by reconstructing intent from a conversation that has long since scrolled past everyone's memory of having it.

A concrete example of the difference

It's easier to feel this distinction with a specific case than with the abstract description. Say a team decides, mid-project, not to use a particular caching strategy because it introduced a subtle consistency bug during testing. In transcript form, that decision lives somewhere inside a long exchange that also covers three other topics — buried between a discussion of naming conventions and an unrelated question about deployment. Anyone who needs to know "why don't we use caching here" six months later has to either remember which conversation that was, or search for keywords and hope they land in the right exchange, and then read enough surrounding context to confirm they've found the actual reasoning rather than someone's first tentative guess before the real answer emerged.

In structured form, that same fact exists as one recorded decision: reject caching strategy X, reason: observed consistency bug under condition Y, evidence: test case Z. Anyone asking the question later finds exactly that, without needing to know which conversation to look in, and without wading through the unrelated naming-convention discussion that happened to share the same session. The information content is the same. The retrieval cost is not, and retrieval cost is what actually determines whether institutional knowledge gets used or quietly ignored because finding it isn't worth the effort.

The honest cost of this approach

Structured memory isn't free. It requires the discipline of actually recording a decision as a decision at the moment it's made, rather than letting it live implicitly in a conversation and hoping search will surface it later if needed. That's friction, and friction is exactly the kind of thing that gets skipped under deadline pressure — "we'll write it up properly later" is a promise that gets broken more often than kept, in my experience, including my own.

The honest limitation is that this only works if the discipline holds, and I don't think any tool can fully guarantee that a human under pressure will take the extra sixty seconds to record the reasoning behind a fast decision instead of just making it and moving on. What I can say is that making the recording easy and immediate — closer to a habit than a chore — matters more to whether it actually happens than any amount of arguing for its importance in the abstract. That's a design problem as much as a discipline problem, and it's one I'm still working on.