The Lilo device health score rulebook · v1.0
Every deduction has a name.
Every point Lilo deducts has a name, a threshold and a version. This is the current rule set — the same one the product runs, not a marketing summary. If we change a rule, this page changes with a dated note at the bottom.
How a score works
- Every device starts at 100. Rules deduct points; the floor is 0.
- Bands: Healthy = 75+, Plan = 50–74, Replace = below 50.
- No data, no guess: a device with no fresh signals for 14+ days is not assessed (rule RL-01) — never scored zero, never scored from stale data.
- Band hysteresis: near a threshold, the previous band holds until the score crosses by 3+ points, so a device at 74–76 never flaps between Healthy and Plan from run to run.
- Alert cap (AL-CAP): alert-history rules can deduct at most 30 points combined, because alert volume reflects how an RMM is configured as much as device health.
- Every deduction is stored with its evidence string (the actual reading that triggered it) and the rules version, so a score from last quarter can always be explained with last quarter's rules.
The current rules (v1.0)
Hardware & lifecycle
- HW-W1 — Warranty expired → −8
- HW-W2 — Warranty ends within 90 days → −4
- HW-A1 — Device older than 4 years → −10
- HW-A2 — Device older than 3 years → −5
Patching
- PT-01 — Not fully patched (per RMM patch status) → −8
Usage pressure
- US-M1 — Chronic memory pressure: 10+ memory alerts in 30 days → −15
- US-M2 — Recurring memory pressure: 3–9 memory alerts in 30 days → −8
- US-M3 — Memory above 90% at last check → −4
- US-C1 — Chronic CPU saturation: 10+ CPU alerts in 30 days → −10
- US-C2 — Recurring CPU saturation: 3–9 CPU alerts in 30 days → −5
Storage
- ST-D1 — Disk nearly full: under 10% free → −8
- ST-D2 — Disk space low: under 20% free → −4
- ST-D3 — Slow disk response: over 25 ms average → −6
- ST-D4 — Recurring disk alerts: 3+ in 30 days → −6
Security posture
- SE-B1 — Disk encryption disabled (active BitLocker-disabled alert) → −10
- SE-D1 — Antivirus detections: any Defender alerts in 30 days → −6
Reliability
- RL-C1 — Very high critical-alert volume: 20+ in 30 days → −10
- RL-C2 — Elevated critical-alert volume: 5–19 in 30 days → −5
- RL-01 — No data for 14+ days → not assessed (no score at all)
Rules you've seen in our examples
The worked examples on this site (HW-04, HW-07, HW-12, SW-03, NW-05, US-02, PF-03) illustrate the diagnosis categories the agent-based rule set covers as it rolls out — storage wear and uncorrected errors, battery capacity, per-application crash isolation, Wi-Fi dead zones, and spec-versus-workload checks. Rules ship here, with their thresholds, the day they ship in the product. The RMM-based rules above are what runs today against SuperOps data.
Arguing with a rule
That's the point of naming them. If HW-A1 is wrong for your fleet — say your workstations run fine at five years — tell us which rule and why: hello@angilabs.com. Thresholds change by evidence, and changes land here with a date.
Change log
- 2026-10-12 — v1.0 published: the initial RMM-based rule set (warranty, age, patching, memory/CPU pressure, storage, encryption, antivirus, alert volume), the 30-point alert cap, band hysteresis, and the not-assessed rule.
See what these rules produce: score a device yourself, or see it on your fleet.