Deployment Actions

The Deployments surface is AuditTrail's audited control plane for operational changes proposed against your live agent fleet. Every action is recorded as an immutable DeploymentAction row with a deterministic state machine, approval TTL, and — for the highest-tier irreversible actions — typed confirmation + second-approver requirements.

Visit /deployments after demo-login to see the queue in action.

The 3 tiers

Tier	Action types	Execution rule
Tier 1	`alert` · `tag_trace` · `create_incident`	Autonomous-safe. In `mode="autonomous"`, auto-executes on creation.
Tier 2	`throttle` · `switch_model` · `disable_flag`	Supervised only. Requires explicit approval before execution, even in autonomous mode.
Tier 3	`kill_run` · `rollback_deploy` · `scale_down`	Explicit-enable only. Requires typed confirmation (first 8 chars of target ref) + operator reason.

Modes

dry_run — proposal surfaces in the queue, never executes
supervised — execute after explicit approval within the TTL
autonomous — Tier 1 executes immediately on creation; Tier 2/3 still require supervised approval regardless of mode

State machine

          propose
             │
             ▼
        proposed ──── reject ──► rejected
             │
             ├─ approve ───► approved ──── reject ──► rejected
             │                   │
             │                   └─ mark-executed ──► executed
             │
             ├─ TTL exceeded ──► expired
             │
             └─ propose w/ mode=autonomous + Tier 1 ──► executed

proposed → approved → executed is the standard supervised flow
Tier 1 in autonomous mode: single-step proposed → executed
TTL enforcement: approval attempts after the TTL window flip the row to expired and 400 the request

The `/deployments` page

When you open /deployments, the page renders:

A KPI strip summarizing Proposed · Pending approval · Executed today · Rejected today counts
A filter tab bar (All · Proposed · Approved · Executed · Rejected · Expired)
A table listing every deployment action visible to your user, sorted by proposed-at descending, with columns: Tier · Type · Target · Reason · Mode · Status · Proposed at · Actions
Clicking a row opens a side drawer with the full payload, outcome JSON, approver note, rejection note, and audit timestamps
Approve / Reject / Mark-executed buttons on each row (visible only for valid state transitions)

Typed confirmation (Tier 3)

Tier 3 actions (kill_run, rollback_deploy, scale_down) require the operator to type the first 8 characters of the target reference before the Approve button activates. This is the same pattern used by the right-click NodeActionMenu in the DAG viewer — implemented as a single reusable <ConfirmTypedDialog> component.

Endpoints

All endpoints are user-scoped (JWT or sk-at-* API key).

Method	Path	Purpose
`GET`	`/api/v1/deployments/actions?status=&limit=`	List actions, ordered by proposed_at desc
`POST`	`/api/v1/deployments/actions`	Propose a new action
`POST`	`/api/v1/deployments/actions/{id}/approve`	Approve a proposed action
`POST`	`/api/v1/deployments/actions/{id}/reject`	Reject a proposed or approved action
`POST`	`/api/v1/deployments/actions/{id}/mark-executed`	External runner callback

See api-reference for full schemas.

Demo data

On demo-login, the seed function _seed_demo_deployment_actions populates 10 rows spanning every (tier × status) combo so the queue renders populated immediately. Each row has a realistic reason string describing the kind of operational concern that would trigger the action (cost spikes, latency degradation, canary drift, etc.).

Rate limits

State-transition routes (propose / approve / reject / mark-executed) are bounded at 30/minute per client. List reads are unrestricted.

Shipped in: prod-v2.6.4 — backend was in place since V1.3 (2026-Q1); the frontend queue page landed in this sprint.