AIOps Control Deck documentation

AIOps Control Deck is a multi-tenant AIOps platform. It ingests alerts and cloud scanner findings, correlates them into incidents and hands each incident to an incident, change or compliance agent. The agents investigate through read-only connections, write a root-cause analysis and propose fixes. A fix runs after people approve it; only a pre-approved route, in a workspace that switched automatic fixes on, runs one without that step.

Quick start

• 1. Your first investigationConnect one read source, discover its context, send a test alert and follow the answer. Add approved fixes when you are ready.
• 2. Send your first alertCreate a test alert, send its sample with one curl command and open the resulting incident.
• 3. Rehearse your first approved fixOpen a test security-group rule, let the agent prepare its fix, release it through one approval, roll it back and clean up.

Get started

• What the platform does — The seven agents, the path from an alert to a verified fix, connections and roles, what spends model budget, and the guardrails that never switch off.
• Start here: your first investigation — Connect one read source, discover its context, send a test alert and follow the answer. Add approved fixes when you are ready.
• Send your first alert — Create a test alert, send its sample with one curl command and open the resulting incident.
• Rehearse your first approved fix — Open a test security-group rule, let the agent prepare its fix, release it through one approval, roll it back and clean up.
• Glossary — Plain meanings for the terms used in this product.
• Connect and verify your first read source — English narration and captions for your first read connection.
• Video transcript: an alert becomes a fix — English narration and captions from an arriving alert to the approval gate.
• Video transcript: connect your own agent — English narration and captions for private-network and MCP client setup.
• Video transcript: review execution and verify recovery — Exact requests, rollback limits, manual verification references and recorded recovery.
• Video transcript: CloudShell setup and connection verification — English narration and captions for reviewed AWS/Azure CloudShell setup, public output and connection tests.
• Video transcript: compliance checks from cloud changes — English narration and captions for captured cloud changes, pull receipts and change-triggered checks.
• Workspace tours — Recorded workspace task walkthroughs, each with its source, what it establishes and its transcript.
• Platform tours — Recorded platform task walkthroughs, each with its source, what it establishes and its transcript.

Install and operate the platform

• Architecture and responsibilities — This runbook covers the managed installation in a dedicated customer AWS account.
• Install — The vendor installs the platform into your dedicated AWS account from its deployment pipeline, in a window booked with you.
• Customer deploy runbook — a fresh AWS account in 8 steps — The managed install into one dedicated AWS account in eight steps, with upgrade, rollback, teardown, costs, licence and secret rotation.
• Licence — The licence is an offline signed file verified on the control plane at boot and scheduler ticks. It makes no call to a licence server.
• Cost management — Expected monthly cost of the customer template (about USD 725–755 at list price, before model usage), pricing the models, the four spend limits and an AWS budget.
• Set up your first customer — Create a customer organization, appoint its first administrator, then hand over workspace creation and setup to the customer.
• Customers and workspaces — Customer organizations and their separate workspaces, explicit assignments, Test Labs, staff support access, runtime configuration and workspace suspension.
• Platform configuration — Shared configuration for customer workspaces, including connector types, default models, user accounts, admin MCP, the audit log and release verification.
• Connecting the LLM gateway — Three deployment settings that give the platform a model, worked gateway configurations, how to verify them, the built-in mock model, where model prices come from, and rotating a key safely.
• Upgrade and release verification — The deployment pipeline is the normal upgrade path.
• Post-upgrade checks, 0.1.109 to 0.1.143 — The operator follow-up and the evidence to keep for every release from 0.1.109 to 0.1.143, for an install older than 0.1.144: the first part of the table in Upgrade and release verification, moved…
• Rollback — Choose an image rollback for a bad release that can still read the database. Restore data only when necessary. Additive schema migration normally lets the previous image use the newer schema.
• Backup, restore and disaster recovery — Plan for 5–10 minutes of potential data loss with point-in-time restore (PITR). The customer-template drill reached a verified database copy in 21 minutes 56 seconds; this excludes service cutover.
• Platform monitoring and alerting — Scrape the control plane and runners with your monitoring system.
• Security operations — Maintain the vault copy of deployment secrets, review access, and keep a verified audit archive outside the database.
• Platform incident response — This chapter handles failures of the platform itself. Page the customer platform on-call through an independent monitoring route; never feed these alerts into the platform's own ingest.
• Patching and cluster upkeep — The cloud team owns cluster version, capacity and certificates; the release team owns application images and dependencies.
• Recurring checklist — Assign a named owner to each check below. These are proposed operating cadences for WBS 10.1–10.17, not a claim that every schedule or monthly service is already enabled.
• Availability and recovery — As of 0.1.110 (8 October 2026): what a customer can rely on today, and what is roadmap.
• Audit trail retention policy — Written policy, 2026-10-06. The archive retention period is to be agreed with the customer; until it is, every audit row stays online. Enforced truncation is not in this release.
• Support and escalation — DRAFT — support contacts, coverage and response commitments are awaiting agreement. This page describes the information needed to investigate a support request.

