Help Center/Verification loop

Verification loop

Installers lie. They exit 0 while the old version is still on disk, stage updates for the next reboot, or hand off to self-updaters that never run. Patch Console never marks a vulnerability fixed on an exit code: only a later inventory that proves the version healed, or the software is gone, closes a finding.

Why exit codes are not trusted

An exit code proves at most that an installer process ran and returned. It says nothing about what is on disk afterward. Between staged updates, pending reboots, per-user versus per-machine installs, and installers that return success on "already handled", the exit code is the least reliable signal in the pipeline. Patch Console records it as evidence, and trusts none of it as proof.

What proves what

SignalWhat it actually proves
Installer exit code 0The install ran. The finding moves to Attempted, nothing more.
Version gate passImmediately after the install, the device reported the fix-target version or higher. Strong evidence, and it triggers a fresh inventory.
Inventory at or above targetThe fix is real. The finding becomes Resolved.
Software absent from inventoryThe product was removed. Also Resolved: an uninstalled product is not vulnerable.
Inventory still below targetThe deployment did not take. The finding becomes Failed and counts toward auto-halt.

Event-driven, not once a day

Verification does not wait for the next daily scan. A successful install is a signal: it triggers a fresh inventory from the device, and that inventory is evaluated as it arrives. In practice a clean install resolves its findings within minutes. Devices that were offline during the rollout are picked up on their next check-in, and the daily scan remains the backstop that re-evaluates everything.

Reboots and stragglers

When an update lands but needs a restart before the new version is in effect, the finding sits at Reboot required rather than pretending to be fixed or failed. Findings stuck at Attempted mean the install ran but inventory has not confirmed the change yet, usually a device that has not reported since.

The consequence of this design: your vulnerability counts can only go down when devices actually changed. There is no way to "green" the dashboard with a deployment that did not work.