The whole loop in one picture

Everything in this section is a step of the loop below. The names in bold are the API resources you will meet on the following pages.

sequenceDiagram
    participant U as You
    participant TA as Trainers API
    participant SC as Scheduler
    participant J as Training job
    participant IA as Inferencers API
    participant RU as Rules engine

    U->>TA: POST trainer (plan, data source, schedule)
    TA->>SC: schedule image execution or pipeline
    SC-->>J: at the scheduled time: export data, run the plan's image
    J->>J: train, evaluate, register the model version
    J->>J: build the inference image and push it
    J->>IA: create inferencer, or add the new version to it
    J->>RU: create the rule (first time only)
    J-->>SC: callback: OK
    U->>IA: activate a version
    IA->>RU: deploy the service, activate the rule
    RU->>IA: on each matching reading: POST prediction request
    IA-->>RU: prediction
    RU->>RU: collect datastreams, open or close alarms

1. You create a trainer

A trainer is a request to run a training plan on a data source, optionally on a schedule (POST /ai/organization/{organizationId}/trainer, see Trainers). You give it:

• the plan to run, by its identifier from the catalogue;
• the model name — lowercase letters, digits and hyphens. It becomes the name of the model, of the inferencer, of the rule and of the scheduler entry, so choose it with care: it cannot be changed later and only one trainer per model name can exist in an organization;
• the plan’s configuration — the fields the plan declares, such as the APN to learn;
• a data source — a file in your organization’s file space, or a time series to export;
• a schedule, if the model has to be retrained periodically; and
• an execution timeout for the training job.

The Trainers API checks the plan exists, stores a small Kubernetes secret with your API key and organization so the job can call the platform back on your behalf, and hands the work to the scheduler.

2. The scheduler runs it

The scheduler is a general-purpose service: it runs REST requests, container images and pipelines of both on a cron expression or an interval, and keeps a history of every execution. A trainer becomes one of two things there, both named after the model:

Inside the job your organization’s file space is mounted at /data, which is why every path the plan sees starts there. The job also receives the plan’s configuration as environment variables, the platform-wide AI settings from a shared secret, and a callbackUri it must call when it finishes. The training job is a Kubernetes Job with no retries: it either completes, fails, or is killed when the timeout expires.

3. The job trains, versions and publishes

Every plan image runs the same three commands, provided by the training template framework:

1. Generate the run profile — experiment <organization>-<model>, registered model <organization>-<model>-<algorithm>, data location from dataSourcePath.
2. Run the recipe — ingest, split, transform, train, evaluate, register. Each run is tracked in the platform’s MLflow, which is where model versions come from: the first successful training registers version 1, a retraining registers version 2, and so on. If the data does not meet the plan’s minimum, the run fails here and says so.
3. Publish the inference — download the latest run’s model and metrics, wrap them in the framework’s FastAPI inference server, build a container image named <organization>-<model>:v<version> and push it to the platform registry. Then, through the Inferencers API:
   • if an inferencer named after the model does not exist yet, create it with that image as its only version — and, unless the trainer was created with createRule: false, first create the plan’s rule in default_channel and link it to the inferencer;
   • if it already exists, add the image as a new version.

Whatever happens, the job reports back to the scheduler with OK, ERROR or — if it was killed by the timeout — TIMEOUT, and a description. That report is what you see as the execution’s history.

4. You activate a version

A freshly created inferencer has one version and nothing deployed. Activation is your call (PUT .../inferencer/{inferencerId}/activation?image=<version>&active=true), because it is the moment the platform starts spending resources on your behalf:

• the Inferencers API deploys the image as a service reachable inside the platform at https://<organization>-<model>:8443/api/predict — lowercase, underscores turned into hyphens;
• it waits for the container to be running;
• it sets the linked rules to active: true.

You can activate a specific version, or latest: then every new version a retraining produces replaces the running one automatically, and the rule keeps calling the same address. Deactivating (active=false) undeploys the service and deactivates the rules; the versions stay, ready to be activated again.

5. The rule scores every reading

The rule a plan creates is an ordinary ADVANCED rule: it triggers on the datastream the plan cares about, builds the request the model expects, calls the inferencer with http.client, and translates the answer into your data model — typically a boolean datastream saying whether the reading was anomalous, a score, an explanation, and an alarm that opens when the entity turns anomalous and closes when it returns to normal. The rule is created inactive and is switched on and off together with the inferencer, so a deactivated model never leaves a rule calling a service that is not there.

The rule is yours: you can read it, tune its thresholds or change what it collects in the rules editor like any other. Deleting the inferencer deletes its rules too, unless another inferencer still uses them.

Naming, in one table

Once you know the organization name and the model name, you can predict every other name the feature creates:

Retraining