Connect your environment

• Choose your connection — Alert source, read connection, write credential, private-network agent or ticket system — what each agent needs, which connector types serve which need, and where to start.
• Connect AWS — Review a CloudShell setup command, import its public output and verify separate AWS connections.
• Proactive monitoring — Incidents without alerts of your own — the platform watches endpoints, metrics and the cloud's own state, and raises outages and degradation by itself, shadow first.
• Built-in detection (AWS) — CloudWatch rules over your estate inventory for accounts with no alarms — outages, and latency or faults above each service's own baseline; read-only, shadow first.
• Synthetic checks — Probe an endpoint from the platform every few minutes and open an incident when it stops answering; checks suggested from the service graph run in trial first.
• Connect Azure — Review Azure CloudShell setup, obtain workspace application approval and verify separate cloud connections.
• Connect Google Cloud — Give a service account project and telemetry read access, connect it and verify the evidence.
• Connect Kubernetes — Create a namespace reader, produce its kubeconfig and verify a real cluster read.
• Connect an on-premises server — Put an agent inside your network, verify a restricted SSH account and investigate host evidence.
• Connect a private network — Install a private agent, confirm its heartbeat, then prove it can read your system.
• Alert sources and intake rules — set it up like the demo — Wire CloudWatch, Azure Monitor and webhook senders to the intake, prove the path with a test alert, and set the rules for alerts that name no service or keep coming back.
• Alerts from your observability platform — If you already run Dynatrace, Datadog, Grafana, CloudWatch, Azure Monitor or Robusta, point its alerting at the platform; anything else uses the generic endpoint.
• Notifications, paging, on-call and tickets — set it up like the demo — Send incident events to chat, email and pagers, set the on-call schedule, and file and write back tickets.
• Ticket systems — Jira Cloud, ServiceNow, Azure DevOps — Connect Jira Cloud, ServiceNow or Azure DevOps so every incident gets one ticket: filed at open, the analysis written back and the ticket closed at resolve.
• Report changes to the change webhook — Report deploys, releases and settings to the change ledger from your own tools, Kubernetes audit logs or Argo CD, and choose a git watch list, a webhook or both.
• Write connections and approved fixes — set it up like the demo — Add a write connection with consent, read the exact prepared fix, and release it through its approvals.
• Read and write roles, and the write gate — Investigate only, approved changes only or both on one credential; what counts as a write for every connector type; and the write gate as a control matrix.
• Connections and remediation access — The hub for the connection pages: how your estate becomes tools the agents can call, which credential may do what, ticket systems, and one page per connector type.
• Manage connections — The connector catalog, the connect form per kind, keyless cloud access, secrets and rotation, Test and its failures, the connected list and its actions, and legacy routes.
• Alertmanager — Alertmanager: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Argo CD — Argo CD: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• AWS — AWS: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Azure — Azure: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Azure DevOps (Repos, Boards) — Azure DevOps (Repos, Boards): fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Datadog — Connect the Datadog API with read-only keys for monitors, metrics, events and logs, and send monitor notifications to the workspace webhook with the paste-in template.
• Dynatrace — Connect the Dynatrace Environment API with a read-scoped access token, send problem notifications to the workspace webhook, and let Smartscape feed the service map.
• Elasticsearch / OpenSearch — Elasticsearch / OpenSearch: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• FortiGate (FortiOS REST API) — Connect a FortiGate's management API with a read-only REST API admin: what the agents read, what the estate harvest draws, and the read gate. Drafted from Fortinet's public docs.
• Generic API connector — Generic API connector: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Generic CLI connector — Generic CLI connector: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Generic MCP connector — Generic MCP connector: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Gitea — Gitea: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• GitHub — Connect GitHub twice — a read token for the agents and a Contents read-and-write token for GitOps pull requests — and capture pushes and merges with a watch list or a webhook.
• GitLab — GitLab: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Google Cloud — Google Cloud: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Grafana — Connect Grafana with a Viewer service-account token so the agent reads dashboards and queries the backends behind them, and point Grafana alerting at the workspace webhook.
• Grafana Tempo — Grafana Tempo: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Jaeger — Jaeger: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Jira — Connect Jira Cloud with an account email and an unscoped API token for issue reads, file and close one issue per incident with the ticket preset, and send Jira issues in as signals.
• Kubecost — Kubecost: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Kubernetes (kubectl + kubeconfig) — Paste a view-only ServiceAccount kubeconfig and the agent runs kubectl reads against the cluster; which verbs and flags pass, what Connect and verify runs, and the save-time checks.
• Kubernetes (MCP) — Kubernetes (MCP): fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Log Analytics workspace (KQL) — optional — Log Analytics workspace (KQL) — optional: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Loki — Connect Grafana Loki for LogQL reads, address a multi-tenant Loki with one connection, and know which log endpoints the agent may call.
• Network device (Cisco / pfSense via netmiko) — Network device (Cisco / pfSense via netmiko): fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• New Relic — New Relic: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Opsgenie — Opsgenie: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• PagerDuty — PagerDuty: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Palo Alto Networks (PAN-OS API) — Connect a PAN-OS firewall's REST and XML APIs with a read-only admin's API key: what the agents read, what the estate harvest draws, and the read gate. Drafted from the public docs.
• PostgreSQL — PostgreSQL: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Prometheus — Connect Prometheus, Mimir, Cortex, Thanos or VictoriaMetrics for PromQL reads, what the agent's prometheus_query tool returns, and how its reads are gated.
• RabbitMQ — RabbitMQ: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• ServiceNow — Connect ServiceNow for Table API reads, file and close one incident ticket per AIOps incident with the ticket preset, and send ServiceNow tickets in as signals.
• Splunk — Splunk: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• SSH (remote host, read-only) — Connect a Linux host over SSH with a dedicated read-only user and key; what Connect and verify runs, what the agents can and cannot do with it today, and where approved commands run.
• VictoriaMetrics — VictoriaMetrics: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.
• Zabbix — Zabbix: fields, the check Connect and verify runs, the tools the agent gets and the read gate, from the connector catalog.

