How graph-powered reasoning can help engineers investigate incidents with evidence, relationships, and persistent memory.
When a software system experiences an incident, engineers need to answer several questions quickly:
The challenge is that operational information is interconnected. An incident may affect one service, that service may depend on another, and a historical incident may contain a resolution worth investigating.
Looking at individual records is not always enough. Engineers need to understand how these pieces of evidence relate to each other.
That motivated me to build TraceGraph AI, a graph-powered incident investigation application built with FalkorDB.
TraceGraph AI helps Site Reliability Engineers (SREs), DevOps engineers, and incident response teams investigate software incidents through connected operational evidence.
The application connects incidents, services, dependencies, deployments, historical incidents, resolutions, runbooks, and investigation memory in a graph.
The project includes:
The goal is not to claim that a graph automatically discovers the true root cause. Instead, TraceGraph AI makes relevant evidence and relationships easier to explore, helping engineers investigate more systematically.
The central design decision was to treat relationships as first-class data.
Consider a simplified example:
INC-1001 → AFFECTS → Checkout API
The Checkout API may depend on another service. A historical incident may have affected the same service, and that earlier investigation may have recorded a resolution.
A graph allows the application to traverse these relationships and retrieve connected context rather than relying only on isolated incident records.
FalkorDB serves as the graph database behind TraceGraph AI. It stores the connected operational entities and supports the graph queries used by the investigation workflow.
This makes the graph more than a visualization. It is part of the application's retrieval and reasoning process.
TraceGraph AI follows an evidence-first approach.
1. Retrieve connected evidence
The application queries FalkorDB for the incident, affected services, dependencies, historical incidents, resolutions, and related operational context.
2. Explore potential explanations
The investigation engine evaluates the retrieved evidence and counter-evidence to rank potential causes. For example, a deployment preceding an incident may be relevant, but timing alone does not prove causation.
3. Preserve provenance
The application presents evidence identifiers and relationship paths so users can inspect where an investigation finding came from.
4. Save investigation knowledge
Completed investigations can be stored as reports with episodic memory. The application also supports sourced semantic and procedural memories, including review and archive controls.
5. Use memory carefully
Relevant reviewed procedural knowledge can inform checks in a later investigation. However, previously stored information is context to evaluate, not automatic proof that the same explanation applies again.
This design aims to make investigation results more explainable and useful over time.
Another important part of TraceGraph AI is persistent investigation memory.
An investigation should not necessarily end when the current incident is closed. Its evidence, decisions, and lessons may help with future incidents.
TraceGraph AI supports persistent episodic, semantic, and procedural memory in the graph. Users can inspect and review stored knowledge rather than treating every past conclusion as unquestionably correct.
The project explores a practical form of coordination between automated investigation workflows and human review. It does not claim that the current version implements a network of autonomous agents negotiating with one another.
TraceGraph AI combines:
The investigation engine can operate deterministically without requiring a paid language-model API key. Optional model-assisted ranking is constrained to reordering existing hypothesis identifiers, with a deterministic fallback.
The demonstration uses synthetic incident data rather than real production telemetry.
Drawing connected nodes is not enough. The relationships must support meaningful retrieval and help answer investigation questions.
A deployment may precede an incident without causing it. A historical resolution may be relevant without being the correct fix for the current problem.
This distinction influenced the project's evidence-first design and its treatment of uncertainty.
Saving previous findings can improve continuity, but outdated or incorrect knowledge can also mislead future investigations. Sources, review controls, and the ability to archive memory are therefore important.
A useful graph-powered application needs a reliable API, a clear interface, meaningful queries, error handling, and a deployment that can be tested by other people.
Building and deploying TraceGraph AI helped bring these pieces together in a complete demonstration.
There are several opportunities to extend the project:
These improvements would move the project closer to a production-ready incident investigation platform.
The live application and source code are available here:
Building TraceGraph AI reinforced an important idea: incident investigation is fundamentally about connecting evidence.
FalkorDB provides a graph-based foundation for retrieving those connections, exploring historical context, and retaining investigation knowledge. By combining graph queries, explainable evidence paths, cautious hypothesis ranking, and persistent memory, TraceGraph AI demonstrates how connected data can support a more systematic incident response workflow.
The larger lesson is that useful AI-assisted investigation should not only suggest an answer. It should help engineers understand the evidence behind that answer, recognize uncertainty, and make better-informed decisions.
Built for the FalkorDB Graph Hacks hackathon.