Compliance
The Compliance view is a heatmap of Fact Policy results over time — at a glance, which compliance rules are passing or failing across your estate, and when each rule last changed. It turns the facts MisterShell collects into a continuously-updated answer to “are my resources configured the way policy requires?”
Compliance results are a projection of Fact Policy rules: you do not configure anything here. To change what is measured, edit the rules and checks under Govern → Fact Policy.
Where it appears
The same heatmap is available at three scopes:
- Fleet — on the Monitor Dashboards page: every rule across the whole estate.
- Location — in the Summary card on a Location detail page: every rule across the resources at that location (and its sub-locations).
- Resource — in the full-width Compliance card below metrics on the resource Summary tab: every rule that applies to that one resource.
On resource and location pages the card appears only when an administrator has enabled Facts, you hold app.fact_policies.execute within the scope, and the fact-policy capability is licensed; the fleet-level Dashboards tab is shown based on the permission alone.
Reading the heatmap
- Rows are rules; columns are time buckets. Each cell is colored by the rule’s aggregated status during that bucket.
- The timeframe selector (24h, 7d, 30d, 90d) sets how far back the heatmap reaches. Buckets are hourly for short ranges and daily for longer ones.
- Statuses, per the legend:
| Status | Meaning |
|---|---|
| Pass (green) | The evaluated pass/fail results were all Pass. Additional N/A or Error results remain separately counted. |
| Fail (red) | The evaluated pass/fail results were all Fail. Additional N/A or Error results remain separately counted. |
| Mixed (yellow) | Some resources passed and others failed (fleet and location scope). |
| N/A (grey) | No pass/fail result or evaluation error exists: the rule was not applicable or no usable root observation was available. |
| Error (dark grey) | An evaluation error exists and the aggregate has no Pass or Fail result. An error does not erase a known aggregate verdict. |
A separate error marker and counts remain visible even on Pass, Fail, or Mixed cells. Each cell uses the result active at its bucket timestamp, carrying it forward until the next recorded change. The drill-down uses that same instant.
Because Fact Policy is all-match, each rule is shown independently, regardless of rule order. An explicitly observed empty collection can Pass or Fail according to the check’s quantifier; it is different from having no observation or no evaluation yet. See the quantifier table.
Drilling into a cell
At fleet or location scope, click a cell to open Compliance Summary with Pass, Fail, N/A, and Error resource counts. Select a status to open its paginated resource list. Click Details on a row to inspect its stored explanation; resource links remain available separately. At resource scope, click the cell to open that rule’s details directly.
Each check has one summary row with its name, verdict, and evaluation date. Two bordered sections with chevrons start collapsed:
- Definition shows the assertions and direct relationship conditions used for that evaluation.
- Result shows matching facts for a passing check, including matching directly related facts. Other verdicts show No match. A passing absence or zero-count assertion can have no matching facts; the result explains this. When stored samples or values are truncated, they are marked.
The summary verdict is the check’s assertion result. For Match: Fail rules, the rule verdict in the heatmap is inverted; check results are not. Errors and N/A are never inverted. Evaluations with no check rows show a brief explanation instead.
Historical details use the definitions and results recorded for that evaluation, even if a check was subsequently renamed, edited, or deleted. Missing historical definitions or results are identified; the UI does not reconstruct them from today’s check. To inspect collection diagnostics and nonmatching examples, use Test assertions in the check editor against the resource’s latest facts.
Access to observed values
Compliance readers can inspect verdicts and definitions. Matching observed values additionally require app.resources.read and resource access at the resource’s location. For passing checks, Result explains when this access is missing. Restricted results and results that were never recorded are distinct states.
How the data is produced
Each rule is re-evaluated whenever a resource’s facts are collected (on every snapshot), and results are versioned, so the heatmap reflects history rather than just the current state. A cell that just turned red means a resource flipped to non-compliant during that bucket; status transitions appear on the resource’s History timeline. Explanation-only versions preserve changed diagnostics without a new History transition or alert.
With Notify, transitions to Fail (including from N/A or Error) emit a violation, and Fail → Pass or Error → Pass emits resolution. Transitions to N/A or Error emit neither; N/A → Pass also emits no resolution. Log records the same event transitions. See Notify and Log.
For the freshest possible reading, collect a new snapshot (use the collect button on the Snapshot Selector in the resource page header, or wait for the next scheduled collection); compliance updates with the facts it is built on.
Common tasks
- Widen or narrow the window — Use the 24h / 7d / 30d / 90d toggle.
- Investigate a failure — Click the red cell, then the Fail row, then click Details on a row to inspect the check verdict and expand its Definition. Use Test assertions in the check editor for a detailed test against current facts.
- Check one resource in depth — Open the resource’s Summary → Compliance card and click a cell for check summaries, definitions, and results.
Permissions
- View compliance:
app.fact_policies.execute. - Observed values in details additionally require
app.resources.read, with resource access at the resource’s location. - Requires Facts to be enabled by an administrator. Editing the underlying rules needs
app.fact_policies.write— see Fact Policy.