# Release notes 0.1.161

> 27 October 2026: The dashboard after its first day on a live workspace: the hub is drawn as one picture, so the rings keep their places at every window width; the page shows the three pillars the…

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

## 0.1.161 — 27 October 2026 {#0-1-161-27-october-2026}

The dashboard after its first day on a live workspace: the hub is drawn as one picture, so the rings keep their places at every window width; the page shows the three pillars the product sells today and hides SecOps, FinOps and Continuous Improve until a workspace lists them; a ring, its Pillar health row and its section read one "unresolved"; and the MTTA and MTTR tiles say how many incidents they rest on and compare nothing from fewer than five. List tables fit their card from 1024 px instead of scrolling sideways. A change request's blast radius card and its document's 2.4 Impact and 2.5 Risk say one basis sentence and the estate map's coverage gaps by kind, against the whole map. The estate map keys a Lambda function's versions and aliases by the function, so it no longer lists each function twice (a second card named `$LATEST`), and a wall of identical objects folds into one group node. One new setting, `aiops_dashboard_pillars` (`dashboard_pillars` on `GET`/`PATCH /api/aiops/{tid}/guardrails`, `members.manage`, the **Dashboard pillars** card; default `incident`, `compliance`, `change`); `GET /api/aiops/{tid}/dashboard/summary` carries `shown_pillars`, `shown` per ring and `samples` per mean. No new route, permission, audit action, schema change or chart value. Nothing to do for the upgrade itself; the next estate harvest of each AWS read connection removes the duplicate function entries a map harvested before 0.1.161 holds (see the [upgrade row](/help/ops-upgrade-and-verify.md)).

