AI Capabilities

AI capabilities

Axiom Border can run machine-learning models on the probe, in containers, to detect anomalies in the metrics it ingests. A model trains locally on local data, exposes an inference endpoint on loopback, and rules call it to decide whether an event is worth an alarm.

The point is the same as everywhere else in the product: no cloud round trip, no data leaving the site.

Where you manage it

AI capabilities in the console lists the models configured on the probe. On a fresh installation it is empty, because model images are supplied separately from the product:

From here you create a capability, follow its training state, force or cancel a training run, edit the rule that calls the model, and read the quality metrics the model reports about itself. Everything on this page is done from that view — the sections below follow it in order.

The lifecycle

flowchart TB
    TAR["Model image tarball<br>supplied separately"]:::ext -->|"stage on disk"| IMG["Image imported<br>for one agent type"]
    IMG -->|"deploy"| EXPORT["Training data<br>exported"]
    EXPORT --> DEPLOY["Container deployed"]
    DEPLOY --> HEALTH{"Model<br>healthy?"}
    HEALTH -->|"not yet"| HEALTH
    HEALTH -->|"responds"| READY["READY"]
    READY -->|"retrain due"| TRAIN["TRAINING"]
    TRAIN --> READY
    READY -->|"predict"| INFER["Inference<br>from rules"]
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

Each agent type has a fixed loopback port, which is how a rule reaches the right model:

Each model listens on the host’s loopback address, so rules reach it at 127.0.0.1:<port>.

Loading a model image

Model images are not part of the installation bundle — they are supplied separately, because which model you run is a decision about your data rather than about the product.

Create new AI trainer collects everything needed in one step: the model package, and the agent type it applies to. You can upload the package from your machine, or tick Use file on disk and pick one already staged on the probe — the wizard lists what is there, with the directory it is reading.

Deploying a capability

The same wizard deploys it. Two settings decide how it behaves afterwards:

Deployment then does four things in order: exports the training data the probe already holds, starts the model with that data available to it, waits for the model to report itself healthy, and marks the capability ready — at which point it collects the model’s own quality metrics and enables the rule.

The health wait is bounded, roughly a minute and a half by default. A model that is slow to start needs that raised in Configuration; it is not a failure of the model.

Only one capability per agent type can exist at a time. Deploying over an existing one is refused — remove it first.

Following it from the console

The table on AI capabilities is the whole operational picture: trainer and model name, type, the retraining period, when it last ran and when it runs next, whether the script is enabled, the data source and inferencer, the model version, and the status.

Each row carries its actions:

Calling inference from rules

This is where the capability earns its place. A rule script fetches recent metrics, builds a feature vector, asks the model to score it, and raises an alarm when the model says anomaly:

function process(metrics) {
  for (var i = 0; i < metrics.length; i++) {
    var metric = metrics[i];
    metric.SetT0();

    var payload = JSON.stringify({
      sent_vars:     metric.GetFieldByName("sent_vars"),
      prepared_vars: metric.GetFieldByName("prepared_vars"),
      ram_usage:     metric.GetFieldByName("ram_usage")
    });

    var response = newPredict(payload, "metrics");
    var result   = JSON.parse(response);

    if (result.prediction === 1) {
      newAlarm(metric, "critical", "New anomaly detected", "Anomaly", "AI Capability");
    }

    metric.SetT1();
  }
}

Two globals are available to scripts for this: newPredict(payloadJSON, agentType) calls the model’s inference endpoint, and newGetMetrics(agentType) fetches the model’s own metrics. Both target the loopback port for that agent, and both are configured under trainerDetails.

The rule script for an agent is enabled through ruleEnabled when deploying the capability, and can be managed directly through the /scripts endpoints. See Alarms and rules.

Surviving a restart

Capabilities are part of the probe’s local state, and startup restores them: containers are resumed, model metrics are re-fetched, and retraining schedules resume from their stored next-run time.

One case is treated deliberately: a capability that was training when the process stopped is considered cancelled rather than resumed, because the training run did not finish. It moves to the appropriate cancelled state and waits for its next scheduled run.

Failures during this restoration are logged and do not prevent startup.

Configuration reference

The relevant block is trainerDetails — container name, TLS material, and the three endpoint definitions for health, metrics and inference. See Configuration.

The health, metrics and inference endpoints are meant to be reached over loopback only. Keep them bound to 127.0.0.1 and do not expose those ports beyond the host.