Why root cause matters more than anomaly detection — and what actually changes when a platform reasons about cause and effect instead of statistical coincidence.
"What's unusual?" and "what's wrong?" sound like the same question asked two ways. They aren't. Anomaly detection answers the first — it tells you a metric moved outside its normal range. Root cause analysis answers the second — it tells you why, and what to do about it. Most observability tooling built over the last decade is very good at the first question and structurally unable to answer the second, because it was never given the information it would need to: the causal relationships between the things it's watching.
This paper is about that gap, and about the specific architectural choice — a causal entity graph instead of a metrics-correlation engine — that Applicare's ArcIn uses to close it.
A conventional anomaly-detection or correlation engine watches time series and flags statistical deviations: a metric crossed a threshold, or moved in a way that's uncommon relative to its history. When several such deviations happen close together, the tool may group them because they're temporally correlated — they happened around the same time.
That is useful information, but it is not causal information. Two metrics moving together does not establish that one caused the other, or that either caused the underlying problem — both could easily be downstream symptoms of a third thing the tool never measured directly. The result, familiar to anyone who has been paged at 2am, is a wall of simultaneous alerts and no way to tell which one is upstream of the others.
Applicare's platform is built around a continuously updated causal entity graph — a live model of every service, host, container, database, and dependency in an environment, and the causal relationships between them, rebuilt in under 12 seconds as the environment changes. This is the foundation every other capability in the platform sits on top of, including ArcIn.
The difference in one sentence: a correlation engine asks "what else moved around the same time?" A causal entity graph already knows which services depend on which, so it can ask "which of the things that moved is actually upstream of the others?"
When an engineer asks ArcIn a question like "why is checkout slow?", ArcIn does not search for statistically similar historical incidents. It traverses the causal entity graph from the symptom backward through real dependency edges — this service calls that service, that service reads from that database, that database's replica just fell behind — until it reaches an event that plausibly explains what changed: a deploy, a configuration change, a traffic surge, a resource constraint.
That traversal is what makes a plain-English answer possible in under 60 seconds. ArcIn isn't summarizing a dashboard full of correlated alerts for a human to interpret — it's walking the same causal chain a senior engineer would walk by hand, across as many as 40 services in a single incident, and reporting the node where the chain actually starts.
The same incident, reasoned about two different ways:
| Step | Correlation-based approach | Causal entity graph (ArcIn) |
|---|---|---|
| Signal | Latency, error rate, and DB metrics all flag around the same time | Same signals, but already attached to graph nodes with known relationships |
| Grouping | Grouped because they're temporally close | Grouped because they're causally connected — one is genuinely upstream |
| Output | A list of correlated alerts, ranked by statistical strength | A single causal chain, ending at the event that explains it |
| Human task remaining | Interpret which alert is the cause, usually by process of elimination | Confirm the fix; the cause is already named |
None of this makes correlation and anomaly detection obsolete — it makes them a different layer of the same system. Applicare's IntelliSense engine uses per-entity behavioral baselines and anomaly detection specifically because that is the right tool for the job it does: noticing that something has changed before there's enough information to explain why, including zero-day patterns that have no historical precedent to pattern-match against.
The point is not "anomaly detection is wrong." It's that anomaly detection answers "something is different" and a causal entity graph is what turns that observation into "here is what's different, and why" — and conflating the two, treating correlation output as if it were root cause, is where a lot of AIOps tooling overpromises.
In a correlation-driven workflow, the engineer's first ten minutes are spent doing causal reasoning that the tooling didn't do: opening each alerting dashboard, checking deploy timelines by hand, asking around in Slack about who touched what. In a causal-graph-driven workflow, that reasoning already happened before the engineer opened anything — the plain-English answer is waiting, with the specific service, the specific commit, and a recommended fix attached.
The practical effect isn't just speed, though under-60-second root cause is a meaningful speed difference on its own. It's that the engineer's attention goes to deciding whether the recommended fix is right, not to reconstructing what happened in the first place.
Teams don't need to discard existing monitoring to get the benefit of a causal entity graph — Applicare ingests OpenTelemetry and existing metric sources into the graph rather than requiring a wholesale replacement. The entity graph and ArcIn typically run alongside existing anomaly detection during evaluation, so the difference between "something moved" and "here's why" is visible on the same incidents, side by side, before any tooling gets retired.