Work with the agents

• Dashboard — The overall dashboard — pillar rings around the human gate, service KPIs, pillar health, the gate queue, one section per pillar, the guardrails strip — and where every number comes from.
• Dashboard, Operate and alerts — Read your next action on the Dashboard, follow the work under Operate, and trace an incoming alert to its incident.
• Incidents — The incident is the unit of work. Where to read how one opens, what its page shows, how a fix is approved, verified and reviewed, and what to do when something is off.
• How incidents work — The concepts, the six statuses and the moves between them, severity, priority and risk tier, and how the incident list and the compliance findings table are read.
• Read an incident and its analysis — The incident page top to bottom, the Probable cause card, the last-known-good record, how to read an RCA and how to ask the incident a follow-up.
• How the platform finds the last-known change — Which recorded change caused an incident, if any — the step in the flow, the suspect and proven-good criteria, the change sources per onboarding option and the exact prompt section.
• Storms, unmapped and flapping signals — How dedupe, correlation and suppression group alerts, how services failing together are grouped by the service graph and checked, and the intake rules for unmapped and flapping signals.
• Approve and run a fix — Every incident action and its permission, reviewing and applying a prepared fix, the approval gate in both write postures, and the Needs you queue.
• Verify recovery — The recheck: scheduled rechecks, post-fix validation and post-close verification, the code-first ladder, validation by metric, and what each verdict does.
• Review execution in Changes — The change request behind a fix, changes captured from your cloud audit log, the compliance check a change triggers, and suppressing a flagged resource.
• Troubleshoot incidents — Incident symptoms, causes and fixes, the limits and gotchas of the incident page, and the permission each action needs.
• Change windows, emergency changes and rollback — set it up like the demo — Set change and freeze windows, release an emergency change with its review, verify a fix and roll a change back.
• How unauthorized changes are detected — Per change source (cloud audit log, Kubernetes audit, GitOps, ITSM), what counts as an authorized change, what raises an unauthorized change, and a sandbox demo.
• The change request document and the change management agent — Read and export a change request in the customer's template, see which sections the change management agent drafted, and switch the agent on or off.
• Write, verify and certify a runbook — A runbook in two parts — the steps the platform runs and the words an approver reads — written, checked and certified in the portal.
• Runbooks and automatic fixes — set it up like the demo — Certify a remediation route so a proven fix runs without a per-incident click, and read why one did not run.
• Runbook library and runbook rules — The step runbooks shipped with the platform, where each one comes from, and the rules every runbook keeps — one use case, never one resource.
• Automatic API fixes for proven runbooks — Let a certified API runbook repeat, on its own, a fix the platform already verified for the same alert — off by default — and set it up like the demo.
• Turn on compliance — set it up like the demo — Connect scanner findings, platform checks and change capture for an account, and check what each source covers.
• Security posture — findings, decisions and frameworks — Read a finding's evidence, request and approve risk decisions, and keep framework evidence honest.
• Knowledge, x-ray and insights — The hub for the Knowledge and insights pages: where the platform learns your organization, and where you get evidence back out of it.
• Knowledge base — Runbooks, reference documents and instructions the agents read, the skill catalog per pillar, the Review queue that turns corrections into skills, and knowledge export and import.
• Estate harvest and x-ray — Harvest a cloud or Kubernetes inventory, launch a read-only Estate x-ray scan, read its service graph and Estate map, apply drafts, and know how far to trust the model.
• Insights chat — Ask the read-only analyst about incidents, approvals, costs, scores, telemetry and the running estate: what it can answer, what it guarantees, and how sessions work.
• Lakehouse — Collection specs that fill the per-workspace telemetry store, the bronze and silver tables, read-only SQL, PII findings as compliance incidents, retention and erasure.
• Artifacts — What lands in Artifacts (pull requests, reports, exports, certifications, pre- and post-change states), why the store is append-only, and how to reach rows past the 100-row cap.
• Archive — read records past the retention window — Find, open and download archived incidents and changes; download a month's fine-tuning data or turn it into Test Lab cases.
• Service delivery report — The 7, 30 or 90-day report: service levels, noise and correlation, remediation outcomes, compliance posture, recurrence, agent quality, and platform cost as an appendix.
• Feedback — Human ratings of the agents' analyses by pillar, model and week, the finished incidents waiting for a score, and what the aggregate counts before a quality review.
• Test Lab — prove the agent before you trust it — Replay known cases or validate changes in an isolated live test environment.
• Set up the Test Lab on your own cluster — Provision an isolated test environment using your own Kubernetes cluster.
• Benchmarks and scores — Golden datasets, the builtin suite, back-tests on your own incident and change history or an archived month, sandbox versus live access, the 80% gate, and what a score means.

