An incident is resolved. The dashboard turns green. Someone writes a short summary, closes the ticket, and moves on.
A few weeks later, another engineer sees similar symptoms. They search old tickets, scroll through chat messages, and ask whether anyone remembers what worked last time.
The team has dealt with the problem before. Finding that experience—and deciding whether it still applies—is the difficult part.
That gap is what we set out to explore with Recall, our Incident Memory Command Center.
What We Wanted to Build
We wanted an incident workspace that could carry useful experience from one investigation into the next:
- Describe the current problem
- Retrieve relevant historical incidents
- Use historical context alongside fresh evidence
- Record what actually happened
- Preserve failed attempts and lessons learned
The difficult part is deciding how that history applies.
Two incidents can look similar and still have different causes. A previous fix is a clue, not permission to repeat it.
That distinction shaped how we built Recall.
From Symptoms to a Working Hypothesis
An investigation starts with the information an engineer already has:
- Affected service
- Environment
- Severity
- Symptoms
- Relevant logs
The backend saves the incident locally before requesting an analysis. If a provider call fails, the incident still exists, allowing the engineer to return to it later.
Recall then asks Hindsight for relevant historical context and sends the current evidence and retrieved memories to a model through Groq.
The response includes:
- Suspected root cause
- Investigation steps
- Recommended actions
- Verification steps
- References to the historical sources used
We deliberately frame the diagnosis as a hypothesis because the engineer still needs to test it.
For example, a previous incident might suggest that a connection pool caused a service slowdown. That makes pool utilization worth checking; it does not establish that today's slowdown has the same cause.
Recall does not execute infrastructure commands. Its role is to help an engineer decide what to investigate next.
Why We Used Two Kinds of Storage
Recall uses two storage systems for different purposes.
SQLite
SQLite holds the structured state of an investigation:
- Incident status
- Updates
- Saved analysis
- Recorded outcome
It gives the application a concrete record to display and update.
Hindsight
Hindsight makes previous incident information available for retrieval across investigations.
When an engineer records evidence or an outcome, Recall can send a readable incident document to the memory bank.
That document includes:
- Symptoms
- Actions taken
- Outcome
- Lessons learned
It also labels investigation updates as human-reported evidence, preserving the distinction between an observation and a model's interpretation.
An investigation is more than its final fix.
Knowing that a restart did not help can save the next engineer from repeating the same attempt without a reason.
A Comparison View That Makes Memory Visible
One feature we particularly wanted was a with-memory versus without-memory comparison.
The application analyzes the same incident through two paths:
- Using current evidence alone
- Using current evidence together with retrieved historical memory
The results appear side by side.
This lets us inspect what memory actually contributed.
Did it:
- Suggest a more specific check?
- Surface an earlier failed attempt?
- Change the suspected cause?
- Provide useful historical context?
Sometimes there may be no useful history to retrieve.
That is a meaningful result too.
The comparison is an inspection tool, not a benchmark proving that memory always produces a better answer. Model responses can vary, and a different answer is not automatically a more accurate one.
Building Around Imperfect AI Responses
A useful AI interface needs more than a well-written prompt.
We use Pydantic to validate structured model responses before accepting them, and check cited source IDs against the memories actually supplied to the model.
If a response fails validation or cites an unknown source, the application requests a correction.
If that attempt also fails, it reports the failure instead of inventing a replacement diagnosis.
Retrieved text and incident fields are treated as evidence rather than instructions.
The application also flags selected risky action patterns for review.
These checks can catch malformed output and certain unsupported claims, but they cannot prove that a diagnosis is correct.
Verification still belongs in the incident workflow.
The Tech Stack
| Technology | Purpose |
|---|---|
| React | Frontend |
| Tailwind CSS | UI styling |
| FastAPI | Backend |
| SQLite | Local incident persistence |
| Groq | Model inference |
| Hindsight | Operational memory |
| Pydantic | Request and response validation |
| Docker | Containerization |
| Render | Deployment |
The interface brings together:
- Incident overview
- Investigation workspace
- Memory comparison
- Memory explorer
- Learning journal
What the Project Taught Us
The most useful lesson was that adding memory involves more than saving text.
The system needs to preserve context:
- Which environment an incident affected
- What was observed
- What was only suspected
- What was attempted
- Whether recovery was actually confirmed
It also needs to handle failure honestly.
A model response and a verified diagnosis are separate events.
The interface needs to leave room for an engineer to question a suggestion, add contradictory evidence, and change direction.
What Comes Next
Recall is currently a hackathon prototype.
Our next steps include:
- Evaluating Recall with repeatable incident scenarios
- Inspecting whether retrieved history leads to more useful investigation steps
- Making the path from evidence to outcome easier to follow
- Improving the workflow when an incident is reopened
- Handling cases where an earlier hypothesis turns out to be wrong
The question behind the project remains simple:
When the next incident arrives, how much of the team's previous experience will still be available—and useful?
Recall is our attempt to make that experience easier to carry forward.
Try Recall
🔗 Live Demo: https://incident-memory-command-center.onrender.com/
💻 Source Code: https://github.com/Tanmaisutrave/incident-memory-command-center
Team
- Tanmai Sutrave
- Abhay Kumar Mishra
- Tannidi Durga Karthikeya
Final Thoughts
When an incident happens again, engineers shouldn't have to start from zero.
Recall is our attempt to make previous incident experience easier to find, understand, question, and carry forward into the next investigation.
How does your team find previous incident knowledge today?
I'd love to hear what works—and where useful context gets lost.
Top comments (0)