A trainer with a schedule.expression runs every time the expression fires, and each run adds a new version to the same inferencer. The scheduler understands standard five-field cron and the extended form with a leading seconds field and a trailing year field; the web console writes seven-field expressions such as 0 0 0 15 */3 ? * — midnight on the 15th, every third month. If the expression pins a single instant (every field numeric, year included), the trainer is a one-off and the API reports hasRetraining: false.

A trainer created without a schedule runs once, about a minute after it is created.

An inferencer keeps a bounded number of versions (five by default). When a new one arrives over the limit, the oldest inactive version is dropped; the active one is never removed by a retraining.

Callbacks and history

Because trainings take minutes to hours, nothing in this loop blocks. The scheduler records every execution in its history (GET /scheduler/organization/{organizationId}/history), with a state — IN_PROGRESS until the callback arrives, FINISHED when it does, FINISHED OUT OF TIME if it arrived after the wait expired — and one entry per step with its result and description. For a time-series trainer that is two steps: the export and the training. The web console’s See history action is a view of exactly this.

What you need

• A user with the root or super_admin_domain profile: the five AI services accept no other.
• Authentication is the usual X-ApiKey header, or Authorization: Bearer <JWT>.
• The AI services are exposed on the same host as the rest of the OpenGate API, under the prefixes /ai (training plans, trainers, inferencers), /scheduler and /fileConnector.

What a training plan is

A training plan is a packaged answer to one question — is this RADIUS session unusual for its APN?, is this part defective? — built and validated by the platform team and published in a catalogue. It bundles:

• the algorithm and the whole training recipe: how the data is cleaned, split, transformed, trained and evaluated;
• the container image that runs that recipe;
• the data it needs: which source types it accepts (a file, a time series, or either) and, for time series, the columns it expects to find;
• the configuration you must supply when you create a trainer — an APN, for example;
• the minimum amount of data below which a training is refused rather than producing a meaningless model;
• and, implicitly, the inference contract of the model it produces and the rule it creates to call it.

You do not modify a plan. You create a trainer that runs it, and the plan’s own pages below tell you what to feed it and what comes out.

Listing the catalogue

curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     https://api.opengate.es/ai/trainingPlans

The catalogue is platform-wide, not per organization, and read-only through the API. Each entry:

{
  "identifier": "6f1c2a4e-…",
  "name": "RADIUS anomalies per APN (Isolation Forest)",
  "description": "Detects anomalous data sessions of the subscriptions of one APN",
  "modelType": "anomaly",
  "modelFormat": "isolation-forest",
  "source": ["file", "timeserie"],
  "configFields": ["apn"],
  "columnData": [
    { "name": "APN", "type": "STRING", "description": "Access point name of the session" },
    { "name": "sbytes", "type": "LONG", "description": "Bytes sent by the device" }
  ],
  "minDataToTrain": { "value": 15000, "unit": "ITEMS" },
  "image": { "name": "trainingplan-if-radius-anomalies-per-apn", "tag": "1.0.0" }
}

The plans available

• RADIUS session anomalies — Isolation Forest

  Learns what a normal data session looks like on one APN and flags the sessions that do not fit: the data it needs, how it trains, the prediction request and answer, and the rule and alarm it creates.

• RADIUS session anomalies — Autoencoder

  The same RADIUS-per-APN problem solved with a neural network that learns to reconstruct normal sessions and flags the ones it reconstructs badly: data, training, prediction contract and the rule it creates.

• Image anomaly detection

  Tells defective items from correct ones in photographs and draws a heat map of the defect: the folders of images it trains on, the two models it combines, the prediction request over the organization's file space, and the rule and alarm it creates.

The three plans share the same lifecycle, described in How it works: what differs between them is the data they take, the request their inferencer answers, and the rule they create.

API specification

What a trainer is

A trainer is the instruction run this training plan, on this data, with this configuration, now and maybe again later. Creating one is the only step a person takes to obtain a model: everything after the 201 — the export, the training job, the model version, the inference image, the inferencer and its rule — happens on its own and is described in How it works.

Creating a trainer

curl --request POST \
     --header "X-ApiKey: <your-api-key>" \
     --header "Content-Type: application/json" \
     --data @trainer.json \
     https://api.opengate.es/ai/organization/acme/trainer

A trainer that learns the sessions of one APN from a time series and retrains every quarter:

