> For the complete documentation index, see [llms.txt](https://docs.autopilotmonitor.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autopilotmonitor.com/rules/analyze-rules.md). # Analyze Rules Automated analysis of every enrollment session — findings with severity, confidence, explanation and remediation, from rules you can manage and extend. Analyze rules are the analysis engine of Autopilot Monitor. Every enrollment session is automatically evaluated against all enabled rules — no one has to watch the dashboard for problems to surface. A rule that matches produces a **finding** on the session: * a **severity** (info / warning / high / critical) and a **confidence score**, * an **explanation** of what was detected, with the actual evidence from this session interpolated in (app names, error codes, durations), * **remediation steps** that tell you what to do about it, * optionally, links to related documentation. Findings appear as cards on the session detail page and feed the analysis summary, fleet statistics, and per-rule telemetry (how often each rule fires across your enrollments). ## In this section
ConceptsThe anatomy of a rule: conditions, sources, operators, preconditions, and confidence scoring.Concepts
Built-in Rules ReferenceThe catalog of all built-in rules — what each detects and when it fires.Built-in Rules Reference
Template RulesConfigurable blueprints: fill in your environment-specific values and get a tailored rule.Template Rules
CookbookSeven worked recipes for building your own rules, from five-minute template to end-to-end custom detection.Cookbook: Build Your Own Rules
## Managing rules in the portal The **Analyze Rules** page (requires the Admin or Operator role; editing requires Admin) shows all rules with search, severity/category filters, and type filters (Built-in / Community / Custom). Rules are grouped by category. Each group header shows how many rules it holds and how many are active or custom, and can be collapsed; **Expand All** / **Collapse All** sit above the list. Your collapsed groups are remembered in the browser, separately for the Rules and Templates tabs. While you type in the search box every group stays open so no hit is hidden. Each rule card offers: * **Enable/disable** per tenant — your choice is preserved across product updates. * **Evaluation triggers** — by default a rule runs at enrollment end; custom rules can additionally run while the enrollment is still in progress (at the WhiteGlove seal or when specific events arrive). Such findings appear live as *Preliminary* and are confirmed or resolved by the final analysis — see [Concepts → Evaluation triggers](/rules/analyze-rules/concepts.md#evaluation-triggers-when-a-rule-runs). * **Mark session as failed** — a per-rule toggle that makes a firing rule fail the whole session (a "knock-out criterion"). A few built-ins ship with this on by default; you can override it. * **Fire statistics** — how often the rule fired and its hit rate over the last 30 days, plus a 30-day sparkline of daily fires, so you can see which rules actually earn their keep in your environment. For a different range, add `?days=` to the page address (up to 90 days on Community, 365 on Pro). * **Regression badge** — a red **↑ Regression** badge appears while a rule is firing markedly more often than it used to (see below). * **Edit / Export** — custom rules are fully editable in a form or as raw JSON (the **Form ⇄ JSON** toggle); built-ins are read-only but can be exported as JSON to use as a starting point for your own. * **Test against a session** — the create and edit forms run the draft, exactly as it would be saved, against a session you name: the verdict, every condition with its evidence and event count, the confidence score and a preview of the explanation. Nothing is saved; test a session where the rule should fire and one where it should stay silent. ## Regression detection A rule that suddenly starts firing far more often than it used to is a signal in itself: something changed in your environment — a Windows build, a driver, an app version, a policy — and it changed for the worse. Autopilot Monitor watches for that automatically, once a day, per rule and per tenant. A rule is flagged when **all** of the following hold: * its hit rate over the **last 7 days** is at least **twice** its rate over the **preceding 28 days**, * the increase is **statistically separated** — the confidence intervals of the two rates do not overlap, so a quiet week followed by a busy one is not enough, and * the window carries real volume: at least **5 sessions with a hit** and **20 evaluated sessions**. Rules younger than about a month, rules you edited inside the window, and rules without a baseline are deliberately skipped — a new or changed rule has no "usual" to compare against. When a rule is flagged you get a **bell notification** that links to the rule card, and the card shows the **↑ Regression** badge for as long as the episode lasts. Both carry the actual numbers (*"18 % of evaluated sessions in the last 7 days vs 4 % baseline"*), and where the affected sessions concentrate on one **OS build, device model, agent version, or IME version**, that share is reported too — as a correlation to investigate, not a cause. The episode ends when the rate falls back to normal, and only then can the same rule alert again, so an ongoing problem never turns into a stream of notifications. Regression detection covers **analyze rules**; [gather rules](/rules/gather-rules.md) collect rather than judge and are not part of it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.autopilotmonitor.com/rules/analyze-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.