Alert rules and anomaly detection

An alert rule is a stored condition evaluated against live data on a schedule. It sits on a metric definition: a measure from the platform's semantic layer, the time dimension it is aggregated by, and the filters and dimensions that scope it — a count of seismic events per day, incidents inside one province, vessel counts at one passage.

The rule adds the part that decides when a value is interesting: a condition type, a threshold, an optional spatial constraint, and the channels that a firing reaches. Because the definition lives in the rule rather than in the code, a threshold can be changed by the person who watches the metric, and the change takes effect on the next evaluation.

• Metric — a measure with its time dimension, granularity, dimensions and filters.
• Condition — what has to be true of that measure for the rule to fire.
• Spatial constraint — an optional radius and centre that binds the condition to one area.
• Channels — where a firing is delivered, chosen per rule.
• Severity — the weight carried on the alert, so a notification can be read at a glance.

On each evaluation the rule asks the semantic layer for its metric at the configured granularity, ordered newest first and limited to the current and previous period. The result is compared against the threshold using the rule's condition type, and the outcome is recorded with the actual value, the previous value for change conditions, and a plain-language detail line.

Conditions compose into an AND/OR tree, so a rule can require several things to be true at once. Activity above a level and a change above a rate can be demanded together, rather than either on its own, which is usually what an operator means by the word interesting.

• Threshold — fires when the current value is greater than the configured number.
• Change, percentage — fires when the period-over-period change passes a percentage, in either direction.
• Change, absolute — fires when the difference between the two periods passes a fixed amount.
• Spatial constraint — the condition applies within a radius of a location, so one metric can be watched per area instead of nationally.
• Insufficient data — a change condition with only one period available reports that it cannot decide, rather than firing on a guess.

Not every interesting event has a number an operator can name in advance. Anomaly detection compares a metric against its own recent history: the platform keeps a rolling baseline and flags when the current window departs from it, so a quiet area that suddenly escalates raises a signal that no fixed threshold would catch.

The same comparison supports week-over-week and month-over-month change and short-horizon forecasts, which answer the question that follows an anomaly — is this getting worse, flattening, or returning to normal. A rule states what you already know; a baseline states what that metric normally does.

Rules catch what you already know to look for; baselines catch what you did not.

Every rule keeps its last evaluation, so the rule list doubles as a status board: which metrics are in range, which are close, and which are firing. A firing rule raises a notification whose message is built from a template with the metric, the value and the threshold substituted in.

Repetition is controlled rather than assumed, because a condition that stays true overnight should produce a usable record and not a stream of duplicates. Severity, a cooldown and a quiet-hours window are all part of the rule, not of the tool that receives the notification.

• Last evaluation — the actual value, the comparison, and a pass-or-fail detail line per condition.
• Cooldown — a minimum interval between firings of the same rule.
• Quiet hours — a window in which notifications are suppressed while evaluation continues.
• Detail text — the reason a rule passed or failed, in a sentence rather than a bare number.
• Rule list — every definition in one place with its current state.

Alerting is one surface of the same semantic layer that feeds the platform's dashboards and its automated situation reports. A metric defined once can be charted, alerted on and summarised without a second definition drifting away from the first.

Because a firing is an event with a place and a time, it can be read next to the layers that explain it and carried into the workflow that responds to it. The alert is the start of the work rather than a notification that ends in itself.

• Dashboards — the same metric rendered as a panel or a chart.
• Reports — the same metric summarised in a written situation report.
• Response — a firing can be read alongside the map, the entity graph and the crisis board that handles it.

A rule is a signal, not a decision, and it cannot invent a metric that is not already defined: the measure, the time dimension and the filters have to exist in the semantic layer before a rule can be placed on top. That keeps every alert traceable to a definition somebody owns.

Thresholds are set by people, which means they can be wrong in both directions, and the platform is explicit about that: a rule reports the value it saw and the comparison it made, so a badly set threshold is visible in the record instead of hidden inside a black box. The record is what makes a bad setting correctable, and the correction is a change to the rule rather than a change to the software.