🤖 AI

A Topology-Aware, Memory-Centric Architecture that Separates Root-Cause Derivation from Root-Cause Explanation

This paper introduces OPS CORTEX, a topology-aware, memory-centric architecture that decouples deterministic root-cause derivation from LLM-based explanation by maintaining a persistent, structured representation of system behavior and dependencies to address the challenges of fault propagation in modern microservice deployments.

Original authors: Momil Seedat

Published 2026-06-23

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Momil Seedat

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the captain of a massive, high-tech spaceship. Suddenly, alarms start blaring everywhere. Lights flash red. The ship is shaking.

The Problem:
In modern computer systems (called "microservices"), when something breaks, the alarms are easy to trigger but hard to understand. It's like having 50 different sensors screaming "Fire!" at once. The real problem isn't that the sensors don't work; it's that the human in charge (the engineer) is overwhelmed. They have to figure out:

Which sensor is the real fire?
Which sensors are just reacting to the smoke from the first fire?
Why did this happen now and not yesterday?

Usually, the computer system forgets everything the moment the alarm stops. It has no memory of what "normal" looks like at 3 a.m. on a Tuesday, or how the ship's parts are connected. So, the engineer has to play detective from scratch every single time, often while the system is still crashing.

The Solution: OpsCortex (The "Operational Memory")
The paper introduces OpsCortex, a new way to run these systems. Instead of trying to make the computer "smarter" with a giant brain (like a super-advanced AI) to guess the answer, the authors say: "Give the system a memory."

Think of OpsCortex as a super-organized, long-term memory for the computer system. It's built like a four-story library:

The Hot Desk (Tier 1): This is the "Right Now." It holds the current temperature, speed, and alerts. It's like a sticky note on a desk that gets thrown away every few hours.
The Live Map (Tier 2): This is a drawing of how all the computer services talk to each other. If Service A talks to Service B, this map knows it. It's updated constantly.
The Photo Album (Tier 3): Every minute, the system takes a "snapshot" of the whole map and saves it. This lets you look back and see, "Oh, the connection broke 5 minutes ago, not 1 second ago."
The Encyclopedia (Tier 4): This is the permanent brain. It remembers: "At 3 a.m. on Tuesdays, the system usually slows down a bit, and that's normal." It also remembers past disasters and how they were fixed.

How It Works: The "Detective and the Translator"
The paper argues that finding the cause of a problem and explaining it are two different jobs. OpsCortex splits them up:

Step 1: The Detective (Deterministic Logic):
First, the system uses simple, hard math rules (like a detective following a trail of footprints). It looks at the "Live Map" and asks: "Which service broke first?" and "Which services are connected to it?"
- Analogy: If a domino falls and knocks over a line of 10 others, the math doesn't guess. It simply points to the first domino that fell. This is 100% reliable and fast.
Step 2: The Translator (The AI/LLM):
Only after the Detective has found the culprit does the system call in the "AI Translator."
- Analogy: The AI isn't asked to guess who did it. Instead, the Detective hands the AI a folder of evidence (the map, the timeline, the first domino) and says, "Here is what happened. Now, write a report for the human captain in plain English and tell them how to fix it."
- This makes the AI much better at its job because it's not guessing; it's just explaining facts.

Why This is Better (The "Silence" Trick)
The system also learns to ignore "noise."

The Problem: Every night, a computer might run a big, slow job that looks like a crash but is actually normal. Old systems would scream "ALARM!" every night.
The OpsCortex Fix: The system learns, "Oh, this happens every night at 2 a.m. It's normal." It goes silent.
The Safety Net: But if that same job suddenly gets slower than usual, or if it happens at 2 p.m. instead of 2 a.m., the system remembers, "Wait, this isn't the usual pattern!" and wakes up the alarm.

Real-World Proof
The authors tested this on a fake online store. They broke it in 8 different ways (like making a queue back up or overloading a service).

When they tested it against real-world disasters (like the Slack outages mentioned in the paper), the design directly solved the problems those companies faced:
- Slack 2021: Their own dashboard broke because it relied on the same broken network. OpsCortex doesn't need the dashboard; it has its own permanent memory (Tier 4) so it can still work even if the main tools fail.
- Slack 2022: A small change caused a huge crash during peak traffic. OpsCortex remembers what "peak traffic" usually looks like, so it spots the drift toward disaster before the alarm even goes off.

The Bottom Line
The paper claims that the biggest problem in fixing computer systems isn't that we lack better sensors or smarter AI. It's that we lack memory.

OpsCortex says: "Let's build a system that remembers what is normal, remembers how things are connected, and remembers past mistakes." By doing this, it can find the root cause using simple math, and then use AI just to explain it clearly. This makes the system cheaper, calmer, and much faster at fixing itself.

Technical Summary: OpsCortex – Operational Memory for Self-Diagnosing Microservice Systems

Problem Statement

Modern microservice architectures face a critical asymmetry: failure detection is mature and automated, but root-cause localization and explanation remain manual, slow, and prone to context loss. When faults propagate through service dependencies, they trigger "alert floods" that overwhelm engineers. The core challenges identified are:

Alert Fatigue: Threshold-based systems are memoryless; they cannot distinguish between benign recurring events (e.g., nightly batch jobs) and genuine crises.
Lost Context: Critical diagnostic data—such as the live call graph, time-of-day baselines, and recent configuration changes—is often transient or scattered, forcing diagnosis to become "archaeology."
The Cascade Problem: Failure signals are topological and temporal (who broke first and how the damage spread), yet flat alert streams discard this structure, making it difficult to distinguish the root cause from downstream victims.

The paper argues that the missing ingredient in autonomous operations is not better anomaly detectors or larger Large Language Models (LLMs), but operational memory: a persistent, structured representation of system behavior, dependencies, and historical failures.

Methodology

OpsCortex is a multi-agent prototype that organizes operational memory into a four-tier architecture and separates root-cause derivation from explanation.

1. Four-Tier Operational Memory Architecture

The system layers memory by lifetime and purpose to ensure the system is never "blind" on restart:

Tier 1 (Hot Working Memory - Redis): Stores current metric values, sliding windows, and alert streams with a short Time-To-Live (TTL). This represents the system's "present tense."
Tier 2 (Live Dependency Graph - NetworkX): An in-process, three-level directed graph (Service → Category → Metric) with CALLS edges. Status propagates upward (worst metric determines category status, etc.) for fast traversal.
Tier 3 (Snapshot History - Neo4j): Serializes the full graph every 60 seconds. This allows the system to analyze how the state changed in the minutes preceding an incident, distinguishing slow leaks from sudden crashes.
Tier 4 (Permanent Brain - SQLite): The "learned" state. It stores per-service/metric/hour/weekday baselines, confirmed call edges with confidence counts, structural noise registries, and full incident history. On cold start, this tier reconstructs the graph and baselines before new telemetry arrives, ensuring the system retains knowledge across restarts.

2. The "Derive, Then Explain" Pipeline

The diagnosis process is deliberately split into two distinct stages to leverage the strengths of deterministic logic and generative AI:

Stage 1: Deterministic Derivation:
- Root Cause Computation: The system performs a Breadth-First Search (BFS) over confirmed CALLS edges to identify all services connected to a fault.
- Temporal Ordering: The root cause is identified as the service that crossed its alert threshold first ( $arg \min t_{amber}$ ). This separates the cause from its victims.
- Noise Handling (Suppress-Then-Detect): The system learns structural noise (e.g., harmless nightly jobs) and suppresses alerts for them. However, suppression is overridden by sudden spikes (self z-score), gradual drift (trend z-score), or correlated anomalies in peer services.
- Time-Aware Baselines: Detection uses baselines bucketed by (service, metric, hour, weekday) to account for normal cyclical variations.
Stage 2: Generative Explanation:
- An LLM is invoked only after the deterministic layer has identified a root cause and assembled evidence (fault path, z-scores, Isolation Forest scores, status progression).
- The LLM's task is narrowed to explaining, confirming, and recommending fixes based on the provided evidence, rather than inferring causation from raw telemetry.
- Pattern Matching: If a new incident matches a known signature from the permanent brain, the system reconstructs the prior diagnosis and bypasses the LLM entirely, reducing cost and variance.

Key Contributions

Four-Tier Memory Architecture: A design that separates present state, live topology, change history, and permanent knowledge, preventing context loss during restarts.
Two-Stage Root-Cause Method: A deterministic approach (BFS + temporal ordering) that computes the cause, with the LLM strictly confined to the role of an explainer using pre-assembled evidence.
Learned Suppress-Then-Detect Lifecycle: A mechanism that silences structural noise while dynamically overriding suppression when genuine degradation (spikes or drift) occurs.
Explicit Failure Mode Mapping: A direct architectural mapping where each design choice addresses specific failure modes observed in documented production incidents (Slack 2021 and 2022 outages).

Results and Validation

The prototype was validated on an instrumented e-commerce benchmark with eight injectable failure scenarios, including request surges, queue lag, cascading failures, and resource exhaustion.

Learning Behaviors: The system successfully demonstrated the ability to learn and suppress benign recurring patterns (batch jobs) while immediately detecting and un-suppressing them when they degraded.
Pattern Bypass: The system successfully identified known patterns to bypass the LLM, demonstrating cost-efficiency gains as the system "learns."
Scope of Validation: The authors explicitly state that this is a validation of the mechanism end-to-end, not a comparative accuracy evaluation against production data or other tools like MicroRCA.

Significance and Claims

The paper posits that the bottleneck in autonomous operations is memory, not perception. While detection systems are abundant, systems that "understand" normalcy, dependencies, and history are not.

OpsCortex claims significance as a concrete architectural argument for:

Reframing the Goal: Moving from inferring root causes from scratch on every alert to maintaining a "living model" where the answer is often already known.
Division of Labor: Assigning deterministic tasks (localization, ordering) to rule-based systems and generative tasks (explanation, recommendation) to LLMs, thereby reducing the risk of hallucinated root causes.
Cost Reduction: Making the system "cheaper" over time by learning to suppress noise and bypass expensive LLM calls for known patterns.

The authors remain modest about the prototype's current status, acknowledging limitations such as the use of "first-crossing" as a proxy for causation (which can fail in feedback-coupled systems) and the lack of evaluation on real-world, labeled incident corpora. Future work is identified as moving from temporal heuristics to causal inference and validating the system on real post-mortem data.