Building an Incident Dashboard Around Hindsight Memory

GADDI KOPULA VENKATESH — Mon, 28 Sep 2026 11:23:31 +0000

Building an Incident Dashboard Around Hindsight Memory
An incident-response agent can have good reasoning and still be difficult to use.

For OpsMind, the frontend was therefore treated as more than a place to display an AI-generated answer. The dashboard needed to make the incident state, evidence, historical memory, diagnosis, remediation, and learning lifecycle visible to an engineer.

The interface follows the same principle as the backend:

Current evidence first. Historical memory second. Action only after review.

From Backend State to Operator View
The OpsMind backend exposes endpoints for:

Health
Incident listing
Individual incident details
Incident analysis
Incident resolution The frontend consumes these APIs and turns the resulting state into an incident-response workflow.

The main dashboard provides an incident selector and displays information such as:

Severity
Service
Metrics
Health signals
Evidence timeline
Historical context
Hindsight memory
AI diagnosis
Confidence
Recommended actions
Runbook
Resolution state OpsMind and Hindsight memory architecture visual

Figure 1 — The dashboard reflects the same incident-response and memory lifecycle as the backend.

The goal is to allow an engineer to understand the incident without jumping between multiple screens.

Making Current Evidence Visible
The first information shown after selecting an incident is its current operational state.

For example, INC-008 displays:

Payment API
Critical severity
6.1-second latency
26% HTTP 500 error rate
97% database connection utilization
The dashboard also shows the related log signals.

This gives the engineer immediate visibility into what is happening now.

The UI should not make an engineer open the historical memory section before seeing the current evidence.

That mirrors the reasoning architecture.

Making Memory Explicit

One of the most important frontend decisions was to make historical memory visible rather than hiding it inside the AI prompt.

The dashboard can show a memory match and identify the historical incidents retrieved by Hindsight.

For INC-008, historical context included incidents such as:

INC-007
INC-006
INC-001 After INC-008 was resolved and retained, another investigation could retrieve INC-008 as historical context.

This makes the memory loop observable.

AI incident and memory context visual

Figure 2 — The incident dashboard exposes diagnosis, evidence, confidence, and historical memory together.

An engineer can therefore see not only what the AI concluded, but also the context that influenced the conclusion.

Why Memory Should Not Be Hidden

If historical context is completely invisible, an engineer may have difficulty understanding why an agent recommended a particular action.

Showing the historical incident references provides a basic explanation of where additional context came from.

It also makes the system easier to debug.

If an irrelevant incident appears in memory, an engineer can identify that problem rather than simply seeing an unexplained AI recommendation.

This is especially useful when working with retrieval systems.

Retrieval quality becomes part of the application's observable behavior.

The Confidence and Evidence Sections
OpsMind also displays a confidence value and evidence signals.

The confidence field gives a concise indication of how strongly the agent's reasoning supports the diagnosis.

The evidence section shows the concrete signals associated with the incident.

Root Cause

Database connection pool exhaustion.

Evidence

Database connection utilization, connection acquisition delays, latency, and HTTP 500 errors.

This makes the diagnosis easier to inspect.

The interface does not need to expose every internal model token or reasoning detail.

Instead, it provides structured information relevant to an operator's decision.

Designing the Approval Experience

After diagnosis, the dashboard presents a human approval gate.

The interface makes the distinction between recommendation and execution visible.

The engineer can review the diagnosis and runbook before approving remediation.

The runbook is marked as simulation-only.

This is important because the dashboard should communicate the system's operational boundaries clearly.

The user should never be left wondering whether clicking the action button will change a real production service.

Showing the Learning Event

Once the simulated remediation succeeds, the interface changes state.

The incident becomes:

RESOLVED

and the dashboard shows that the outcome was retained as organizational memory.

Hindsight memory lifecycle visual

Figure 3 — The dashboard shows that the resolved incident has become persistent organizational memory.

This visual state is important because it communicates that resolution is not the end of the workflow.

The incident has moved into the memory lifecycle.

Demonstrating Future Recall
The strongest frontend demonstration occurs when a different incident is analyzed after the memory has been retained.

When INC-007 is analyzed, the dashboard can show INC-008 among its historical context.

AI incident investigation visual

Figure 4 — The dashboard makes the cross-incident memory relationship visible.

This creates a clear visual narrative:

## INC-008 was resolved.
## INC-008 was retained.
## INC-007 was investigated later.
## INC-008 appeared as historical context.

That is much easier to understand when the interface makes the state transitions visible.

Keeping the Frontend Focused

One lesson from building the dashboard was that an AI interface can become cluttered very quickly.

There are many possible pieces of information:

Logs
Metrics
Memory
Diagnosis
Reasoning
Recommendations
Runbooks
Resolution
Learning Displaying everything with equal visual importance can make the interface harder to use.

The useful hierarchy is:

Current incident → Evidence → Diagnosis → Historical context → Recommended action → Approval → Outcome

That sequence follows the engineer's decision process.

Frontend and Backend Boundaries
The frontend does not perform the incident reasoning itself.

It calls the backend API.

The backend coordinates:

Incident retrieval
Evidence retrieval
Hindsight recall
AI diagnosis
Runbook selection
Resolution
Memory retention This separation keeps the frontend focused on presentation and interaction.

It also makes it possible to change the AI or memory implementation without redesigning the entire interface.

What We Learned

1. Observability should include the AI workflow

If memory influences an AI decision, users should have some visibility into that context.

2. UI state should match backend state

The dashboard should clearly distinguish between analyzed, awaiting approval, resolved, and memory-retained states.

3. Current evidence needs visual priority

Historical memory is useful, but the latest telemetry should remain prominent.

4. The learning loop should be visible

Showing the transition from resolution to retained memory makes the value of persistent memory much easier to understand.

5. Good AI UX is about decision support

The interface should help an engineer inspect and decide, not simply display generated text.

Conclusion

Building the OpsMind dashboard made one thing clear: an AI SRE agent is not only a backend problem.

The frontend determines whether an engineer can understand what the agent knows, why it reached a conclusion, what historical context influenced it, and what will happen if remediation is approved.

The dashboard therefore mirrors the architecture of the agent itself.

Current evidence is visible first.
Historical memory is explicit.
Recommendations are inspectable.
Execution requires approval.
Successful outcomes become visible as retained organizational memory.

That makes the memory loop something an engineer can actually see and reason about rather than an invisible mechanism behind an AI response.

DEV Community: GADDI KOPULA VENKATESH