{
  "name": "radius-orange-trainer",
  "description": "Anomalous sessions on the corporate APN",
  "imageExecution": {
    "model": { "name": "radius-orange" },
    "trainingPlan": { "identifier": "6f1c2a4e-…" },
    "configuration": { "apn": "corporate.example.apn" },
    "timeout": 1800
  },
  "source": {
    "timeserie": {
      "id": "683fee1f2b447a7318586445",
      "filter": { "gte": { "at": "2026-06-01T00:00:00Z" } },
      "columns": [
        { "column": "apn",           "output": { "name": "APN" } },
        { "column": "state",         "output": { "name": "SessionState" } },
        { "column": "ggsnIp",        "output": { "name": "IP_GGSN" } },
        { "column": "deviceIp",      "output": { "name": "IP_Device" } },
        { "column": "sentBytes",     "output": { "name": "sbytes", "parquet": { "type": "LONG" } } },
        { "column": "receivedBytes", "output": { "name": "dbytes", "parquet": { "type": "LONG" } } },
        { "column": "sentPackets",   "output": { "name": "spkts",  "parquet": { "type": "LONG" } } },
        { "column": "receivedPackets", "output": { "name": "dpkts", "parquet": { "type": "LONG" } } },
        { "column": "duration",      "output": { "name": "dur",    "parquet": { "type": "LONG" } } }
      ],
      "timeout": 6000
    }
  },
  "schedule": {
    "expression": "0 0 0 15 */3 ? *",
    "isImmediateExecution": true
  },
  "createRule": true
}

The response is 201 Created with a Location header holding the trainer’s identifier.

Field by field

Read-only fields come back on GET: identifier, orgName, hasRetraining and schedule.schedulerId — the identifier of the entry the scheduler created, which is also the model name.

Data sources

A file in your file space

"source": { "path": "radius/sessions-2026-q2.parquet" }

path is relative to the root of your organization’s file space, where you upload it beforehand. Inside the job the file space is mounted at /data, so the plan reads /data/radius/sessions-2026-q2.parquet. A path may also be a folder, which is what the image plan expects.

A file source schedules a single image execution in the scheduler.

A time series

"source": {
  "timeserie": {
    "id": "<time series identifier>",
    "filter": { "…": "…" },
    "columns": [ { "column": "<yours>", "output": { "name": "<the plan's>", "parquet": { "type": "LONG" } } } ],
    "timeout": 6000
  }
}

A time-series source schedules a pipeline: first the platform’s own Parquet export of that time series, writing <model>-<plan>-<time series>.parquet into your file space, then the training image with dataSourcePath pointing at it. Each retraining exports again, so the model always learns from current data.

Schedules

"schedule": { "expression": "0 0 0 15 */3 ? *", "isImmediateExecution": true }

• expression — a cron expression. Standard five fields work; the scheduler also accepts a leading seconds field and a trailing year field, and ? in the day fields. 0 0 0 15 */3 ? * is 00:00:00 on the 15th of every third month. Time zone is UTC.
• isImmediateExecution — also run now, without waiting for the first tick. The console sets it, so a new trainer always produces a first version straight away.

No schedule at all means a single execution about one minute after creation, and hasRetraining: false. An expression that pins one instant — every field numeric, including the year — is treated the same way.

What the platform does with your request

Knowing this helps when something does not appear where you expect it.

1. Rejects the request if another trainer in the organization has the same name or the same model name, or if the plan is not in the catalogue.
2. Creates a Kubernetes secret named <organization>-<trainer name>-env-secret holding your API key and the organization name. The training job uses it to register the inferencer, create the rule and report back — everything the job does, it does as you.
3. Asks the scheduler for an image execution (file source) or a pipeline (time-series source) named after the model, running the plan’s image with these environment variables: your configuration entries, modelName, createRule, minDataToTrain from the plan, and dataSourcePath; plus the secret above and the platform’s shared AI settings. The scheduler waits for the job’s callback for timeout + 5 seconds.
4. Stores the trainer and answers 201.

The trainer record is a schedule, not a status: to know whether a training ran and how it went, read the scheduler’s history for schedulerId = model name, or open See history in the console.

Listing trainers

curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     https://api.opengate.es/ai/organization/acme/trainer

Returns every trainer of the organization, with the read-only fields filled in. An organization with no trainers gets an empty list, not an error.

Removing a trainer

curl --request DELETE \
     --header "X-ApiKey: <your-api-key>" \
     https://api.opengate.es/ai/organization/acme/trainer/<trainerId>

Removes the schedule from the scheduler, the credentials secret and the trainer record, and answers 204. A training that is running is not interrupted — cancel it through the scheduler if you need to. The inferencer, its model versions and its rule are not touched: they are separate resources, removed through the Inferencers API. Deleting the trainer only means no further version will be trained.

Errors

Errors follow the platform’s usual shape, a list of code, message and context:

API specification

What an inferencer is

An inferencer is a trained model as a running service. It has a name, a list of images — one per model version, each a container the platform can deploy — at most one active image, an endpoint where rules call it, a request schema describing what to send, and the rules that call it.

Trainers create inferencers: the first successful training of a model creates one named after the model, later trainings add versions to it. You will rarely create one by hand, but you will use this API for what the trainer does not decide for you — which version runs, and whether it runs at all.

Reading an inferencer

curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     "https://api.opengate.es/ai/organization/acme/inferencer?name=radius-orange"

[
  {
    "identifier": "b1c4…",
    "orgName": "acme",
    "name": "radius-orange",
    "images": [
      {
        "id": "9e2a…",
        "url": "<registry>/acme-radius-orange:v1",
        "creationDate": "2026-07-02T03:00:41.120Z",
        "metrics": { "calculated_threshold": 0.575, "training_max_score": 0.722 }
      },
      {
        "id": "4c7f…",
        "url": "<registry>/acme-radius-orange:v2",
        "creationDate": "2026-08-15T00:01:12.004Z",
        "metrics": { "calculated_threshold": 0.581, "training_max_score": 0.731 }
      }
    ],
    "active": "latest",
    "activeName": "4c7f…",
    "port": 8443,
    "endpoint": "https://acme-radius-orange:8443/api/predict",
    "requestSchema": { "…": "…" },
    "rules": [ { "id": "a0d3…", "channel": "default_channel" } ]
  }
]

The list accepts two filters: ?name=<inferencer name> and ?image=<image url>.

Activating a version

A new inferencer is not deployed. Nothing runs, and its rules stay inactive, until you activate a version:

curl --request PUT \
     --header "X-ApiKey: <your-api-key>" \
     "https://api.opengate.es/ai/organization/acme/inferencer/b1c4…/activation?image=latest&active=true"

What activation does, in order: deploys the image as a service named <organization>-<name> listening on 8443 with TLS, waits until its container is running — an image that cannot be pulled fails here with 404 — and then sets every linked rule to active: true. It answers 204.

Only one version can be active. Activating a second one while another is running is refused with 400; deactivate first:

curl --request PUT \
     --header "X-ApiKey: <your-api-key>" \
     "https://api.opengate.es/ai/organization/acme/inferencer/b1c4…/activation?active=false"

Deactivation reverses the steps: rules to active: false, then the service is undeployed. The versions remain.

Versions

Trainers add versions; you can also add one yourself:

curl --request POST \
     --header "X-ApiKey: <your-api-key>" \
     --header "Content-Type: application/json" \
     --data '{ "url": "<registry>/acme-radius-orange:v3", "metrics": { "calculated_threshold": 0.59 } }' \
     https://api.opengate.es/ai/organization/acme/inferencer/b1c4…/images

Rules that keep the version list honest:

• An image url ending in :latest is refused — a version must be a fixed tag, or active: latest would mean nothing.
• The same url cannot be added twice.
• An inferencer keeps a bounded number of versions, five by default. Adding one beyond the limit drops the oldest inactive version; the active one is never dropped. With a limit of one and the only version active, the addition is refused.
• With active: latest, adding a version redeploys the service on the new image straight away. If the new image fails to start, it is removed again and the previous version is put back.
• A version cannot be removed while it is active, and the last remaining version cannot be removed at all. With active: latest, removing the newest version redeploys the one before it.

Rules

rules lists the rules that the inferencer switches on and off. A trainer fills it with the rule the plan creates; you can point it at your own instead:

curl --request PUT \
     --header "X-ApiKey: <your-api-key>" \
     --header "Content-Type: application/json" \
     --data '{ "rules": [ { "id": "<rule id>", "channel": "default_channel" } ] }' \
     https://api.opengate.es/ai/organization/acme/inferencer/b1c4…

Every rule is checked to exist; an unknown id is a 400. The same PUT changes resourcePath — which also rewrites endpoint — and requestSchema. At least one of the three must be present.

Calling an inferencer from a rule

The rules a plan creates are the model to follow. The essential part, in the ADVANCED rules JavaScript API:

http.client.uri = parameterObject['inferenceServiceURL'];   // https://acme-radius-orange:8443/api/predict
http.client.trustedAll = true;                              // the service uses the platform's internal certificate
http.client.headers = { 'content-type': 'application/json', 'accept': 'application/json' };
http.client.body = {
    sbytes: session.sentBytes, dbytes: session.receivedBytes,
    spkts: session.sentPackets, dpkts: session.receivedPackets,
    dur: session.duration
};
var response = http.client.post();
if (response.body.prediction === 1) {
    alarm.open({ alarmName: 'deviceWithAnomaly', ruleName: ruleName, severity: 'URGENT', priority: 'MEDIUM',
                 description: 'Detected anomaly with inferencer service' });
}

Keep the endpoint in a rule parameter rather than in the script, as the generated rules do: the address is stable for the life of the inferencer, but a parameter is what you would change if you ever pointed the rule at a different model. Besides /api/predict, every inferencer built by the platform framework also serves GET /api/metrics, returning the metrics of the running version, and GET /health.

Deleting an inferencer

curl --request DELETE \
     --header "X-ApiKey: <your-api-key>" \
     https://api.opengate.es/ai/organization/acme/inferencer/b1c4…

