Capability Matrix And Release Boundary

Capability Matrix And Release Boundary

Lane	Guest / VirtualBox host	Required qualification	Non-claims
windows-linux	Windows guest / Linux host	A fresh create-vm, current NSIS bootstrap and authenticated WinRM proof, the required guest reboot and managed cycle, VIPM/LabVIEW installation, registration of the same VM, and the known-answer runner job.	A runner job does not prove licensed LabVIEW activation or a production SBOM workload.
ubuntu-linux	Ubuntu guest / Linux host	A fresh provision-public, independently verified public receipt and committed snapshot, safe start of the same VM, registration, and the known-answer runner job.	The job does not prove the separate activation or consumer-specific package-build phase.
ubuntu-windows-public	Ubuntu guest / Windows host	Fresh public provisioning, independently verified public receipt and committed snapshot, and safe qualification cleanup.	Runner registration and a runner job are not applicable to this public-only lane.

Windows guest provisioning on a Windows host and Ubuntu runner registration from a Windows host are not claimed by this release matrix. They need separate support and proof before being advertised. Ubuntu activation, licensed workloads, consumer-specific package builds, and private-consumer adoption remain separately scoped capabilities, not substitutes for these lanes. A downstream consumer's pinned engine and vendored workflow must be assessed independently without requiring its private configuration in the public engine. The Linux Run-Pipeline.sh analysis tool is not a native SBOM pipeline.

The local engine baseline currently routes Windows guest provisioning to a Linux host and makes Ubuntu register-runner Linux-host-only. Ubuntu public provisioning powers the guest off after making its pre-activation snapshot; registration requires it running. Thus the same-VM start and lineage above are planned integration work, not an already demonstrated orchestration. Historical successful runs establish only their documented, revision-bound scope; they do not qualify a different candidate commit.

The engine's VM procedure currently describes all five Windows phases as individually dispatch-proven, while the workflow header describes four dispatch-proven phases and a manually proven registration procedure. ADR-0006 records registration as not yet dispatch-proven at its authoring time, and #110 tracks the fresh proof. Reconcile the current claim with actual run evidence; manual registration and an older authoring-time statement do not establish that dispatch succeeded. The Windows workflow also installs pywinrm without a version pin, so the engine commit alone does not identify that resolved dependency. Neither observation proves the historical WinRM failure's cause.

The current Ubuntu runner installer examines one runner-list response and suppresses API failures during polling; it does not establish complete pagination before choosing a matching name. The Windows runner script instead rejects an incomplete inventory and duplicate names. A historical Ubuntu registration observation does not establish the stronger complete-inventory and local-ID matching contract planned here.