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 · Updated 2026-10-28 · Describes release 0.1.164

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 step templates and a catalog, the portal faults from the 26 October demo, and the setup and documentation items. New routes: GET /api/aiops/{tenant_id}/runbook-templates, GET /api/aiops/{tenant_id}/incidents/summary, GET /api/aiops/{tenant_id}/changes/summary, POST /api/aiops/{tenant_id}/changes/{change_id}/schedule and POST /api/aiops/{tenant_id}/changes/{change_id}/schedule/cancel (MCP list_runbook_templates, incident_summary, change_summary, schedule_change and cancel_change_schedule). New workspace switches, with their platform defaults as app/config.py sets them: aiops_demote_on_deviation (on), aiops_canary_execution (off) and aiops_repeated_other_resource (off); a new settings map patch_schedules; a new notification event change_schedule. One additive column, cloudfinding.cleared_reason, is created at start with a one-shot backfill. No permission changes. See the upgrade row.

Scheduling and patch windows

Approve and schedule. The release dialog of a compliance or vulnerability change offers When to run: now, at a time (UTC), or when the service's maintenance window next opens. Scheduling records the person's release vote on the exact reviewed digest; the scheduler releases a due schedule as that person, with their role at that time, so the digest, window, quorum and permission are checked again exactly as on a click, and a schedule is claimed before it is released so a crash never fires it twice. A release that ran lands released with its outcome; nothing run lands refused with the reason and stays open to release or schedule again; a claim older than 30 minutes without an outcome is landed by the next tick. An incident's change takes no schedule (422): incidents are fixed as soon as possible. The change page shows the schedule line with Reschedule and Cancel schedule, the list a Scheduled badge and the incident an L5 Scheduled fact; audited as change.scheduled, change.rescheduled, change.schedule_cancelled, change.schedule_released and change.schedule_refused.
A patch run per service window. A Patch schedules row under the maintenance windows (service pattern, lead hours, owner, an optional patch runbook; refused while no maintenance window applies to the pattern) makes the platform plan one change request at the lead time before the window opens, for the EC2 instances of that service Patch Manager reports non-compliant. It expands the patch step runbook once per instance with every target bound by code, mints its validation list, notifies the change_schedule targets and emails the owner, then waits for a person: the approval schedules it for the window, and a run nobody approved before its window opened is rejected so the next opening plans afresh. One run per opening, at most 25 instances; audited change.patch_planned.
One resource first. With aiops_canary_execution on (off by default), a released change that writes to several resources runs the first resource's steps, reads it back with each step's own check and only then the rest. A check that contradicts the step stops the run before any other resource is touched, so only that resource needs rolling back; a read that cannot observe it does not stop the run. The review binds the canary point into the request, so the approved order is what runs; audited change.canary_checked.
A withdrawn runbook never leaves a request stuck. A change request whose runbook was deleted or disabled after the draft drops to a normal change, and the review lists the steps to run by hand in the runbook's own order instead of manual by design with nothing to run. A planned patch run whose runbook was withdrawn reads the same.

Runbooks

No runbook is bound to one resource. A runbook certified on one VM, with that VM written into it as a literal target, expanded into a change on that VM for another VM's incident. The quality check now reports a pinned target (a backup or change target with no parameter bound from a label, an annotation or the plan, or a literal resource parameter) and a pinned selector (one exact resource, a hostname or an instance name under a key that names the resource); certification refuses both, the route list shows them, and a runbook certified before the rule no longer expands or classes a change (skip reason pinned_target).
AWS-published fixes as step runbooks. Five Security Hub fixes from Automated Security Response on AWS v4.1.0 — EC2.8 (IMDSv2), EC2.13 and EC2.14 (administration ports), EC2.19 (high-risk ports), S3.1 (the account's public access block) and IAM.7 (password policy) — captured as step runbooks of the platform's own typed operations (the SSM Automation documents are never run): check, change, validate and a compiled-inverse rollback, with the source document, its owner, the version, the controls and any difference recorded. Seeded on the demo workspace disabled and uncertified; EC2.7, CloudTrail.1 and SSM.1 are listed as not captured.
Package upgrade on an instance. The runbook-only operation aws.ssm.upgrade_packages upgrades named installed packages on one EC2 instance through Run Command (AWS-RunShellScript): the script is compiled by code from the runbook's literal package names (at most 16, the certifier's allowlist, never an alert value), only installed packages are upgraded, versions are read before and after, a package whose version is unchanged fails the step, and the quality check needs an image backup of the instance with its restore as the rollback. The write role needs ssm:SendCommand on that document; the guided role does not grant it.
A certified runbook is demoted when its fix deviates. With aiops_demote_on_deviation on (the default), a run through a certified runbook route that fails its validation, or whose fix does not hold, takes the runbook's certification away: its next fixes are normal changes and no automatic lane takes it until an approver certifies it again. Needs you lists it, the route and the skip reason say why, and the audit row (route.demoted_deviation) names who declared the deviation. A route edited and certified again since that run is kept. The rollback demotion now also finds a change minted from a step runbook.

Change management agent