If a version is active it is deactivated first — rules off, service undeployed. Then the inferencer is removed, and so are its rules, except any rule another inferencer of the organization still lists. The model versions in MLflow and the images in the registry are not deleted. The trainer that created the inferencer is not affected: its next scheduled run creates the inferencer again, rule included.

Creating an inferencer by hand

Trainers do this for you. If you need to register a model that was not trained on the platform:

{
  "name": "my-model",
  "resourcePath": "/api/predict",
  "requestSchema": { "type": "object", "properties": { "x": { "type": "number" } }, "required": ["x"] },
  "images": [ { "url": "<registry>/acme-my-model:v1", "metrics": { "f1": 0.93 } } ],
  "rules": [ { "id": "<rule id>", "channel": "default_channel" } ]
}

Exactly one image at creation, not tagged latest; rules is optional. The image must be pullable by the platform and serve HTTPS on the port the platform expects — the framework’s inference server does, which is why Building training plans is the practical route for a custom model rather than a bare container.

API specification

What the scheduler does

The scheduler runs things later, and again. Three kinds of things:

Every schedulation belongs to an organization, has an identifier you choose, a schedule and a history of executions. Trainers are its main customer today, but the console’s Schedulers screen and the dashboard scheduler widgets let you use it directly.

The schedule

Every schedulation carries the same schedule object, in one of two forms:

"schedule": {
  "cron": { "expression": "0 0 2 * * * *", "timeZone": "Europe/Madrid" },
  "executeNow": false,
  "from": "2026-09-01T00:00:00Z",
  "to": "2026-12-31T23:59:59Z"
}

"schedule": {
  "interval": { "minutes": 15 },
  "executeNow": true
}

If an execution is still running when the next one is due, the next one is skipped and logged, not queued. An invalid time zone or expression is rejected on creation with 400 and the offending field named in the error.

REST requests

{
  "identifier": "export-sessions-nightly",
  "schedule": { "cron": { "expression": "0 0 1 * * * *" } },
  "restRequest": {
    "url": "https://api.opengate.es/north/v80/timeseries/provision/organizations/acme/683fee…/export",
    "method": "POST",
    "header": { "X-ApiKey": "<your-api-key>", "Content-Type": "application/json" },
    "body": { "outputFile": { "name": "sessions.parquet" }, "select": [ "…" ] }
  },
  "response": { "async": { "maxTimeToWaitCallback": 600 } }
}

response says how the scheduler knows the request is done:

Image executions

{
  "identifier": "nightly-aggregation",
  "schedule": { "cron": { "expression": "0 0 3 * * * *", "timeZone": "UTC" } },
  "imageExecution": {
    "name": "acme-aggregator",
    "tag": "1.4.0",
    "env": { "organizationId": "acme", "window": "24h" },
    "envFrom": [ { "secret": "acme-aggregator-secrets" } ],
    "timeout": 900
  },
  "maxTimeToWaitCallback": 1200
}

The container runs as a Kubernetes Job with no retries, with the organization’s file space mounted at /data, and with one extra environment variable the scheduler adds itself: callbackUri, the URL the container must POST to when it finishes. An image that cannot be pulled, or a container that exits with an error before reporting, fails the execution with that reason in the history.

Pipelines

{
  "identifier": "export-then-train",
  "schedule": { "interval": { "minutes": 1440 }, "executeNow": true },
  "pipeline": [
    {
      "identifier": "timeserieSource",
      "restRequest": { "url": "…/export", "method": "POST", "header": { "…": "…" }, "body": { "…": "…" } },
      "response": { "async": { "maxTimeToWaitCallback": 6005 } }
    },
    {
      "identifier": "launchTrainer",
      "imageExecution": { "name": "trainingplan-if-radius-anomalies-per-apn", "tag": "1.0.0", "env": { "…": "…" }, "timeout": 1800 },
      "maxTimeToWaitCallback": 1805
    }
  ]
}

A pipeline is a list of at least two steps, each a REST request or an image execution with a step identifier unique in the pipeline. Steps run in order: a synchronous REST step hands over as soon as its response arrives; an asynchronous REST step and an image step hand over when their callback arrives at …/pipeline/{pipelineId}/execution/{executionId}/{stepId}. A step that fails stops the pipeline; the history records the failing step and its description, and the remaining steps are not run.

The example above is, field for field, what the Trainers API creates for a time-series trainer.

Callbacks

Asynchronous work reports back with a POST to the callback URL — the one in the callback header for a REST request, in callbackUri for a container — carrying:

{ "result": "OK", "description": "Model version 3 published", "startedDate": "…", "finishedDate": "…" }

result is free text by contract; the platform’s own jobs use OK, ERROR and TIMEOUT. The callback is authenticated like any other call to the scheduler. It answers 204.

