Pre-flight & compatibility
The cheapest failure is the one that never reaches a device. Before a change widens across your fleet, the platform applies gates that can refuse it up front. The strongest gate today is a vulnerability admission gate, described below.
Vulnerability admission gate
The platform continuously matches the components in each artifact's bill of materials against known vulnerabilities. You set a block severity that decides how strict the gate is when a rollout is created:
| Block severity | A rollout is refused when the artifact has open findings at... |
|---|---|
critical (default) | critical severity |
high | high or critical severity |
none | the gate is off |
When the gate refuses a rollout, the error names the artifact and how many open findings are blocking it, so the path forward is clear: resolve the vulnerabilities, dismiss the findings, or make a deliberate exception.
Deliberate overrides are evidence
Sometimes you must ship despite an open finding. An operator can override the gate, but only with a written reason — the override is rejected without one. Both the override and its reason are written to the audit log as their own record, so a CRA or supply-chain reviewer can see exactly when the gate was bypassed, by whom, and why. The gate makes the safe path the default and the unsafe path accountable.
Only an operator with approval rights can change the block severity or override the gate.
Planned extensions
Capability-based compatibility gating — refusing a rollout whose declared constraints don't match a target device's hardware or runtime — and emulated pre-flight against virtual and lab device profiles are planned extensions of this model.
The live safety net is the canary-first wave plan and health-based halt rules: a change reaches a small cohort first, and the rollout pauses itself before a problem can spread.