Early access preparation

The Ops Stack Windows Patch Compliance

Know what was intended, what was confirmed in scope and discovered, what became baseline-assessable, and how each coverage and compliance metric was calculated.

An early-access Windows patch-compliance assessment direction for teams that need discovery, confirmed scope, Windows Build + UBR evidence, baseline comparison, visible evidence gaps, and reviewable compliance reporting.

Patch reporting is only useful when the denominator and the missing evidence are visible.The assessment model separates intended scope, confirmed discovered scope, evidence completeness, baseline evaluation, and final metrics so an operator can explain what each number represents.
Not currently for sale or public download.Final pricing, supported requirements, packaging, licensing, support terms, security documentation, sample output, and a release date have not been published.

Operator Questions

Questions the assessment is designed to answer.

A green percentage is not enough. The report should show scope, evidence completeness, baseline findings, metric denominators, and the gaps that limit the conclusion.

  • What was the declared or intended assessment scope?
  • Which discovered Windows systems were confirmed to be in scope?
  • Which confirmed in-scope discovered devices produced complete baseline-assessable evidence?
  • What Product, Release, Edition, Build, and UBR did each baseline-assessable device report?
  • Which applicable baseline was used for each eligible device?
  • Which baseline-assessable devices were compliant or ahead of baseline?
  • Which discovery, collection, authorization, support, evidence, or baseline gaps remain?
  • Can another reviewer recompute the reported metrics from the evidence?

Assessment Flow

Separate discovery, evidence, assessment, and reporting.

01Define intended scopeStart with the systems the assessment is expected to account for so discovery gaps can be reconciled instead of ignored.
02Discover and confirm scopeDiscover candidate Windows systems or use an explicit target list, then confirm which discovered devices belong in the assessment.
03Collect assessable evidenceKeep complete baseline-assessable devices distinct from unreachable, unauthorized, unsupported, incomplete, or conflicted devices.
04Compare the applicable baselineEvaluate complete Windows version evidence against the baseline that applies to the device and record the resulting assessment state.
05Report the metrics and gapsReport Evidence coverage, Assessed compliance, and Verified compliant population with defined denominators, while keeping intended-scope reconciliation gaps separate and visible.

Requirements

Exact release requirements are not published yet.

The current design is a Windows assessment utility using directory discovery or explicit hostnames and a constrained evidence-collection path. Supported Windows versions, access requirements, network prerequisites, and package details will be stated explicitly before public availability.

  • Authorized Windows systems and an intended assessment scope.
  • An applicable maintained baseline for eligible systems.
  • A review path for discovery gaps, collection failures, unsupported systems, and other exceptions.
  • Environment and operator prerequisites will be published with the release documentation.

Security & Data Handling

Current scope: read-only assessment.

The product is not intended to deploy patches or act as a persistent endpoint-management agent. Exact evidence collected, credential handling, output locations, retention behavior, and any update or licensing traffic will be documented before release rather than inferred here.

  • No patch-deployment or endpoint-management capability is claimed.
  • The collection path is intended to be constrained to the evidence needed for assessment.
  • If released artifacts are code-signed, signing will establish publisher identity and artifact integrity; it will not imply that the software is vulnerability-free or independently endorsed.

Methodology

Three metrics answer three different questions.

Evidence coverage = complete baseline-assessable devices / confirmed in-scope discovered devices. It answers how much of the confirmed discovered population produced complete evidence that could be assessed.

Assessed compliance = compliant + ahead-of-baseline / complete baseline-assessable devices. It answers how much of the population that could actually be assessed met or exceeded the applicable baseline.

Verified compliant population = compliant + ahead-of-baseline / confirmed in-scope discovered devices. It answers how much of the confirmed discovered population can be positively verified as compliant or ahead of baseline.

Declared or intended scope remains important for discovery and reconciliation, especially when an expected device is never discovered. It does not replace the confirmed in-scope discovered denominator in these defined metrics.

Windows Product, Release, Edition, Build, UBR, and FullBuild are version evidence used by the assessment model. They do not prove that every individual Microsoft KB installed correctly.

Evidence States

Keep discovery gaps and non-assessable devices visible.

Declared / intended scopeThe systems the operator expects the assessment to account for. This drives discovery and reconciliation but does not silently replace a metric denominator.
Confirmed in-scope discoveredDiscovered devices confirmed to belong in the assessment. This is the denominator for Evidence coverage and Verified compliant population.
Complete baseline-assessableConfirmed in-scope discovered devices with complete evidence and an applicable baseline. This is the numerator for Evidence coverage and denominator for Assessed compliance.
Compliant or ahead of baselineComplete baseline-assessable devices that meet or exceed the applicable baseline. This population is the numerator for Assessed compliance and Verified compliant population.
Gap or exceptionDiscovery misses, unreachable or unauthorized devices, unsupported systems, incomplete evidence, and baseline gaps remain visible instead of disappearing from the assessment story.
Sample report: not published yet.A sanitized sample will be published when it matches the release output. It should show scope reconciliation, evidence completeness, assessment states, metric denominators, collection gaps, baseline identity, and device-level evidence without presenting synthetic data as customer evidence.

Availability

Early-access preparation only.

There is no purchase or public download path today. Before availability, this page will state the exact supported requirements, security and data-handling behavior, licensing and support terms, installation/download details, and representative output.

FAQ

Current scope and limitations.

Does The Ops Stack Windows Patch Compliance deploy patches?No. The current product direction is assessment, not patch deployment or endpoint management. It is intended to collect authorized evidence, compare it with an applicable baseline, and report the result clearly.
Does Build + UBR prove that every individual KB installed correctly?No. Build and UBR are Windows version evidence used by the baseline assessment model. They do not prove that every individual Microsoft KB installed correctly.
What happens when a system is offline or cannot be queried?The gap stays visible. An intended device that is never discovered remains a discovery/reconciliation gap. A confirmed in-scope discovered device that cannot produce complete assessable evidence remains visible in the coverage story instead of silently disappearing.
Can I buy or download The Ops Stack Windows Patch Compliance now?No. This is an early-access preparation page. Public download, pricing, licensing, support, and release details are not available yet.

Product Requests

Tell us what the assessment needs to make clear.

Share the discovery, scope, evidence, baseline, compliance, reporting, or exception-handling question you need this product to answer. This is product feedback only: no checkout, preorder, or delivery promise.

No checkout, no preorder. This only helps prioritize what gets built.