The file survived. The explanation didn't.
A few months ago I needed to understand why one of our services was using Redis.
The engineer who made that decision had already left the company.
Finding the implementation wasn't difficult.
I found the Jira ticket.
Implement Redis cache.
I found the pull request.
The code was there.
I found the architecture document.
It mentioned caching.
I even found the Slack discussion where someone asked:
Why not Memcached?
The reply was one sentence.
Redis should be fine.
That was all.
The implementation survived.
The explanation didn't.
Nothing was missing
At first that felt strange.
Every artifact still existed.
Nothing had been deleted.
Git history was intact.
Slack history was searchable.
The documentation hadn't disappeared.
And yet the organization had clearly forgotten something.
Not what had been built.
Why it had been built that way.
We preserve artifacts better than reasoning
Most engineering organizations are very good at keeping records.
We keep tickets.
We keep code.
We keep documents.
We keep backups.
What we rarely preserve is the reasoning that connected them.
The ticket tells you what changed.
The pull request shows how it changed.
The architecture document describes what the system looks like.
None of them necessarily explains why one option was chosen over another.
That explanation often existed only during a conversation.
Context has a half-life
I've started thinking of context as something that slowly decays.
When a decision is made, everyone involved shares the same mental model.
The constraints are obvious.
The trade-offs are fresh.
Rejected alternatives are still remembered.
Six months later the code remains exactly the same.
The shared understanding doesn't.
A year later someone asks:
Why didn't we use Memcached?
Nobody knows anymore.
Not because the answer was lost.
Because it was never stored anywhere in a form that could survive the people who understood it.
This is how organizational memory disappears
It rarely happens all at once.
Nobody deletes a document.
Nobody wipes a database.
Instead, every small decision loses a little of its surrounding context.
A meeting ends.
A Slack thread sinks into history.
Someone changes teams.
Someone leaves.
Months later all the pieces still exist.
The explanation doesn't.
I stopped asking a different question
I used to ask:
Did we document this?
Now I ask:
Could someone explain this decision after everyone involved has left?
Those aren't the same question.
Documentation preserves artifacts.
Organizational memory preserves reasoning.
One can exist without the other.
Forgetting is usually invisible
Organizations don't usually notice they're forgetting.
Everything still looks healthy.
Repositories are there.
Documentation is there.
Search still works.
The problem only appears when someone asks a simple question:
Why?
And nobody can answer with confidence.
I've become less convinced that organizations lose knowledge because they delete information.
More often, they lose the relationships, assumptions, and reasoning that gave that information meaning.
The files survive.
The memory quietly fades.
Next time I'd like to explore something that surprised me while building retrieval systems: why the LLM often turned out to be the least interesting part of the pipeline.
