Workflow Gate & safe_to_deploy
One POST runs audit, plan, and validation — then your pipeline reads machine fields, not prose.
What the Workflow Gate is
For the systems context behind pre-deploy checks, read why deployments fail even when CI is green — CI and gates answer different questions.
A workflow gate is a single request that aggregates pre-deploy checks so CI, merge queues, and automation see one envelope instead of stitching several calls. Verixet exposes this as POST /api/v1/workflow/pre-deploy with the same success, request_id, and data envelope as every other v1 engine.
What you read from the response
Inside data.workflow, safe_to_deploy is a boolean you can assert in jq or a test harness. risk_score gives a comparable signal across runs. Policy mode and policy pack fields tell you how strictly the workspace interpreted the outcome.
How CI should gate
Treat safe_to_deploy as the primary pass/fail bit for blocking pipelines. In advisory workspaces you may still receive HTTP 200 with safe_to_deploy: false — that is intentional so teams can observe signal before enforcement. Pair this page with policy modes to choose advisory, blocking, or strict posture.
Idempotency
POST engines accept Idempotency-Key so flaky runners can retry without double-applying side effects — same as other Verixet engines.