AIOps

AIOps takes the events the alert center has already grouped, and produces a root-cause analysis with the diagnostic steps a human should run next.

Three rules this module is built on

1. The model is a brain, not a hand. At this stage AI analyses and recommends. It runs read-only diagnostics and it does not change device configuration. A human executes.
2. Diagnostics are read-only, and enforced. Runbook commands are validated line by line on save; only show / display / ping -class commands are accepted.
3. Nothing leaves the network unmasked. Device data is masked before any external call, and the check is fail-closed: if masking cannot be verified, nothing is sent. A local endpoint keeps the data inside your network entirely.

AI tickets

The module is titled AI Remediation, with AI Tickets, Alerts, Logs, Audit and Knowledge base down the left.

An event becomes an AI ticket: time, severity, status, host, incident, alert count, confidence, and the AI root cause. The counters across the top are Active, Pending close, Closed, AI adoption and AI cost — the cost counter reads $0.00 while you are on a local endpoint or the built-in heuristic engine, which is where a new install starts.

Filter with Active / Awaiting takeover / Pending close / Closed / All.

Inside a ticket you get the proposed root cause, the diagnostic steps, the related configuration section it reasoned about, and the full configuration if you want the context.

Auto-diagnose is a checkbox, off by default: nothing runs against your devices until you turn it on. Emergency stop halts automatic diagnosis fleet-wide, and is deliberately the most prominent control on the page.

Engines

LLM settings selects the analysis engine:

• Local endpoints — one per line, as address model-name. They are tried in order and the first available one wins, so a second entry is a failover. Data sent to a local endpoint never leaves your network.
• Hosted models (Claude, OpenAI) need an API key. Keys are stored encrypted and never echoed back.

Knowledge base

Two things make the analysis better over time, and both are local:

Runbooks are the diagnostic command set for each alert type, per vendor. Placeholders {peer}, {ifname}, {vrf} and {hostname} are filled from the alert's object at execution time, and a step whose parameters cannot be resolved is skipped rather than run wrong. For commands with a VRF form, write global command || vrf-form command and vConfig picks the second when it can determine the object's VRF.

A runbook can be marked human-reviewed, which locks it: automatic write-back will not overwrite a command set an engineer has vetted.

Precedents (RAG) are root causes engineers have accepted. Click Adopt on a ticket and it enters the store; the next analysis of a similar alert automatically retrieves the three most recent matching precedents as context. Retrieval is entirely local — no data is sent anywhere to make it work.