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

0.1.115 — 12 October 2026

Several connections into one cloud account — declare what each one runs: an AWS or Azure read connection (read or read_write) now lists Jobs this connection runs under Advanced · agent access and automation credentials: Estate inventory, Platform checks (EST-01..06), Security findings sync and Change capture (config keys harvest_inventory, platform_checks, sync_findings, harvest_changes). All four start ticked. An unticked job saves false, ticking it again removes the key, and a connection without the key runs the job, so every existing connection keeps running all four. A remediation-only (write) connection runs none. When the role ARN or the subscription you type reaches an account another read connection already reaches, the form names that connection and the jobs it runs; it warns and never refuses the second connection. Saving re-tests the connection, as every edit does.
Platform checks — one answer per account: EST-01..06 list a resource seen through several connections into one account once, from one connection's copy; its row says also seen through the others. An exclusion covers only the copy it was approved on, and holds only while that copy's connection reads the resource: if that connection stops running the checks, is disabled or deleted, stops reading the region (on Azure, the subscription), or a read there fails, the resource reopens through another connection's copy until that connection reads it again or that copy is excluded too. Where you can, leave Platform checks on one connection per account before approving exclusions. Two resources a check cannot tell apart, such as two VMs with one name in different resource groups, stay two. A read one connection could not make (a denied call, for example) no longer holds back the check when another connection into the same account ran that check with no failed read over at least the same regions (on Azure, the same subscriptions); the evidence still names the excused reads, a check is never pieced together from two connections' partial reads, and a listing cut short is never excused. The number of resources checked still adds up every connection's reads.
Switching platform checks off never gives a silent pass: a connection with Platform checks unticked is not probed, and counts as checked only while a connection that runs the checks is known to read the same account in every region it reads (on Azure, every subscription it lists). Otherwise the check reads unknown with probe pending for <name> (platform checks off; no other connection checks its account), never a pass for an account nobody checked. Test an access-key connection before unticking it.
Security Hub clears — counted by account: a connection into the workspace's only AWS account, for example the Security Hub administrator account, asks Security Hub for every account's clears however many connections run Security findings sync into it. Before, a second connection into that account made each one ask for its own account only. An access-key connection counts as an account of its own until a passing Test confirms which account it is in.
One estate block in the agents' prompts: when the inventory items of several connections hold the same resources, the agents read them as one block, estate inventory, merged from <items> (as of <date>), each resource once with the newest harvest's values, so the cost of a prompt no longer grows with the number of roles. Items that do not overlap, and items with prose of their own (a hand-written ontology, a recorded x-ray inventory), render exactly as before. Private-network agents build the same block.
The estate inventory follows the account, not the role: a change captured through a connection that does not run Estate inventory (a dedicated CloudTrail or Activity Log role) now lands in the inventory item of the connection into the same account that does, the first by name, once the capturing connection's account is known: its role ARN or a passing Test on AWS, one whole subscription on Azure. A verified platform change, its rollback and an exact captured change patch every active item that holds the changed resource, not only the newest; a captured change never moves a same-named resource of another cloud or account (an S3 bucket write leaves an Azure storage account of that name alone); an item with prose of its own keeps its text and only its recorded resources move. Estate changes since the last scan lists each change once, with every changed property any connection saw.
Superseded inventory items switch themselves off: an [estate] <connection> item stops riding the prompts once every connection it was harvested from is deleted, has become remediation-only, has Estate inventory unticked, or now harvests into a newer item. It is switched off at the next harvest by any connection in the workspace, or when the connection is deleted: Knowledge shows it inactive and the audit log records knowledge.deactivate by the system, with the reason. Activate brings it back for good; the platform never switches off an item a person re-activated. X-ray and hand-written items are never switched off.
A merged resource keeps the typed reader's verdict: when a narrow role (tag reads only) and a typed reader both see one resource, the typed copy names it and decides whether it is modelled, whatever order the harvests run in, so a narrow role no longer turns a change's impact into Estimated impact.
Data sources — connections grouped by account: each AWS or Azure connection shows the account it reaches, AWS account <id> · same account as <names> (Azure subscription <id> on Azure), or account not confirmed — Test it to group it for an untested access key, and a Runs: line with its jobs. Rows sort by account, then name, and one notice per account reached by two or more connections names who runs each job, with nobody … for a job no connection runs. A connection's account is its role ARN's account, else the account its last Test proved for its current settings; an Azure connection's is the one subscription its jobs read whole (several subscriptions, or a resource group, group with nothing). Scope accounts never group connections. The Test result names the same-account connections, and Changes → What the change agent watches lists one entry per account. API: GET /datasources rows gain account and account_peers; the Test reply gains same_account.
Estate x-ray and agent tools, account by account: a scan over several connections into one account carries a coverage note — 'a', 'b' reach AWS account <id>: the same account through different roles, so a resource seen through one is the same resource through the others — so the agent does not inventory one account as several estates. A connection counts as covered only through its own tool: one aws_request call no longer covers every AWS connection, and a connection whose name starts another's no longer borrows that connection's calls. Each AWS or Azure tool's description names its same-account sibling tools. With several connections of one native type, the canonical tool (aws_request and the like) goes to the first connection by name, the same on the control plane, private-network agents and private chat.
Extra roles — what a staff-prepared setup needs (copy corrected): the connection form and the Test refusal no longer say the platform prepares one read/write pair per account. In any-account mode a further aiops-* role with the read role's trust works on its trust alone. With roles prepared by platform staff (also with a private-network agent), the workspace reader is granted only the prepared roles: staff must also grant it, and the platform role where its grants name exact roles, sts:AssumeRole and sts:TagSession on the new role. Test runs as the platform role and cannot check the reader's grant, so until staff add it, x-ray scans and investigation reads through the new connection are refused. Guide: Connections and remediation access → Several connections into one cloud account.

Upgrade notes

