Glossary

Plain meanings for the terms used in this product.

Reference · Updated 2026-10-27 · Describes release 0.1.164

What this chapter is for

This is the lookup table for the whole guide. Every term below appears on a screen, in the API, or in one of the other chapters. Definitions assume you have never used the product: read the second column to know what a word means, the third for the agent whose screens use it (incident, change, compliance, platform for workspace-wide set-up, all when every agent uses it), and the last to find the page that explains the machinery behind it.

Two things make the vocabulary worth reading rather than guessing. First, several words have a narrow, product-specific meaning that differs from common industry usage — Needs attention (escalated) is a normal outcome here, not a failure. Second, a few concepts appear under two different words because one word is a screen label and the other is the mechanism; those cases are marked, with the canonical word named.

The glossary

Term What it means Pillar Explained in
Alert One notification received from a monitoring source — Alertmanager, Grafana, CloudWatch, Azure Monitor, Datadog or a generic JSON post — through your tenant's webhook. Alerts are the raw input, not the unit of work: they are deduplicated and grouped into incidents, and each carries a status: Received (received), Root alert (correlated), Related — grouped (suppressed) or Cleared (ignored — the source resolved it, or the finding was suppressed). incident Dashboard, Operate and alerts
Any-account keyless (AWS) Deployment-enabled setup of aiops-<workspace>-read/-write in another AWS account without a per-account staff step. The platform's own account, private-agent workspaces and staff-prepared workspaces retain the prepared flow. platform Connect AWS
Approval A recorded human decision on one specific write an agent proposed: Approve, Deny with a note that is sent back to the model, or approve an edited version of the command. An agent's paused write is decided on the incident page, next to the trace that justifies it; a change request's approval on the incident or the change page. Needs you lists everything waiting for a decision and links to it; it has no decision buttons of its own. all Approve and run a fix
Artifact A durable output that outlives the run that produced it: a remediation pull request, an estate x-ray report, or an exported RCA. Artifacts are append-only — nothing edits one, and the only thing that removes one is the data-retention sweep, which takes an artifact with the closed record it belongs to once the workspace's retention window passes (never a certification artifact; see Data retention) — and only http and https links are ever stored. all Artifacts
Attestation A person's statement that a framework requirement is met, recorded with Attest (pillars.manage): an evidence note, a re-review interval of 1 to 1095 days and an optional evidence artifact. A later attestation supersedes an earlier one; nothing edits one. It is human evidence, not an automated check. compliance Security posture
Automatic API fix A certified runbook route that calls a cloud API making its own call with no per-incident click, because it repeats unchanged a fix the platform verified for the previous occurrence of the same alert. Off by default: it needs Allow pre-approved routes to auto-fire and its own switch on Guardrails & cost. incident Automatic API fixes for proven runbooks
Automatic fix A fix the platform runs with no per-incident click: a certified GitOps route opening its pull request (inert until a person merges it) while Allow pre-approved routes to auto-fire is on, an automatic API fix, or a certified step runbook releasing the standard change it matches. An incident's fix only: never for a flapping or unmapped incident, a compliance control, a scanner finding, a vulnerability or a security alert. incident Runbooks and automatic fixes
Before-state The target's state the platform reads and stores with a checksum just before a change writes to it (Pre-state per step): what a rollback puts back. With Refuse a change when its before-state cannot be captured on, a write whose before-state cannot be read is refused. A pull request keeps its before-state in the repository. change Approve and run a fix
Benchmark A scored replay of scenarios against a pillar agent, graded by code against declared ground truth. Sandbox mode is the default; explicitly enabling live datasources or web access changes what the agent may reach and makes the result incomparable with a sandbox baseline. The suite that decides whether you can trust the agents is your own golden set of historical incidents, not the builtin pack. all Benchmarks and scores
Blast radius What else the root cause affects. One of the six fields the agent must fill in its structured wrap-up, and its own heading in every RCA. incident Read an incident and its analysis
Change class How a change request is released: standard (a pre-approved fix: with Standard change for a runbook route's operations on, the default, a certified runbook route covers its operations — even at P1, released under the standard rules; with it off, a runbook matched and every typed operation is on the workspace's pre-approved list), normal (an approver releases it; at least L2) or emergency (any other P1 or critical incident: L3, two approvers, a closed change window yields once both approved, and a post-implementation review follows). A class can only make a release stricter, never looser; Reclassify raises it with a note while nothing has run, and demoting or disabling the runbook makes a standard request normal. change Review execution in Changes
Change request The record of one proposed change and everything that happens to it: class, scope, the exact reviewed action, approvals, execution, verification and rollback. Every analysis that proposes a fix drafts one (status planned, left out of the Changes list until someone requests approval); a person can also declare one. change Review execution in Changes
Change window The UTC days and hours inside which a person may release an L2 or L3 change (change_window, for example {"days": ["sat"], "hours": "22:00-06:00"}; an overnight range wraps midnight, but the day is checked on its own, so that example is Saturday 00:00–06:00 and 22:00–24:00 — add "sun" for the night into Sunday). Outside it the release is refused, except an emergency change on the approval that completes its quorum. A malformed window is read as open. change Change windows, emergency changes and rollback
Chat (spend class) The Usage & billing class (chat in the API and the CSV) that holds every analyst turn asked on Chat: fractional spend that costs what people ask, booked on the turn's own run record and never on an incident. platform Usage and billing
Certified route A remediation route an approver (approvals.decide) marked safe to run without a per-incident click — one exact route revision, never by anyone who changed the route since its last certification while another approver exists. The product also says pre-approved. Any change to what the route does drops it; a route pre-approved before certification existed reads certifier unknown. incident Runbooks and automatic fixes
Compliance finding An incident of the compliance pillar: one rule failing on one or more resources, raised by AWS Security Hub, Defender for Cloud, one of the platform's own checks or the telemetry PII scan (the Source column says which). It uses the incident statuses — open means found, not analysed yet — and is listed under Security posture, in the menu item of its compliance domain, never in the Incidents list. EC2.19-style codes are Security Hub control IDs; EST-02-style codes are the platform's own checks. compliance How incidents work
Compliance domain The area a compliance finding belongs to, each its own Security posture menu item: Posture (a configuration rule), Vulnerabilities (a vulnerable package or an unsupported version), Patching (Systems Manager SSM.1 / SSM.2) and Backup (a backup or point-in-time recovery setting, and the platform's EST-01 check). Derived from the finding's family and control on every read, never stored; a legacy storm incident that holds several rules lists under each of their domains. compliance Security posture
Concern A worry typed in by a person using Raise a concern. It enters exactly the same pipeline as a machine alert: it becomes a synthetic alert, correlates, routes to a pillar and starts an investigation. Raising the same concern twice deduplicates on its summary rather than opening a second incident. incident Dashboard, Operate and alerts
Connection jobs The account-wide reads an AWS or Azure read connection makes beside its agent tool: Estate inventory, Platform checks (EST-01..06), Security findings sync, Change capture and, on AWS only, Service map (Application Signals / X-Ray) and Built-in detection (runs only while the workspace has it on). Each is ticked or unticked on the connection under Jobs this connection runs (config keys harvest_inventory, platform_checks, sync_findings, harvest_changes, service_map, builtin_detection; a missing key means on). platform Several connections into one cloud account
Built-in detection Deterministic rules the platform evaluates for what no alarm watches, read-only: CloudWatch rules over the AWS estate inventory (R01–R30, outages and latency or faults above each service's own baseline) and Kubernetes pod and node state through a kubectl connection (R31–R34). Off until a workspace owner turns it on; it starts in shadow mode (would-have-fired hits only) and arms itself after 24 h of covered time. Its alerts have source builtin; a warning rule's incident is held until someone presses Analyse. incident Built-in detection (AWS)
Connector Short for connector type: the platform-owned catalog entry describing how to talk to one kind of system, including its fields and its request template. Connector type is canonical for the catalog entry; the instance you create from it is a datasource. Platform staff own the catalog; you own the instances. platform Manage connections
Correlation key The label alerts are grouped on: the alert's service. An alert with no service opens its own unidentified service incident while the triage queue is on (the default); with the queue off the key falls back to namespace, then alertname, then the alert's own fingerprint. Alerts sharing a key join the same incident however old it is, as long as it is not resolved — a Needs attention incident still joins; a resolved incident is not re-joined (unless the workspace sets a reopen window), so a recurring problem produces a series of incidents rather than one long-lived row, each tagged reopened, repeated or new when it opens. incident Storms, unmapped and flapping signals
Criticality How important the resource is (low to mission-critical), declared by an alert label or the workspace criticality map, never inferred. Not severity. incident How incidents work
Data retention How long a closed record — a resolved incident, a finished scan, a completed change, a cleared finding — is kept before the daily sweep removes it together with its runs, alerts, evidence and artifacts. One year unless platform staff set another default or the workspace sets its own window (30 days or more) on Guardrails & cost. Open records, knowledge and the audit trail are never removed, and the month's usage statement is sealed before its cost rows go. Separate from the lakehouse Retention window on the Lakehouse page, which sweeps collected telemetry rows (30 days by default), not records. platform Guardrails and cost limits
Datasource One connected instance of a connector type in your tenant — this cluster, that cloud account, your metrics server — which becomes a named tool the pillar agents can call. Each carries a role: read is rendered into the agents' tool list, while write marks a remediation-only credential that no agent can see, name or call. platform Manage connections
Demoted route A pre-approved route whose certification the first rollback of one of its runs took away, while Demote a pre-approved route after one rollback is on, or a certified runbook whose run failed its validation or whose fix did not hold, while Demote a certified runbook when its fix deviates is on (the default). It stops running on its own until an approver certifies it again; Needs you → Demoted asks a route editor to decide. incident Runbooks and automatic fixes
Escalation Handing an incident to a named human, shown as the status Needs attention (escalated in the API). It is the normal end state whenever a fix still has to be applied, not a failure of the agent. The word has a second, unrelated use in model routing — see model tier. incident Approve and run a fix
Estate x-ray (spend class) The Usage & billing class (xray) for service discovery: each scan is billed once, on its own scan record, within the budget entered at launch — never again under the incidents or knowledge it leads to. platform Usage and billing
Estate x-ray scan An agent run over chosen read connections that enriches the harvested inventory with services, dependencies, findings and draft recommendations; a discovery in these guides. Optional, and it costs model spend: up to the Budget (USD) set at launch (25 USD by default, capped by the platform's per-scan ceiling), booked under the Estate x-ray spend class. It harvests its connections before the agent starts. all Estate harvest and x-ray
Evidence The list of concrete observations the agent cites in support of its root cause; a required field of the wrap-up and its own section of the RCA. Every entry should be traceable to a tool call in the run's timeline. incident Read an incident and its analysis
Feature availability Every enabled tenant/workspace includes all product features. Historical grant and agreement rows do not control access. Your role and actual setup still matter. platform Members and roles
Grader version The rules for cases scored by this platform grader (v2 from 0.1.109). Relevant version-stamped results are named on certificates; legacy unstamped results from this grader count as v1. Other graders may have no version row. Compare uses matching versions; model reports select the newest version present. all What a score means
Fixed — awaiting CSPM An incident with a scanner finding whose fix is recorded — reported by a person, released through the platform or verified on the resource — that the scanner (the CSPM: Security Hub, Defender for Cloud) has not reported passed yet. A derived label on the incident header and list row, filterable with Fix state (?awaiting_cspm=true); never an incident status. The scanner's own clear ends it; a re-send that still fails drops the fix and reopens the incident. incident How incidents work
Flapping An incident whose alert resolved and fired again so often inside the reopen window that it reached the workspace's flap threshold (3 reopens when switched on). It keeps its id, never gets a pre-approved automatic fix, and proposes a problem record a person confirms or dismisses (or joins the one already open for it). Off unless set under Intake rules. incident Storms, unmapped and flapping signals
Freeze window A UTC window (change_freeze, the change-window shape) during which a change observed being made outside the platform is flagged Unauthorized. It flags; it blocks nothing outside the platform. change Change windows, emergency changes and rollback
Guardrail Any limit on what an agent may do, in two layers: floors that ship on and cannot be switched off — the write gate, lakehouse PII scrubbing, write-credential separation, the egress guard — and tenant-editable settings such as the cost cap, extra PII patterns, extra approval gates and the web allowlist. all Guardrails and cost limits
Harvest The estate harvest: a deterministic read of an AWS, Azure or Kubernetes (kubectl) read connection's inventory into the workspace's estate model, through its read-only credential. No agent runs and no model spend is booked. It runs once a day by default, before every Estate x-ray scan, and on demand with Harvest now (POST /api/aiops/{tid}/xray/harvest). A required onboarding step: the agents read the harvested inventory, the Estate map draws it and a change's blast radius is computed from it. A write-role connection is never harvested. all Estate harvest and x-ray
Human gate Informal wording for a decision that requires a person. The Dashboard and Needs you lead to the approval evidence; code-level write gates enforce the boundary. all Dashboard, Operate and alerts
Incident The unit of work: one root cause, however many alerts feed it, within the limits of correlation (see Correlation key) and storm folding (see Storm). It holds the status, the correlation key, the count of grouped alerts and, once an agent has run, the RCA. incident How incidents work
Investigation One agent run. It owns the model used, the tool timeline, the token and cost counters and the RCA; a single incident can have several. Chat turns, x-ray scans, rechecks and API completions are investigations internally, but none of them appear in the incident feed. all Read an incident and its analysis
Investigations (spend class) The Usage & billing class (operating) that holds every alert, pulled finding, scheduled or manual run and agent-API call — from the signal to the RCA and the change request, incident and compliance alike. It is the operating cost of incident response; the other four classes are deliberately kept out of it. platform Usage and billing
Knowledge item A stored, versioned piece of your own context that agents read: a runbook, a reference document, a per-pillar instruction, a service graph or an ontology. Saving supersedes rather than overwrites — the version number increments and the previous row is retained, inactive. all Knowledge base
Lakehouse The per-tenant telemetry store, one database file per tenant, that scheduled collectors fill with raw envelopes plus typed metrics, logs and inventory tables. Included in every enabled workspace. Every row is PII-scrubbed on write with no off switch, and the agent's query tool opens the file read-only and accepts a single SELECT. all Lakehouse
Last known changes The incident card listing the applied changes recorded on the incident's resources from the healthy boundary — the latest of where the previous error ended, where the alarm last recovered (CloudWatch back to OK; on Azure, the rule's previous alert resolved) and when the fix in a verified last-known-good record was verified; at most 72 hours back by default, and the same window the Probable cause ranking uses — until it closed: the platform's own and external ones from the cloud audit log. A storm, a compliance control, a scanner finding, or an incident whose window could not be read starts 24 hours before opening. Per resource it shows the before-state of the earliest change; Revert everything in this window drafts a revert of all of them — after a verified fix, back to that fix's verify and no further — on request and approved like any change. Its Captured from line names each audit-log connection with its newest read, a scheduled one or the pull when the incident opened. When no resource recorded a before-state the card reads Not applicable — no before-state to revert to instead (a platform change links to its own change page, naming Roll back only when that page offers it). A change history, not a verified good state: which change most likely broke the incident is ranked on the Probable cause card. incident Read an incident and its analysis
Last-known-good record The record the platform writes once an incident has stayed resolved through its one-hour post-close check: the probable cause change as the Probable cause card shows it — the analysis's pick when it is among the ranked candidates, else the platform's #1, never a change made during the incident (without a ranking, the change pinned to the incident) — the RCA, the steps that ran, each resource's state before and after with the diff, and the verification. Append-only, graded by code (verified, human_reported, unverified or failed), and marked did not hold when the incident reopens or its alert comes back as a reopened incident. Only a verified record's after-state is a last known good, and only until it is marked did not hold. incident Read an incident and its analysis
Managed-risk score The share of scanner findings that are scanner-cleared or suppressed, weighted by severity and by how far each fix reaches, shown above each compliance domain list under Security posture. It falls when a suppression expires or is revoked, while the scanner-cleared score does not move. compliance Security posture
Model tier One of four named slots — premium, reasoning, standard, light — mapped to real models, so work is routed by the kind of work rather than by hardcoding a model name. A tier you leave empty resolves to the nearest configured tier above it, then below. Model escalation is the platform moving a run up this ladder by fixed rules, never by asking another model. platform Models, tiers and routing
Ontology A semantic model of your estate: object types with their properties, the typed relationships between them, and the invariants they must satisfy. It is a knowledge item kind and the one deliverable an estate x-ray must produce. Objects merge by type and name, so the graph gets richer with each scan instead of being replaced. all Estate harvest and x-ray
PAT Personal access token: a bearer credential beginning ntp_ for the MCP servers, the REST API and the OpenAI-compatible agent endpoint. It is shown once at creation and stored only as a hash, carries your own permissions capped further by a read, write or admin scope, expires within a year at most, and can be revoked. Canonical wording is personal access token; it is not the webhook ingest token. platform Personal access tokens
PII pseudonym The token a scrub leaves behind, in the form [REDACTED:kind:sixteen hex characters]. It is derived from a per-tenant salt, so the same value always produces the same token — analysis that joins on it still works — while two tenants never produce the same token for the same value. platform Security and data
Pillar One of seven operational domains: incident, compliance, change, secops, finops, improvement and reporting. Each has exactly one pillar agent per tenant, with its own prompt, tool allowlist, extra gates, model, step cap and optional schedule. "Pillar" is the domain; "pillar agent" is the configured agent. all Configure the agents
Platform check One of the platform's own catalogue controls, as opposed to a scanner's finding: EST-01 to EST-06 read your cloud accounts through the read connections (backups, public storage, open security groups, encryption, audit logging, IAM hygiene), and the other prefixes check platform, repository and connection settings. A failing check opens or joins a compliance finding with source Platform check. compliance How incidents work
Platform staff Whoever holds a superadmin account on this installation and works in the platform console (/ops); after handover, your own platform administrators. A superadmin account has no access to a workspace's content without a membership or a time-limited support grant. platform Support access
Post-implementation review The review an emergency change owes once it executes — or from its submission, with Schedule the post-implementation review when an emergency change is submitted on: due in 72 hours by default, listed on Needs you as Review, closed by an approver with a note of at least ten characters. change Change windows, emergency changes and rollback
Posture trend Daily posture history: solid marks were saved at the UTC close, faded marks are reconstructed, and today's outlined mark remains live. A saved day's numbers do not change. compliance Compliance findings
Precedent What an API runbook needs before it repeats its call on its own: the previous occurrence of the same alert on the same service was fixed by this runbook at this exact revision, the platform verified the fix, the source reported the condition cleared and the fix held — within 30 days, with the same call and write connection. incident Automatic API fixes for proven runbooks
Priority P1 to P4, the order to work incidents in: set from severity, one step higher when two or more services sit in the incident's blast radius and one more for a mission-critical resource. incident How incidents work
Probable cause The incident card, above Last known changes, about the recorded change most likely to have broken the incident. Code ranks the applied changes made between Healthy since — the latest of where the previous error on the key ended, where the alarm last recovered and when a recorded fix was verified, none of them a proof of health — and the error start. The agent may name one recorded change, or none: the card shows its pick only when it is in the top five, and otherwise the platform's #1 as a ranking ("the analysis has not concluded"), never as a conclusion. Draft revert of this change drafts a revert of the change shown, from its State before this change. incident Read an incident and its analysis
Problem (proposed) A problem record suggested by a flapping incident rather than opened by the count of same-key incidents. Under Operate → Problems a person Confirms it (it becomes an open problem) or Dismisses it. incident Storms, unmapped and flapping signals
Proposal Short for skill proposal: a draft procedure waiting in the Knowledge base Review queue. It arrives from one of four sources — a human correction on an RCA, an observation the agent recorded during a run, an import from another workspace, or the automatic draft when an incident closes with a validated fix — and is built from your recorded rows by template, not written by a model. Nothing an agent uses changes until an approver accepts it. all Knowledge base
RCA Root cause analysis: the report an investigation writes at the end, containing an executive summary, the root cause and the failing component, the evidence, the blast radius, a proposed fix, a verification plan and a confidence figure. The model produces it as a structured wrap-up rather than filling a template, and it is the thing you rate and correct. incident Read an incident and its analysis
Recheck A bounded, read-only agent run that re-asks whether an incident's condition is still true right now, recording a verdict of Still present, Cleared or Uncertain — or, when no agent answered, Verify could not run (the turn errored) or Not verified (the budget refused it, or it is waiting out the backoff after repeated failures). "Recheck" is canonical for the mechanism and the card; verify and post-close verification name the recheck that pressing Mark resolved starts; post-fix validation names the one a released fix starts, which asks whether the service normalised rather than only whether the alert stopped. It never resolves an incident; a Still present verdict on an incident that was already closed re-opens it into escalated for a human. incident Verify recovery
Remediation route A declared channel for executing an approved fix: a selector for the incidents it matches, a mode (cli, api, mcp, network or gitops_pr) and the datasource that carries it out. Lower priority numbers are matched first; when nothing matches, the platform escalates to a human rather than guessing a write path. A workspace pre-approves a runbook through one: a route named remediate-… that an approver certified (see Runbook route). Ordinary fixes need no route. incident Legacy remediation routes
Reopened An incident's occurrence class, set by code when it opens: the newest incident on the same correlation key in the last 30 days fired the same alert (always, for a key that names the alert itself) — the same issue on the same resource. It links that incident and marks its record did not hold; a fix that did not hold twice in 30 days is not a good state. Its chip reads recurring ×N, the incident list recurring: a new incident, a repeat of that one. An incident that comes back after its own close — inside the reopen window, or when the post-close check finds the condition still present — is reopened too, and its chip reads reopened. When the newest incident on the key fired a different alert on the same service, the class is new, with a same-service count. The RCA's ## Occurrence section states it. incident Read an incident and its analysis
Repeated An incident's occurrence class, set by code when it opens: no earlier incident on its correlation key, but one on another key in the last 30 days carried the same issue — the metric that fired when the source names one (CloudWatch), else the alert name. For a cloud alert it must be in the same cloud account and, when the alert names its resource (instance id or ARN), on that same resource: another instance is not a repeat, unless the workspace turns on Count the same issue on another resource as repeated (off by default; the definition is still being confirmed). It links that incident and judges none of its fixes. incident Read an incident and its analysis
Reverts / undone by a later change Change links identifying a revert and the completed fix a later captured change undid; the original fix keeps its completed status. These links do not prove recovery. change Captured changes
Risk decision A person's decision on a scanner finding or a flagged resource — Fix (a change request) or Suppress (owned until an expiry) — with a reason and an expiry. It is sent as a request (Requested) and takes effect only when an approver other than the requester approves it, on its finding or under Decisions (Needs you lists it as Risk request); a sole approver may approve their own, recorded as self-approved, unless Never let a requester approve their own exception is on. compliance Security posture
Risk register Every such decision, with who requested and approved it, its scope, reason and expiry, under Security posture → Audit & coverage → Decisions; Export for auditor saves it as an artifact. compliance Security posture
Risk tier L0 to L3: who may release a fix and how many people must approve it. Not the model tier. all How incidents work
Route revision A fingerprint (shown as 8 characters) of what a remediation route does: its name, selector, mode, connection, parameters, tier and lifecycle flags. A certification is about one revision; turning the route on or off or changing its priority keeps it. Every route run records the revision it ran on its change record. incident Runbooks and automatic fixes
Runbook route A remediation route named remediate-… that covers a fix's operations; certified, it is the product's certified runbook: it may open its pull request on its own, give its change the standard class and, as an API runbook, repeat a verified fix. Not a knowledge runbook, which is guidance the agent reads. incident Runbooks and automatic fixes
Runner An optional separate process that claims and executes one tenant's agent jobs, so that upgrading the platform never kills a running investigation. If your deployment is configured to use runners and none is running, new investigations are enqueued and simply never start — the symptom is a job that stays queued. platform Troubleshooting
Same-account connections Two or more connections whose reads land in one AWS account or Azure subscription: the role ARN's account, the account a passing Test proved for the current settings, or the one Azure subscription a connection reads whole (no resource group). Each keeps its own agent tool; platform checks list a resource once per account, and Data sources groups them under one notice naming who runs each job. An access-key connection that never passed a Test belongs to no account yet. platform Several connections into one cloud account
Scanner sync Pull findings from connected scanners. Owners set Pull from scanners automatically; Sync now has a separate permission, and the result reports coverage/stale skips. compliance Pulling findings
Skipped route A pre-approved route that matched an escalated incident and did not run. The incident's Timeline says why, once per reason (Pre-approved route matched — not run); route editors see the ones a route edit or a setting would fix on Needs you → Not run. incident Runbooks and automatic fixes
Service dependency A → B means A depends on B, so A's alert can join B's open incident under the workspace's fold rules. The source legend distinguishes declared, traced, discovered and observed edges. incident Service dependencies
Severity How bad one alert or finding says it is: critical, error, warning or info, taken from the source. Not criticality. incident How incidents work
Skill A markdown procedure the agent fetches by name mid-run when it judges the procedure relevant, instead of carrying every runbook in its prompt. A builtin incident pack ships enabled; your own runbooks and reference documents become skills as well. all Knowledge base
Source suppression Writing an approved suppression back to the scanner — Security Hub workflow status SUPPRESSED, or an Azure Policy exemption — through the write connection, while Suppress scanner findings at the source is on. Revoking the suppression lifts it; its expiry lifts it only while Act when an exception expires is on. compliance Turn on compliance
Stance Part of a scanner finding's fixed classification, beside its family: auto (its fix is eligible for a pre-approved change a person releases, never an unattended fix; auto · manual today when the control has no typed fix yet), human or ticket. compliance Security posture
Statement month (UTC) The unit of the Usage & billing statement and the platform invoice: a UTC calendar month, each run assigned to the month in which it started. The month in progress is labelled month to date; its figure still grows. platform Usage and billing
Storm A cross-service burst that ordinary label grouping cannot contain. Since 0.1.147 it is grouped by the service graph, never by a count: a failing dependency and the failing services that depend on it become one incident on the top-most failing service, at once over edges allowed to fold and by the grouping agent (on by default, aiops_storm_agent) over every recorded edge; victims stay as suppressed evidence and merged incidents record merged_into_id. Unrelated services stay separate incidents, except that an alert name already firing on 3 services joins their incident (shared-cause). The agent is bounded by budget, pause state and interval; digests throttle notifications separately. incident Storms, unmapped and flapping signals
Support access A time-limited, audited operator membership that platform staff can grant themselves inside your tenant in order to help with a problem. It appears in your members list with a SUPPORT badge, expires by itself after 24 hours by default, and an owner can revoke it at any time. platform Support access
Suppression Leaving one flagged resource of a platform check (EST-01 to EST-06), or a scanner finding, out of the fix, with a reason, an owner and an expiry. It is a request until an approver approves it (see Risk decision). The resource is still scanned and recorded as suppressed, never as a pass; when the suppression expires or is revoked, the next scan flags it again. The risk register lists it with outcome suppressed; its export keeps the API outcome accept. compliance Review execution in Changes
Tenant Your isolated workspace. Every alert, incident, datasource, credential, secret, lakehouse file and audit row belongs to exactly one tenant, and nothing reads across the boundary — including platform staff, who need a support grant to see inside. platform Getting started
Test Lab (spend class) The Usage & billing class (test) for benchmarks and the lab box: deliberate test spend, never operating cost — shown so it can be budgeted, and kept out of every operating figure, the service delivery report and the model-tier suggestions. platform Usage and billing
Tool call One invocation of one connected system by an agent, such as prod-prometheus_request or kubectl_exec. Every call is recorded in the investigation's timeline with the exact invocation, its status and its output; that timeline is the evidence behind the RCA. all Read an incident and its analysis
Unidentified service (unmapped signal) An alert with no service label after the workspace label map and its mapped source, while Send alerts that name no service to the triage queue is on: it opens its own incident keyed on its fingerprint, is never grouped, starts no analysis, files no ticket, sends no notification and never gets an automatic fix, and waits in the triage queue until someone maps its source or presses Analyse. incident Storms, unmapped and flapping signals
Unmanaged change A change made outside the platform — captured from the cloud audit log (by a principal outside the platform), or reported by a webhook or an operator — never requested, approved or executed here. One of the observed changes (stored as source ingested), next to the platform's own writes the audit log recorded, writes made with the platform's credential that no platform record accounts for, and deployments of a platform change; each row's badge says which. change Review execution in Changes
Validation (spend class) The Usage & billing class (verify) for the read-only recheck after a fix — did the condition clear, did the change hold — booked apart from the investigation it validates, so the cost of the diagnosis and the cost of proving the fix can be told apart. platform Usage and billing
Write gate The rule that classifies every tool call as a read or a write and never lets a write reach your estate unattended. It is a floor: your own configuration can add gates on top, but can never remove one. On the shipped default a write proposed while the agent is still diagnosing is refused and returned to you inside the remediation plan instead of pausing the run. all Approval policy → The write floor
X-ray Estate x-ray: a one-shot, read-only deep scan across chosen datasources that produces an inventory, findings, an ontology and ready-to-apply drafts. Included in every enabled workspace. Every write the scan attempts is refused and counted regardless of what the credential would allow, and applied drafts arrive switched off — knowledge inactive, collectors and routes disabled — until a human turns each one on. Canonical label: Estate x-ray. all Estate harvest and x-ray

Where two words mean one thing

The interface, the API and this guide occasionally use different words for the same concept, usually because one is a screen label and the other is the underlying mechanism. Use the canonical word in tickets, runbooks and support requests.

| You may see | Canonical word | Why the two exist | |---|---|---|---| | Human gate | approval gate | A human decision required by the write gate. Review it from Needs you or the incident. | | Home / Mission overview | Dashboard | Older names for the landing page. The Dashboard starts with the human gate. | | Connector | connector type | The catalog entry is a connector type, owned by platform staff. What you create from it in your tenant is a datasource. | | Verify, post-close verification | recheck | Both name the same bounded read-only run. "Verify" is reserved for the recheck that Mark resolved starts. | | Post-fix validation | recheck | The recheck a released fix starts. Same mechanism, stronger question, and the only one that can close an incident. | | Run | investigation | One agent run against one incident. "Run" is fine in conversation; the record is called an investigation. | | Root cause analysis | RCA | Spelled out on first use in each chapter, abbreviated afterwards. | | Agent | pillar agent | There is exactly one per pillar per tenant. "Agent" alone is fine after the first mention. | | Token | personal access token (PAT) | Three different credentials exist: a personal access token, the webhook ingest token, and a runner token. Name which one you mean. | | Discovery | Estate x-ray | Estate x-ray is the navigation label; a scan is still called a discovery in these guides, and API paths keep xray. The harvest is not a discovery: it is the deterministic inventory read a scan starts from. | | Skill proposal | learned skill draft | The Review queue tab holds skill proposals awaiting a decision. | | Pending activation | draft, inactive knowledge version | The Knowledge page badge for an inactive version with nothing newer under its name that nobody turned off, with Disable or by activating an older version; Activate is its next step. | | escalated | Needs attention | Needs attention is the screen label; the API, filters and URLs keep escalated. The Escalate button is the action that sets it. | | Accept risk, risk acceptance, exclusion | suppression | The screens say Suppress and, in the risk register, suppressed (before October 2026 they said exclude); the API (accept_control_exception, outcome accept) and the register's export keep the risk-acceptance names. | | Last known good, LKG | Last known changes; last-known-good record | The change list on the incident is Last known changes. Last known good itself names a state a verified fix left: the after-state in a verified last-known-good record not marked did not hold. The State before this change on the Probable cause card is what a revert restores; it is unverified unless it equals such a record's after-state. The API path /lkg, the MCP tool incident_last_known_good and the Test Lab lane Last known good keep the older name. |

Five words that mean something specific here

These are the terms most often misread by someone arriving from another incident tool. Each one is a real behaviour of the shipped product, not a simplification.

If a word you need is missing here, the chapter that owns the surface defines it in context; start from Getting started and follow the cross-reference in the third column above.

Next steps