# Release notes 0.1.165

> 28 October 2026: A fix now fails on one unhealthy validation round, approval waits for the change agent's draft, change windows take a time zone, node replacements by the autoscaler are system…

_Release notes · Updated 2026-10-28 · Describes release 0.1.165_

## 0.1.165 — 28 October 2026 {#0-1-165-28-october-2026}

A fix now fails on one unhealthy validation round, approval waits for the change agent's draft, change windows take a time zone, node replacements by the autoscaler are system events, and scanner LOW findings open at P4. The incident page opens with one plain line, and the triage steps hold their own tool calls. The automation in your AWS account arrives: a scheduled function with no AI that probes the private endpoints the platform cannot reach, posts your CloudTrail writes, and can reach the platform through AWS PrivateLink. The built-in detection rules are served as data, and the platform pauses its own detection poll while a function in your account evaluates them. Schema, additive and created at start: the tables `monitorautomation` and `monitordetector`. New routes: `POST` and `DELETE /api/aiops/{tenant_id}/monitor-automation/token`, `GET /webhook/automation/{slug}/checks`, `GET /webhook/automation/{slug}/detections/dictionary` and `POST /webhook/automation/{slug}/results`. New settings: `aiops_validation_fail_on_any_round` (on), `aiops_automation_relax_harvest` (off) and `AIOPS_AUTOMATION_RELAXED_HARVEST_S` (3600). New audit action `change.approval_waited_for_draft`. New private-agent chart value `hostAliases` (empty). Nothing to do for the upgrade.

### Change safety {#change-safety}

- **One failed validation round fails the fix.** After a write, every validation round must be healthy: a round that fails now fails the fix (*still present*, then the rollback plan under the release rules), where before only all rounds failing did. Clean rounds mixed with rounds that read nothing still go to the read-only verify, and the added round is unchanged. Switch `aiops_validation_fail_on_any_round`, on by default; a workspace may turn it off (`PATCH /api/aiops/{tenant_id}` settings, JSON `true`, `false` or `null`).
- **Approval waits for the change agent's draft.** While the change request is pending or being drafted, **Approve**, **Apply**, **Approve and schedule** and the incident's release answer `409` *the change request is still being drafted* with `drafting: true` (audit `change.approval_waited_for_draft`). Approval opens when the draft lands, fails or times out. An emergency change and the automatic release of a certified runbook do not wait. A document approved without the narrative says so in section 9. On the change page the approve buttons are disabled meanwhile with *The change agent is drafting the document (about 1 min).*, the page refreshes every 5 seconds until the draft lands, and a change approved without the narrative carries the badge *Approved without the agent's narrative*.
- **Change windows take a time zone.** `tz` (an IANA name such as `Asia/Singapore`, default UTC) on a maintenance, release or freeze window: its days and hours are that zone's wall clock, and the next opening is still shown in UTC; an unknown zone is refused with `400`. The **Maintenance windows** editor has a **Time zone** column (UTC, `Asia/Singapore` or any IANA name, checked in the browser); a blank or UTC row sends no `tz`.
- **Node replacements are system events.** A node launched or terminated by the autoscaler, EKS or Karpenter is kept on the timeline as a system event (*pod/node replaced; earlier logs may be gone*), never a last-known-change candidate and never an unauthorized change. Karpenter is recognised by its role and its workload credentials, never by a user agent, and a change a webhook reports can never mark itself a system event.

### Compliance {#compliance}

- **Scanner LOW = P4.** CRITICAL opens at P1, HIGH at P2, MEDIUM at P3 and LOW at P4. A register row takes it on its next pull; an open incident keeps its priority.

### Incident page {#incident-page}

- **One plain line first.** The **Summary** card opens with the incident title, its state and what is needed from you (*You: …*, *Next: … — another role takes it.* or *Nothing is needed from you now.*), with the next-step button on that line.
- **Triage steps hold their calls.** Each of the seven **Automated triage** steps keeps its one-line result and lists its own tool calls under a collapsed *Details · N tool calls*; the full trace stays under **Agent activity**.

### Automation in your account {#automation-in-your-account}

- **A function with no AI in your AWS account.** It runs every 1, 5, 10 or 15 minutes, probes the synthetic checks whose targets are private to your network, and posts the results; a result lands on its check exactly like a platform probe. It can also read your CloudTrail and post the writes it finds as changes. It writes nothing in your account except its own table. The guided CloudShell setup installs it in the same reviewed stack as the connection roles (**Install the automation in this account**); its token is created on **Synthetic checks**, card **Automation in your account**. One runs per workspace: a second one is refused while the first is live. If it stops calling in for 30 minutes its checks read *Unknown* and one *Automation silent* alert opens. Cost: about USD 15 a month in your account. The help chapter *Automation in your account* has the details.
- **Read CloudTrail less often on the platform side.** With `aiops_automation_relax_harvest` on (off by default), the platform's own CloudTrail read of the automation's account runs every hour instead of every 15 minutes while the automation is live and reading.
- **Reach the platform privately.** Optional: the AWS setup can create an AWS PrivateLink interface endpoint to the platform in your subnets, so the automation and a private-network agent reach it with no internet route. Platform staff first allow your account on the endpoint service. The private-agent chart value `hostAliases` maps the platform host to the endpoint when private DNS is off. The help chapter *Reach the platform privately* has the steps.
- **The built-in rules as data.** The 37 built-in detection rules are served, read-only, for one of the workspace's AWS accounts and regions (`GET /webhook/automation/{slug}/detections/dictionary`, with an `ETag`), for a function in your account to evaluate there. While such a function's last run, under 15 minutes old, says it evaluated every rule reader for every AWS connection that runs detection, the platform pauses its own detection poll of the workspace; it resumes when that run is older, the function says it stopped, the automation token is revoked, or a Kubernetes connection names a cluster that run did not read.
- **The tenant detector (preview).** `deploy/aws/tenant-detector` is a function you deploy with one command that evaluates those rules in your account and posts only firing and clearing alerts. It runs beside the synthetic-check automation, not instead of it: each has its own record and heartbeat (`kind` `checks` or `detector` on the results post), and only the detector's runs pause the platform's poll — and only a run that fetched the platform's dictionary and delivered every alert. Reserved concurrency is off unless the stack parameter `ReserveConcurrency` is `true`.


## Next steps

- Next: [Release notes 0.1.164](/help/release-notes-0-1-164.md)
- [All What's new pages](/help/what-s-new/llms.txt)
- [Documentation home](/help/)