Your Next Incident Shouldn’t Start From Zero: Building Recall

Karthik — Tue, 29 Sep 2026 16:21:03 +0000

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: YOUR_LIVE_DEMO_LINK

💻 Source Code: YOUR_GITHUB_LINK

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.

DEV Community: Karthik