- **The hub keeps its shape at every width.** The pillar rings were HTML discs sized in rem over a percentage box, with the spokes in a separate picture: at about 1950 px the SecOps ring sat on the Human gate ring, its label hidden, and the dotted spokes ended nowhere. The hub is now one SVG with a viewBox: the rings sit on a circle around the gate, evenly spaced from the top (three pillars: top, lower left, lower right; two: top and bottom), the spokes run from halo to halo, and the whole picture scales with its box, so no ring can meet another or the gate — checked in the browser at 390, 768, 1280, 1920 and 2400 px, light and dark, and in the geometry for one to six rings. Its type is sized in the picture's units, so it shrank with it (7.7 px at 390 px against 0.1.160's 10–11 px): a hub narrower than about 430 px now sets its labels larger, and every label reads at 10 px or more and sits inside its circle at every width — the rings and the gate are drawn a little larger to hold it.
- **Three pillars until a workspace lists more.** The Dashboard shows the pillars the workspace lists under **Guardrails → Dashboard pillars**: only their rings, **Pillar health** rows and sections render, and the hub copy reads *across the pillars this dashboard shows*. The platform default is Incident & Problem, Compliance and Change Mgmt; SecOps, FinOps · Optimise and Continuous Improve are hidden until listed, and their counts stay in the summary the page reads. The list applies on the next read, not a minute later; an unknown name or an empty list is refused (`400`), `null` follows the platform default again; the **Dashboard pillars** card's *Follows the platform default* line prints the default the control plane reports, not a copy of it. The sidebar has no per-pillar entry (grouped by task since September); its **Incidents** badge is covered below.
- **One "unresolved" per pillar.** The Incident ring counted the Incidents list's unresolved rows (every pillar but compliance) while the **Pillar health** row counted the incident pillar alone, so the hub read 19 and the row 3. Each ring's figure is now the total of the list it opens, and the row and the section headline read the same number: Incident = the Incidents list under *Unresolved (any but resolved)*, Compliance = the findings list under the same filter, Change = the requests pending approval, Improve = the open problems. The column is labelled **Unresolved**; the section links read **Unresolved incidents**, **Unresolved findings** and **Waiting for approval** (the requests pending approval). **Pending approvals** counts in the same scope as the row's **Unresolved** — for Incident & Problem a paused write of any pillar but compliance, a SecOps one too — so the column adds up to the **Human gate**: a paused write of a hidden pillar counted at the gate and in no row. The sidebar's **Incidents** badge is the Incident ring's number: it reads the list's unresolved total from the server (`X-Total-Count` under `?status=unresolved`) instead of counting the first 500 rows in the browser without *escalated* — it read 4 beside a ring of 6.
- **MTTA and MTTR tiles say what they rest on.** MTTA read *0s · no previous 30 days to compare* and MTTR *2.3 h · +268 % vs previous 30 days* in red over a handful of resolved incidents. **MTTR**, **MTTA** and **Alert noise reduced** now print the rows each window rests on — *over 7 resolved incidents*, *over 9 analysed incidents*, *over 412 alerts* — and compare only when both windows have at least five; with fewer the tile reads *too few to compare*. An MTTA under a minute reads *under a minute · analysis starts on open*: an alert's analysis begins the moment its incident opens, so "0s" was true and misleading. The Incident section's MTTA and MTTR carry the same counts; a window with no previous window at all reads *no previous 30 days to compare*, whatever its count, and a window with no rows says nothing about them (never *over 0 resolved incidents*). **Auto-handled events**, a count, compares the same way: 1 against 2 reads *too few to compare*, not *+100 %*.
- **List tables fit the page.** The **Incidents** list (and the other list tables) scrolled sideways inside its card at ordinary desktop widths, hiding the right part of its first column; a SecOps denied-access report titled with the caller's assumed-role ARN widened the list on exactly the row that was reported. From 1024 px a long identifier (a correlation key, an ARN, a hash) and a title that carries one break inside their column, dates break only between the date and the time, an email or an artifact's source label stays on one line, and badge groups and action buttons wrap. The service-group tables on **Estate**, the collection-spec table on **Lakehouse**, the role permission grid and the posture numbers fit at 1024 px too; a table whose columns cannot share one screen — the Test Lab run ledger, the x-ray scan list and the console's connector catalog at 1024 px only, the x-ray phase table, a Lakehouse query result, a documentation chapter's reference table — scrolls inside its own box. Tables in an RCA, a chat answer or a report wrap a long code token instead of widening the card. **Archive** shows the **Closed** and **Archived** dates again: both columns rendered empty.
- **The blast radius card speaks with one voice.** The card under **Affected resources & blast radius** said an estimate three times and set the change management agent's *No impact* beside *Estimated impact* as a second verdict. It now prints one basis sentence (*Estimate: computed from the target's direct neighbours in the estate map; this operation has no exact before/after delta.*, or the report's own reason instead — *Estimate: target not found in the harvested estate*), then the map's coverage gaps one line per kind, only when non-zero and each against the whole map — *N of M resources in the estate map: no relationship model yet (types without a typed reader: …)* (only types no reader models are named), *… stale after the last harvest, left out of reasoning*, *… inconsistent between sources, left out of reasoning*. The kinds no longer overlap: one change request read 5,257 + 2,078 of 5,947, with 1,845 resources counted twice. An estimate's affected list is the target's direct neighbours, unmodelled and unexpanded ones included, never the account, subscription, team or owner the target sits under. The agent's words read as a conclusion on the same basis (*The change management agent read the same neighbourhood: …*) only while the report shown is the one its draft read — the draft records the report's estate version, basis, mode and a fingerprint of what it lists as `meta.cr.impact_read` (the report's `fingerprint`), so a report redrafted with another scope is not taken for it — and *No impact* is spelled out only over a report that reasoned over the target and found nothing negative — as *nothing loses reachability, a route, a permission or a dependency* over a certified or computed delta, as *nothing depends on the target through the estate model* over a runtime one (a start, reboot or restart); otherwise the words show as written. The change request document's **2.4 Impact** prints the same lines and, with nothing negative, the card's headline with its basis label, and **2.5 Risk** now cites the blast radius it weighs the risk against (headline, basis sentence and gaps, without the agent's words), in Markdown and in Word.
- **The estate map lists a function once.** Resource Explorer and AWS Config list a Lambda function once per version and alias (`…:function:<name>:$LATEST`, `:3`, `:live`), and the harvest kept each as its own resource: every function sat on the map twice, the twin named `$LATEST` and unmodelled, and a change request counted the twins as resources left out of reasoning. The harvest now keys a Lambda function's versions and aliases, and a Step Functions state-machine version, by the unqualified ARN, names it by the resource and keeps the versions and aliases as the properties *versions* and *aliases*; a change target or a relation that names an alias (an alias update targets `…:function:<name>:live`) resolves to the function, and a recorded alias update (CloudTrail keeps the alias ARN) marks the function stale instead of adding a node of its own. An ECS task-definition revision and a Lambda layer version keep their own nodes: each is registered or published, permissioned and deleted on its own. A map harvested before 0.1.161 is cleaned by the next harvest of each connection: a twin of a function the map holds is removed, and a function the map no longer holds keeps one node under its own name.
- **A wall of one type folds.** Seventy-seven Lambda functions with no VPC drew as 77 identical cards on the **Estate map**. More than twenty objects of one class that share the same neighbours, or have none, now fold into one dashed group node (*24 functions · click to expand*) that unfolds on click, like a hub's leaves; the group keeps every edge. A search or a **Type** filter lists its hits one by one.


## Next steps

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