Thingbook Object Structure (TOS)

Overview

TOS — Thingbook Object Structure — is a framework for representing behavioural systems in a way that is modular, scalable, and operationally consistent. It distils recurring design patterns from real forecasting and anomaly-detection deployments into a small set of reusable objects.

Instead of treating every new use case as a bespoke modelling exercise, TOS gives teams a stable way to answer four recurring questions:

• What behavioural system are we modelling?
• What is the unit of analysis?
• Which attributes describe that behaviour?
• Which behaviours matter enough to detect explicitly?

Why TOS Exists

Behavioural AI projects often become harder than necessary because the modelling logic is mixed with infrastructure choices, naming inconsistencies, and ad hoc data representations. TOS exists to standardize that layer.

In practice, TOS helps organizations:

• structure anomaly detection and forecasting initiatives consistently,
• reduce implementation complexity,
• improve maintainability and governance,
• shorten time from concept to deployment.

The Four Foundational Objects

Behavior Prediction Engine (BPE)

A BPE is a logical unit used to group sensors that serve a common functional purpose. It provides the top-level organisational boundary for a behavioural system.

For example, a telecom operator may want to monitor antenna or cell performance by region or technology. In that case, the BPE groups the relevant sensor templates and actual sensors into one operationally meaningful engine.

Sensor

A Sensor is the logical behavioural entity that acts as the unit of analysis in Thingbook. It is not simply a raw data field. It is an abstraction that answers:

Each sensor is modelled independently and emits multiple metrics or categorical signals over time. In MPAD, different sensor perspectives can be created from the same dataset.

Examples of sensors include:

• a pod,
• an IP address,
• an application,
• a server,
• a gateway,
• a smart meter.

Feature

A Feature is an attribute, metric, or categorical value that describes the behaviour of a sensor. Features form the multivariate input space used to model the sensor’s behaviour.

Features may be:

• Numerical — latency, packet count, bytes sent, response time, spend
• Categorical — application name, region, protocol type, store category

Relevant Behavior of Interest (RBI)

An RBI captures a specific behavioural pattern that the system should detect and flag explicitly. It represents a meaningful situation — often risky, costly, or operationally important — that deserves direct monitoring.

Each RBI is defined using:

• a set of relevant features,
• a set of datapoints describing the characteristic pattern,
• a mapping to the sensor templates where that behaviour is expected to occur.

Once defined, the system continuously evaluates the probability that a live sensor is moving toward that behaviour. If the probability exceeds a chosen threshold, an alarm can be triggered.

For example, in a network monitoring context an RBI might capture the traffic pattern characteristic of a scan or exfiltration precursor — defined by high packet rate, low byte size, and an unusual concentration of destination ports. Once defined, the system continuously evaluates how closely live sensor behaviour resembles that pattern and raises an alarm when the probability crosses a configured threshold.

Sensor / Feature Inversion by Perspective

One of the most important ideas in TOS is that the same data field can act either as a Sensor or a Feature, depending on the perspective selected.

Example:

• If the objective is to understand the behaviour of servers, then each server becomes a Sensor and applications may be used as Features.
• If the objective shifts to understanding the behaviour of applications, then each application becomes a Sensor and servers may become Features.

Example: IP Network Monitoring

The following simplified example defines a BPE for monitoring network behaviour at three levels: Source IP, Application, and Protocol. Each level includes a sensor template, a list of actual sensors, and shared configuration such as granularity and buffer size.

{
  "name": "X Flow Monitoring BPE",
  "sensorTemplates": [
    {
      "name": "Source IP",
      "description": "Sensors monitoring the behavior of individual IP addresses.",
      "features": [
        { "name": "Packets Sent", "type": "NUMERICAL" },
        { "name": "Bytes Sent", "type": "NUMERICAL" },
        { "name": "Packets Received", "type": "NUMERICAL" },
        { "name": "Bytes Received", "type": "NUMERICAL" },
        { "name": "TCP Source Port", "type": "CATEGORICAL" },
        { "name": "TCP Destination Port", "type": "CATEGORICAL" }
      ],
      "actualSensors": [
        "192.168.1.1", "10.0.0.1", "172.16.0.1"
      ]
    },
    {
      "name": "Application",
      "description": "Sensors monitoring application behavior.",
      "features": [
        { "name": "Packets Sent", "type": "NUMERICAL" },
        { "name": "Bytes Sent", "type": "NUMERICAL" },
        { "name": "Packets Received", "type": "NUMERICAL" },
        { "name": "Bytes Received", "type": "NUMERICAL" },
        { "name": "TCP Source Port", "type": "CATEGORICAL" },
        { "name": "TCP Destination Port", "type": "CATEGORICAL" }
      ],
      "actualSensors": [
        "Web Browse", "Email Client", "File Transfer"
      ]
    },
    {
      "name": "Protocol",
      "description": "Sensors monitoring protocol behavior.",
      "features": [
        { "name": "Packets Sent", "type": "NUMERICAL" },
        { "name": "Bytes Sent", "type": "NUMERICAL" },
        { "name": "Packets Received", "type": "NUMERICAL" },
        { "name": "Bytes Received", "type": "NUMERICAL" }
      ],
      "actualSensors": [
        "HTTP", "HTTPS", "SSH"
      ]
    }
  ],
  "granularity": 5,
  "bpeBuffer": 100
}

In practice, each actual sensor becomes an independently tracked behavioural stream maintained by DriftMind. Anomaly detection and forecasting can be applied at each step, while RBI logic can be layered on top where needed.

How TOS Supports MPAD

MPAD depends on the ability to define multiple behavioural entities cleanly and consistently. TOS provides exactly that foundation.

Go to the MPAD concept page →