checkId: check.verification.policy.engine plugin: stellaops.doctor.verification severity: fail tags: [verification, policy, vex, compliance]
Policy Engine Evaluation
This Stella Ops Doctor check confirms that the policy engine behind release gating is configured and reachable by the verification plugin. It is aimed at platform operators who need assurance that Doctor exercises the same policy and VEX-aware rules that production release orchestration uses — a verification result is only trustworthy if it is produced by the policy the deployment actually enforces.
What It Checks
Requires the verification plugin plus a configured test artifact.
- Offline mode — inspects the exported bundle for a policy-result marker.
- Online mode — reads
Policy:Engine:Enabled, a policy reference, andPolicy:VexAware.
The check fails when the policy engine is disabled and warns when no policy reference is configured. Critically, the out-of-process Doctor does not run the policy engine against the artifact, so it cannot confirm the actual “no-go if critical vulns without VEX justification” decision. Per ADR-026 D7 a check may never report a fabricated Pass: where the previous version Passed on a present-but-unvalidated policy marker (offline) or on config presence (online), the check now returns an honest Skip (“not verified”) naming the unverified capability — a present marker or enabled config is not a verified policy decision.
| Condition | Result |
|---|---|
| Online, policy engine disabled | Fail |
| Online, engine enabled but no policy ref | Warn |
| Online, engine enabled + ref + VEX-aware (config present, decision not evaluated) | Skip — “not verified; requires the runtime policy engine” |
| Offline bundle missing | Fail |
| Offline bundle contains no policy marker | Warn |
| Offline bundle contains a policy-result marker (present but not evaluated) | Skip — “marker present, decision not evaluated” |
Full policy evaluation is verified by the runtime policy engine, not by Doctor’s out-of-process check.
Why It Matters
Release verification is only trustworthy if the same policy engine and VEX rules used in production can be exercised by Doctor.
Common Causes
Policy__Engine__Enabledis false- No default or test policy reference is configured
- Policy rules were not updated to account for VEX justifications
How to Fix
Docker Compose
services:
doctor-web:
environment:
Policy__Engine__Enabled: "true"
Policy__DefaultPolicyRef: policy://default/release-gate
Policy__VexAware: "true"
Doctor__Plugins__Verification__PolicyTest__PolicyRef: policy://default/release-gate
If you use offline verification, export the bundle with policy data included before copying it into the air-gapped environment.
Bare Metal / systemd
Keep the Doctor policy reference aligned with the policy engine configuration used by release orchestration.
Kubernetes / Helm
Store the policy ref in ConfigMaps and enforce the same value across the policy engine and Doctor service.
Verification
stella doctor run --check check.verification.policy.engine
Related Checks
- VEX Validation (
check.verification.vex.validation) — VEX-aware policy only helps if VEX collection works - SBOM Validation (
check.verification.sbom.validation) — policy evaluation usually consumes SBOM and vulnerability evidence
