Deploy and Rollback Policies#

This runbook covers the promotion end of the policy lifecycle: approving a reviewed draft, deploying it to an active version, and rolling back to a prior version when a change misbehaves. It picks up where Author a Policy and Simulate Impact leave off.

Deploying a draft replaces the policy version the runtime's evaluate stage consults on every request. Roll back to restore the prior version instantly.

Prerequisites#

• The authority:policy:write permission. Every lifecycle transition requires it, and each appends to the audit ledger.
• A draft in the approved state. Deploy refuses to promote a draft that has not been approved.
• Tenant scope aligned across credential, x-tenant-id, and body tenantId (else 403 TENANT_MISMATCH).

The lifecycle, end to end#

The governed promotion path is a fixed sequence. Each step is an explicit API call (or console action) — nothing auto-promotes.

Reject instead of approve with POST /policy/drafts/:id/reject. Read state at any point with GET /policy/drafts/:id and GET /policy/packs/:pack/versions.

Step 1 — Approve the draft#

A reviewer who holds authority:policy:write approves. Separation of duties (author ≠ approver) is a process control you enforce in review; honor it.

curl -X POST https://api.intended.so/policy/drafts/draft_123/approve \
  -H "Authorization: Bearer $INTENDED_API_KEY" \
  -H "x-tenant-id: tenant_acme_prod" \
  -H "Content-Type: application/json" \
  -d '{
    "tenantId": "tenant_acme_prod",
    "reviewerId": "user_security_lead",
    "comments": "Impact summary reviewed; changed-outcome rate 1.1%, recommendedMode review."
  }'

Step 2 — Deploy#

Promote the approved draft to the active version.

curl -X POST https://api.intended.so/policy/deploy/draft_123 \
  -H "Authorization: Bearer $INTENDED_API_KEY" \
  -H "x-tenant-id: tenant_acme_prod" \
  -H "Content-Type: application/json" \
  -d '{
    "tenantId": "tenant_acme_prod",
    "deployedBy": "user_admin",
    "comments": "Promote prod-release-controls v1."
  }'

curl "https://api.intended.so/policy/packs/prod-release-controls/versions?tenantId=tenant_acme_prod" \
  -H "Authorization: Bearer $INTENDED_API_KEY" \
  -H "x-tenant-id: tenant_acme_prod"

intended watch --tenant tenant_acme_prod --decision DENY

Step 3 — Roll back#

If the deployed version misbehaves, restore a prior version. Roll back first, investigate second — do not fix-forward under pressure.

curl -X POST https://api.intended.so/policy/rollback/ver_prev \
  -H "Authorization: Bearer $INTENDED_API_KEY" \
  -H "x-tenant-id: tenant_acme_prod" \
  -H "Content-Type: application/json" \
  -d '{
    "tenantId": "tenant_acme_prod",
    "rolledBackBy": "user_admin",
    "comments": "Unexpected deny spike for svc-ci-bot after prod-release-controls v1."
  }'

:versionId is the prior version you want to restore — find it via GET /policy/packs/:pack/versions. The rollback appends to the audit ledger like every other transition.

Failure modes#

Next steps#

• Simulate Impact — always read the impact summary before the next deploy.
• Incident Response — what to do when a deployed change causes an incident.
• Control Center — monitor runtime health after deployment.