> ## 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.

# Creating checks

> Build a compliance check using Luumen's rule builder — left field, operator, right value, and combinations with AND/OR.

A **check** is a named rule (or set of rules) that a host must satisfy. Checks live under **Acceptance to Run → Checks** in the Luumen UI. This page walks through creating one.

## Anatomy of a rule

Each rule in the rule builder is an equation with three parts:

* **Left field** — a host property (e.g., `MEMORY`, `OS Version`, `Kernel Version`, or an application-specific property like `SAP Components`).
* **Operator** — a comparison (`equals`, `not equals`, `greater than`, `less than`, `contains`, `does not contain`, and so on; the available operators depend on the data type of the property).
* **Right value** — what to compare against (e.g., `8`, `Linux`, `SLES 15`).

Multiple rules can be combined with **AND** and **OR**. Group rules in parentheses (the UI calls these "AND/OR" blocks) to express logic like "RAM must be ≥ 12 GB AND (CPUs ≥ 3 OR vendor = AWS)".

## Create a check

<Steps>
  <Step title="Open the checks page">
    Go to **Acceptance to Run → Checks** and click **Add custom check** (or pick from **Preset checks** if Luumen ships a built-in that matches your need).
  </Step>

  <Step title="Name and describe it">
    Give the check a clear, specific **name** (e.g., "Minimum memory for production app servers") and a one-line **description** of what it verifies. The name is what your team sees in the assignment picker, so make it descriptive enough to choose by.
  </Step>

  <Step title="Set the access level">
    Choose whether the check applies to **All clients** (available across your workspace) or **Only for this client**. For most enterprise customers there's only one client, in which case the choice is effectively cosmetic.
  </Step>

  <Step title="Build the rule">
    In the **Condition** panel, click **+ AND/OR** to add a rule and pick the left field, operator, and right value. Add more rules and group them as needed.
  </Step>

  <Step title="Assign it to one or more groups">
    Optionally pick the host groups this check should apply to from the **Assign check to host group(s)** picker. You can also assign later from the group's detail page — see [Assigning checks](/enterprise/compliance/assigning-checks).
  </Step>

  <Step title="Save">
    Click **Done**. The check now evaluates on the next agent run for every host in the groups you assigned.
  </Step>
</Steps>

## A worked example

Suppose your standard for a production app server is "at least 12 GB of RAM, at least 3 CPUs, running Linux, and either AWS or on-prem hardware".

In the rule builder, that's:

```
CPUs > 3
AND
RAM > 12
AND
OS version Contains Linux
AND
(vendor = AWS OR vendor = on-prem)
```

The exact field names will match what the agent reports for your environment — confirm them in **Acceptance to Run → Checks → \[Check name]** after creation.

## Choosing the right left field

A rule can only reference a property that's actually been reported for the target hosts. If you write a rule against a property the agent doesn't collect, every host in scope will return **Error** rather than **Pass** or **Fail**.

To confirm a property is collected:

1. Open **Hosts → All hosts** and click any host in the target group.
2. Look for the property in the detail view.
3. If it's missing, see [Missing properties](/enterprise/troubleshooting/common-issues#missing-properties-on-a-host).

If a property you want to check on doesn't exist yet, raise it with your account team. Adding new properties typically requires an agent update — see [What the agent collects](/enterprise/data/what-the-agent-collects#custom-properties).

## Operators

The operators available depend on the property's data type:

| Type                             | Operators                                              |
| -------------------------------- | ------------------------------------------------------ |
| Numeric                          | `=`, `≠`, `>`, `<`, `≥`, `≤`                           |
| String                           | `equals`, `not equals`, `contains`, `does not contain` |
| Boolean                          | `is true`, `is false`                                  |
| Lists (e.g., installed packages) | `contains`, `does not contain`, `count >`, `count <`   |

If you don't see an operator you expect, double-check the property's data type — sometimes a numeric value comes through as a string and needs a string operator, or vice versa.

## After saving

Saved checks live in the **Checks** list. From there you can:

* **Edit** — adjust rules, name, description, or group assignments.
* **Disable** — keep the check definition but stop running it. Useful for staging changes.
* **Delete** — remove the check entirely. Historical results stay in the database but no new evaluations are made.

When you save a new check or change one, results refresh on the next agent run — not immediately. See [Compliance scans overview](/enterprise/compliance/overview) for the timing.