AI Anomaly Analysis Assistant for Time-Series Monitoring

Whether the analysis gets done depends on who is on shift

Someone has to open each metric, work out which movements are related and which merely happened at the same time, and write it up before the context fades. Neither of the things that go wrong there is a monitoring problem. The engineer on shift at three in the morning gets through fewer charts than the one at ten, which is a property of people and not of the alerting. And the write-up that comes out carries the shape of whoever wrote it, so two incidents of the same kind leave behind two documents nobody can put side by side.

The arithmetic happens before the model does

The order of the stages is the whole design, and it is the part we would defend hardest.

Statistics and ML find the anomalies

Metrics are collected, statistical features computed, and anomalies and correlations detected by classical time-series methods and ML. No language model is asked to look at a chart and say whether something is unusual. A model given raw series will find a pattern in noise, and it will describe that pattern fluently.

The model writes, it does not detect

Its job starts once the detection is done: turn the long technical report into a short brief that leads with the signals most likely tied to the failure. Prioritising a list it was handed is a task a language model is good at. Deciding what belongs on the list is not.

The output is shaped, not shipped raw

Model text goes through a cleanup pass into a fixed form before an engineer sees it. That is what makes two briefs comparable, which is the point of writing them down at all.

What we ruled out

The obvious build is to hand the metrics to a model and ask what went wrong. It demos well. It fails in the way that costs most: the answer is confident and readable whether or not anything real was found, and an engineer under incident pressure is the worst-placed person to audit it. Splitting detection from writing costs a pipeline that a single prompt would not have needed, and it buys a brief whose claims came from arithmetic somebody can re-run.

Where it stands

In development. What exists is the pipeline end to end - collection, statistical features, detection, the technical report and the condensed brief - and what does not yet exist is a measured answer to how often the prioritisation puts the right signal first. That number is what would decide whether this belongs in front of an on-call engineer, and until it exists we are not claiming it.

Safe because it was never asked to be right about the data

Everything above is one argument: an LLM is safe here because it was not asked to do the part that requires being right about the data. That is a design decision you can only make if you have already worked out what the model is reliably good at, and the only way to know that is to measure it on your own cases.