A callback that arrives after maxTimeToWaitCallback is not lost: the execution, already marked as finished without a callback, moves to FINISHED OUT OF TIME and records the late result.

Execution history

curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     "https://api.opengate.es/scheduler/organization/acme/history?schedulerType=PIPELINE&schedulerId=radius-orange&limit=20"

[
  {
    "id": "6d6081ee-…",
    "schedulerId": "radius-orange",
    "organization": "acme",
    "type": "PIPELINE",
    "state": "FINISHED",
    "startedDate": "2026-08-15T00:00:01.120Z",
    "finishedDate": "2026-08-15T00:41:37.004Z",
    "steps": [
      { "stepId": "timeserieSource", "result": "OK", "description": "Timeserie exported.",
        "startedDate": "2026-08-15T00:00:01.120Z", "finishedDate": "2026-08-15T00:03:12.271Z" },
      { "stepId": "launchTrainer", "result": "OK",
        "startedDate": "2026-08-15T00:03:12.300Z", "finishedDate": "2026-08-15T00:41:37.004Z" }
    ],
    "content": { "…": "the schedulation as it was executed" }
  }
]

state is IN_PROGRESS while a callback is awaited, FINISHED when the execution completed — look at each step’s result to know how — and FINISHED OUT OF TIME when the callback arrived after the wait had expired. An execution stopped by hand shows a step with result CANCELLED.

Cancelling a running execution

curl --request DELETE \
     --header "X-ApiKey: <your-api-key>" \
     https://api.opengate.es/scheduler/organization/acme/pipeline/radius-orange/execution/6d6081ee-…/launchTrainer

Deletes the Kubernetes Job behind an image execution — or the image step of a pipeline — waits until it is gone, and records the step as CANCELLED in the history. The schedulation itself is untouched and fires again at the next tick; to stop that, DELETE the schedulation.

In the web console

Everything on this page has a dashboard widget: the Image Execution, Rest Request and Pipeline scheduler browsers, their wizards, and the Schedulers History list. The Artificial Intelligence section of the console has its own, simpler Schedulers screen — see The web console.

API specification

What it is

Every organization has a file space on the platform: a directory tree of its own that the file connector manages over HTTP, and that the AI services see as a mounted volume. It is where a trainer’s input file lives, where the time series export writes its Parquet file, where the image plan reads its photographs and writes its heat maps. Nothing outside the organization can reach it.

All paths are relative to the organization’s root. Wildcards are not supported. Authentication is the X-ApiKey header.

Uploading

curl --request POST \
     --header "X-ApiKey: <your-api-key>" \
     --form 'meta={"destinyPath": "radius", "overwriteFiles": true};type=application/json' \
     --form "file=@sessions-2026-q2.parquet" \
     https://api.opengate.es/fileConnector/organizations/acme/upload

A multipart request with two parts:

Archives are unpacked, not stored. A .zip, .tar, .tar.gz or .tar.bz2 — recognised by its MIME type — is extracted into destinyPath, which is how the image plan’s correct/ and incorrect/ folders are uploaded in one request. Any other file is stored as it is.

204 means everything was written. 200 with an error list means a partial upload: overwriteFiles was false and some files already existed; the list names them.

Listing

curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     "https://api.opengate.es/fileConnector/organizations/acme/list?path=radius"

[
  { "name": ".", "isDir": true, "size": 4096, "modificationTime": "2026-09-01T10:12:00Z", "mode": "drwxr-xr-x" },
  { "name": "sessions-2026-q2.parquet", "isDir": false, "size": 48219833, "modificationTime": "2026-09-01T10:12:00Z", "mode": "-rw-r--r--" }
]

For a directory, the first entry named . is the directory itself, followed by its children. For a file, just that file. A path that matches nothing is a 400.

Downloading

curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     --output part-0412_heatmap.jpg \
     "https://api.opengate.es/fileConnector/organizations/acme/download?path=line-3/2026-09-03/part-0412_heatmap.jpg"

Returns the file’s bytes. This is how you retrieve a heat map the image plan wrote next to a photograph.

Deleting

curl --request POST \
     --header "X-ApiKey: <your-api-key>" \
     --header "Content-Type: application/json" \
     --data '{ "destinyPath": "radius", "fileName": "sessions-2026-q2.parquet" }' \
     https://api.opengate.es/fileConnector/organizations/acme/delete

With fileName, deletes that file inside destinyPath. With fileName omitted or null, deletes the whole destinyPath directory. 204 on success, 404 if there was nothing to delete.

How the AI services see it

So the console’s file browser in the trainer wizard, the list endpoint and the paths a rule sends to an inferencer all name the same files.

API specification

Where it is

