Skip to content

What Artekis does

Artekis runs playbooks. A playbook is a small JSON resource in one of your Perspective projects that names a template, the collections it covers (a collection is a plant area with its own context model, section 7), when it runs, and where its findings go. Five templates ship in 1.2:

Template What it answers Runs Model role
alarm-health@1 Which alarms are nuisance, stale, duplicated, mis-prioritised or flooding, and what configuration change fixes each: with the ISA-18.2 KPIs behind it on a schedule (weekly is typical) or on demand analyst
gateway-health@1 What regressed on the gateway in the last 24 hours: log bursts, failing scripts, Store and Forward backlog, connections, devices, bad-quality tags daily, in the reserved collection gateway writer
incident@1 What most likely caused this alarm or line stop, from the 30 minutes before it (configurable) when an alarm goes active (Event Stream) or a script reports a line down analyst
ask@1 A plant engineer's question about a collection, answered from live gateway data with citations when someone asks, from the Ask panel or a script writer
anomaly-watch@1 Which process measurements behave unlike their own history for the machine's current state (drift, out of band, stuck, fast swings, flapping quality), whether the historian's data is healthy, and (once a person confirms an anomaly) what alarm would have caught it hourly or daily, over the last 24 hours writer

Each run gathers evidence on the gateway with deterministic analyzers, offers the model a fixed list of candidates (the analyzers decide what a finding can be about), validates the model's answer rule by rule, stores the surviving findings with their evidence, and announces them: a Perspective session message, an HTML email digest, MQTT, tags, or a project-library callback (section 9). Findings are deduplicated across runs, resolve themselves when the analyzers stop producing them, and carry your engineers' verdicts (confirm, known issue, dismiss, wrong).

What Artekis never does. It never writes to a device, OPC item, setpoint, expression tag or alarm; never acknowledges or shelves an alarm; never applies a configuration change: a finding's proposed change is a recommendation you apply under your own change control. It never creates or alters database tables (your DBA applies the DDL). It never sends data to a model provider except inside a run you configured, through a key you supplied, and every such call is recorded. It is not an MCP server, holds no cloud component, and trains nothing.