> ## Documentation Index > Fetch the complete documentation index at: https://docs.luumen.ai/llms.txt > Use this file to discover all available pages before exploring further. # Compliance scans overview > How Luumen evaluates each host against the compliance checks you define, and how the terminal and web UIs relate. A **compliance scan** is the evaluation of a host against the set of checks assigned to its groups. Scans run automatically every time the agent reports fresh data — there's no separate "scan" step beyond the agent run itself. This page explains how scans are triggered, where to view results, and how the terminal and web interfaces relate. ## How scans run On its scheduled cycle, the agent connects to every host, gathers properties, and reports them to the Luumen API. See [What the agent collects](/enterprise/data/what-the-agent-collects). For each host, Luumen finds every group the host belongs to, then every check assigned to those groups, and evaluates each rule against the most recent properties. Pass, fail, and error counts update on the **Acceptance to Run → Overview** page and at the host-detail level. Because evaluation is automatic, the cadence of scans is determined by the agent's schedule. If you want results to refresh faster than the schedule allows, run the agent manually on the Patch server (see [Scheduling runs](/enterprise/installation/scheduling)). ## Terminal vs web Compliance results are surfaced in two places: the **web UI** and an interactive **terminal interface** on the Patch server. These are two views of the same data, not two different scan engines. | Surface | What it's for | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Web UI** | The day-to-day view. Schedule-driven, automatic — the agent runs on its interval and the dashboard reflects the latest state. Use this for ongoing operations, reporting, and stakeholder reviews. | | **Terminal** | Manual, on-demand. Useful when you've just changed a check or fixed a host and want to validate without waiting for the next scheduled run. The terminal triggers an agent run and displays the same pass/fail output the web UI would. | Both surfaces read from the same underlying scan results. Findings, status changes, and history persist regardless of which interface initiated the run. ## Anatomy of a scan result For each host in a group with assigned checks, a scan produces three categories of result: * **Passed** — the rule evaluated true against the latest properties. * **Failed** — the rule evaluated false. The UI surfaces the expected vs. actual values to make debugging easy. * **Error** — the rule could not be evaluated. This is typically because the required property was missing from the host (e.g., a memory check on a host the agent couldn't reach for memory data on the last run). The **Overview** page shows roll-ups at the group level and a "Needs attention" list of hosts with recent failures or errors. Click any host or group to drill in. ## Last-N-checks indicator The Overview page shows a sparkline-style indicator of the last 12 check runs per host. Reading the indicator: * Mostly green with a recent red — a regression to investigate. * Mostly red — a check that's been failing consistently. Either the host needs remediation or the check rule needs adjustment. * All grey ("Not checked") — the host hasn't been part of a successful scan recently, usually a connectivity or credential issue. ## Where to start If you're setting up compliance for the first time: Build a rule using the rule builder — left field, operator, right value. Attach the check to the right host group so it only runs where it applies. Watch results land on the Overview page and export reports for stakeholders. If you haven't already, create host groups for your major host classes.