Documentation / Modules
Patch & vulnerability
Ring-based deployment with supersedence, enforced maintenance windows, and four states rather than two.
Rings
Canary, early wave, broad. A patch that breaks something breaks it on the canary and never reaches the fleet.
Supersedence
Patches are tracked as chains. A machine carrying the newer patch needs neither of the ones it supersedes, and the report says why.
Without supersedence a patch report generates false positives — machines reported as missing patches they do not need. Six phantom findings beside one real missing security update is how the real one gets missed.
Four states, never two
| State | Counts as |
|---|---|
| Installed | Compliant |
| Missing | Non-compliant — applicable, absent, not superseded |
| Superseded | Compliant, with the chain shown |
| Undetermined | Undetermined — never silently resolved to either |
Maintenance windows
Per client, per group, per asset — with a timezone, always. Blackouts outrank windows and are overridden only by a named person with a recorded reason.
A job outside its window does not start. Not a warning — it does not start. A job running when its window closes stops at the next safe boundary and reports what is in a partially-patched state.
Pending reboot is not protected
A patch installed and awaiting reboot does not protect the machine, and no compliance count treats it as if it does. A machine pending beyond threshold is a finding with an owner.
Exclusions expire
Every exclusion carries a reason and an expiry. At expiry it resurfaces for a person to renew or drop — and an expired exclusion does not silently lapse into patching either.
Not running it yet? Start a thirty-day evaluation — read-only, on your own estate, no card.
Thirty days · read-only · no card
Run it beside what you already have, against your real clients. It tells you what your tools are reporting that is not true.