Administer a workspace

• People, access and audit — Where membership and roles, single sign-on, support access and the audit log are documented — one page each — and where the permission matrix went.
• Members and roles — Invite, re-role and remove members, create custom roles, what every workspace includes, the tenant brand, and what each role may do day to day.
• Single sign-on — Register this platform at your identity provider, connect it, map groups to roles, test discovery, what login looks like afterwards, and why SSO can never mint a tenant admin.
• Support access — The expiring, audited operator grant platform staff use when you ask for help, how you end it, and exactly what staff can and cannot see without one.
• Audit log — What the append-only, hash-chained audit log records, how to filter and search it, verify the chain, export evidence for an auditor, and what it records for a notification.
• Agents and guardrails — Where agent behaviour, the guardrails and cost limits, and model routing are documented — one page per settings page, with a map from this chapter's old sections.
• Configure the agents — The seven pillar agents and the Agent behaviour page — enablement, the prompt layer, schedules, a model override and extra approval gates per pillar, with the procedures.
• Guardrails and cost limits — The write posture, the always-on floors, budgets and the cost cap, PII patterns, egress, the switches around a fix, validation checks, risk exceptions, unmanaged changes and data retention.
• Models, tiers and routing — Which model serves each tier, what you inherit, the bring-your-own endpoint and how its models are priced, smart escalation, model residency, and the set-up procedure from the demo.
• Usage and billing — The month-by-month statement of what the agents cost this workspace: the five spend classes, the tiles, daily and per-model spend, the organization view, the CSV and how it reconciles.
• Security and data handling — Understand data boundaries, credential storage, redaction and approval rules.