The Artificial Intelligence section of the web console is the front end of everything in this chapter. It signs its requests with your console session, so you see the organization you are logged into and nothing else, and every action it offers is one of the API calls documented on the previous pages. Its menu has two screens: AI capabilities and Schedulers.

AI capabilities

The screen lists the trainers of your organization, one row per model:

Each row has three actions:

• Configure inferencer — opens the inferencer’s versions. Pick a version from the list to see the metrics its training recorded, and use the Enabled switch to deploy it or take it down. Saving with a different version selected deactivates the running one and activates the new one. This is the console’s face of the activation call. Greyed out until the first training has created the inferencer.
• See history — the executions of this trainer from the scheduler’s history, one line per step with result, description, start and end. A time-series trainer shows two steps per run: the export and the training. A failed training says why here — Not enough data for APN, a timeout, an image that could not be built.
• Delete — removes the trainer and its schedule. As with the API, the inferencer and its versions stay; remove them from Configure inferencer or through the Inferencers API.

Reload data refreshes the table; Create new AI trainer opens the wizard.

Creating a trainer

The wizard has four steps and ends with the POST described in Trainers.

1. Selection of training plan

The catalogue, grouped by type — anomaly holds the two RADIUS plans, classification the image plan. Each plan shows its description; read Training plans before choosing, because a plan is specific about the data it wants.

2. Configure training data

• The plan’s configuration fields, one input per entry in its configFields — the APN for the RADIUS plans.
• The source type: File or Timeserie. Only the types the plan accepts are enabled; the image plan is file-only.
• With File: a browser of your organization’s file space. Navigate folders, upload a file or an archive into the current one, download or delete files, and select the file — or stay in a folder to select the folder itself, which is what the image plan needs.
• With Timeserie: pick one of the organization’s time series, set the export timeout in seconds (the default is generous; a large series can take a while to export), and map every column the plan expects onto a column of the time series. The identifier column of the series is offered first.

3. Trainer configuration

Whatever you choose, the wizard asks for an immediate first execution, so a first version is trained as soon as the trainer is created.

4. Summary

Everything you selected, then Create. The trainer appears in the table at once; the first version appears when the training finishes, and See history follows its progress.

Schedulers

A compact view of the organization’s schedulations — REST requests, image executions and pipelines together — with identifier, type, cron pattern, last and next execution, and a Delete action. New scheduler opens a wizard for a REST request or an image execution. Trainers appear here too, as the pipeline or image execution named after their model: deleting one from this screen stops the trainer’s retraining as surely as deleting the trainer, but leaves the trainer record behind — prefer the Delete action on the AI capabilities screen.

For the full-featured scheduler widgets — cloning, per-schedulation history, pipeline editing — use the dashboard scheduler browsers.

The framework

Every training plan is a Python project built on the training template framework, the platform’s fork of MLflow Recipes. The framework provides:

• the recipe engine — the ingest → split → transform → train → evaluate → register pipeline, with anomaly detection recipes (anomaly/v1@isolation_forest, anomaly/v1@autoencoder) and a classification recipe (classification/v1) on top of MLflow’s regression and classification ones;
• a generic inference server — a FastAPI application that loads whatever model the plan produced and serves POST /api/predict, GET /api/metrics and GET /health over TLS;
• the training-template CLI that runs the recipe, publishes the inference image and registers the result with the platform;
• the conventions that let the Trainers API, the scheduler and the Inferencers API treat every plan alike.

A plan is therefore mostly declarative: a recipe.yaml, a handful of Python functions, and templates.

Layout of a plan repository

trainingplan-<name>/
├── recipe.yaml                      # the recipe: algorithm, steps, thresholds, metrics
├── model_schema.txt                 # JSON schema of a prediction request → inferencer.requestSchema
├── steps/
│   ├── ingest.py                    # load_file_as_cleaned_dataframe(path): read and clean the data
│   ├── split.py                     # create_dataset_filter(df): rows to keep after the split
│   ├── transform.py                 # transformer_fn(): the scikit-learn transformer to fit
│   ├── train.py                     # estimator_fn(params): the unfitted estimator
│   └── custom_metrics.py            # metrics referenced from recipe.yaml
├── configurations/
│   ├── entrypoint.sh                # the three CLI commands the container runs
│   ├── config.json                  # how the inference server loads the model
│   ├── predict_service.py           # the prediction service class
│   ├── schemas.py                   # pydantic RequestBody / ResponseBody
│   ├── mapper.py                    # map_to_response_body(dict) → ResponseBody
│   ├── requirements.txt             # runtime dependencies of the inference image
│   └── cli_config/rule_generator.py # generate_rule_creation_body() → the rule to create
└── cli_templates/
    ├── inference-docker-template.txt          # Dockerfile of the inference image
    ├── rule_create_body.txt                   # template the rule generator fills in
    └── additional_trainer_dependencies.txt    # extra RUN lines for the trainer image

The recipe

