Business Memory: How to Preserve Decision Context
Business memory is a company's ability to reconstruct a past decision: what was chosen, on what grounds, by whom, and whether it still stands. Most companies have not lost the files. They have lost the thread that connects them, and that is a different problem with a different fix.
We have written about what belongs in chat and what belongs in the system (opens in new tab). That article answered where a decision should be recorded. It did not say what has to be inside the record, and a record kept in the right place with the wrong contents fails in exactly the same way.
Where a document archive stops
A repository answers one question: where is the file? That question is rarely the one that stalls work.
The files usually survive. Emails stay in inboxes, documents sit in shared drives, tasks stay in the project tool, and the conversation is somewhere in chat. One person remembers part of the reasoning, another has a link to an older version, and a third knows the decision was changed later without remembering why.
Nothing was deleted. What went missing is the relationship between the pieces, and a faster search across disconnected fragments does not restore it. Rebuilding that relationship is what business memory means.
The same idea turns up in older writing as organisational memory. What changed since then is that the pieces now sit in more systems than any one person checks in a week.
What a decision record has to hold
Few decisions deserve an entry. Business memory fails as often from too many records as from too few, and the limit is the first thing to set. The UK Health and Safety Executive keeps decision logs for investigations, and its guidance is useful here because it sets a limit rather than a format. Only key decisions go in, meaning those that materially affect the course of the work, and routine decisions and decisions that merely reflect the implementation should not be recorded (opens in new tab). One instruction there gets skipped in most companies: recording the reasons for not doing something matters as much as recording the reasons for doing it.
On what goes inside an entry, the UK government's architectural decision record framework lists a similar set of fields (opens in new tab): title, date, status, context, decision, consequences, stakeholders consulted, and links to supporting documents. It was written for software architecture, and the fields survive the move to commercial decisions with one addition, which is the last item below. Entries are dated and timed, made as soon as possible after the decision, and signed by whoever made it.
Each item below is a question somebody asks months later, once the people and the circumstances have changed. The sentence after each question says what it costs when the answer is missing.
Context. What problem were we solving, and what did we know at the time? Without this the decision gets re-argued from today's information, by people who hold more of it than anyone held then.
The decision itself. What did we choose to do, and what did we choose against? Drop the second half and rejected options come back round as fresh proposals every few months.
Grounds and sources. Which numbers, documents or limits shaped the choice? Absent these, nobody can tell a changed mind from a lost record, and those two call for opposite responses.
Owner. Who decided, and who carries the next action? An unowned decision stalls work while somebody hunts for anyone willing to confirm it.
Status. Is this in force, or has something replaced it? Two plausible answers circulating at once cost more than having neither, because both get acted on.
Consequences. What changes for people, systems, budgets or deadlines? Leave this out and the change lands in a budget or a deadline with no reason attached to it.
Change history. What was altered afterwards, and on what grounds? Most companies skip this one, and it produces the worst failure of the set. A record that was correct when written and never touched again still reads as current, so a replaced decision gets quoted to a client as live.
Marking a decision as replaced takes one line and costs less than anything else named here. It is also the only entry that ages, which is why it belongs with a person rather than with a system.
Why an AI answer about business memory has to carry its source
A keyword search is honest by accident. When no document matches, it returns nothing, and that silence tells you the record was never made.
An AI system does not go silent. It assembles an answer from whatever fragments it can reach and presents it in the same confident shape whether the full record exists or not. That tolerance is the reason to want one, and it removes the single signal people were relying on without announcing that it has gone.
So the thing to require from business memory is the source rather than the answer. That means four things: which documents the answer stands on, when those were last changed, whether anything inside the company contradicts them, and what the system could not find.
The practical test is small. Ask a question you already know the answer to, then check whether the system names where it got that answer. When it cannot, what you have is faster retrieval across the same disconnected fragments, delivered in a tone that no longer sounds like a guess.
What we do in our own projects
The product named below is ours, so this is the paragraph to read with the most suspicion.
AI Business Brain (opens in new tab) connects the tools a company already uses and keeps track of decisions, commitments and risks across them. Decision tracking is the part that matters here. It holds the link between a decision and the material behind it, so a question arriving six months later has somewhere to land. Commercial, financial, legal and people decisions of any weight stay with a named person, and the system is built that way deliberately.
A different kind of evidence sits in a manufacturing quality control project. It produced 100% traceability through digital audit trails and cut manual documentation by 80%, and both figures are on our case studies page (opens in new tab). Nobody involved called that project business memory. The mechanism is the same one: each step carries a record of what was done and on what basis, so nobody has to remember.
What is not worth writing down?
Three kinds of decision do not belong in a record, and the third is a reason to stop a project of ours before it starts.
Decisions that are routine or easily reversed. The guidance above excludes them for a practical reason. A log that captures everything becomes as unusable as an empty one, because the entries that matter sit in the same pile as the rest.
Decisions the system already enforces. Where a tool will not let work continue without an approval, that approval is recorded and binding already. A second record beside it duplicates the first and then drifts out of step with it.
Decisions nobody is allowed to make. Sometimes a company cannot say why it decided something because it never did decide, and the question keeps returning because the authority was never settled. A business memory project turns that into a documentation problem and makes it look solved. No system absorbs it, and the cheaper fix is to name who decides, which costs nothing and removes our work entirely.
Where to start
Take the last decision somebody asked you to explain a second time. Open whatever you have about it: the thread, the file, the task, the email. Then answer three questions in writing: who decided, on what grounds, and whether it still stands today.
If all three have answers, the exercise cost you ten minutes and told you something useful. Where one of them does not, write the record now instead of reconstructing it again later. A gap found this way costs ten minutes, and the same gap costs considerably more when the question arrives from a client.
Get in touch (opens in new tab) and bring that one decision with you. We will spend the first half hour on it alone, before anything at all about systems.