Reference

• Integrations: MCP, API, webhooks, CLI — The hub for everything outside the browser: the REST API, personal access tokens, the MCP server, the agent API, the change webhook, aiopsctl and the webhooks.
• REST API — The concepts every doorway shares, your tenant id, the live OpenAPI schema, the endpoints most people want, pagination, the per-investigation stream and what REST lacks.
• Personal access tokens — Create a personal access token, choose its scope and lifetime, and rotate or revoke it; the credential the REST API, the MCP server, the agent API and aiopsctl use.
• Agent API (OpenAI-compatible) — Each pillar agent as an OpenAI-compatible chat-completions endpoint: live and sandbox base URLs, curl and Python examples, and how one completion behaves.
• MCP server — Point an MCP client at your workspace: endpoint and authentication, client setup, the operations to start with, approvals, uploads, scans and lake queries.
• MCP operation reference — Named tools, request bodies, permissions and asynchronous results.
• Admin MCP server — The /mcp/admin server for platform staff: its credential, the tools it offers and how catalog changes are sent.
• aiopsctl (command line) — The supported command-line client over the REST API: install and authenticate, the command reference, and how to use it as a CI gate.
• Webhook reference — Every inbound webhook adapter — URL forms, the fields each one reads, how service, severity, status and identity are derived, the response counters, correlation rules and the exact error strings.
• Settings reference — Every workspace setting a customer can set — key, shape, default and its platform variable, who may set it, where the portal edits it, and what it changes. API-only keys are marked.
• Settings added since 0.1.157 — The workspace settings added since 0.1.157 — demotion on deviation, canary execution, the repeated-incident rule, patch schedules, the Dashboard pillars — with key, shape, default, card and effect.
• Thresholds and why — Every number the platform works with — its value, why it has that value, what goes wrong lower or higher, and who changes it.
• Status and error reference — Every status word the product shows (connections, incidents, runs, changes, approvals, findings, licence) with its meaning and next step, and the HTTP error strings with their fixes.
• Approval policy and change tiers — Who may release what — the write floor, risk tiers L0–L3, the roles that decide, change classes, windows, the automatic lanes and every guard they check.
• Changes reference — The change ledger record field by field — sources, statuses, classes, risk tiers, windows, last-known-good records, rollback paths, harvest sources and the audit actions a change emits.
• Compliance reference — Frameworks, the agreed comparison table, your own requirements, the 22 controls, finding families, finding to incident, risk decisions, attestations, the scanner pull, scores and audit.
• Permissions — The sixteen permission keys, what each unlocks, which builtin role holds which, and the navigation and action permissions per destination.
• Architecture — AIOps Control Deck — The diagram set: system context, components, the closed loop, the key sequences and the state machines, all generated from the code.

