Overview
Traditional anomaly detection often asks whether a particular metric has deviated from expected behaviour. More advanced multivariate approaches go one step further and ask whether the combined behaviour of a single entity has changed. MPAD extends this logic again: it asks whether the same dataset can be reorganised into multiple meaningful behavioural entities, each analysed independently from a different perspective.
That distinction matters because many operational problems are not well explained by one entity alone. A pod may look abnormal, but the real explanatory signal may appear more clearly when the same data is reorganised around IP addresses, applications, virtual networks, merchants, devices, patients, routes, or substations.
Traditional focus
One metric or one composite entity is usually treated as the primary unit of anomaly detection.
MPAD focus
Several behavioural entities are created from the same dataset and analysed in parallel.
The Core Question: Which Behaviour Are We Analysing?
Every anomaly detection problem hides a foundational modelling choice:
The answer determines how anomalies are interpreted, detected, and acted upon. If we choose the wrong observational unit, the resulting alarms may be noisy, incomplete, or misleading. If we choose the right unit, anomaly detection becomes much more context-aware.
MPAD treats this choice as first-class. Instead of fixing one observational unit too early, it allows several valid behavioural entities to coexist and be analysed side by side.
Three Levels of Abstraction
1. Metric-level analysis
At the lowest abstraction level, individual metrics are treated independently. A metric such as latency, packet rate, or response time can trigger an alarm on its own when it deviates from normal behaviour. This is useful for sensitivity, but it often creates too many isolated alarms and a high proportion of false positives.
2. Entity-level behavioural modelling
At a higher abstraction level, multiple metrics are grouped to model the behaviour of a single larger entity, such as a pod, server, gateway, device, or customer. Here, individual metrics do not trigger alarms independently; instead, they collectively define the behaviour of the entity.
3. Multi-perspective behavioural modelling
MPAD introduces a third layer of abstraction. Rather than building only one composite entity from the dataset, it creates multiple behavioural entities from different perspectives. Each perspective becomes its own multivariate problem, and anomalies are then compared and correlated across those views.
| Level | Unit of analysis | Main limitation |
|---|---|---|
| Metric-level | Individual KPI / field | Too reactive, often context-poor |
| Entity-level | One behavioural entity | May miss alternative explanatory views |
| MPAD | Several behavioural entities from the same dataset | Requires scalable modelling infrastructure |
What MPAD Really Means
Consider a network monitoring example. One valid approach is to model the overall behaviour of a pod using all relevant metrics. MPAD does not reject that view. It simply says that this is only one valid behavioural entity among several.
From the same dataset, MPAD may also model:
- the behaviour of each IP address accessing the pod,
- the behaviour of each application interacting with the pod,
- the behaviour of each virtual network, independently.
Each perspective is treated as an independent multivariate time-series problem. Once anomalies are detected within each view, MPAD compares them and correlates them. The value of the method is not just stronger detection; it is stronger explanation.
Business Benefits of MPAD
| Dimension | MPAD capability | Business value |
|---|---|---|
| Focus | Multiple behavioural entities across the same dataset | Broader anomaly coverage across users, systems, products, and locations |
| Scope | Independent models per perspective | More flexible and targeted analysis |
| Value | Understands scope, context, and impact of anomalies | Faster triage and richer operational insight |
| Correlation | Correlation is native to the method | Reduced alert fatigue and better contextual understanding |
| Root cause | Analyses both what is wrong and why it may be happening | Supports more strategic and confident decisions |
How MPAD Works in Thingbook
Thingbook automates the MPAD lifecycle through a combination of behavioural abstractions and scalable modelling infrastructure. In practice, the process looks like this:
- Define sensor abstractions: decide which entities represent behaviour in each perspective.
- Build models per perspective: each behavioural entity gets its own unsupervised multivariate model.
- Run in batch or streaming mode: the same method supports historical and real-time analysis.
- Correlate anomalies: compare what is happening across perspectives to identify scope and likely cause.
The important point is that the methodology remains conceptually simple for users, even though the system may instantiate thousands of models behind the scenes.
Why DriftMind Makes MPAD Operationally Possible
MPAD is only practical if the modelling engine can handle large numbers of behavioural entities efficiently. That is where DriftMind becomes essential. It allows Thingbook to instantiate, maintain, and update many independent models in parallel without turning the system into an operational burden.
- Massive rollout of behavioural perspectives
- Automatic model creation per sensor type or entity group
- Unsupervised multivariate modelling per sensor
- Support for batch and streaming data
- Adaptive learning under drift and seasonal change
- Correlation of anomalies across sensors and perspectives
Cross-Industry Examples
| Industry | Example scenario | Sensor perspectives | MPAD insight |
|---|---|---|---|
| Telecom | Network traffic degradation | Applications, gateways, ports, IPs | Traffic degradation becomes localizable when anomalies converge on specific gateways and app flows |
| Retail / E-Commerce | Sudden drop in Christmas sales | Customers, stores, products | Cart abandonment can be linked to promo-code issues in specific stores or products |
| Healthcare | ICU patient heart-rate spikes | Patients, devices, wards | What first looks like a patient anomaly may correlate more strongly with faulty monitoring equipment |
| Manufacturing | Decline in product quality | Machines, batches, operators | Defects can be scoped to a machine/operator interaction rather than one defective batch alone |
| Cybersecurity | Suspicious login behaviour | Users, geolocations, devices | Credential abuse becomes visible through coordinated anomalies across device and geography perspectives |
| Energy & Utilities | Localized voltage drops | Smart meters, substations, regions | Household-level anomalies can be traced to one faulty substation or transformer context |
Where TOS Fits
MPAD defines the anomaly-detection methodology. To make that methodology operational, Thingbook uses a structural framework called TOS — Thingbook Object Structure. TOS defines how behavioural entities are represented in the system through objects such as:
- BPE — Behavior Prediction Engine
- Sensor — behavioural unit of analysis
- Feature — attributes describing sensor behaviour
- RBI — Relevant Behavior of Interest