Most teams have plenty of raw history and very little usable history. Logs exist. Chat exists. Postmortems exist. None of that guarantees the next investigation starts from what the last one learned.
Investigation memory is the retained case history of production work. If the same class of issue appears again, the system should be able to remember:
- what was investigated last time
- which paths were useful
- which paths were dead ends
- what engineers corrected afterward
If it cannot do that, the investigation loop never gets cheaper.
Why Teams Need a Usable History
Postmortems are too sparse. Runbooks are too static. Chat history is too messy.
A lot of useful operational learning happens in the middle of routine investigation work and never gets promoted into a formal artifact. Investigation memory exists to retain that layer of reality.
What Belongs in the Record
Useful investigation memory usually includes:
- the triggering alert or question
- the services and systems involved
- the hypotheses explored
- the evidence gathered
- the findings produced
- the outcome, when known
- corrections from engineers
The corrections are usually the high-value part because they carry the local context the telemetry alone could not provide.
What Gets Cheaper Over Time
Recurring incidents should get cheaper.
That does not mean every recurrence is identical. It means the system should stop wasting time on the same low-yield steps when a similar pattern shows up again.
This is especially useful in environments where a lot of the real knowledge lives outside formal docs.
Where Reuse Breaks
Investigation memory becomes dangerous when:
- a weak prior investigation gets treated as authoritative
- the environment changed and the old pattern no longer applies
- the system jumps from “similar” to “same”
- no one has a way to correct or remove bad memory
The operational rule is simple: reuse context, not certainty.
Where It Sits in Cleric’s Model
In Cleric’s architecture, investigation memory is mostly part of episodic memory.
We keep both terms because “episodic memory” describes the architectural layer and “investigation memory” describes the practical thing operators care about: whether the system remembers how earlier incidents were worked.
Related Concepts
Frequently Asked Questions
What is investigation memory?
It is the stored history of prior investigations, including what triggered them, what was checked, what evidence was gathered, what findings were produced, and how engineers corrected the result afterward.
How is investigation memory different from a postmortem database?
Postmortems cover a small number of major incidents and focus on summarizing the event. Investigation memory is broader. It includes the routine investigations, the dead ends, and the real-time corrections that rarely become formal documents.
How does investigation memory speed up future work?
It lets the system start from relevant prior context instead of rediscovering the same hypotheses and local service quirks every time. The current incident still has to be verified, but the search becomes narrower.
Is investigation memory the same as episodic memory?
They are closely related. Investigation memory is a practical description of the incident-history part of the system. Episodic memory is the broader architectural label Cleric uses for that layer.
What are the risks of investigation memory?
Bad analogies, stale context, and overconfidence. A new incident may resemble an old one without sharing the same cause, so prior investigations should be treated as useful context, not final answers.