# Settings added since 0.1.157

> The workspace settings added since 0.1.157 — demotion on deviation, canary execution, the repeated-incident rule, patch schedules, the Dashboard pillars — with key, shape, default, card and effect.

_Reference · Updated 2026-10-27 · Describes release 0.1.164_

The [Settings reference](/help/settings-reference.md) is at its page size, so the settings added since 0.1.157 are listed here in the same columns. They are layered, written and read exactly as that page describes ([How settings are layered](/help/settings-reference.md#how-settings-are-layered)): the three switches ride `GET` and `PATCH /api/aiops/{tenant_id}/guardrails` (`members.manage`), answer flat with their layers under `switch_state`, and take `null` to follow the platform default again; the patch schedules are a map on the same endpoint.

## Automatic fixes and change class {#automatic-fixes-and-change-class}

Rows of the reference's [Automatic fixes and change class](/help/settings-reference.md#automatic-fixes-and-change-class) table.

| Field → stored key | Shape · default | Card | What it changes |
|---|---|---|---|
| `demote_on_deviation` → `aiops_demote_on_deviation` | `true`/`false`/`null` · `AIOPS_DEMOTE_ON_DEVIATION` (on) | same (*Demote a certified runbook when its fix deviates*) | A certified runbook route whose run fails its validation, or whose fix does not hold, loses its certification until an approver re-certifies it ([Demotion](/help/runbook-library.md#demotion)). |
| `canary_execution` → `aiops_canary_execution` | `true`/`false`/`null` · `AIOPS_CANARY_EXECUTION` (off) | **Pre-approved operations** (*Run a multi-resource change one resource first*) | On: a released change that writes to several resources runs the first resource's steps, reads that resource back with each step's own check, and only then the rest; a check that contradicts the step stops the run before any other resource is touched, so only that resource needs rolling back (released as any failed change's rollback), and a read that cannot observe it does not stop the run. The first resource is the one the plan writes first, and the order is part of what is approved: the review binds the canary point into the request, so what was approved is what runs whatever the switch says later. Off: every step runs in turn. See [Review execution](/help/review-execution-in-changes.md). |

## Intake rules {#intake-rules}

A row of the reference's [Intake rules](/help/settings-reference.md#intake-rules) table.

| Field → stored key | Shape · default | Card label | What it changes |
|---|---|---|---|
| `repeated_other_resource` → `aiops_repeated_other_resource` | `true`/`false`/`null` · `AIOPS_REPEATED_OTHER_RESOURCE` (off); returned flat, its layers under `switch_state` | **New, reopened or repeated** (its own card below Intake rules) | On: [repeated](/help/read-an-incident.md#repeated-resource) also counts the same issue on another resource of the same account; off keeps the rule since 0.1.148. |

## Changes and remediation {#changes-and-remediation}

A row of the reference's [Changes and remediation](/help/settings-reference.md#changes-and-remediation) table.

| Field → stored key | Shape · default | Card | What it changes |
|---|---|---|---|
| `patch_schedules` → `patch_schedules` | `{"<service glob>": {"lead_hours": 1..336 (24), "owner": "<email>", "route_id": "<step runbook id>"}}`, `route_id` optional · none | **Patch schedules** (Change control, under the maintenance windows) | At `lead_hours` before the service's maintenance window next opens, the platform plans one change request for the EC2 instances of that service Patch Manager reports non-compliant (the open Patching findings and Security Hub SSM.2; an instance belongs to the service by its `service`, `app`, `application` or `Name` tag or its instance id), compiles the patch step runbook once per instance (`route_id`, else the first enabled step runbook with a patch step), notifies the `change_schedule` targets and emails the owner. A person approves it and the approval schedules it for the window; a run nobody approved before its window opened is rejected and the next opening plans afresh. One run per opening, at most 25 instances. Refused (`400`) while no maintenance window applies to the pattern, also when a window edit would remove it. See [Change control](/help/change-control.md). |

## Dashboard (0.1.161) {#dashboard}

A row for the [Dashboard](/help/dashboard.md): the pillars it shows.

| Field → stored key | Shape · default | Card | What it changes |
|---|---|---|---|
| `dashboard_pillars` → `aiops_dashboard_pillars` | list of `incident`, `compliance`, `change`, `secops`, `finops`, `improvement` (stored in that order, at least one) or `null` · `AIOPS_DASHBOARD_PILLARS`, a JSON list (default `["incident","compliance","change"]`; one that names no pillar falls back to it); `GET` also returns `dashboard_pillars_inherited` | **Dashboard pillars** (Guardrails, the last card) | Which pillars the Dashboard shows — their rings around the human gate, their **Pillar health** rows and their sections. SecOps, FinOps · Optimise and Continuous Improve are hidden until listed; their counts stay in `GET /dashboard/summary`, whose `shown_pillars` names the listed ones. `null` follows the platform default again; an unknown name is `400 unknown pillar: …` and an empty list `400`. Applies on the next read of the page, never a minute later. |


## Next steps

- Next: [Thresholds and why](/help/thresholds-and-why.md)
- [All Reference pages](/help/reference/llms.txt)
- [Documentation home](/help/)