A policy is a rule you define once — “disk usage under 80%,” “agent version up to date” — that AssetGullak checks on a schedule, automatically, across whichever devices or assets you point it at. When something breaks the rule, that’s a violation, and it stays visible until the underlying problem is actually fixed.
Policy types
Ten types, covering three different things a policy can watch:
Device health & configuration
| Type | Flags a device when… |
|---|
| OS Version | Its OS version doesn’t match what you expect |
| Agent Version | Its AssetGullak agent is outdated |
| Uptime | It’s been running too long without a restart |
| Type | Flags a device when… |
|---|
| CPU Usage | CPU usage crosses your threshold |
| RAM Usage | Memory usage crosses your threshold |
| Disk Usage | Disk usage crosses your threshold |
| Type | Flags a device when… |
|---|
| Required Software | Software you’ve marked mandatory is missing |
| Forbidden Software | Software you’ve marked disallowed is present |
| Type | Flags an asset when… |
|---|
| Asset Age | It’s older than the age you set |
| Warranty Expiry | Its warranty is expiring soon |
Resource usage policies (CPU/RAM/Disk) can optionally require the breach to be sustained over a time window you choose, rather than flagging on a single instantaneous reading. This is the difference between “disk hit 85% for one reading” and “disk has been over 85% for the last 30 minutes” — the second is a real problem, the first might just be a backup job running. Use a sustained window if you want to avoid noise from brief spikes.
Who a policy applies to
Every policy has a target — company-wide, a specific location, a department, a single device, or a tag. A policy only evaluates devices (or assets) inside its target; nothing outside it is touched.
How evaluation actually works
Policies are checked automatically, roughly every 10 minutes — you don’t trigger this yourself. Each enabled policy runs independently, so a slow evaluation on one policy never delays another.
Just fixed something and don’t want to wait for the next automatic check? There’s a manual re-check action on the policy’s detail page that evaluates it immediately.
- Compliant — evaluated, and it meets the rule.
- Violating — evaluated, and it breaks the rule. This opens (or keeps open) a violation.
- Not applicable — the policy couldn’t be evaluated for this subject right now (most commonly: a resource-usage policy needs data from the last N minutes, and none has come in yet). Not applicable subjects are excluded from both the compliant and violating counts — they’re neither.
Violations open and resolve automatically
You never manually close a violation because the underlying problem got fixed — the next evaluation cycle does it for you. A violation resolves when either:
- The subject is re-evaluated and is now genuinely compliant, or
- It’s no longer targeted by the policy at all (the device was removed, or the policy’s targets changed)
One deliberate exception: if a device goes from violating to not applicable (for example, it briefly stops reporting metrics), the violation is left open, not auto-resolved. This is intentional — a gap in data isn’t confirmation that the problem is fixed, so AssetGullak doesn’t clear the flag just because it temporarily can’t check. The violation only resolves once a real evaluation confirms compliance, or the device is removed from the policy’s scope.
Previewing before you commit
When creating or editing a policy, you can preview its effect before saving — it runs a live evaluation against your real fleet and shows you how many devices would currently comply or violate (“18 of 200 would violate”), without writing anything. Useful for catching an overly strict threshold before it floods your Alerts with new violations the moment you enable it.
Where violations show up
- On the policy itself — its detail page shows live compliant/violating counts and the list of currently-violating devices or assets.
- On the device timeline — only for device-subject policies (resource usage, software, OS/agent version, uptime). Asset-subject violations (warranty, asset age) don’t have a device to attach to, so they surface through Alerts and reports instead.
- In Alerts — see Alerts vs. Policy Violations for exactly how the two relate; they’re not quite the same thing.
How this relates to your dashboard’s compliance score
The number on your dashboard is fleet-wide: the share of your devices with zero open violations, across every policy. A device counts against that score if it’s violating any enabled policy, even just one — the per-policy compliant/violating counts you see on each policy’s own page are narrower, scoped to that one policy’s targets. A device can be compliant on nine policies and violating on a tenth; it still counts as non-compliant on your dashboard.
Next
Alerts vs. Policy Violations clears up a common point of confusion — these look similar but come from different places. 
