Compliance Evaluation Lifecycle

Once you've authored rules, grouped them into a baseline, and assigned that baseline to a collection, two questions come up straight away: when do machines actually get the rules, and when do they re-check? This page answers both — the events that push a baseline to agents, the timer that re-evaluates it, and how machines that were offline at the time catch up when they reconnect.

Push and evaluate: two halves of one cycle#

Compliance works on a push-then-evaluate model. The server pushes a baseline's rule bodies down to each agent, and each agent then evaluates those rules against itself locally and reports a per-rule state back. The two halves are deliberately decoupled:

Because the agent keeps its own cached copy of the rules, a machine can keep evaluating on schedule even if it briefly loses contact with the server — and the server only needs to re-push when something actually changes.

When a baseline is pushed to agents#

The server pushes rule bodies to agents on five occasions. Together they cover both "the assignment changed" and "the fleet changed" — so a machine ends up with the right rules no matter which one moved:

Pushes only reach agents that are online at that moment. An agent that is offline when an assignment or rule changes is simply skipped — it picks the change up automatically the next time it connects, via the agent connects trigger above. Re-pushing rules an agent already has is harmless, so overlapping triggers never cause duplicate work.

The re-evaluation timer#

After the initial push, the agent owns its own re-evaluation cadence — there is no server-side clock ticking on behalf of each machine. Every assignment carries an evaluationIntervalMinutes value (set when you create the assignment; it defaults to 60 and must be a positive number). The agent re-runs each assigned baseline against itself once that interval elapses, then reports the fresh per-rule states.

Each assignment keeps its own interval and its own "last evaluated" timestamp, so a machine that belongs to several collections evaluates each baseline independently on its own schedule — a fast-cadence security baseline and a slower inventory baseline don't interfere with each other.

Evaluations run one at a time on the agent. Because compliance checks are PowerShell — and the same machine may also be running commands, scans and deployments — the agent deliberately serialises them to stay non-disruptive rather than running them all at once.

Forcing a re-check with Evaluate Now#

You don't have to wait for the interval to come around. Evaluate Now tells agents to re-run a baseline immediately and is available in two places in the console:

Evaluate Now sends a lightweight "evaluate now" signal — the agent already holds the rule bodies from an earlier push, so nothing heavy travels. Online agents receive the ping and re-evaluate right away; the console reports back how many machines were pinged.

How offline machines catch up#

Compliance is built to tolerate machines that are powered off, asleep, or briefly disconnected — nothing is silently lost:

The net effect: whether a machine was online for the change or not, it converges on the current baseline and the current results without any manual re-push.

Telling stale evaluations apart#

Because pushes and evaluations are decoupled, it helps to know which version of a rule a machine actually ran. Every rule body is fingerprinted with a hash when it's created or changed, and each result an agent reports carries the hash of the script it ran. When you edit a rule, the re-push and the machine's next evaluation update that fingerprint — so the console can flag a result that was produced against an older version of a rule, rather than leaving you to guess whether a change has propagated. See Compliance rules for how the fingerprint is stamped.

Quick answers#