Snapshots before, during and after. Each resource a plan writes is read, read-only, at three points: its before-state, after every executed write step of a multi-step plan (the same compiled read on the step's own connection; at most 10 resources per step and 40 reads per change, each a snapshot artifact), and the post-change read the last-known-good record takes. A failed read is recorded with its reason and never stops the release, and the read runs in a savepoint so a failure past it never lands a change that went through as uncertain. The change page shows a Resource snapshots card and Section 8 of the change request document lists them as changed or unchanged against the before-state; a credential a read echoes is masked.
The impact in plain words. The change-agent draft receives the computed impact and the target's one-hop neighbours in the service graph and writes what could break upstream or downstream and how, or exactly No impact, beside the computed blast radius (section 2.4 and the change page), never in its place; No impact over a report that lost a relation or affected a resource says the computed impact decides the level. It rides aiops_change_agent_cr and the same run.
The last-known change, stated. The analysis prompt's change candidates block now says what its verdicts mean (suspect, proven good, possible) and when a change counts as the cause — a mechanism for this error, the timing, and its effect still in place against the recorded before-state; its budget grows from 2,500 to 2,900 characters. A new chapter, How the platform finds the last-known change, gives the step in the incident flow, the criteria and the change sources each onboarding option adds.

Two-part runbook, templates, catalog and triage knowledge

Every runbook in plain words. A step runbook carries a readable part: purpose, when to use, the steps in plain words, risks and backout. The author may write the prose parts; an empty one is generated from the steps, and the steps are always generated so the words cannot drift from what runs. The guide sits inside the route's parameters, so the revision and the certification cover the words an approver read; the change page shows Runbook in plain words and Section 4 of the change request document prints it ahead of the step table.
Platform step templates. A step may name a platform template and its version — {"template": "aws.ec2.patch@1", "target": "${instance}"} — instead of copying the steps. Seven ship at version 1: the EC2 image backup, isolation, restore of the recorded groups, patch and reboot, and the Azure OS-disk snapshot and VM restart. A shipped version is never edited; the quality check refuses an unknown, unshipped or superseded version, and a runbook certified on an older version keeps running that version until it is moved and certified again. GET /api/aiops/{tenant_id}/runbook-templates lists the current versions; the route editor gains Add platform step.
A runbook catalog. Agent quality → Runbooks lists every step runbook — name, what it fixes, the resource kinds it acts on, its certification in words and the templates it references — behind one search box, with the platform step templates below.
Certified runbooks reach the analysis. Before each incident analysis the platform adds a short fenced block for up to three enabled step runbooks, certified at their current revision by a named person, whose selector matches the incident's alerts (purpose, when to use, steps, targets, backout; at most 900 characters each). It runs nothing: a runbook still runs only when the plan names it and a person or the workspace's rules release it. An incident with no matching certified runbook keeps its prompt byte for byte.
A how-to with screenshots. Write, verify and certify a runbook walks from the catalog to a certified runbook on a change.

Portal

Display faults from the 26 October demo. A refused rollback shows its refusal on its own step row only and reads Rollback failed in the Timeline, with the provider's code and message instead of the XML body; a check whose write never ran reads Not run; actors read in words; the releaser after an approval reads Released; a rejected change keeps the platform's refusal under its status; the change request document names the before-state in words; scores and the decision dialog print no setting names and pre-select neither Fix nor Suppress; platform Backup and Patch Manager findings read Commands ready on each resource beside their commands; a record the platform's read cleared because its resource left the tag scope is cleared out of scope, never fixed (cloudfinding.cleared_reason, backfilled once from the audit rows); estate rows name the connection they were harvested from; the report names a person by display name; an automatic release reads deterministic; an incident Timeline fix row names its change request.
The service graph one and two hops out. The service group carries the dependency rows two hops out each way, drawn as columns from upstream to downstream with each service's source and staleness, a 1-hop / 2-hop filter, and a name that re-centres the group.
Dashboards above the lists. The Incidents, Compliance findings and Changes lists open with how many rows their filters match — by severity and status, the domain on compliance, the status, risk tier and source on changes — and a 14-day trend; each count is a button that sets the list's own filter. Counted server-side under the lists' own filters (GET /api/aiops/{tenant_id}/incidents/summary, GET /api/aiops/{tenant_id}/changes/summary).
A moved load balancer drops its old subnets. A load balancer moved to other subnets kept the old public ones, and their internet route, on its network path; a described load balancer now owns exactly the subnet and security-group links the read returned.

Setup and documentation

Tag-scoped guided setup for a shared account. The guided AWS setup's write option takes Leave out account-wide settings (shared account) (aws_write_scope=no_account_settings): the writer is created without the three statements the aiops-managed=true tag cannot bound — S3 Block Public Access, the IAM password policy and the Security Hub workflow status, which stay manual. The choice is not remembered on a re-run.
What counts as a repeated incident. aiops_repeated_other_resource (off, the rule since 0.1.148): off, a cloud alert that names its resource is repeated only after the same issue on that resource; on, the same issue on any resource of the same account counts. Its own card sits under the alert intake page; the definition is still open with the customer.
Documentation. The unauthorized-change method per source (cloud audit log, Kubernetes audit log, GitOps, ITSM) with a sandbox demo script; the firewall device test report (FortiOS 8.0.2, PAN-OS 11.2.15) and every page that still said the readers were not validated; the Azure gap list per flow step; the change-agent design note; and the settings 0.1.157 added on their own page, Settings added in 0.1.157, with the settings reference pointing at it.