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 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): 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

Rows of the reference's 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).
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.

Intake rules

A row of the reference's 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 also counts the same issue on another resource of the same account; off keeps the rule since 0.1.148.

Changes and remediation

A row of the reference's 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.

Dashboard (0.1.161)

A row for the Dashboard: 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