recipe: "anomaly/v1@isolation_forest"
threshold: 0.95                         # percentile of training scores that becomes the decision threshold
steps:
  ingest: {{INGEST_CONFIG}}             # filled in at run time from dataSourcePath
  split:
    split_ratios: [0.75, 0.125, 0.125]
    post_split_filter_method: create_dataset_filter
  transform:
    using: custom
    transformer_method: transformer_fn
  train:
    using: custom
    estimator_method: estimator_fn
    model_type: isolation-forest
  register:
    allow_non_validated_model: True

recipe selects the engine: anomaly/v1@isolation_forest, anomaly/v1@autoencoder or classification/v1. Each step names the function in steps/ that customises it; estimator_params under train is passed to estimator_fn. evaluate.validation_criteria and primary_metric decide whether a model is validated; register.allow_non_validated_model: True registers it regardless, which is what the current plans do. Custom metrics are declared under custom_metrics and implemented in steps/custom_metrics.py.

The {{INGEST_CONFIG}} placeholder is rendered when the container starts: the framework writes a run profile pointing the ingest step at steps/ingest.py::load_file_as_cleaned_dataframe with the location in dataSourcePath. That function is where a plan cleans its data and enforces minDataToTrain, failing the run with a clear message when there is not enough.

The inference service

After training, the framework copies its FastAPI server, the model artefacts and the plan’s configurations/ into a dist/ folder and builds an image from cli_templates/inference-docker-template.txt. At start-up the server reads configurations/config.json:

{
  "service_class_name": "AnomalyPredictionService",
  "service_file_name": "predict_service.py",
  "model_path": "model/model.pkl",
  "transformers_path": "transformer.pkl"
}

and loads the class from predict_service.py. The framework adds two keys after training — threshold, the calculated decision threshold, and training_max_score — so the running service knows the numbers its version was trained with. The class contract:

class AnomalyPredictionService:
    def __init__(self, model, threshold, transformer=None, max_score=None): ...
    @staticmethod
    def load_model(model_path: str): ...          # joblib, Keras, torch — the plan decides
    def predict(self, data: dict) -> dict: ...    # one request in, one result out

schemas.py declares the request and response as pydantic models — the request is what model_schema.txt describes in JSON schema, and what the inferencer publishes as requestSchema — and mapper.py turns the service’s result into the response. Requests that fail the schema get 422.

The rule template

configurations/cli_config/rule_generator.py must expose generate_rule_creation_body() returning the JSON of a rule creation request. The existing plans render cli_templates/rule_create_body.txt with the model name, the inferencer’s service name and port, and plan configuration such as the APN. The rule is created inactive, in default_channel, named after the model, and only when no rule of that name exists there already. Keep the inferencer endpoint in a rule parameter, as the templates do.

What a trainer job looks like from inside

The container’s entrypoint.sh runs three commands and forwards SIGTERM to whichever is running, so a job killed by its timeout still reports TIMEOUT:

training-template generate-local-yaml --model-type isolation-forest
training-template run --profile local
training-template publish-inference isolation-forest

The environment the job receives:

Packaging a plan

1. Build the base trainer image — the framework plus the plan’s extra dependencies from cli_templates/additional_trainer_dependencies.txt (TensorFlow for the autoencoder, PyTorch for the image plan):

   training-template build-base-trainer --image-name <registry>/base-trainer-<type> --tag <tag>

2. Generate the trainer Dockerfile, from the plan’s directory, and build it from the parent directory:

   training-template generate-trainer-dockerfile --image-name <registry>/base-trainer-<type> --tag <tag>
   cd .. && docker build -t <registry>/trainingplan-<name>:<version> -f trainingplan-<name>/generated/Dockerfile .
   docker push <registry>/trainingplan-<name>:<version>

   The generated Dockerfile copies steps/, configurations/, recipe.yaml, model_schema.txt and cli_templates/ and sets configurations/entrypoint.sh as the entry point.

3. Register the plan in the catalogue with its image.name and image.tag, configFields, columnData, minDataToTrain, and the source types it supports. The catalogue is the platform’s own collection; the Training Plans API reads it, it does not write it.

To try a plan without the platform, set the variables of the table above in a shell, run the three entrypoint commands by hand with a local MLflow, and start the built inference server with training-template run-sbox-inference. A generate-mock-trainer command produces an image that skips the training and only exercises the callbacks, the Inferencers API and the rule creation — the way the end-to-end tests check the loop without waiting for a real training.

The AI platform itself

The services this chapter documents — the Training Plans, Trainers and Inferencers APIs, the AI console, the MLflow tracking server and the shared AI secret — are versioned and deployed together by the platform team, alongside the scheduler and the file connector that belong to the core platform. Each API generates its server from the OpenAPI specification shown at the bottom of its page, so the specification is the contract, not a description of it.