Your Team Doesn’t Have a Documentation Problem. It Has a Decision-Memory Problem.
Why I’m building a tool to recover what teams decided, why they decided it, and what changed.
Why I’m building a tool that helps teams recover not just what happened, but why.
Most teams are not short on documentation.
They have product requirement documents, meeting notes, technical designs, tickets, roadmaps, Slack threads, postmortems, and project updates. Every important decision is probably written down somewhere.
And yet, ask a simple question a few months later—“Why did we postpone authentication?” or “Who decided to replace this workflow?”—and the answer is surprisingly difficult to find.
Someone may remember part of the story. Someone else may remember it differently. A document might describe the original plan but not the later change. A meeting note may contain the reason, but only as one sentence buried in several pages of discussion.
The information exists. The decision does not.
That is the problem I want to explore by building a **Decision Memory Assistant**.
Documentation stores information, not organizational memory
Documents are snapshots. Decisions are stories.
A useful decision record needs more than a final conclusion. It needs the context around it:
- What was decided?
- Why was it decided?
- Who was involved?
- Which alternatives were considered?
- What evidence supported the choice?
- Was the decision later revised or replaced?
These details are rarely kept together. They are spread across files created at different moments by different people for different purposes.
A design document may explain the proposed architecture. Meeting notes may record objections. A roadmap may show that the work was postponed. A later document may quietly introduce a different direction. Each source contains a piece of the truth, but no single source contains the history of the decision.
This creates a kind of organizational amnesia.
The effects are easy to underestimate. New team members repeat old debates because they cannot see what was previously considered. Engineers hesitate to change systems because they do not know which constraints still matter. Product leaders revisit choices without knowing whether the original assumptions remain valid. Teams sometimes treat an old decision as permanent simply because its reasoning has been lost.
The cost is not only the time spent searching. It is the quality of the next decision.
Why search is not enough
Search tools are good at finding documents containing particular words. They are less useful when the question is about reasoning or change over time.
Imagine asking:
> Why was authentication postponed, who made that decision, and was it later changed?
Answering that question may require finding an early proposal, a meeting where the trade-off was discussed, a roadmap update, and a later decision that superseded the first one. The answer is not a paragraph waiting to be retrieved. It must be reconstructed from several pieces of evidence.
Generative AI makes that reconstruction possible, but it also introduces a new risk: a fluent answer can sound convincing even when the underlying evidence is incomplete or contradictory.
For decision memory, “probably correct” is not good enough. A useful system must show its work. It must distinguish a supported fact from an inference, expose conflicting records, and admit when the available documents cannot answer the question.
What I’m planning to build
The Decision Memory Assistant will turn project documents into a searchable, evidence-backed history of decisions.
A user will be able to add meeting notes, specifications, project updates, PDFs, and Word documents. The application will identify decisions within those sources and organize them into structured records: the decision, its reasoning, its owner, its status, the alternatives considered, and the passages that support each detail.
Users will then be able to ask natural-language questions about a project. Instead of returning a list of loosely related documents, the application will provide:
- A concise answer grounded in the uploaded material
- Citations linking each important claim to an exact source passage
- A chronological timeline showing how a decision evolved
- Clear warnings when sources conflict
- An explicit “I don’t have enough evidence” when the documents cannot support an answer
The timeline is especially important. Decisions are not static entries in a database. They are proposed, accepted, revised, rejected, and superseded. The application should preserve that evolution instead of presenting the latest document as if it were the whole story.
It will also allow people to inspect and correct extracted decision records. AI can help organize the evidence, but it should not silently become the authority on what a team decided.
What this application is really solving
At the surface, this looks like a document-search product. That is not how I think about it.
The real goal is to reduce the distance between a decision and the evidence behind it.
For an engineering leader, that means understanding why a technical constraint exists before approving a change. For a product leader, it means seeing which assumptions shaped a roadmap choice and whether those assumptions still hold. For someone joining a project, it means learning the history without depending entirely on whoever happens to remember it.
It should help teams:
- Preserve reasoning, not just outcomes
- Avoid repeating discussions that have already happened
- Revisit old choices with their original context intact
- Identify when two sources disagree
- Make onboarding less dependent on tribal knowledge
- Build on previous decisions with greater confidence
The application will not make decisions for the team. It will make the team’s existing decisions easier to understand, verify, and challenge.
That distinction matters. I am not trying to build an AI oracle. I am trying to build a trustworthy interface to organizational memory.
Why I’m building it in public
This idea contains several assumptions worth testing.
Can AI reliably extract decisions from messy project documents? Can retrieval find the right evidence across different file types? Can citations and timelines make generated answers meaningfully more trustworthy? And, most importantly, is decision history painful enough that teams will change how they work to preserve it?
Building in public creates a way to test those assumptions openly. I plan to share the architecture, trade-offs, evaluation results, failures, and changes in direction—not just polished demos.
That feels appropriate for a product about preserving reasoning. The decisions behind the product should be visible too.
If you have ever inherited a project and wondered, “Why is it like this?”, I would like to hear how you found—or failed to find—the answer.
That is the problem I’m starting with. The next step is to see whether a Decision Memory Assistant can solve it.