Skip to content

reference

Intended Documentation

Go-Live Runbook

The production rollout sequence for Intended — pre-deployment verification, required controls, staged cutover, and rollback — using real endpoints and CLI commands.

intermediate5 min readimplemented

Go-Live Runbook#

The sequence to route production traffic through Intended. Every command below is a real CLI command or endpoint; do not skip the verification steps.

Danger

Because Intended is fail-closed, misconfiguration surfaces as denied traffic, not silent pass-through. A skipped validation step typically shows up in production as unexpected DENIED / AUTHORITY_LOOP_FAILED responses.

Pre-deployment verification#

Confirm the service is reachable and ready

Probe the unauthenticated operational endpoints from the production network zone:

bash
curl -fsS https://api.intended.so/health   # liveness
curl -fsS https://api.intended.so/ready    # readiness

Both must succeed from where your workloads run. A failure here is a networking or dependency problem to resolve first.

Deploy and inspect the production policy

Deploy the policy pack you intend to run, and confirm what is active:

bash
intended deploy-policy --pack production-baseline --tenant "$TENANT_ID"
intended policy-pack-inspect --tenant "$TENANT_ID"

Confirm the active pack and rule set match what you expect — no stale or orphaned packs.

Run an authority round-trip

Submit a synthetic, clearly-allowed intent and confirm it is APPROVED:

bash
intended intent-submit \
  --tenant "$TENANT_ID" \
  --actor svc-golive-probe \
  --action "go-live probe — no-op"

Then inspect and verify the issued token:

bash
intended inspect-token --token "$AUTHORITY_TOKEN"
intended verify --token "$AUTHORITY_TOKEN" --key tenant-public.pem --kid "$KID" --tenant "$TENANT_ID"

decision must be APPROVED, exp within 300 s of iat, and the signature must verify.

Verify audit integrity

Confirm the per-tenant hash chain is intact:

bash
curl -H "Authorization: Bearer $INTENDED_API_KEY" \
  -H "x-tenant-id: $TENANT_ID" \
  "https://api.intended.so/tenants/$TENANT_ID/audit/chain-verification"

Require valid: true with the expected totalEntries. Confirm recent events are landing with intended audit-query --tenant "$TENANT_ID" --limit 5.

Confirm connectors validate tokens

For each connector you will rely on, confirm it is wired and fail-closed:

bash
intended connectors-list --tenant "$TENANT_ID"
intended connectors-test --connector "$CONNECTOR_TYPE" --tenant "$TENANT_ID"

Required controls#

Before routing production traffic, confirm:

Emergency controls#

  • [ ] The tenant emergency-controls surface (Console / enterprise-admin API) is accessible to on-call
  • [ ] The token-revocation path is documented and rehearsed (/revocations, per-token revoke)
  • [ ] Operators understand that a kill action defaults the tenant to deny (fail-closed)

Access controls#

  • [ ] API keys are intended_live_… (legacy mrt_… still accepted), scoped to the minimum permissions
  • [ ] Any environment label on a key is understood to be cosmetic — it does not gate authorization or data isolation; least-privilege scopes are the real control
  • [ ] Role assignments reviewed for least privilege

Monitoring#

  • [ ] /health and /ready are monitored by your observability stack
  • [ ] Alerting on DENIED / AUTHORITY_LOOP_FAILED rate spikes
  • [ ] Alerting on any audit/chain-verification result that is not valid: true

Rollback#

  • [ ] The previous policy pack version is identified for rollback
  • [ ] The rollback procedure is tested in a non-production tenant
  • [ ] The approval chain for a rollback is identified

Staged cutover#

Enable at low traffic

Route 5–10% of traffic through the Intended evaluation path. Watch decision latency (p50/p95/p99), error rate, and the allow/deny ratio.

Validate steady state

After ~30 minutes: confirm latency is within bounds, error rate is below threshold, and a sample of DENIED decisions is correct (read each rationale[]).

Increase to full traffic

Step up gradually (5% → 25% → 50% → 100%), holding at each step until metrics are stable.

Post-launch validation

After 24 hours at full traffic: re-run the authority round-trip and audit/chain-verification, review audit volume for completeness, and export an evidence bundle for a representative intent (intended audit-export --tenant "$TENANT_ID" --intent "$INTENT_ID") to archive as go-live evidence.

Incident readiness#

  • On-call rotation — at least one operator available for the first week.
  • Incident runbook — reviewed and accessible.
  • Escalation path — operator → engineering → leadership, defined and shared.
  • Failure-mode literacy — on-call knows that 500 AUTHORITY_LOOP_FAILED is a denial (fail-closed), not a retryable transient.

Rollback procedure#

If issues appear after cutover, the supported path is to roll back the policy through the audited pipeline and, if needed, halt via the emergency-controls surface:

bash
# Re-deploy the previous known-good policy pack
intended deploy-policy --pack production-baseline --tenant "$TENANT_ID"

# Confirm the active pack
intended policy-pack-inspect --tenant "$TENANT_ID"

For a hard stop, use the tenant emergency-controls surface (Console / enterprise-admin API) to halt evaluations; the tenant defaults to deny while halted. Then verify the audit chain remains intact before resuming.

Note

There is no intended emergency … or intended policy rollback CLI command today. Policy rollback is performed by re-deploying a previous pack; emergency halt is performed through the emergency-controls surface, not the CLI. Roadmap: first-class CLI verbs for emergency halt and policy rollback.

Next Steps#

Go-Live Runbook | Intended