From software version data to a patch decision.

Inventory is the starting point, not the decision

A software record becomes useful when an operator can connect the installed product, publisher, version, architecture, channel, device scope, and observation time. Raw package names are rarely consistent enough across operating systems and installers, so normalization is part of the control—not cosmetic cleanup.

Dayrook is designed to preserve first-seen, last-seen, affected customer and device scope, and confidence alongside the normalized record. That context lets a technician distinguish a current observation from stale or ambiguous inventory before creating work.

Build a source trail an operator can review

Latest-version intelligence should prefer official vendor APIs, package indexes, release feeds, app-store metadata, supported release repositories, and vendor or public security advisories. Controlled release-page collection belongs at the end of that hierarchy, only where terms allow it and no structured source exists.

The resulting record should carry its source URL, observation time, release date when the source provides one, confidence, severity, and whether the evidence points to the latest stable version or the latest security-fixed version. Missing or stale evidence should remain an explicit state.

Prioritize the change that matters

A version gap does not have one universal severity. The decision changes when the release fixes a known vulnerability, the installed version is unsupported, the device is exposed, the customer marks the application as critical, or a maintenance policy blocks immediate action.

A useful queue combines advisory severity, exploitability, exposure, customer policy, device and service criticality, and the number of affected endpoints. Operators can then suppress an accepted exception, create a ticket, schedule a deployment, or approve remediation without losing the reason behind that path.

• Confirm whether the gap is feature-only, security-fixed, end-of-life, or policy-blocked.
• Review affected customers, device groups, business services, and maintenance constraints.
• Record suppressions and exceptions with owner, reason, scope, and review state.
• Choose ticket, schedule, deployment, or accepted-risk handling based on policy.

Stage remediation as a controlled change

Deployment should respect customer scope, rollout rings, maintenance windows, exclusions, restart policy, approval requirements, and recovery readiness. Dispatch is only one event in the change; it is not proof that the endpoint reached the desired state.

AI can summarize risk or draft a plan when the customer has connected and verified an operational AI provider. It still cannot bypass RBAC, MFA, entitlement, maintenance windows, signed commands, local agent policy, approval, or audit controls. High-risk updates remain approval-bound unless an exact policy explicitly allows the action class.

Verify the resulting state

After execution, refresh inventory and confirm the installed version, command or job result, endpoint health, service impact, restart outcome, and any remaining exposure. Failed, deferred, incompatible, or rolled-back devices stay visible until an operator resolves or accepts them.

Customer-facing evidence should connect the original installed version, current source evidence, alert history, remediation decision, execution result, and remaining risk. That chain is what turns a patch count into a reviewable operating record.

Sources reviewed

Vendor pages can change after the review date above. Open the current source and confirm plan, contract, regional, and product details before purchasing.

• NIST Guide to Enterprise Patch Management Planning
• CISA Known Exploited Vulnerabilities Catalog

Continue through this topic

Use the product and operator guides that carry this decision into setup, daily work, control, and verification.

• RMM software for MSPs
• Patch management
• Vulnerability management
• Discovery and inventory
• Agent trust guide
• MSP platform TCO calculator