# Deployments Domain

**Status:** Approved target-state baseline  
**Activation:** I6.

## Target State

`Deployment` is one durable attempt/progression of a `Release` into an `Environment`, with exact provider/config/evidence/health/rollback provenance.

```text
Release + Environment + policy
  -> Deployment
       preflight/diff
       Approval if required
       provider apply
       rollout/health
       success / failure / rollback
```

## Identity and Inputs

Deployment records Release/artifact digests, Environment, deployment strategy/provider, config revision, provider resource target, Principal/policy, required evidence, previous known-good Deployment and timestamps.

## Invariants From Day 1

- Deployment never rebuilds/changes Release contents silently;
- provider apply/rollout state is observation under AWP Deployment identity;
- production credentials remain trusted control-plane Connection projections;
- preflight/diff occurs before apply where provider supports it;
- cancellation/rollback are durable operations with their own outcome;
- health evaluation is recorded and tied to deployment revision;
- failure does not erase previous known-good state;
- repeated provider call reconciles before duplicate apply.

## Lifecycle

```text
planned -> preflighting -> waiting-approval -> applying -> verifying
 -> succeeded
 -> failed
 -> rolling-back -> rolled-back / rollback-failed
 -> cancelled
```

Reason codes distinguish config/render, policy/admission, auth/permission, provider outage, capacity/scheduling, rollout health, cancellation and unknown drift.

## Strategy

Baseline Kubernetes strategy is ordinary rollout via Helm-rendered manifests + Server-Side Apply. Canary/blue-green only when concrete risk/requirements justify them; provider can expose strategy capabilities.

## Rollback

Rollback selects exact known-good Release/Deployment and applies through the same trusted provider/policy path. Forward-fix may be preferred when data migrations make rollback unsafe; the Deployment record explains the resolution policy.

## Increment Realization

| Increment | Deployment realization |
|---|---|
| I2 | deployment strategy/requirements planned. |
| I6 | full primitive/provider/health/rollback activates. |
| I8 | generic incident/resolver can diagnose/remediate deployment failures. |
| I9 | formal SLO/error-budget policy may influence promotion. |

## Current Implementation State

Target spec only.

## Deferred Realization

Progressive delivery controllers/GitOps reconciliation are optional adapters triggered by requirements.

## Temporary Dogfood Behavior

Manual development deployments before I6 do not create a competing product deployment authority.

## Failure / Recovery

All side effects are idempotent/reconcilable. A control-plane restart resumes durable workflow and re-observes provider rollout before retrying.

## UI Implications

Page shows source/artifacts, target environment, preflight/diff, approvals, rollout/health, timeline, previous safe release and rollback action/result.

## Decisions / ADRs

See ADR 0008 and deployment-resolution workflow.