FalkorTrace

Graph-Guided Software Investigation, Sandboxed Verification & Version-Aware Agent Memory on FalkorDB

---

Core Thesis: Why Multi-Hop Graph Traversal + Sandboxed Verification + Version-Aware Memory Beats Single-Hop Retrieval

Why do standard single-hop text retrieval pipelines fail in production incident triage, and why is FalkorDB the core operational engine for reliable engineering agents?

When a customer files a ticket on an entrypoint service (e.g., billing-edge-api), single-hop text retrieval (Lexical TF-IDF Baseline, k=3) scores document chunks by lexical overlap. Because the ticket only mentions billing-edge-api, single-hop retrieval surfaces local chunks (sim = 0.81) and misses a breaking Git commit 3 hops downstream in proration-engine (sim = 0.14, ranked #9)—or returns false nearest-neighbor matches when queried about an unknown service (quantum-ledger-v9).

Even more importantly, a production engineering agent cannot rely on pre-seeded boolean graph flags (compliant: false) or blindly reuse stale past findings when code artifacts change.

FalkorTrace places FalkorDB at the center of a closed-loop verification architecture:

1. Left Pane (❌ 1. Lexical TF-IDF Baseline (k=3)): Computes deterministic TF-IDF Cosine Similarity over a fair serialized fact corpus (containing the exact same service, dependency, code module, commit, and PRD facts stored in FalkorDB), exposing single-hop retrieval blindness without handicapping the corpus.
2. Center Hero Pane (🧠 2. Core Central Unit: Live FalkorDB Graph Engine): Traverses multi-hop dependencies ([:DEPENDS_ON*1..4]), native GraphBLAS algorithms (algo.SPpaths, algo.pageRank, algo.WCC, algo.betweenness), and selects allowlisted verification checks ((:CheckDefinition)-[:VERIFIES]->(:Requirement)). Supports a controlled graph-only fault simulation (/api/inject-fault) and simulated artifact rollback (/api/remediate); neither action changes an external deployment or incident system.