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

0.1.152 — 25 October 2026

A hotfix from the live test of 0.1.151 on the demo. A change on the resource a verified fix touched now lowers the known-issue relevancy whatever spelling of the resource's id the ledger holds, so the shortened analysis no longer runs over it; the shortened analysis says whether the prior fix held; a new incident of a resolved alert reads recurring, not reopened; and the Probable cause card's look-back sentence is the API's. No schema change, setting, route or permission.

A change on the fixed instance counts as a change since the fix: an operator stopped the instance a verified fix had started, the platform recorded the stop (CloudTrail's StopInstances), and the instance's alarm opened a new incident. Its relevancy still read no change recorded since the fix, 100 %, and the analysis took the 3-step fast path, told that no change had been recorded. The ledger keeps CloudTrail's bare instance id (i-…), the last-known-good record the ARN its typed step addressed, and the two were compared as different resources; the second check compared the harvested row's event source (ec2) with the incident's service name. An EC2 ARN (an instance, a volume, a security group) and its bare id are now one resource for the changes since a fix — in the relevancy and in the record's changes on these resources since that resolve (the incident page and the analysis's PRIOR RESOLUTION) — and a change harvested from the cloud counts for an incident by its resource or the services it is linked to, matched against the incident's services and the resource its alert names (InstanceId, resource). Such an incident now reads 85 %, changed since the fix: CHG-…, and its analysis runs in full.
The fast path says whether the prior fix held: the shortened analysis was told a verified fix that held although the record showed the fix had not held (the same alert back, twice in 30 days). It now reads a verified fix that did not hold (N× in 30 days) — the count the PRIOR RESOLUTION block gives — or a verified fix that held. The relevancy level is unchanged.
A new incident of a resolved alert reads recurring: when the same alert opened a new incident after an earlier one with the same key was resolved (no reopen window, or past it), its header chip read reopened ×N, the incident list reopened and triage step 2 reopened, as if the incident itself had come back. They now read recurring ×N, recurring and recurring ×N; reopened stays for an incident back after its own close, including one the post-close check reopened, which the incident detail's recurrence now marks with kind_at. The occurrence class is unchanged: recurrence.kind, the RCA's ## Occurrence and the record's did not hold mark still say reopened.
The Probable cause card's look-back sentence is the API's: a reopened incident whose previous episode has no recorded end read No earlier error within the 72 h look-back — not proven healthy although it had earlier episodes in that window. The card now shows the window's own note: No recorded end of this incident's previous episode within the 72 h look-back — not proven healthy.

0.1.151 — 25 October 2026

A hotfix from the live test of 0.1.150 on the demo. A certified step runbook that backs up an instance runs on its own again, and the incident says when an automatic fix never ran or stopped between steps; the probable cause of an incident that absorbed another service's incident, or that reopened, reads the incident's own current episode and never ranks its own fix; a fix whose first validation round read no data gets one more round, and the post-fix check takes an incident whose fix ran first; a resolved incident shows its latest resolution note; and model calls no longer leave a connection unclosed. No schema change, setting, route or permission.

A certified step runbook with a backup runs on its own again: with both automatic-fix switches on, a certified runbook that backs up an instance before starting it approved its own release and then refused it at dispatch (refused at dispatch: the reviewed plan, connection or target changed), so nothing ran. For a step the estimate cannot model exactly (the backup step here), the estimated blast radius also names the harvested resource whose name is the incident's service, when exactly one resource carries that name (here the instance's root volume, tagged with it); the release reviewed the fix without its change request and the dispatch reviewed it with it, so the two named different resources. An incident's fix now reads the service from the incident in every review, so the Prepared change section, the change page, the approval and the dispatch bind the same blast radius. A person's Approve & run on the incident page refused such a fix the same way; a release from the change page was not affected. An approval of such a fix recorded on the incident page before this release is asked for again; nothing ran under it.
A harvest during a backup's wait no longer stops the run after the backup: a released change is checked again right before each step, and that check also estimated the blast radius again. The run's own image creation, harvested from CloudTrail while the run waited for the image (up to 30 minutes), marks the instance as changed and leaves it out of the estimate, so the next step (the start) was refused with the reviewed plan, connection or target changed after the image was taken. Once a step has run, the check keeps the blast radius the release was approved on; the steps, targets, connections, approvals and change windows are still checked before every step, and before the first step the blast radius is compared as before. A person's release was exposed the same way.
The incident says when an automatic fix never ran: a certified step runbook's automatic release that the check at dispatch refused showed Automatic fix failed · a step failed on the incident's Timeline although no step had run. It now reads Automatic fix refused before dispatch · nothing ran: <reason> (incident.auto_remediate carries not_dispatched and reason). A run that check stops before a later step reads Automatic fix failed · stopped before step N: <reason> (stopped_before and reason). As before, it uses the incident's one automatic try.
The probable cause reads the incident's own, current alert: an incident that absorbed another service's incident read its error start, the alert's resource and the alarm history from its earliest alert ever received, the merged one: the Probable cause card ranked a stop of the other VM first ("same resource as the alert") and offered to revert it, the RCA Timeline started at the other VM's alert, the triage listed the other VM among the incident's resources, and a reopened incident's analysis looked for a change before the first episode's error. The error start, the ranking's resource, the alarm read, the Timeline's first alert and the triage resources and fault domain now come from the alert that opened the incident's current episode among its own alerts. A reopened incident is ranked against the error start of the episode the reopen opened, from where its previous episode ended (when its condition cleared, else when it was closed), so a change that broke it again after the first fix is its cause and the fixes of the earlier episode are not; back within 30 minutes of that end it is one flapping episode from the earlier start. A fix the platform made for the incident is never ranked as its cause, and an alarm history read in an earlier episode no longer bounds the window.
A fix whose first validation round came too early validates sooner: the first post-change validation round opens on the signals' period a few seconds after the write, so a started instance had often published nothing in it: round 1 read no data, the later rounds were clean and the fix waited for the read-only verify, which took 83 minutes to reach it behind 147 open scanner findings. When only round 1 read nothing and every later round was clean, the window now reads one more round in its place (after 1 added round (round 1 read no data)), once; and the scheduled check takes an incident whose fix ran (Remediating) before the other incidents of its workspace.
A resolved incident shows its latest resolution: an incident a person had closed with a note, reopened and then closed by the platform still showed that earlier note as its resolution. The reopened episode's analysis still reads the note as how it was fixed last time; the next close drops it, and a note written for that close stays.
No unclosed connection after an LLM call: model calls now go over httpx, like every other outbound call of the platform, instead of litellm's aiohttp transport, which left a session unclosed (Unclosed client session in the log) each time its one-hour client cache expired. Proxy settings still apply as before (HTTPS_PROXY, NO_PROXY); NO_PROXY entries are now matched by httpx's rules.

0.1.150 — 25 October 2026

A hotfix from the live test of 0.1.149 on the demo. The fix for an incident that absorbed another service's incident binds its target from the incident's own alert and is refused when a step would act on the other service's resource, and a fix that acted only on such a resource is never credited with the clear; a validation round is no longer clean while the incident's own alarm is silent; the change records the person who released it apart from the approver; and a reopened incident chooses its suspected change again. No schema change, setting, route or permission.

A fix on a resource a merge brought in is refused: an incident that absorbed another service's incident (a merge, a fold or the grouping wait) bound its step runbook's target from its earliest alert, the merged one, so one VM's fix backed up and started the other. A runbook now binds from the alert that opened the incident's current episode among its own alerts (after a reopen, the alert that reopened it). A fix with a step on a merged-in alert's resource and none on the incident's own is never a standard change and is never released, by a person or automatically, whether a step runbook or the analysis wrote it (the automatic direct API lane also refuses a route whose fixed target is such a resource). The change request's service, scope, validation checks and a GitOps ${service} path read the incident's own alerts only.
A clear is credited only to a fix that could have made it: when every step of the change that ran acted on a merged-in alert's resource, the incident's clear completes it with the verdict uncertain and no last-known-good, memory or runbook-precedent credit. The change page says why, the incident's Timeline shows Clear not credited to the fix that ran, and the remediation history and back-test cases no longer count it as validated.
A silent alarm no longer reads as a clean validation round: a post-change validation round is clean only when every one of the incident's own alarms passed. An alarm that read no data fails the round when it treats missing data as breaching (CloudWatch TreatMissingData=breaching: a stopped instance publishes nothing and its alarm stays in ALARM) and CloudWatch confirms the alarm is in ALARM (data that is only late leaves the round not observed); it reads OK when the alarm treats missing data as not breaching (an error count publishes only when errors happen), without cleaning a round on its own; it leaves the round not observed otherwise. Before, other signals that passed cleaned the round while the incident's own resource was still down. An alarm whose period is longer than a round is shown but never holds one. The alarm of an alert merged or folded in from another service is a neighbour unless the fix changes its resource: it only flags a round, so a service still down beside a working fix never fails the fix. Every item of the change request's validation plan (V1, V2, …) now reports a row in every round — a neighbour through its own signals' rows — and the L6 list shows the last round's.
The releaser is named beside the approver: a change approved by one person and released by another records two ledger entries, approved and released, each with the person and time (an Approve that completes the quorum is now approved; the run writes released). The change request document's version control and platform approvals name both (one person who approved and later ran it reads Approved by then Released by), and the incident's L5 approval line reads Approved by … · released by …, counting only votes on the action that ran.
A reopen chooses its suspect change again: a reopened incident kept the suspected change-induced pin of an earlier episode. The reopen now pins the change inside the window before the new episode's onset, or clears the pin when there is none, audited Likely change re-pinned (incident.suspect_repinned, trigger reopen). The re-pin after a change harvest reads the same episode — the alert that opened it, never one merged in from another service — so it no longer puts the earlier episode's change back, and it now also covers incidents reopened in the last 6 hours.

0.1.149 — 24 October 2026

The first scale release, groundwork only: a start that no longer grows with the history, indexes built while the platform serves, a size cap on webhook bodies and live views that hold no database transaction. No setting to change and no new screen; the chart adds a startup probe.

The start no longer grows with the history: before it serves, the control plane only adds tables and columns. A new column carries its default in the catalog, so no row is rewritten, and each schema statement waits at most 3 seconds for a table lock, then rolls back and retries (5 tries; the last one waits in line up to 60 seconds). The backfill every start ran over every table is gone: it runs once in the background as migration:null-defaults-v1. On a load-test database with 30 days of history (10 workspaces, 2.35 million audit rows) the schema step took 0.23 s instead of 2.0 to 2.7 s. With leader election off, the start still resumes the runs a restart interrupted before it serves, and that part grows with the number of runs that were running.
Indexes built while the platform serves: seven new indexes (ix_auditevent_action_target_at, ix_auditevent_tenant_target_at, ix_incident_tenant_key_status, ix_incident_tenant_status_resolved, ix_investigation_tenant_started, ix_knowledgeitem_tenant_name_version and the partial ix_changerecord_live_status) serve the scheduler's markers and the harvest cursor, incident and change audit trails, the incident lookup of every alert, retention, the daily cost check at every run start, knowledge saves and the live-changes gauge. Each was kept for a gain measured on that database: an incident's audit trail 361 ms to 0.07 ms, the newest scheduler marker 360 ms to 0.03 ms, the live-changes gauge 733 ms to 3.6 ms. They are built with CREATE INDEX CONCURRENTLY once the app serves, by one pod at a time, and writes continue; so is any of the ten indexes earlier releases made at start that is missing (a new installation). An interrupted build is dropped and built again; a failed one is retried after a minute, the wait doubling up to an hour. AIOPS_DB_ONLINE_INDEX_BUILDS=false leaves the builds to a DBA and logs the statement for each index still missing.
Upgrade progress: GET /api/aiops/admin/overview (platform superadmin) carries a migrations block: each background index (pending, building with its percentage and phase, valid or invalid), each data migration (pending, running, done or failed) and pending, how many are not done. The metrics port exports the same as aiops_migration_pending{name}.
Startup probe: the chart gives the control-plane pod up to 5 minutes (60 checks, 5 seconds apart) before its liveness probe counts, so a slow start after an upgrade, or after a rollback to an older image, is not killed at 140 seconds. A template change; no values change.
Webhook bodies are capped: a /webhook/* body over 1 MiB is answered 413 before it is read; Alertmanager, Grafana and the generic intake, which send a whole alert group in one notification, accept 8 MiB, and /webhook/kubernetes-audit/* accepts 16 MiB, because the API server batches its events. Earlier releases accepted any size the load balancer let through. A sender does not retry a 413: Alertmanager and Grafana drop that notification, so a grouped notification over 8 MiB is lost. Each 413 is logged with the source and the size. AIOPS_WEBHOOK_MAX_BODY_BYTES (bytes, 0 = no cap) raises the cap; Alertmanager's max_alerts keeps a notification under it by leaving the rest of the group out.
Live views hold no transaction: the investigation and chat live streams end each read's transaction at once, so an open page holds no database connection or table lock between events, and a schema change no longer queues behind it.
The PII salt is made with the workspace: every new workspace gets its pseudonym salt when it is created, and an older workspace without one gets it at the first start. Before, the first use committed it in the middle of an alert's ingest, which released the workspace's ingest lock before deduplication and correlation ran.
Metrics: aiops_change_records counts open change rows only: the finished statuses completed, rolled_back, rejected and recorded are no longer exported, so a dashboard that sums them reads nothing. New: aiops_scheduler_subtick_seconds{subtick} (harvest, scanner, inventory, retention, seal, collector, group_triage, monitors) and aiops_migration_pending{name}.
Audit trail trigger: the append-only trigger on the audit trail is created once instead of dropped and created again at every start; a start switches it back on when it was disabled and replaces it when it was redefined.

0.1.148 — 24 October 2026

A hotfix from the 0.1.147 live end-to-end run on the demo. A change approved by one person and released by another runs again; an incident a person closed as known noise is no longer reopened; a caller's analysis waits up to 300 s for its root to arrive (the grouping wait), so a two-service outage gets one incident; the connection's tag scope now applies to backup findings, suggested synthetic checks and built-in detection, and what was already open outside it clears once; and a change no verification answered can be closed without a verdict. No schema change and no new permission; one new route and one new workspace setting (aiops_grouping_wait_s).

A change approved by one person and released by another runs: in 0.1.147 the re-check at dispatch required the person releasing to have voted, so when an approver approved and someone else pressed Approve & run, nothing ran and the change was set to rejected. The re-check now requires that the person releasing may release the change's tier and that the approvals still valid meet the quorum. Releasing an approved change still records no extra approval. Every refusal at dispatch writes change.release_refused with the reason (refused at dispatch: …, PII-scrubbed), and the change's execution result carries it too. An approval whose approver may no longer release the tier (role changed, member removed, support access ended) stops counting before the next click: the person who presses Approve & run adds their approval in its place and the change runs, instead of being refused at dispatch and rejected. A vote that stops counting is audited (change.approval_lapsed, Approval no longer counts, naming the people and the tier) and listed among the change's approvals as lapsed, and the approval gate counts only the votes still valid: on an L3 change with one lapsed vote the button reads Approve again, not Approve & run. The execution result of a release stopped between its backup and its first write is PII-scrubbed like the audit row.
No rollback page for a change that stopped at its backup: when a plan's backup was refused or never became available, the plan stops before any write ("Nothing was changed"). The rollback sweep now skips such a change (change.rollback_skipped) instead of asking a person to roll it back (change.rollback_escalated). A change whose write a person reconciled as executed still follows the rollback rules.
A failed execution reads as failed in the change's history: the change.executed row of an execution that failed now reads Change execution failed instead of Change executed, in the change's history, the incident's timeline and the audit log. An execution whose outcome is unknown (no receipt; the change waits to be reconciled) reads Change outcome unknown.
A failed backup is the failed step in the runbook's step list: on a change whose backup failed, step 1 Check current state showed Failed with the backup's error, because the check was matched to the backup step. The check is now matched to the write it reads before, so the failure shows on the backup step, and a check whose write never ran reads Skipped — an earlier step stopped the run. When the backup ran and the write was then refused at dispatch, the write step reads Failed with the reason.
A finished Test Lab run's change no longer blocks deleting a connection: a lab rehearsal's change (origin testfactory) left in verifying refused the delete of the connection its step once named, for good. Once its Test Lab run is no longer running it no longer holds it; while the run runs (a lane writes real resources, rolls them back and cleans up through that connection) or while the change is mid-write, it holds it like a customer change.
Close a change without a verdict: a released change whose verification never concluded stayed verifying for good. Once it has gone 24 hours without a verdict (none, or uncertain only), a person with approvals.decide selects Close without verdict on its page and gives a reason: the change becomes failed with the verdict uncertain and the reason as its note, audited as change.closed_without_verdict. Nothing rolls back on the close; a later verdict still decides (cleared completes it, still present goes to the rollback sweep). New route POST /api/aiops/{tid}/changes/{id}/close-without-verdict (MCP close_change_without_verdict).
L6 reads every listed item after the rounds: the change request's validation plan shows each changed resource as the rounds' own read of it found it (not observed when no round could read it) instead of not checked yet, and when every round was clean and the fix is Cleared the declared criterion reads pass (clean in every validation round). A neighbour is never assumed. The rows that decided the window and the alert source row are kept under the row cap.
Section 4 lists the backup command: the change request document's Section 4 gives the aws ec2 create-image (or create-snapshot) line of a pre-change backup, before the step it protects, with the name, description and tags the platform sends — a runbook's own backup step and one the review puts before a reboot.
One domain per compliance row: a compliance incident whose findings span several domains (an older rule-wide incident such as the shared Software and Configuration Checks one) is listed under Posture only, no longer under each domain it holds.
Wording while SOC 2 / ISO 27001 are off: the findings list's subtitle names AWS Security Hub, Microsoft Defender for Cloud and AWS Backup, and the platform's own checks only while they run, and Who changed what on Changes cites SOC 2 CC8.1 / ISO A.8.32 only while the frameworks run.
Backup findings and the Backup coverage keep to the tag scope: the platform's AWS Backup read checks only resources carrying the read connection's Only findings on resources tagged tag (exact value) and the workspace scope tags. Another team's instance on a shared account is no longer raised or counted (live: 10 of 13 instances in the BACKUP.PLAN incident). A record already open for such a resource clears at the next read of its region, in one compliance.backup_out_of_scope audit row; the incident stays open while the workspace's own resources are still unprotected. A scope that none of the resources read carries (aiops-managed=True for =true) clears nothing and says so on the card. A connection whose account is not verified clears in the accounts of every resource it read, not only of its offenders. The coverage figure names the tags it counted when every connection kept to the same tags.
Suggested synthetic checks keep to the tag scope: a resource harvested through a connection with Only findings on resources tagged is suggested only when it carries that tag. A suggestion nobody kept whose resource is now outside the scope is removed at the next suggestion run (named in the monitor.derived audit row), also while the daily suggestions are turned off; a kept one stays.
Built-in detection keeps to the tag scope: a resource harvested through a connection with Only findings on resources tagged is watched only when it carries that tag; a pair already in alarm on another team's resource resolves with the note outside the workspace scope or the connection's tag scope. A tag scope that none of the connection's harvested resources carries (aiops-managed=True for =true) or that cannot be read (no =) resolves nothing: its pairs in alarm stay watched until they clear, no new resource of that connection is read, and the card counts the resources held back (the connection's tag scope cannot be read or matches none of its resources — nothing cleared). The suggested-check clean-up follows the same rule.
A suggestion never fails on its certificate's name: a suggested HTTPS check probes the load balancer's own DNS name, which the listener's certificate does not name. It now verifies the certificate chain but not the name (only on the load balancer's own *.elb.amazonaws.com name), and reads the real HTTP answer. A check you add yourself, or a suggestion whose target you change to another name, still verifies the name.
The Backup list holds backup rules only: DynamoDB.1 (capacity auto scaling) and the deletion-protection controls (Cognito.6, RDS.7, RDS.8, ELB.6 and the like) move to Posture; ElastiCache.1 (automatic backups) is a backup rule and ElastiCache.2 (minor version upgrades) an unsupported-version one, the other way round before. FSx.1 and FSx.2 ("copy tags to backups") move to Posture beside RDS.16; Redshift.3 (automatic snapshots) joins Backup. A finding already on the register moves when Security Hub next sends it (daily).
A noise close is never reopened: inside a reopen window (aiops_reopen_window_h), the next alert on the key of an incident a person closed as known noise opens a new incident that carries the similar: noise chip, as the close dialog says, instead of reopening it. The new incident is analysed as usual: the chip is a hint and never holds or skips the run. An older incident on the key is not reopened in its place. An ordinary resolve still reopens.
Repeated means the same resource for a cloud alert: a cloud alert that names its resource (the resource label, an instance id or ARN, else resource_arn) is tagged repeated only against alerts on that same resource in its account. Another instance in the same account on the same metric no longer reads "repeated (seen on <the other instance>)". When the other incident names no service, the chip, its hover and the RCA's Occurrence section say seen in another incident.
A caller's analysis waits for its root (the grouping wait): two services failing on a declared dependency 52 s apart opened two incidents, because the caller's analysis escalated before the root's alarm arrived (88 s after the caller's) and an escalated incident is never regrouped. An incident on a service that depends on another over a dependency allowed to fold now opens (or reopens) with its analysis held for the grouping wait (aiops_grouping_wait_s, new, 300 s, at most 600 s; a raised aiops_storm_group_window_s does not lengthen it): the root's alert inside it takes the incident in, and the outage gets one incident and one analysis. Its summary reads Held for triage — grouping window: … and its Timeline Analysis held — grouping wait; its ticket and notification go out as usual. The analysis starts when the wait ends (Grouping wait over — analysis started on the Timeline) or with Analyse. A potential root, an unrelated service and a P1 never wait; 0 turns the wait off. A waiting incident starts at once when a merge or a joining critical alert makes it a P1, when a member's concern joins it, or when it takes in an incident already under analysis (the merge stops that run). A service does not wait for a dependency whose incident is already open, and an alert that clears inside the wait resolves its incident with no analysis; when that alert comes back, its analysis starts at once, so an alarm that flaps faster than the wait is still analysed. An incident whose alert comes back into the wait after an earlier analysed episode reads Held for triage — grouping window: … with Analyse too, not the earlier episode's outcome.
A reopened caller joins its open root: with a reopen window set, a caller whose resolved incident would reopen now joins the open incident of the service it depends on (the dependency fold goes first), instead of reopening beside it.
The failing badge reads the whole workspace: in a root's blast radius, a service with a live alert on another unresolved incident (one kept apart) now carries failing too.

0.1.147 — 24 October 2026

Changes from the customer reviews of 22 and 23 October: incidents grouped by the service graph instead of a storm count, a short analysis of a known issue, post-change validation in rounds, synthetic checks, change requests a person can reject, CI/CD pipelines' writes as changes, compliance findings by domain on their own page, and SOC 2 / ISO 27001 moved to phase 2.

Grouping by the service graph replaces the storm hold: there is no storm threshold and no __storm__ incident any more. When a failing dependency's alert arrives, its incident takes in the open incidents of the failing services that depend on it, opened or reopened inside the grouping horizon (aiops_storm_group_window_s 300 s plus aiops_storm_spread_window_s 600 s), over the edges allowed to fold (declared by default), audited as incident.grouped. The grouping agent (on by default, aiops_storm_agent) gives a related group of open incidents one bounded turn over every recorded edge. Unrelated services stay separate incidents however many alert at once; the one fold that needs no relationship stays: an alert whose name already fires on 3 services joins their incident (shared-cause, aiops_fold_shared_cause_threshold, 0 = off). A merged incident records merged_into_id and names its root in its resolution; it is never a previous occurrence, a recurrence or a prior fix, and a later alert on its key follows the merge to the root while the root has had an alert inside the fold window (30 minutes). Failing dependents taken in count in the root's blast radius, so a root with two or more affected services rises one priority level. The root's L2 layer lists How these were grouped. aiops_storm_threshold and aiops_storm_window_s are gone: a stored value is accepted and ignored. A __storm__ incident an earlier release left open is not split any more: no alert joins it, and it resolves when its alerts clear or a person resolves it. The webhook metric's outcome="storm" is now outcome="grouped".
A known issue is analysed briefly: the Compare against known issues triage step carries a Relevancy level read by code (100, 85, 70, 50 or 0 %, the reasons on hover). At 100 % (the same key resolved in the problem window by a fix with a verified last-known-good record, the same alert names, no change since the fix, no open provider issue, no reopen and no noise close) an alert-started analysis is capped at 3 steps and checks only what could make it a different incident. On by default (AIOPS_KNOWN_ISSUE_FAST_PATH), never for a P1 or a Re-analyse; a workspace turns it off on Guardrails → Automated triage (Shorten the analysis of a known issue). The change request still waits for a person.
Triage reads the service's resources: before its first turn the analysis gets the service's resources from the estate model, one line each with the ids and dimensions to read it by, or no connected source reads it. The cloud-health step takes its accounts, regions and services from those resources when the alerts name no cloud; an alert that names an account or region keeps resources outside it out.
A person's noise close carries over: the next incident with the same key inside the problem window carries a similar: noise chip that links to it and names who closed it, and its analysis is told so. It is a hint only: never a close, a hold or a count. Merged duplicates are left out of the hint and of the known issues.
Post-change validation in rounds: a change a Post-change validation rule watches is read in rounds, 3 by default and 300 s apart (validation_rounds 1 to 6, validation_interval_s 60 to 1,800, on Change safety), the first once the write has settled, each read three minutes after it closes. Every round failed fails the fix; every round clean with the alerts cleared at their source validates it; anything else goes to the read-only verify. A rule's minutes no longer times anything. When no rule matches an incident's fix (other than a typed posture fix), the rounds watch what the change request's validation plan names: the incident's open CloudWatch alarms, the built-in detection signals of the changed resources and of the target groups in front of them, and their one-hop neighbours, which only flag a round (AIOPS_VALIDATION_DERIVED, on; Watch the signals of a fix that no validation rule matches on Guardrails). With no readable signal the verify starts as before. L6 reads Validating — round k of N at $0 and the change page lists every round. For 10 minutes after a start, reboot or restart an automatic verify writes a $0 held row instead of starting an agent; a person's Verify still runs.
Synthetic checks: Settings · Data in → Synthetic checks probes an HTTP(S) URL or a TCP host:port from the control plane every 60 to 600 s (300 by default). A failure confirmed by one retry 10 s later opens or joins an incident on the check's service (source synthetic); two passes in a row resolve it. Once a day the platform suggests a check for each internet-facing load balancer and API Gateway API in the inventory (AIOPS_MONITOR_DERIVE, on); a suggestion runs in trial, probing its endpoint (GET / every 300 s) but opening nothing, until a person keeps it. A target that resolves to a private address needs an agent in that network, which this release does not have, and stays not checked; a cloud metadata address is never probed. An armed check that names a change's service counts in its validation rounds.
Reject a change request: Reject on the change page, with a reason (approvals.decide), refuses a draft, planned, waiting or approved request: it shows Rejected by with the person and time, the incident's L5 reads Not released — and the reason, and the plan is not offered again until a re-analysis drafts a new one. Resolving the incident, closing it as noise, a bulk close, accepting a control's risk or a merge rejects its unreleased requests the same way. A request already dispatched or finished cannot be rejected.
CI/CD pipelines' writes are changes: writes by Kubernetes service accounts in the workspace's k8s_ci_namespaces (default flux-system, jenkins, gitlab-runner and tekton; argocd and the kube-* namespaces are refused) are recorded with actor_kind: service, one row per object per pull and at most 50 objects per cluster and service account, from the EKS audit pull and the audit webhook. Server-side dry runs, the pods and runs a pipeline spawns, status writes and its controller's own objects are left out (only a request whose dryRun parameter is All counts as a dry run), and the EKS query now leaves plumbing such as lease renewals out at the source.
Tickets: the body of every new Jira, ServiceNow and Azure DevOps ticket carries Assignee and Notify lines (an email assignee arrives as a pseudonym; Notify names channel kinds, never an address). Azure DevOps workitem.updated is now a signal when the update changes the state: Done, Closed, Resolved or Removed resolves it, and a state change on a work item the platform has not seen opens an incident like workitem.created; any other update is ignored. An incoming ticket that lacks a service, severity, priority, assignee or who to notify is not held yet and starts an analysis like any alert. Work items carry the area path's last segment as the area_path label, which Map this source can make the service.
Maintenance windows on the Nth weekday: a window takes "weeks": [1-5] (Weeks of the month), so {"days":["tue"],"weeks":[2], "hours":"22:00-02:00"} is the 2nd Tuesday. The hours after midnight of an overnight window now belong to the day the window starts: before, tue 22:00-02:00 was open on Tuesday 01:00 and closed on Wednesday 01:00.
Change requests: a backup step reads Automated (platform backup), and while a pre-change AMI or snapshot becomes available the change and the incident read Taking the backup before the change with its id, without Reconcile outcome. A runbook the analysis names keeps its steps on the released request, so section 4 of the document prints its commands (a request released on 0.1.146 keeps its empty list). Approving and then executing records one approval. Section 2.4 of the document shows an estimated blast radius with its basis and counts instead of Not computed yet.
Compliance findings by domain, on their own page: Security posture lists four domains, Posture, Vulnerabilities, Patching and Backup (?domain= on /findings and on /incidents?pillar=compliance). A finding opens /compliance-findings/<id>, which any /incidents/<id> link to it now reaches, with its resources before the pipeline. An AWS Config rule's finding keys on its own rule (control:<rule-name>, without a conformance pack's suffix) and never routes to SecOps, and the Systems Manager patch rules file under Patching.
Fix some resources now: on a scanner rule's incident, In this run picks the open resources one analysis fixes (Analyse with N of M open resources; reinvestigate with {"defer": [...]}). The resources left out stay open, the change request lists them as Not in this run, the review refuses a step that names one, and a certified runbook never releases that change on its own. The Resources card opens with a count line (at open, fixed, open, not in this run, awaiting the scanner) and Analyse the rest.
A vulnerable-package plan per resource type: a container image is fixed by a repository edit or a rebuild under a new tag, never by redeploying its consumers; an EC2 instance by an AMI, a quarantine security group that keeps outbound 443, AWS-RunPatchBaseline and the security groups put back; a Lambda function by publishing a version and moving its alias.
Backup findings: while SOC 2 / ISO 27001 are off, the daily AWS Backup read raises one Backup finding (control BACKUP.PLAN, source AWS Backup (platform read), P3, one incident for all) for each EC2 instance without a recovery point and each RDS database with automated backups off and none, with the commands that close it (AIOPS_BACKUP_FINDINGS, on; the plan from aiops_backup_plan_schedule and aiops_backup_plan_retention_days). A resource a Security Hub backup finding already holds open is not raised twice, and a finding clears only on a complete read.
SOC 2 / ISO 27001 are phase 2: the platform switch AIOPS_COMPLIANCE_FRAMEWORKS, off by default, turns them off in every workspace, existing ones included: no framework score, no EST-01 to EST-06 and no platform alarm (LOG-01, CRY-01, ACC-04, MON-01). Compliance frameworks (phase 2) is not shown in Guardrails, compliance_enabled: true is refused with 409, a compliance cron files no scan and POST …/compliance/scan answers 409. The first scheduler tick resolves the open control:<id> finding of each of those checks (by: scope-change). Security Hub, Defender, Inspector and conformance-pack findings and scores are unchanged.
Estate and recurrence: a route table read in full replaces its route edges, so a removed route or association leaves the network path at the next harvest. A cloud alert is tagged repeated only against alerts in the same account or subscription. The Scanner sync card no longer reports a tag-scope count: the connection's tag filter runs inside Security Hub's own read.
Disable a connection instead of deleting it: every connection row has Disable / Enable; disabled connections are hidden behind Show disabled connections, and Delete is offered only on a disabled one. A delete a waiting change still blocks names that change and says to reject it on its page first.

0.1.146 — 24 October 2026

Changes from the customer review of 23 October: one AWS role upgrade, the scanner pull and the change management agent on by default, the change page as the change request document, and clearer incident pages.

One AWS role upgrade: the CloudShell read role gains lambda:ListFunctions, ecr:DescribeRepositories, ecr:DescribeImages and ecr:ListTagsForResource (a page of functions carries their environment variables; values under a secret-looking name such as DB_PASSWORD or API_TOKEN are masked before anyone or any model sees them, a password inside a connection URL is not). The write role gains ssm:SendCommand with the AWS-owned AWS-RunPatchBaseline document only, on instances tagged aiops-managed=true, with ssm:GetCommandInvocation, ssm:ListCommandInvocations and ssm:DescribeInstanceInformation to read the result, and Reachability Analyzer: it creates a network-insights path and starts an analysis only with the aiops:change tag on what it creates, starts an analysis only on a path that carries that tag, deletes only what carries it, and reads the network the analysis needs (ec2:Describe*, elasticloadbalancing:Describe*, network-firewall:Describe* / List* and five tiros: query actions, also named in the deny boundary). Nothing uses patching or Reachability Analyzer yet. The pre-change backup's ec2:CreateTags is now bound to the backup's own create calls (ec2:CreateAction) and its two tag keys, so it can no longer re-tag an image or snapshot that already exists. The deploy/aws module gains the same writes, the Lambda and ECR reads named in its read policy, a region pin on every statement scoped by the aiops:change tag, and iam:SimulatePrincipalPolicy on the write role's own ARN, so its permission check can answer.
The permission check asks about the real target: a step runbook's permission check now sends the target's ARN and tags, the region and, for a backup, the tags and create action the backup sends, so on the guided write role it can answer instead of reading unknown. Certification and Check the write connection's permissions simulate a resource tagged aiops-managed=true in the connection's region; before every automatic run the check runs again against the run's real targets. A target without the tag reads missing; one whose tags cannot be read (an EBS volume) and a deploy/aws role scoped by another tag value read unknown. In each case a person releases the change.
The scanner pull is on by default: every workspace pulls Security Hub and Defender for Cloud findings through its read connections every 15 minutes (AIOPS_SCANNER_SYNC_INTERVAL_S = 900), whether or not SOC 2 / ISO 27001 scoring is on. A workspace that stored 0 keeps the pull off; an owner changes it on Scanner sync. The Inspector CVE read is on unless the connection says false, 0, no or off. Every HIGH or CRITICAL CVE lands P1/P2 and, while Analyse P1/P2 findings automatically is on, starts one paid analysis.
Pull only the findings of your resources: an AWS read connection takes Only findings on resources tagged (finding_tag_scope, one key=value, for example aiops-managed=true). The pull and the Inspector read then ask Security Hub only for findings on resources with that tag; the clear of a finding already in the register is still read. A value that is not one key=value pair fails that connection with invalid_tag_scope before any read, never a wider pull. Each region's coverage entry names the scope. The webhook is not filtered: scope the EventBridge rule.
The change management agent drafts every change request: AIOPS_CHANGE_AGENT_CR is on by default: one change-agent run of at most 8 steps per change request, about USD 0.33 measured, drafts the narrative sections of the change request document. A workspace turns it off on Guardrails → Change management agent. Its plan drafting (Phase 2, AIOPS_CHANGE_AGENT_OWNS_PLAN) stays off.
The change page reads as the change request document: it opens with the document card, then follows an order modelled on the template (status, impact and scope, before state, plan, runbook steps, validation plan, rollback plan, post-implementation review, pull requests, timeline). "Verification" is now Validation plan and "Safety net" is Rollback plan. Each back-up and change row of Runbook steps shows the exact reviewed call and the provider's answer; What ran appears only for a reviewed step no runbook row shows. A release refused before dispatch keeps its reason on the row and under Rollback plan. The Scope card lists the resources and the decision on each, without the action column whose suppression link never worked.
"No negative impact found": a change whose blast radius the estate model reasoned (certified, computed or runtime; an estimate keeps its counts), with nothing lost, nothing also affected and no service depending on the target, says so on the change page, the estate map and section 2.4 of the change request document, instead of the counts, and a change that only adds reads gains only with what it gains. The blast-radius card defines also affected. A review computed before the upgrade keeps its counts. Section 4 of the document now ends with the command of each typed step in its CLI form.
Service correlation: the L2 layer, the sidebar page and the spend row read Service correlation, and an alert that names no service is shown as an unidentified service (chip, triage filter, map-source card, Needs you, intake rule and the held reason). The skill id, the route, the filter value and the aiops_unmapped_triage switch are unchanged.
Automated triage in the order it runs: the card lists the seven steps as they happen: dependency map, known issues, cloud health, recent changes, signals, summary, fault domain. The API's step numbers follow the new order, and the card drops the code-or-agent badge (the API still carries source). The prompt is unchanged.
L5 names its change request: the plan reads Proposed change — drafted into CHG-… and links to the change request its run's wrap-up minted.
A failed execution on the incident: when a released fix fails before any verdict, the summary reads Execution failed — CHG-… and L5 offers the next steps (feedback, resolve, mark as noise, re-analyse, hand off), never a retry, with the backout and a link to the change. L5 and the L7 history list failed executions and operators' execution reports beside the fix attempts, unnumbered and with their resources; L6 and L7 still wait for a fix the platform ran. The remediation history of the next analysis's report and of the record written when the incident is resolved lists the same rows; an RCA written before the execution failed keeps what it had. Mark as noise sits beside Mark resolved in the incident header.
The network path reaches the firewall: a route table associated with an internet or VPN gateway (ingress routing) makes that gateway part of a service group's path, and a route to a firewall's network interface leads on to the firewall instance. A gateway's own route table is followed only through its routes to the group's subnets, so a neighbour behind another firewall does not list that firewall. Removing ingress routing marks the gateway stale unless the resource inventory lists it. A gateway shows in a service group's network path, not on the map's default view.
Firewall deny rules: a FortiGate deny policy and a Palo Alto Networks rule that does not allow are now drawn on the estate model with their action and no interface link (they never read as traffic let through); the first harvest after the upgrade lists them as added once. The Palo Alto Networks harvest reads show rule-hit-count and puts hit_count, first_used and last_used on each rule (never for no hit); a refused or failed read is a note under its own name and the rules carry no usage. Both readers are still drafted from the vendors' documentation.
A refused connection delete says why: deleting a connection that a remediation route still uses (even a disabled one) is refused; the reason now stays in the Delete dialog with a link to the routes that use the connection, instead of closing the dialog and landing at the top of the page.

0.1.145 — 23 October 2026

Fixes found by the live test of 0.1.144 on the demo.

Releasing a runbook change from its page: a standard change whose fix is a certified step runbook the analysis named (its plan lists no steps of its own) now shows Review approval and Review execution on its change page, and the incident's L5 lists the runbook's steps with Approve & run. Before, both read as having no runnable fix although the review and the API could release it. The incident summary's next step reads Review proposed change.
Permission check before an automatic run: the step-runbook automatic lane runs a runbook only when the cloud confirms the write connection holds every permission it needs. A check the cloud cannot answer (unknown) now stops the automatic run (skip reason permissions_unconfirmed); a person can still release the change. Kubernetes and GCP step runbooks, whose check always reads unknown, never run on their own. Certifying with an unconfirmed check is still allowed, and the route says "permissions not confirmed". The guided AWS write role may now run iam:SimulatePrincipalPolicy on its own ARN only, so its check can answer.
Unauthorized change: a change request the platform has executed no longer covers later outside writes on the same resource; its cover ends 60 seconds after its execution. A change approved for a person to carry out, an operator-reported execution and a GitOps pull request keep the 24-hour window. An added security-group rule whose CloudTrail write named its rule id gets a typed revoke as its revert, and a revert with no typed step offers Open the command instead of an Approve rollback that could not run. The rollback of an unauthorized change is validated by its own read at no cost and shows on the incident timeline. Each action's revert is drafted from its own change, a re-created rule keeps its description, and every STS call (for example GetFederationToken) is left out of the CloudTrail harvest.
Validation after a fix: when every alert of the incident has cleared at the source after the write and every changed resource on the validation plan reads as expected, code clears the fix with no agent run (under Typed fix check); the alert's clear starts that check at once instead of waiting for the next scheduled verify.
CloudWatch EC2 alarms: the alert carries annotations.resource_arn, the instance ARN from the alarm's region and account, so a step runbook binds its target with from: annotation:resource_arn. A bare label:InstanceId never binds an aws.ec2.instance parameter.
Smaller fixes: a withdrawn runbook's raised class shows its raised tier and approvals at once; the runbook's Validate step shows the time of its verdict; the Patch compliance and Backup cards read Not read with the reason when their reads were denied, instead of "0 of 0"; the expected blast radius names resources instead of raw IRIs; CHG-01 counts automatic runs of step runbooks; the A.8.8 and A.8.13 notes of the agreed comparison table say what the Scores tab reports; the FortiGate and PAN-OS connection-name placeholder and the automated triage text (up to five steps are done by code) are corrected.