Stage0
Reference ScenariosEnterprise deployment control

Reference Scenario: Enterprise deployment control

This scenario shows how to use Stage0 as a pre-execution gate for AI-assisted deployments, migrations, and other production-changing actions.

Scenario focus

The objective is not to automate deploy approval blindly. The objective is to make high-risk execution requests pass through a visible authorization layer that understands environment, approval, and runtime state before any control-plane tool is invoked.

Core controls

Environment scoping

Production-changing requests should declare the exact target environment before any tool call or deploy API request is allowed.

Approval and change window checks

Deploys, migrations, and emergency actions should carry explicit approval evidence and business constraints into the authorization request.

Rollback readiness

If the runbook, rollback reference, or execution context is incomplete, the workflow should defer before touching production.

Recommended flow

1

1. Agent proposes the change

The orchestration layer prepares the intended deploy or migration action and sends it to Stage0 before the actual tool runs.

2

2. Stage0 evaluates the request

Policy checks review environment scope, approval state, loop counters, and other runtime constraints.

3

3. Your runtime enforces the verdict

Only `ALLOW` continues to the CI/CD tool. `DEFER` routes into human review, and `DENY` stops execution entirely.

4

4. Audit follows the execution

Store `request_id`, `policy_version`, approver identity, and final execution result together for incident review and compliance.

Representative `/check` payload

{
  "goal": "Deploy the payments service and run a schema migration",
  "tools": ["github_actions", "argo_cd", "slack"],
  "side_effects": ["deployment", "database change", "external notification"],
  "constraints": [
    "approval required",
    "required_role:platform_admin",
    "allowed_environment:staging,production",
    "max_iterations:3",
    "timeout:300s"
  ],
  "context": {
    "run_id": "run_deploy_001",
    "actor_role": "platform_admin",
    "approval_status": "approved",
    "approved_by": "[email protected]",
    "approved_at": "2026-03-14T09:30:00Z",
    "environment": "production",
    "current_iteration": 1,
    "elapsed_seconds": 18,
    "current_tool": "github_actions",
    "recent_tools": ["planner"],
    "cumulative_cost_usd": 0.12
  },
  "pro": true
}

What this should make visible

Authorization evidence

Who requested the change

Which role they held at evaluation time

Which environment and tool path were targeted

Which policy version approved or denied the request

Runtime evidence

Iteration count and elapsed runtime at decision time

Approval timestamp and approver identity

Final execution result after the Stage0 verdict

Any rollback or deferred review outcome

The real proof is operational clarity

A buyer should be able to inspect one blocked deploy, one deferred migration, and the exact request trace that explains both.