Offender counts and the posture trend step down once for accounts that several connections already read: from the first platform check after the upgrade, a resource is listed once per account instead of once per connection. An exclusion keeps holding while its copy's connection reads the resource, since each copy keeps its own key. Tell workspace owners before the upgrade.
An impact basis can move from estimated to computed where a narrow role's copy of a resource sits beside a typed reader's (the merged-resource rule above). The approval digest binds the basis, so a pending approval on an affected change asks for a new review. Upgrade in a window with no pending approval.
Changing a connection's jobs re-tests it, like any configuration edit: on a read_write connection, a pending approval bound to it needs a fresh review.
The merged estate block appears at the first agent run on workspaces whose inventory items already overlap (for example an adopted x-ray context beside its frozen [estate] item). The next harvest then switches the frozen item off, and the prompt is back to one block per item.
The canonical cloud tool can change owner on a workspace with several connections of one native type (first by name now). A private chat turn running during the rollout may answer once with configuration changed.
Azure connections group only on a whole subscription: one with several subscriptions in its Scope, or a resource group, joins no account group, notice, excusal or inventory routing.

0.1.114 — 12 October 2026

Usage & billing — what the agents cost a workspace, month by month: a new Insights → Usage & billing page (/portal/billing, report.view, which every builtin role holds) shows one UTC calendar month at a time — the month in the address (?month=YYYY-MM), the month in progress labelled month to date. Tiles: total cost, tokens with the cached-read share, agent runs, and the median cost per investigation (the hint says avg · median of N investigation runs · scans excluded). Budget · this month reads $spent of $cap with a bar on the current month — operating spend against the Guardrails cap, test spend excluded — and the caps alone on a past month; a workspace on its own LLM endpoint gets Billed by your gateway with the gateway's host instead. Below: the spend by class (Investigations, Validation, Estate x-ray, Chat, Test Lab, with the Test Lab box on its own line), a daily chart with a Show as table twin, the by-model split with the report's pricing caveats, and the ten costliest incidents with their triage and validation spend. A month where only the lab box ran still opens. The figures are the same run records as the service delivery report's cost appendix and the platform invoice: x-ray and compliance scans are billed once on their scan record, benchmarks are test spend, and deterministic layers cost $0.
Usage & billing — the organization view: a seat in an organization adds one Organization card per organization, All workspaces · <organization>: one row per workspace by class with an organization total. The organization admin sees every workspace; a member sees the workspaces where their role holds report.view, and the card says so. The Workspaces page links straight to its organization's card.
Platform console — Billing as a statement: one month at a time with a picker and Download CSV, search by name or slug, Hide zero-spend tenants and sorting; tiles for the total, the production and lab subtotals, runs, tokens and BYO LLM tenants; the platform's spend by class in the portal's words; and one expandable row per tenant (total, share, class split, runs and tokens, Open workspace) in place of the wide table. Nothing scrolls sideways at 1280 px or on a phone.
Usage & billing — CSV and API: Download CSV on the statement (one line per class plus TOTAL, technical class names), on the organization card (the platform export's columns, five lines per workspace plus TOTAL) and on the console (one line per tenant and class plus a grand total). A workspace name or slug that starts with =, +, -, @, a tab or a carriage return gets a leading apostrophe in every billing CSV, so it cannot run as a spreadsheet formula. API: GET /{tenant}/billing?month=YYYY-MM, GET /{tenant}/billing.csv, GET /groups/{gid}/billing and .csv; MCP tenant operations get_billing, get_billing_csv, group_billing and group_billing_csv.
Data retention — closed records age out, default one year, in whole months: once a day per workspace the sweep removes every closed record whose whole UTC month of closing is older than the window, with everything that hangs off it: resolved incidents with their alerts, runs, validations and the verify runs behind them, approvals, feedback, merge proposals and artifacts; closed problems; completed, rolled-back, failed, rejected or recorded changes with their evidence and the runs they name; cleared findings with their risk decisions; finished compliance and estate x-ray scans with their results, phase runs and the attachments no kept scan reuses; chat sessions with their turns; and finished runs that belong to no incident and that no kept record names.
Data retention — never removed: anything open or active; a record with a run still running or paused, or with a run or validation in or after the cutoff's month (a later sweep takes it whole); a cleared finding with a risk decision in force or awaiting sign-off, with its decisions and the change the decision names; the audit trail; knowledge, skill proposals, attestations and the evidence they cite, posture snapshots; benchmark datasets and runs, Test Lab runs, certification artifacts; configuration. A kept row that pointed at a removed one keeps its row and loses only the pointer.
Data retention — the invoice never shrinks: in the same transaction, before anything goes, every month a removed run, validation or scan was billed in is sealed as a usage statement (one per workspace and month, written once, closed months only). From then on the seal is the statement everywhere: Usage & billing totals and its CSV, the organization view and its CSV, and the platform invoice and its CSV (/admin/billing rows carry sealed_at). The page says so under the month — Sealed on <date> by the data-retention sweep: totals are the statement; the daily chart, models and incidents show only records still kept. — and the cost per investigation also reads only the kept records. GET /{tenant}/billing adds sealed: {at}; POST /admin/rebook-costs leaves a sealed month alone.
Data retention — where it is set: the platform default on Platform defaults → Data retention default (GET/PATCH /admin/retention-defaults, 30–3650 days, superadmin; AIOPS_RETENTION_DAYS_DEFAULT 365, AIOPS_RETENTION_SWEEP_ENABLED true). The workspace window on Guardrails & cost → Data retention (members.manage to change it): the window in force and its source, an override of 30 days or more with Use platform default, the last sweep with its counts (an attempt that did not complete says so and is retried a day later), and Preview the next sweep — a dry run, announced to screen readers, with the UTC cutoff and the statements it would seal. API: GET /guardrails → retention, PATCH /guardrails → retention_days (integer or null), GET /{tenant}/retention/preview, POST /{tenant}/retention/sweep; MCP preview_retention_sweep, run_retention_sweep (tenant), get_retention_defaults, patch_retention_defaults (admin). Audit: retention.swept whenever a sweep removes anything (Records removed by retention: counts per kind, the cutoff, the sealed months) and platform.retention_defaults (Retention default changed). One workspace's failed sweep never stops the others.
Knowledge base — where a pending version came from: with Show inactive versions and drafts on (/portal/knowledge?inactive=1), each section lists the drafts waiting for Activate first, then the versions in use, then superseded history. A waiting draft carries Pending activation; every row says when it last changed and by whom — a member's email, Built-in for a shipped skill-pack row, or Platform for anyone outside the workspace (platform staff are never named) — and a version an estate x-ray produced says from estate x-ray with the scan's start time, linking to that run. A version saved before this release shows from estate x-ray when its scan is on record, without the start time. A version turned off with Disable is history, not a waiting draft, including one disabled before this release. After Apply as draft on a knowledge draft, the scan's Review in Knowledge base → link opens the pending list; after Use selected context it opens the plain Knowledge page, since that context is already active. The API stamps data.provenance on every knowledge version (xray with the scan, its start, its datasources, who applied it and when; manual; import) and the list returns provenance and updated_by_label; versions the inventory harvest or the ontology follow write no longer inherit an x-ray stamp.
Estate x-ray — a correction reaches the Review queue and the next scan: a correction typed on a scan's 1–10 rating, with no thumb, now drafts a skill proposal named as an estate x-ray correction (repeats stay deduplicated), so Your correction is waiting in the Review queue is true. Once promoted, it reaches later scans: in-process missions load the reporting agent's active skills, and private-network agents receive the same rows with the scan (older agents ignore them).
Chat — the analyst knows what day it is: the analyst's prompt names today's date (UTC), and sys_costs answers a calendar month (month: YYYY-MM, the billing statement's month bounds) as well as a trailing window, so "token consumption for September 2026" is no longer answered as a month in the future.
Accessibility: the Model residency table on Guardrails & cost scrolls by keyboard at phone width, the incident header's long chips (suspected change, last-known-good record) wrap at 320 px instead of pushing the page sideways, and the knowledge base's inactive toggle no longer snaps back for a moment after a click.
Walkthrough films: the handover walkthrough films are delivered with the handover package, not in this build; the in-product chapters keep the September walkthroughs they already embed.

0.1.113 — 12 October 2026

Changes — every change request in one place: the Changes page has a Requests view (every change request the platform holds, the ones still waiting for a person first, including proposals nobody has requested yet) and a search box that finds a request by its CHG-id, title or service on any page of the list.
Changes — the class is the requester's call: anyone who may request a change can reclassify it between standard, normal and emergency while nothing has been dispatched, with a note. The tier follows the class floor but never drops below what the change itself needs; collected approvals are cleared because the approval basis changed; the derived class stays visible and the Timeline records Change reclassified. A workspace setting on Guardrails, Change class policy, keeps the derived rule (emergency for P1/critical, standard for a pre-approved runbook fix, otherwise normal) or starts every request at standard; under both, a class someone set on an earlier request with the same operations is inherited.
Execution receipts — a refused write is a failure, not an unknown outcome: when the provider rejects the request before acting (an HTTP 4xx such as AccessDenied from a write role without the permission), the change lands failed with the provider's own message on the record, the incident escalates, and the rollback sweep does not page anyone to revert a change that never happened. Genuinely unknown outcomes (timeouts, 5xx, a shell command that exited non-zero) still say outcome unknown and now carry the last response.
CloudWatch alarms — severity and service hints: an alarm's description may say severity=warning (or error, info) and service=<name>; every alarm used to arrive as critical, and an alarm keyed on a load balancer or WAF opened its own incident instead of joining the service it belongs to.
Connections — a multi-account estate: the cloud tools the agent is given now name the AWS account, Azure subscription or GCP project each connection reaches, together with the operator's note on the connection, so an alarm's account can be matched to the right connection. CloudWatch calls use the service's real endpoint, and the Azure DevOps connector spells out the REST path shape.
Keyless AWS, several workspaces on one role: the connection guide says what a customer-owned read role's trust must list when a second workspace or a workspace's pinned reader uses it; the connection test names the missing piece.

0.1.112 — 11 October 2026

Changes / approvals — emergency changes and the change window: an emergency change (the change request of a P1 or critical incident) is now released through a closed change window by the approval that completes its quorum — the standard emergency rule. The quorum is never relaxed: a vote that leaves it short only records, and standard and normal changes stay refused until the window opens. The change records the bypass (meta.window_bypassed) and its timeline reads Change window bypassed — emergency; one rule serves the preview, the release and the dispatch re-check, so no entry point is more lenient than another. The preview says which rule applies: for an emergency under a closed window, that the release goes through once the quorum is complete (and lights the button for the approver whose vote completes it); for any other class, that the release is refused until the window opens. A typed-plan release refused outside the window is now audited (incident.remediate with refused: outside change window (…), change.release_refused on the change) (ec40834f). The change page's own Execute (a route-based change) records the first approval of a short emergency quorum as well, instead of refusing it with the window; nothing executes until the quorum is complete, and a normal or standard change there is still refused.
Changes / approvals — post-implementation review: the moment an emergency change is implemented — a direct write when it executes, a repository change when its pull request merges — it owes a review (meta.pir), due in aiops_pir_due_h hours (72 by default; 0 opens none) and owned by the releasing approver. Needs you lists it as Review (overdue past the due date; GET /needs-you gains the kind pir, with due_at, overdue and display on each item), the change page shows a Post-implementation review card, and POST /changes/{id}/pir/close with a note of at least ten characters closes it under approvals.decide (change.pir_opened and change.pir_closed are audited; a closed review answers 409) (ec40834f, b082e5cf, 69dfa35f).
Incidents — suspect change across a declared dependency: when no change touched the alerting service or resource inside the 30-minute suspect window, the pin may land on the newest change made on a service one hop upstream over a dependency a person declared — never a traced, discovered or observed edge, never two hops, never a dependent. The incident stores it as suspect_change_via and the header reads suspected change-induced · CHG-… · via <service>. Attribution only: the change-window fold never groups on such a pin, so the set of incidents is unchanged. A re-pin after a change harvest carries via in incident.suspect_repinned, and the last-known-good record's Probable cause line names the upstream service. When several declared upstreams changed inside the window, the newest change is pinned. Workspace opt-out aiops_pin_across_dependency (on by default): Settings → Guardrails → Suspect change across a declared dependency, or pin_across_dependency on GET and PATCH /guardrails. Because the rule is on by default, an open incident of the last six hours that had no pinned change may be re-pinned via an upstream dependency at the first change harvest after the upgrade (incident.suspect_repinned carries via); turn the switch off first to keep the previous behaviour (b0b29ce2, 7ac2f87c, e45521cc, 7ee693e4).
Changes / approvals — Kubernetes change capture: writes to a cluster reach the change ledger two ways. On EKS, k8s_audit: true on the AWS read connection makes the scheduled change harvest read the control-plane audit log from CloudWatch Logs (Logs Insights over /aws/eks/<cluster>/cluster, every cluster in the connection's regions with audit logging on; the read role needs logs:DescribeLogGroups, logs:StartQuery, logs:GetQueryResults, eks:DescribeCluster) — nothing is installed in the cluster and its API server is never read. On a self-managed cluster the kube-apiserver audit webhook posts to /webhook/kubernetes-audit/<workspace>/<token>/<cluster-name>. Both keep write verbs by people only (GitOps controller writes arrive as Argo CD sync events) and record a 401/403 as a denied attempt. The Connect page's Webhook ingest card now says, per endpoint, what to configure where and what arrives, with paste-in snippets for Argo CD notifications and the kube-apiserver audit webhook; aiops-inputs-needed.md §S9 is the reference (a7356e51, 7b35c029, 557296bd).
Changes / approvals — Argo CD drift rows: an Argo CD OutOfSync notification now records its own drift row per Application and revision (argocd:<app>@<rev>:drift, titled argocd drift <app>: live state differs from git) beside the sync row of that revision, instead of folding into it. Workspaces that already send on-out-of-sync notifications see one more ledger row per drift, which Probable cause rankings and change counts include (a7356e51).
Guardrails — model residency policy: a workspace can pin which models its agents may run on by model id prefix (model_route_policy: deny prefixes, a required prefix and a label, on PATCH /guardrails with members.manage). The check runs on the backing model id when the platform gateway exposes it and on the alias otherwise: the alias → backing map is fetched before every investigation, chat turn and x-ray launch (cached for five minutes); a gateway without /model/info is checked on the alias; a gateway whose /model/info fails keeps its last fetched map, and with no map at all every model is denied until a fetch succeeds; a prefix is matched against the alias with and without the platform's openai/ prefix; a bring-your-own gateway's aliases are checked as aliases. A denied model is never used — the run fails closed with model route policy: <model> denied (<why>), the incident escalates, the escalation ladder skips denied tiers, and chat, agent-API and x-ray launches are refused with the reason. The mock model is exempt. GET /guardrails returns the policy and model_route_check (per tier: alias, backing model, gateway host, verdict allowed, denied or unknown, and the reason); Guardrails & cost gains a Model residency card with the editable policy and the per-tier table, and the Agents and guardrails guide a section on it (27ad827c, 348cb46d, a95960b0, 393ea705).
The wrap-up output cap now follows the model a gateway alias routes to: an alias the catalogue does not know is capped on its backing model's base id (an apac. inference profile keys as its base model), so a regulated workspace on the in-region Claude alias no longer fails its wrap-up by asking for more output tokens than Bedrock allows.
Audit — model residency evidence: every run started under a policy writes model.routed (model, backing model, gateway host, policy label) once at start, and every refusal writes model.denied. Both are labelled on the incident Timeline and the Audit log (27ad827c).
Validation — after a release: a verification kicked right after a fix is applied no longer reuses a verdict recorded before the fix. The fresh-verdict reuse window (aiops_verify_reuse_s, 300 s) is skipped whenever a change of the incident executed after the cached verdict, and the log says why. The Remediate button and a prepared-plan release kick the verification as post_execution, which skips the reuse on intent alone; it is not the human Verify, so the budget, attempt-cap and escalated-incident rules still apply. Known limit: a repository change is stamped executed when its pull request opens, so a later merge is not seen by this rule; the merge is observed by the incident loop and by the scheduler tick, which never reuses (28b7b1dc, b07cbba4, 0759a166).
Gateway — in-region alias: the platform gateway gains the in-region alias bedrock/claude-3-5-sonnet-apac (served inside the APAC regions only — residency evidence for regulated workspaces) beside the unchanged global bedrock/claude-sonnet. It is Claude 3.5 Sonnet v2, the newest in-region profile the provider serves, so expect lower accuracy than the global alias. The alias is priced at list (3.00 in, 15.00 out, 0.30 cache read per million tokens) under both openai/bedrock/claude-3-5-sonnet-apac and bedrock/claude-3-5-sonnet-apac, so the per-run cost cap and the 70% downgrade apply to it (bbc4780a, aa8f3fad, b1979fac).

0.1.111 — 10 October 2026

Portal and ops console: a page whose files vanished after an update (an old tab asking for the previous release's chunk) now reloads itself once, keeping the address and the workspace; only a repeat failure shows the manual "Reload page" screen.
Incidents — list filters: the Incidents list adds Cloud and Account selects (API ?cloud=aws|azure|gcp|other). An alert's own cloud label sets its cloud, else the webhook that delivered it: CloudWatch and Security Hub are AWS, Azure Monitor and Defender are Azure; Other means no alert is attributed to a cloud. Account also matches an alert's account or subscription label (3e4cc91f, 09511a57, 7cc5dc2e, f6aed6bd).
Incidents — incident page: the pipeline leads the page: signals received, how they were grouped, the agent's steps (folded), then the change request and its approval. Validation and the report wait while a change awaits a person; the report stays a draft until a fix ran. The pinned-change badge now reads suspected change-induced, and an alert held at ingest reads Held for triage and names the fix (b71d0f69, 1d8909e3).
Incidents — Timeline and audit log: the incident Timeline, the change timeline and the Audit log word every audit action the same way, and a label never claims an outcome its row contradicts. System rows fold behind Show N system events. The Audit log names each person by email, links the incident or change and keeps the stored row under Raw record; the export is unchanged (0a657ec6, 354e1da8, eb51550e, f466d758).
Compliance — risk requests: risk decisions on findings and exclusions from a control's fix are now requests (requested, then approved or rejected) sent by members with incidents.act or approvals.decide. One takes effect only when another approvals.decide holder approves it; a sole approver may approve their own, audited. Only approved decisions suppress, count or can be revoked (0380b2f4, 018ad0d6).
Compliance — deciding: requests are signed off in the portal or by POST /risk-decisions/{id}/approve or /reject. Each Resources row opens a Risk decision dialog (expiry from tomorrow to 365 days, 90 by default; a reason of at least 10 characters). Needs you lists risk requests, critical first. Decisions show requester and approver; those made before this release read as approved (48c698a3, d9550d3c, f2074548, 03872d06).
Compliance — automatic P1/P2 analysis: a pulled Security Hub or Defender finding at P1 or P2 starts an analysis without a prepared fix, behind the usual run checks; aiops_auto_investigate_p1p2 is on by default and the held receipt names the rule. Opt-in aiops_auto_investigate_catchup runs older held P1/P2 findings, 3 per workspace per tick. Platform checks now carry a priority (e13a5b83, 7b07df78).
Compliance — posture: a new finding's first-seen time is the scanner's own first-observed time, never later than receipt, so a newly connected account no longer shows as a cliff in the trend. The score cards and the trend follow the Account and Source filters. A finding opened from Needs you, the dashboard or a scanner link opens under Compliance findings (1ef66599, 93556c98, a5024ae4).
Changes / approvals — change request: an escalated analysis that proposes a fix records one planned change request, which Request approval reuses. Fixed rules set its class and minimum tier: emergency (L3, two approvers) for a P1 or critical incident; standard (L1) when a runbook matched and every typed operation is in aiops_preapproved_operations; otherwise normal, at L2 (4c5f1574, 57fe3868).
Changes / approvals — change page: a change request opens with its class, tier, scope (each resource marked remediate or excluded) and approvals (request, approval and release, each with person and time), with the blast radius below. Unrequested proposals stay out of the default Changes list (turn on Proposed), change lookup, change statistics and correlation (845555c9, f8e08fcd, 91ef51b1).
Changes / approvals — apply preview: the prepared-change card always runs its preview. A refusal lists each enabled write connection with its status (ready, not allowed for approved plans, needs a test, needs a confirmed scope, no executor), even one the agent is not offered; a plan with no typed step reads manual by design. A request on a route-based fix is refused rather than run (891fe830, ab431313, f8f4c2b7).
Changes / approvals — before-state: new artifacts record the sha256 of their stored body in meta.sha256, and a change's before-state capture carries its snapshot's digest, so it can be re-checked; captures without a restorable snapshot carry none, and older artifacts are not backfilled. When post-fix verification still finds the condition, its reason now says after the fix was applied (6730bb9c, 2819a98a, 98237f7c).
Access and roles — separation of duties: the builtin operator no longer holds approvals.decide: it analyses and requests but cannot approve, exclude or release. The executive gains approvals.decide. Every risk tier now releases on approvals.decide alone (L2 and L3 previously also needed pillars.manage); L3 still needs two people. Execute and Remediate accept incidents.act or approvals.decide (eb3380ad, 8a73de64).
Access and roles — roles: every member can read the roles (GET /roles); Members & roles shows them as a permission grid with plain descriptions, and editing stays with members.manage. The role editor lists all 16 permission keys, so chat.estate can be granted there. Needs you shows to members with approvals.decide or incidents.act (64fd10fd, 554866ec, c5c45161).
Data sources — Dynatrace: a Dynatrace connector takes the environment URL and an access token, sent as Authorization: Api-Token. Test calls GET /api/v2/problems, so a token without problems.read fails at connect. A platform token (dt0s16…) is accepted the same way; its scopes are named environment-api:problems:read, environment-api:entities:read and so on. Read calls run freely; any other call needs approval. The connect form explains token scopes and URL forms, and a builtin skill triages a Dynatrace problem read-only (593ba771, 50d7ce61, 62773084, 44b2ac3a).
Data sources — Dynatrace problems: a Problem notification posted to /webhook/dynatrace/<workspace> becomes one alert per problem, keyed on the problem id; RESOLVED closes it and a re-send dedupes. The service comes from a service: tag, else the impacted service, application or first entity, so the problem joins an incident other sources opened for that service (1216db09, a82b487c).
Data sources — alert intake: Alert intake & tokens lists Dynatrace with the other alert sources and shows copyable payload templates for Datadog and Dynatrace. Test alert adds Datadog and Dynatrace samples beside Alertmanager and generic. A new guide, Alerts from your observability platform, covers each platform's setup (0d1cf737, ed77313a, c1ed7272, 0b3af485, a4ba1901).
Reports — service delivery report: Insights → Report reads, in order, service levels, noise and correlation, remediation outcomes, compliance posture, recurrence and problems, and human feedback and agent quality, over 7, 30 or 90 days; platform cost moves to a closed appendix. Default targets are P1 4 h, P2 8 h, P3 24 h and P4 72 h; sla_targets_h overrides them (9ac08a20, 2acd6fff, 8ef1b61e, 294a8631).
Navigation — sidebar: Improve splits into Insights (Report, Chat, Estate x-ray, Artifacts, Lakehouse) and Agent quality (Knowledge base, Test Lab, Feedback), and page eyebrows follow the sidebar groups. Artifacts and Lakehouse say what they are for; the Coverage tab is marked Preview, with its counts read as indicative (cabc1540, 8c20e4d8, e832491c, 0bafb4d7).
Guardrails: Guardrails & cost adds Automatic analysis of P1/P2 findings, on by default, and Backlog catch-up, off by default; each follows the platform default staff set in the ops console unless the workspace sets its own. Every analysis is a paid run, so the card shows the daily cost limit in force or warns that none is set. GET and PATCH /guardrails carry auto_investigate_p1p2 and the preapproved_operations behind the standard change class; an unknown operation is refused, and members with members.manage tick them on the Pre-approved operations card of Guardrails & cost (ee592690, 2f9896e0, 4c5f1574, 894f19c3).
Knowledge — runbook drafts: runbook drafts can be edited as fields with guidance. An edit can keep or lower the evidence level, never raise it, and gets one agent review of that revision. Approving an edited draft needs a pass or concerns verdict, or an override note of at least 10 characters; the editor cannot approve their own edit while another approver exists (e1925471, 631ea0d4, 577d1e8e, 51e263bf, 384652e7).
Estate — service dependencies: Dynatrace Smartscape calls between services become traced dependency edges. A fault left the hourly sync from Jaeger and Prometheus service-graph connections recording no edges, without an error; after upgrade the first sync can add traced edges. Traced edges show and widen blast radius but fold nothing unless opted in (a054ed18, b01b3a63).
Connections — AWS reader trust: when analyses run on a separate reader, Test of a keyless AWS read role also reads the role's trust policy. If that trust does not let the reader assume the role, or a Deny names it, Test reads ok from the control plane only and names the fix, and Quick start keeps the source unverified. Audit perms reads IAM's simulator reply correctly, so AWS connections no longer all report as not introspected (f13954db, 6f2f793a, 5e6f68e6, 48139bb5, 3bc36268, de5f9efb).
Install — AWS roles: the deploy/aws module makes the read role trust the control plane and the runner and the write role trust the control plane only (control_plane_role_arn, runner_role_arn; platform_principal_arn stays as a validated, deprecated fallback). It always requires the External ID and keeps role names under aiops-* (12744184, d7fcd9dc, 825ce8b0).
Test Lab: the failure-mode strip shows never-started cases as their own segment, and the provision and teardown dialogs describe the six estates, both injectors and what teardown leaves behind (0776527b, a0881059, ecdf4a8b).
Estate — ontology: the control plane now keeps a model of the estate, reasoned with a vendored ontology library (open-ontologies-lite, pyoxigraph) and two pinned reasoner binaries in the image; without them the reasoner reports unavailable and impact falls back to an estimate. Each AWS, Azure and Kubernetes read connection is harvested into it in three layers: every resource, typed relations, then what an x-ray mission adds; a Kubernetes account that may not list cluster-wide is read namespace by namespace, from the connection's Namespaces field or its kubeconfig context. It runs before an x-ray, daily (aiops_inventory_interval_s) and on Harvest now (POST /xray/harvest); GET /xray/{id}/ontology.ttl downloads the model, and a check after every harvest and x-ray apply leaves agent claims that are off-vocabulary, dangling or contradict the harvest, and agent entities no recent scan saw, out of blast radius (407eef9b, 8712149e, 6860711e, caf05e8b, 312096ce, 5dca3690, 2e2d29fe, ae122e91).
Estate — blast radius on change requests: reviewing and requesting a change computes its impact over the model: current state, the resources it intends to touch, what else is affected and the relations lost or gained. When the plan carries no typed step, a runtime delta is inferred from its well-known commands (rollout restart; instance reboot, start or reset). The basis reads certified, computed, runtime or estimated, and a certified answer stores a downloadable certificate once per approval. The approval is bound to the basis, the intended resources, the lost relations and the risk, never to the affected list, so a later harvest does not stale it. Blast radius alone never raises the tier. The change planner, the RCA and the last-known-good cause read the same model (e8bc3066, d975af1f, 192f5c05, 45fe20c2, ab176895, 25a8907b, 70d7bf06).
Estate — the model follows changes: a platform change moves the model once its fix is verified, and a rollback applies the inverse. External writes harvested from CloudTrail or the Azure Activity log update a known resource exactly when the change is typed; otherwise the resource is marked stale and re-harvested. Each move is audited as Estate model updated (2365fe4e, ebb7d04d, a56973f2).
Estate x-ray — changes since last scan: each harvest is compared with the previous one. The scan report gains Estate changes since last scan (added, not seen, changed by the platform, changed externally) and the scan page leads with the estate map and its counts; each cloud and Kubernetes connection shows its last harvest (990a3d66, bf9fcebc, af047d7f, 3040b5d7, 176d35b7).
Estate — Estate map: Insights → Estate map draws the model in tiers (services and data, workloads, compute, network, accounts): the modelled objects by default, the business layer alone or every object on request, with search and a type filter. Clicking an object centres the map on what lies within 1 to 3 hops of it, with a breadcrumb back; a hub's many leaves fold into one group node. Overlays show a change request's blast radius, open incidents, the latest scan's changes and the flags (unmodelled, unexpanded, stale), explained in words. A lifecycle timeline lists the harvests, applied changes, rollbacks, external writes and scan context that moved the model. The map's state is in its address: incidents, change requests and the scan page link to it (GET /estate/graph, GET /estate/history).
Upgrade note — approved changes: a change that was approved but not yet released before this upgrade, on a workspace with a harvested estate, must be reviewed once more after the upgrade before it can be released.
Infrastructure — demo estate: infrastructure-as-code units for a small demonstration EKS cluster with AWS-native observability, reconciled by Argo CD. They are infrastructure only and do not change the product (9affd733, bff46a45).
Documentation: a new ecosystem and roadmap page maps every integration and agent block to its code, unbuilt ones grey and undated. Role, risk, P1/P2, report, runbook, intake and Dynatrace (§S8) pages follow this release (d32be7c9, 3d0be3f9, 4f164e1b, 8e1262db, ae0d0e80, 379ec8c9, 9164de29, 737f6773, a3cee10f, 5bce4064, 617fb148, 79a75537, 3b5c219b, 30a33a9d, e58936d8, 177d6e54, 1d2fcdb0).

0.1.110 — 8 October 2026

Compliance — posture history: Compliance findings adds Posture trend with Day/Week/Month, account and source filters, numeric results and Export period to Artifacts. One snapshot is saved per workspace at each UTC day's close. Solid periods use saved snapshots; faded periods reconstruct earlier history; outlined today is live. Coverage states when saving began and preserves gaps (7d40c3f0, 723b0d1d, f7de2862, fde679db, 80bf9245).
Compliance — account scope: filters, resource rows and exports can show the connection name beside the account ID; names require datasources.view. Platform checks EST-01–06 remain visible under the Account filter, matched to the account actually read. A note identifies rows hidden by the filter. Export for auditor includes an account column, and GET /findings/accounts supplies account choices (7fc3c9cd, 75da3ef0, 82a17dd5, 02cf0c9b, cc985e17, 15fda476, 8c0fb861).
Compliance — scanner pulls: reads are paced at about three per second and throttled requests retry after 1, 2 and 4 seconds. Each pull rechecks up to 500 open findings; rate-limited regions are reported as partial. The card reports a running sync and explains who can press Sync now. A Defender re-send with a known observation no newer than the recorded fix is skipped only within 48 hours of that fix. Missing or unparseable observation times are not classified as stale; an unhealthy re-send after the interval can reopen the incident (b19c02a9, f2950631, 2836c5a8, 28505a96, 94d0e380, 7e2e4f02, bf91ca0d).
Changes: captured EST-03/EST-02 writes can link a later change to the completed platform fix whose cleared condition they restore. The later change shows reverts CHG-…; the earlier fix shows undone by a later change and stays completed. These links are not backfilled and do not prove an unobserved write or repair (e799c59f, ee194506, 1e9bc113, d7575ca4, 0f82efce).
Incidents: Operate → Alert correlation adds the Service dependencies panel. Owners and operators can add or remove declared pairs; A → B means A depends on B. The panel loads its data on opening and explains source meanings and folding policy (4e0d7cc1, e1705528, f506f344, ed62cef7). A correlation-rule fold on the storm path no longer redirects later storm alerts into that incident without its own audit (abebeae9).

0.1.109 — 8 October 2026

Connections — keyless AWS: installations with any-account mode enabled can generate CloudShell setup for a customer-entered AWS account. Generated roles are aiops-<workspace>-read and aiops-<workspace>-write; manually created roles must be named aiops-* without an IAM path. The account hosting the platform, private-agent workspaces and existing staff-prepared bindings use prepared pairs. The read role trusts both platform identities; the write role trusts the control plane only, with the workspace External ID and sts:TagSession where required (35872fda, 36d26d82, 7ea86af4, 44752426, 3ff7eefb, b84a28b7, a7419f44, 64472c51).
Connections — setup and Test: the AWS form offers a trust policy for a role created by the operator, or explains missing platform setup before calling AWS. Refused keyless Tests name the setup checks and retain the STS Code: Message after AWS said:. Test uses the control-plane identity and does not prove runner access. The generated setup uses neutral naming (f318670a, 2ee0a1a9, aec92d2d, d0bb1548, d5937792, 8ffabfc8, c6539a08).
Compliance: workspace owners can set Pull from scanners automatically to Off, 5 minutes, 15 minutes, hourly, 6 hours or daily; the API accepts 0 or 300–86400 seconds. Compliance findings and its Resources card add an Account filter. A workspace's sole AWS connection can retrieve member-account clears (b2bd6fb1, 79002661, 5dc64bdd, 34db009a, aa03f10d, 900b42d6, cc631ace).
Test Lab — execution: residue checks protect the graded incident from a previous case. Pre-flight checks verify agent read access; cancellation is checked before injection, including after residue waits. Never-started cases remain FAIL with reason not_started and an informational report line; the UI failure strip does not yet list them (fixed in 0.1.111). The lab rejects its chaos engines' own Kubernetes Events on supported clusters. Teardown also removes its lab Git server, event guard and a LitmusChaos installation it provisioned, while retaining Chaos Mesh, the kubeconfig and past runs (0a569d29, 08f8962e, 863dfc4f, 7e51871b, ab31959c, 6ddca8d8, 10a570f9, 1a2dd223).
Test Lab — grading: grader v2 treats hyphens and underscores as separators, handles plurals and grades remediation_plan.manual_commands. For a service-name ground truth, an asserted root_cause_service decides when that field is present; other wrap-ups use root-cause prose. Free-text ground truths also use the prose. Certificates record the grader version, Compare rejects runs from different grader versions, and the model report excludes runs graded before v2 (ee953bb1, 43dc3540, fdeddadd). The catalogue also corrects action keys for pod-kill, cordon and HTTP-fault cases; decommission is marked xfail outside the change-lane denominator. These catalogue and grading changes make pass rates against the 0.1.108 catalogue not directly comparable (ea20fb8d, dd362fca, 70ba9ffa).
Install: customer-template control-plane and runner roles can assume only aiops-* estate roles, replacing the previous unrestricted role target (2fb48374). Example values enable AIOPS_KEYLESS_AWS_ANY_ACCOUNT, and aiops.runner.serviceAccount.awsRoleArn is passed to the control plane (35872fda). Staff configuration rejects a prepared non-aiops-* pair outside the platform account with HTTP 422 (a7419f44, 64472c51). Existing rendered IAM and values files are preserved: merging the release does not migrate them. Follow upgrade preparation before enabling the new mode.

0.1.108 — 7 October 2026

Platform / Test Lab: parallel workers re-check the shared case queue after polling cancellation. A worker no longer removes a case from a queue another worker has already emptied (d969a0db).
Install: supersedes 0.1.107. No investigation-engine change is included in this release.

0.1.107 — 7 October 2026

Incidents: alert storms separate by relationship by default, rather than folding unrelated services solely because they arrive together. CloudWatch anomaly-detection alarms receive resource attribution. Stale Security Hub re-sends do not reopen a finding after the platform has verified its fix on the resource; the portal shows the verified-fix state (0fbfd8c5, 9e69cb46, 85b4a7a5, 6c72d3ab).
Knowledge: owners can schedule estate x-ray re-scans. Discovered context carries its date so users can distinguish older context from a fresh scan (54fc286f, 6c72d3ab).
Security: secret-store key rotation re-encrypts stored workspace secrets using a supplied previous key. Deployment carries the previous key through the rotation. Workspace audit exports stream period-bounded events with a contiguous cursor and chain metadata; an offline verifier is provided. Platform account changes, including SSO and bootstrap changes, are audited. Production console bundles exclude mock fixtures. The web-tools switch reaches provisioned runners (45cc700b, 0ccb0561, 4390ed99, b7173418, fe1b2a7c, 49c49e44, c214c5fa, 370901aa, 6f9e4d27).
Platform / Test Lab: benchmark regression reports explain lane regressions while retaining the configured pass-rate floor. Certificates identify excluded cases and platform version; the trend keeps the newest 60 runs. Best-of-2 threshold fallback uses the measured setting (fec941e2, a3461286, 677733ec, 06200cc2, 944f1171).
Install: the customer template adds durability, monitoring and optional cost guardrails, a named alarm recipient and investigation-spend limits. Licence enforcement covers approved releases and API-mode runners receive the control plane's verdict. Both images use an exact Python dependency version set through constraints.txt; Helm is updated to 3.22.0 (9d4a76f9, e92a4552, 8e7f0fbf, 40065a25, 8818851f, daa64d6c, 088eb4d9). This release was superseded by 0.1.108 the same day.

For recorded recovery results and their limits, see the 7 October restore drill and 8 October customer-template restore drill. For remaining security limitations, see the security review.

0.1.105 — 3 October 2026

Platform: incident detail polling uses counts and a short tool-call tail; transcripts load separately. Failed-call digests and checkpoint suffixes reduce repeated payloads while keeping internal failure details private (2a19285c, 31512dd6, 98802861, 3f83a4bc, 4cbb1f32, dc31b17f).
Install: API-mode runners become the chart default. Graceful shutdown reaches the application process; multi-replica pre-stop handling, database connection recycling and deployment availability knobs are added (7f73306b, 35d8cfc8, 11f09164, 23017e1c, cde43c77). See availability and recovery for the supported architecture and its limits.
Security: workspace disablement remains staff-controlled; AWS regions are validated as host labels. Deleted users lose their memberships, and replaced runner deployments remove obsolete environment entries (94ef892c, 1fc5ebfb, 41b73aaf, 18a08d18).
Platform: ambient AWS credentials are cached until near expiry, and the chat MCP tool advertises read-only behavior (a292cd15, e626d664).

0.1.104 — 2 October 2026

Platform: owners can invite local accounts by link. Workspace creation requires the owner email, explains slug conflicts and prevents a pending invite from landing in another workspace (05e10b80, 9ae059f8, de0df778, e2d3e39a, b91e1b2e).
Compliance / changes: findings distinguish whether a typed fix exists. Prepared-change cards and release controls reflect what can actually run; an operator can request a fix requiring approval above their own tier (63f93a22, f21a54d3, 9049468a, 39420349, 6e7d2dad).
Security: API-mode runner pods no longer receive the secret-store key. AWS execution scope includes every declared region; Azure write access requires a subscription ID (63eaa073, c55d9abc, 1843eb63).
Install: the control-plane chart accepts a priority class (250fae49).

0.1.103 — 1 October 2026

Incidents / changes: recurrence matching follows the recorded incident rules. Revert drafts on a later repeat use the first relevant write and group repeated writes consistently with the probable-cause card. The card handles a newly created resource's absence correctly (c0be6a7b, 461e9b63, 9cacb631, 91315f46).
Platform: last-known-good records explain refused cause picks consistently with the card and avoid repeated ranking during a read; report text ends at a word boundary (5af1fdee, d02f8f67, daa6be3d, a9702603, d6f197d3).

0.1.102 — 1 October 2026

Incidents: declared resource criticality affects priority and investigation routing. Incidents distinguish new from recurring signals; alert event time and monitor history anchor change look-back. A probable-cause card ranks related changes, and resolved incidents produce a last-known-good record. A verified record supplies one window boundary to ranking, change history and revert drafting. A repeat can mark the prior fix as not having held; the pre-approved auto path blocks a fix recorded as not-good (042bfb7e, b5abc7b8, 00621079, 892a6930, bd227fef, cd21768c, 6e721d80, b8437365, 26a908a1, aeeb5797, b5fafd5f, 5a31a90e).
Changes: captured configuration writes are classified and linked to services. Application configuration can arrive through the change webhook. Typed execution captures post-change state separately from restore sources; revert drafts can target one change. Change lookup uses event time, and deployment change sets group CloudFormation writes (9496dd98, ecee87bb, 4854a0dc, 47d3fb78, 663be938, b24c2ae3, bfcb2adc).
Platform: chat notifications collect bursts into a digest; owners can set the burst interval. Benchmark golden sets round-trip cause evidence and grade the suspect change (8755b866, 1b39e82a, 761c980e, 87becbb0, d39081b8).
Security: configuration-content reads require approval, while bounded CloudWatch Logs Insights queries are supported. Secret-named environment values and embedded JSON secrets are masked; secret application configuration is withheld by name (0921d207, 23b1fd92, 0991ce9b, 36636829, 508e113f).
Install: bootstrap, onboarding and teardown scripts support a dedicated customer AWS account. Bootstrap validation checks region/model access, onboarding re-runs are safe, and teardown requires a real account ID (2f0dd46e, ea3d6998, 437fbacf, 569e87d4, 933ad783, c37e6139, 4d1e37bf, 00407bc1).

0.1.101 — 28 September 2026

Platform: failed runs record the cause; provider-routed models receive a bounded wrap-up token limit. The portal identifies model failures rather than describing them as mock runs, and adds a not-found page (6e09d868, 50452b37, 48218267, e2b921dc).

0.1.100 — 28 September 2026

Changes: revert drafts are offered only when a revert can be prepared; the portal stops offering fixes that cannot execute (80bbad0f, d61458c1).
Compliance: a failing Defender list call is reported as missing coverage (e7d043ae).
Install: deployer trust and pull-through role creation are corrected; database bootstrap avoids attaching to the application pod and validates its wait loop (d4899ac9, f7340c3c, 6661952d, 438d6df3, 477c4214).