Troubleshooting

• Troubleshooting hub — Find the failed step and the evidence needed to repair it.
• What to collect before you escalate — The ids, run header, failed tool calls, connection test and audit entries to gather before you ask for help.

What's new

• What's new — The customer-visible changes in 0.1.146 to 0.1.164 and in 0.1.130 to 0.1.133 — what changed on your screens and in the API, and what you may need to do after each upgrade.
• Release notes by version — Customer-visible changes, newest first. The current released version covered here is 0.1.164; GET /healthz reports the version actually running.
• Release notes 0.1.164 — 28 October 2026: A certified runbook demoted for a fix that did not hold, before the outside write that explains the recurrence had reached the change ledger, gets its certification back when that…
• Release notes 0.1.163 — 28 October 2026: An outside change and the scanner finding that followed it now meet on the finding.
• Release notes 0.1.162 — 27 October 2026: Fixes from the live read-back of 0.1.161, where real rows were longer than the sample data: the findings list, the runbook catalog and the change actors table fit their card again…
• Release notes 0.1.161 — 27 October 2026: The dashboard after its first day on a live workspace: the hub is drawn as one picture, so the rings keep their places at every window width; the page shows the three pillars the…
• Release notes 0.1.160 — 27 October 2026: The overall dashboard — the structure of the customer's "Mission Overview" mock-up on the platform's own counts — and two Problems page fixes from the 27 October live runs: a…
• Release notes 0.1.159 — 27 October 2026: Fixes from the live runs of 0.1.156 to 0.1.158 on 26 and 27 October: a Lambda runtime upgrade is verified by reading the function back, at no cost and without waiting for the…
• Release notes 0.1.158 — 27 October 2026: Fixes from the live read-back of 0.1.157 on 26 October: a certified runbook keeps its certification when an outside change explains why its fix did not hold, the AWS-published…
• Release notes 0.1.157 — 27 October 2026: The wave for the customer's open epics in one release: scheduling and patch windows, the runbook library, the change management agent's evidence, a two-part runbook with platform…
• Release notes 0.1.156 — 27 October 2026: Four security hardening waves from the internal review — identity, the private agents and runners, change integrity, and the connector tools — and three fixes from the live run of…
• Release notes 0.1.155 — 26 October 2026: Fixes from the live tests of 0.1.154 (the EC2 patch drill, the ServiceNow test and the Kubernetes, ECR and change lanes), a Lambda runtime upgrade runbook and a not needed end…
• Release notes 0.1.154 — 25 October 2026: A vulnerable container image can be rebuilt by a step runbook under a new tag, with an opt-in block of pulls from its repository; a fix's validation rounds can ask AWS Reachability…
• Release notes 0.1.153 — 25 October 2026: Three changes from the customer reviews of 22 and 23 October: a ticket sent in must name the five fields the platform writes on its own tickets, an EC2 instance can be patched by a…
• Release notes 0.1.145 to 0.1.152 — Archived release notes, newest first: 0.1.152 (25 October 2026) back to 0.1.145 (23 October 2026).
• Release notes 0.1.128 to 0.1.144 — Archived release notes, newest first: 0.1.144 (23 October 2026) back to 0.1.128 (14 October 2026).
• Release notes 0.1.120 to 0.1.127 — Archived release notes, newest first: 0.1.127 (14 October 2026) back to 0.1.120 (13 October 2026).
• Release notes 0.1.116 to 0.1.119 — Archived release notes, newest first: 0.1.119 (13 October 2026) back to 0.1.116 (12 October 2026).
• Release notes 0.1.100 to 0.1.115 — Archived release notes, newest first: 0.1.115 (12 October 2026) back to 0.1.100 (28 September 2026).
• Release notes 0.1.89 to 0.1.99 — Archived release notes, newest first: 0.1.99 (28 September 2026) back to 0.1.89 (22 September 2026).

For AI agents: index at /help/llms.txt; every page has a Markdown twin at /help/<slug>.md.