# Release and Deployment Boundary

**Status:** Approved target-state baseline  
**Full product activation:** I6

## Target State

AWP separates immutable artifact/release identity from environment-specific deployment progression.

```text
verified source / ChangeSet / merge
      ↓
Artifact(s) + provenance/SBOM/signature
      ↓
Release (immutable intended version set)
      ↓
Deployment intent to Environment
      ↓ DeploymentProvider
render Helm/manifests
      ↓ server-side dry-run/diff
policy/Approval
      ↓
Kubernetes Server-Side Apply (AWP field manager)
      ↓
rollout/health observation
      ↓
Deployment result / rollback if policy requires
```

## Invariants From Day 1

- `Artifact`, `Release`, `Environment` and `Deployment` are separate primitives;
- the same immutable artifact is promoted between environments where practical; no rebuild-per-environment unless explicitly required;
- environment credentials remain behind Connection/CredentialReference;
- deployment authority stays in trusted control plane;
- Kubernetes rollout state is observed mechanics, not the sole AWP Deployment identity;
- deployment records exact artifact digest/source/provenance/environment/config revision;
- rollback target is a known-good Release/Deployment, not an ad-hoc mutable working tree;
- production approval/autonomy is explicit policy;
- deployment failures remain durable/observable and feed Incident/Resolver flows.

## Release Strategy

Release may be continuous delivery, continuous deployment, scheduled/batched or on-demand. Planning resolves the strategy in `EffectiveDeliveryPlan`; I6 executes it.

Continuous delivery means qualifying change is releasable/deployable but production may require approval. Continuous deployment means qualifying changes automatically reach production after gates.

## Kubernetes Baseline

Baseline provider:

```text
Helm-rendered manifests
+ Kubernetes Server-Side Apply
+ explicit AWP field manager
+ server-side dry-run/diff
+ rollout/health observation
```

Flux is added only for explicit independent GitOps reconciliation. Flagger only for an explicit progressive-delivery requirement. Do not build a Kubernetes controller inside AWP when provider tooling already owns mechanics.

## Supply-chain Evidence

At artifact distribution/release:

- immutable digest;
- source revision;
- CycloneDX preferred / SPDX accepted SBOM;
- SLSA/in-toto compatible build provenance;
- Cosign signing/attestation;
- vulnerability result bound to digest;
- ORAS/OCI transport where appropriate.

Trivy is baseline scanning/SBOM tool; Syft is optional only when it provides concrete advantage.

## Failure and Rollback

Deployment failure classification distinguishes render/config error, admission/policy denial, capacity/scheduling, rollout health failure, provider/network outage and unknown drift. Rollback is policy-driven and itself creates a Deployment/Resolution record.

## Increment Realization

| Increment | Delivery realization |
|---|---|
| I0/I1 | CI/artifact evidence seam and provider interfaces only. |
| I2 | Planning recommends release/deployment strategy and required connections. |
| I6 | Artifact/Release/Environment/Deployment product activates; full R3 evidence. |
| I8 | generic resolver/self-healing integration deepens failures. |
| I9 | multi-tenant environments, upgrade/supportability and enterprise policy. |

## Current Implementation State

No production CD is required for I1 dogfood. The final seam is still specified now so early CI/change identity does not conflict with I6.

## Deferred Realization

Progressive canary/blue-green, GitOps reconciliation and multi-region are requirement-triggered strategies, not defaults.

## Temporary Dogfood Behavior

Manual local deployment of AWP itself may exist before I6 only as development operations. It must not become a competing product Deployment authority.

## Decisions / ADRs

See ADR 0008. R3 supply-chain practice is binding; R5 reliability policy is separate and parked to I9.