# Artificial Intelligence

{{% notice style="note" title="Limited access" icon="lock" %}}
{{% include file="include/restricted_access.md" hidefirstheading="true"  %}}
{{% /notice %}}

## What OpenGate AI does

OpenGate can **train a machine-learning model on the data it already collects, package the trained model as an
inference service and wire that service into the rules engine** — so that every new reading is scored the moment
it arrives, and an anomaly becomes an alarm without anyone writing a line of Python.

You do not bring a model. You pick a **training plan** from the platform catalogue — a ready-made recipe for a
concrete problem, such as *anomalous data sessions on a mobile APN* or *defective parts in an image* — point it at
your data, and OpenGate takes it from there: it exports the data, runs the training, versions the result, builds
an inference container and, if you ask it to, creates the rule that calls it.

```mermaid
flowchart LR
    D["Your data<br>time series or files"]:::ext --> T["<b>Trainer</b><br>runs a training plan"]
    T --> M["Model version"]
    M --> I["<b>Inferencer</b><br>deployed inference service"]
    R["<b>Rule</b><br>on new readings"] --> I
    I --> R
    R --> A["Datastreams<br>and alarms"]:::ext
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010
```

Four things carry the whole feature:

| Concept | What it is | Where it is documented |
|---|---|---|
| **Training plan** | A recipe for one kind of problem: the algorithm, the data it needs, the configuration it accepts and the container image that runs it. Curated by the platform. | [Training plans](training_plans/) |
| **Trainer** | Your instruction to run a training plan on your data — once, or on a retraining schedule. A trainer produces model versions. | [Trainers](trainers/) |
| **Inferencer** | A trained model deployed as an HTTPS service inside the platform, with the versions it can run and the rules that call it. | [Inferencers](inferencers/) |
| **Rule** | The ordinary OpenGate rule that sends each new reading to the inferencer and turns the answer into datastreams and alarms. Created for you by the training plan. | [Rules](../management/organizations/channels/rules/) |

Two platform services do the plumbing and are worth knowing about because they are reachable on their own:
the **[scheduler](scheduler/)**, which runs anything on a cron expression or an interval — REST requests, container
images, pipelines of both — and is what actually launches a training; and the **[file connector](file_connector/)**,
which gives each organization a file space where training files and images live.

## Two ways to use it

**From the web console.** The *Artificial Intelligence* section of the OpenGate console walks you through
choosing a plan, pointing it at a time series or an uploaded file, naming the model and deciding whether it
retrains. When the training finishes, the same screen shows the inferencer, its versions and their metrics, and
lets you switch versions on and off. See [The web console](web_console/).

**From the REST API.** Everything the console does is a call to one of five services under `/ai`, `/scheduler`
and `/fileConnector` on the platform host. The pages of this section document each of them, with its OpenAPI
specification at the bottom. Read [How it works](how_it_works/) first: it follows one training from the `POST`
that schedules it to the alarm that a rule raises, and names every moving part along the way.

## The plans available today

| Plan | Detects | Learns from |
|---|---|---|
| [RADIUS session anomalies — Isolation Forest](training_plans/radius_isolation_forest/) | Data sessions of SIM subscriptions on one APN whose traffic profile is unusual | The RADIUS session records of that APN |
| [RADIUS session anomalies — Autoencoder](training_plans/radius_autoencoder/) | The same problem, with a neural network that scores how badly a session can be reconstructed | The RADIUS session records of that APN |
| [Image anomaly detection](training_plans/image_anomaly_detection/) | Defective items in photographs, with a heat map of where the defect is | Two folders of images: correct and incorrect |

Every plan on the platform follows the same contract, so what you learn about scheduling, versions and rules
for one applies to all of them. Building a new one is the platform team's job; [Building training plans](building_training_plans/)
explains what that involves.

{{% notice style="warning" title="Trainings and inferencers consume platform resources" icon="triangle-exclamation" %}}
A training is a container job that runs until it finishes or hits its timeout, and an **active** inferencer is a
service that stays up and is called on **every** new reading its rule matches. Both are billed as platform usage.
An inferencer can be left configured but inactive, and a trainer can be created without a retraining schedule;
both are deliberate choices you make when you create them.
{{% /notice %}}

## Index

{{% children sort="weight" depth="100" %}}