ArcPatchCore

What it solves

Patch tools fail when detection, eligibility, execution, and verification are treated as one button. The product has to distinguish what is installed, what is applicable, what is blocked, what is unknown, and what can actually be changed safely under the current execution context.

Capabilities

• Windows, application, Microsoft 365, reboot, execution-context, and software inventory evidence
• Deterministic normalization and patch planning shared by CLI and desktop UI
• Explicit blocked, current, available, partial, and failed source states
• A verification-first execution architecture being hardened for privileged service, installer, and endpoint workflows

Where it gets hard

• Different update providers expose different truth and failure modes
• SYSTEM, interactive users, policy, WSUS, application scope, and loaded user hives change what can be seen
• A successful provider call does not prove the software ended at the intended version
• Trust, authorization, reboot policy, locking, and post-patch verification have to remain explicit

In the loop

The core planner does not need AI to decide patch state. Research and automation can accelerate provider work, but execution stays behind deterministic eligibility and verification rules.

An operator remains responsible for the plan, execution policy, exceptions, and what is allowed to run on a managed endpoint.