SEIF Docs

Environments, promotion and rollback

IMPLEMENTED: development, staging and production are created on first Project registration; Admin can add custom environments. Each environment separately records the promoted Build, promotion event, previous Build and current deployment. The Runtime retains the Build's compiled policy environment as its resolution basis, while traces identify the operational deployment environment. Promoting never recompiles or changes artifact bytes.

In Deploy, register a tested Build, choose the candidate, inspect Regression, then Promote and Deploy. Production change requires an explicit confirmation in the Workstation. Default production policy requires Reviewer/Admin approval; staging/production retain metadata. Approval binds candidate artifact digest, environment, current promotion and policy digest. A candidate, policy or current-release change makes approval stale. Developers and automation identities cannot approve; approval is human-only. Optional separation of duties (requireDistinctApprover, 0.4.0) refuses an approval by the principal who registered the candidate (SEPARATION_OF_DUTIES) and re-checks it at promotion; it is off by default so personal use stays simple.

Every promotion recomputes deterministic tests/regression server-side. User-supplied PASS reports are not trusted. When an environment has a current Build, its assertion corpus remains the baseline even if the caller supplies a weaker comparison. Policy can block required failures/misses, forbidden inclusion, stale required context, and budget failures; warn thresholds are configurable. A failed attempt records its regression and audit reason.

Promotion uses compare-and-set expectedPromotion before and after evaluation. Refresh after STALE_REF; do not retry blindly with an obsolete approval. Registration, promotion, deployment, and health remain separate facts.

Rollback selects the previous registered immutable Build and appends a new promotion and deployment. It preserves all previous history and still satisfies current signature/approval/regression policy. It is not a bypass for a newly introduced safety policy. The old healthy deployment remains active until its replacement proves the exact expected Build, contract and deployment identity.

Break-glass rollback (0.4.0)

When current policy prevents a rapid rollback during an incident — for example a newer Build added an obligation the last good Build fails, or no Reviewer is available — an Admin can request POST /v1/emergency-rollbacks {project, environment, target, reason, expectedPromotion} (capability environment.emergency_rollback, human-only). It is a separate endpoint, never a hidden flag on ordinary rollback:

  • the target must be a registered immutable Build whose deployment previously activated HEALTHY in this environment — a DEGRADED activation under an explicit degrade policy does not count (GET /v1/emergency-candidates);
  • a human reason of 12–1000 characters is required and recorded;
  • signature policy and Build integrity are never bypassed; the approval requirement and the regression gate are bypassed explicitly — the regression still runs and is recorded with enforced: false;
  • under requireDistinctApprover the request waits for a second administrator (POST /v1/emergency-rollbacks/:id/confirm, 15-minute window; the requester cannot confirm);
  • execution appends an EMERGENCY_ROLLBACK promotion (actor, confirmer, reason, bypass facts) and emergency_rollback.request/execute audit events; history is never rewritten and Build contents never change;
  • deployment then proceeds normally (binding checks, readiness, atomic switch) and is marked break-glass in the Workstation.