Sometimes the answer isn't missing. It's just scattered.
A few weeks ago I caught myself doing something I suspect every engineer has done.
I had five browser tabs open.
An ADR.
A Jira ticket.
A Slack thread.
A runbook.
A configuration file.
All of them were about the same problem.
None of them answered my question.
Only after reading all five did the picture become clear.
That was the moment I realized I wasn't searching anymore.
I was reconstructing.
Search wasn't failing
The question itself was simple.
Why does service X bypass the API gateway checks?
Search behaved exactly as it should.
It found the ADR describing the gateway.
It found the runbook explaining how to restart it.
It found a Jira issue mentioning service X.
It found a Slack discussion where someone wrote:
"We'll keep the old behavior for now."
Every result was relevant.
None of them explained why.
The explanation wasn't inside a document
Eventually the story emerged.
Months earlier, a security review introduced a new authentication header for internal services.
Most services were updated.
One legacy service wasn't.
A temporary exception was added so production wouldn't break.
Nobody ever documented that exception as a decision.
It survived as:
- a commit message,
- a Slack discussion,
- one line of gateway configuration,
- and a Jira ticket that treated the symptom instead of the reason.
Nothing was hidden.
Nothing was lost.
The explanation simply never existed in one place.
That's the difference
I've started thinking about search and discovery as two different activities.
Search retrieves artifacts.
Discovery reconstructs explanations.
Search answers questions like:
Where is the API documentation?
Discovery answers questions like:
Why does the system behave this way?
Those look similar.
In practice they're completely different.
Documents aren't the unit of knowledge
One assumption quietly sits underneath most retrieval systems.
The answer is expected to exist inside one document.
Similarity is computed.
Documents are ranked.
Top-k is returned.
This works remarkably well for factual lookup.
It works much less well for organizational memory.
Because organizations rarely write important decisions in one place.
A design review produces one document.
The implementation produces another.
Operations write a runbook.
Someone explains an exception in Slack.
Months later, all four are technically correct.
None tells the whole story.
Relationships carry meaning
What connects those documents is often more important than the documents themselves.
The Slack thread explains the motivation.
The ADR explains the architecture.
The commit explains the implementation.
The runbook explains the consequence.
Individually they're incomplete.
Together they form an explanation.
That's why I've become increasingly skeptical of measuring retrieval quality only by whether it returned the "right document."
Sometimes there isn't one.
Sometimes the answer is the relationship between several documents.
What changed for me
I stopped asking:
Which document contains the answer?
I started asking:
Which documents explain the answer together?
That small shift changed how I think about retrieval.
Not because search became less useful.
But because I realized search is often only the first step.
Discovery begins after the search results appear.
Organizations rarely lose documents.
More often, they lose the connections between them.
And once those connections disappear, every document can still be found—while the explanation quietly becomes impossible to retrieve.
Next time I'd like to explore another pattern I've seen repeatedly: why organizations can forget something even when nothing has been deleted.
