# Merge to Production Workflow

**Status:** Approved target-state baseline  
**Activation:** I6; upstream merge exists I1.

## Target State

```text
trusted Merge completed
  -> identify releaseable source / build definition
  -> build Artifact(s)
  -> generate/verify SBOM + provenance + signatures + vulnerability evidence
  -> Release candidate
  -> ReleaseGate / policy / Approval
  -> promote same immutable Release to Environment(s)
       staging/other required targets
       verify deployment health
       production Approval if configured
       production Deployment
  -> post-deploy health
  -> success or rollback/Incident
```

## Source to Artifact

Release build is bound to exact merged source identity and build inputs. A mutable branch head is insufficient. Build produces immutable digest(s) and R3 supply-chain evidence when applicable.

## Release Candidate

A Release candidate references exact Artifact set/source/evidence. Changing contents creates a new Release candidate rather than mutating one that has already been approved/promoted.

## Promotion

Environment promotion normally reuses the same immutable Artifact/Release. Configuration/secret/environment bindings are applied separately. Rebuild-per-environment is an exception with explicit reason because it weakens provenance equivalence.

## Gates

Release/Deployment gates may require:

- current VerificationAuthority evidence;
- SBOM/provenance/signature/vulnerability checks;
- compatibility/migration checks;
- environment readiness/connection health;
- human Approval or autonomy policy;
- prior environment health;
- deployment preflight/diff.

## Continuous Delivery vs Deployment

Continuous delivery means a qualifying Release is always deployable but production can require Approval. Continuous deployment means policy allows qualifying changes to reach production automatically after gates.

## Database / Stateful Changes

When migration compatibility or rollback is unsafe, release plan must explicitly order schema/application transitions and define forward-fix/rollback strategy. Do not use generic rollback when it would corrupt state.

## Failure / Recovery

Artifact build/upload failure retries/reconciles without re-merging source. Deployment failure routes to deployment resolution. Provider outage preserves Release and pending promotion. Expired Approval/preflight is revalidated.

## Increment Realization

I1 ends at Merge. I2 plans release/deployment strategy. I5 supplies full verification evidence. I6 activates Artifact/Release/Environment/Deployment and this workflow. I8 adds generic resolver/incident automation. I9 may add formal reliability/error-budget policy.

## Acceptance

A user can trace production back to exact Release, Artifact digest, source merge, ChangeSet, Task and Plan, and can identify which gates/approvals allowed each promotion.