Release Checklist (Operators)

Destination currency (source-verified 2026-10-07 at f9dbf896333339ed6ed3e655d4e8e3a793cc38fe): Evidence hosts attestation, canonical-record, capsule, and signing-key reads under /api/evidence/v1; OfflineKit hosts the standard export API under /api/offlinekit/v1/exports. The owner handler suffix determines the complete path. See Evidence architecture. This documentation update does not verify a live signing, promotion, or export operation.

This checklist consolidates production-rollout guardrails that must be re-verified for every cut of the StellaOps suite. It supplements the module-specific runbooks under docs/operations/ and is meant to be reviewed by the release approver before a tag is pushed to a production environment.

Cutting the evaluation bundle? This page is the reviewer’s guardrail list, not the procedure. For the ordered steps from a clean tree to published, verifiable artefacts — build, sign, upload, verify, roll back — see release-bundle-procedure.md. Both apply.

Unsupported deployment targets

Stella Ops targets non-Kubernetes container estates. Kubernetes manifests, Helm charts, kubectl rollout commands, and Helm rollback procedures are not supported release artifacts.

Reviewers must verify, before approving a production release tag:

• [ ] No Helm chart or Kubernetes manifest is included in active release packaging.
• [ ] Release notes and operator docs direct customers to Docker Compose, Offline Kit, and signed release manifests only.
• [ ] Any mention of Helm/Kubernetes in scoped release docs is explicitly historical or unsupported.

Historical note: release digest tooling may still be used for non-Kubernetes release packaging because it validates digest-pinned release-manifest authority from local CI artifacts.

Before a release, verify this checklist against the current release digest inventory, release/evidence schemas, default local model guidance and provider-pack guidance.

Assurance pack evidence-scope guardrails

NIS2 and DORA are optional software-estate Assurance packs, not broad compliance-product modes. Reviewers must verify, before approving a production release tag:

• [ ] stella assurance pack inspect nis2 --json and stella assurance pack inspect dora --json include operator-observed-estate, operator-supplied, and stella-supplier evidence scopes.
• [ ] The /assurance page and setup Assurance step display software-estate coverage and operator-supplied gaps without using “NIS2 compliant”, “DORA compliant mode”, or “CRA compliant mode” wording.
• [ ] The release evidence pack deliberately marks unavailable the stella-supplier-evidence-v1 profile for the shipped Stella release. Note: stella-supplier-evidence-v1 is still Draft/roadmap — no serializer, validator, export profile, or endpoint produces this payload yet (verified against src/ 2026-05-30; see docs/contracts/stella-supplier-evidence-v1.md). What is implemented is the reference to the profile id stella.supplier-evidence from the Assurance pack descriptors; the supplier-evidence export itself must not be cited as a delivered artifact.
• [ ] DORA schema/taxonomy pins are rechecked and release notes identify the exact local pins or local-contract markers used for major incident and RoI artifacts.
• [ ] QTSP/QSCD or release-signing provider selection guidance is current for the release-signature profile used by the release. The authoritative on-ramp is the Production signing runbook — follow it to verify operator-owned signing custody through the configured cryptography provider, then complete the checklist below.

Production signing (compliance evidence)

Evidence capsule sealing and OfflineKit SoA exports require operator-owned signing keys. The checked-in families supply configuration and secret pointers; they do not ship a shared signing key. Use the existing cryptography library, configured operation-specific key and approved custody workflow. The Production signing runbook describes the current source inputs and required operational verification.

Reviewers must verify, before approving a production release tag:

• [ ] Evidence capsule custody: EvidenceLocker:Signing:UseCryptoRegistry is true, the configured key resolves on the intended provider, and AllowEphemeralKeyMaterial / AllowUnsignedCapsules are false. The family requires STELLAOPS_EVIDENCELOCKER_CAPSULE_ED25519_SEED_B64 from the approved secret source for its configured-material path. Provider-held custody must remove that raw input and mandatory interpolation from the selected chain after enrollment; startup alone does not prove that the provider holds a key. Source: src/Evidence/__Libraries/StellaOps.EvidenceLocker.Core/Configuration/EvidenceLockerOptions.cs and the capsule signer/service under StellaOps.EvidenceLocker/Capsules/.
• [ ] Capsule JWKS and artifact: GET /api/evidence/v1/evidence/capsules/signing-keys/jwks returns a usable key whose kid matches the actual exported envelope. Check that key’s algorithm and identity, rather than assuming keys[0] or Ed25519. Verify the exported capsule offline. Source: CapsuleSigningKeyService and src/Evidence/__Libraries/StellaOps.EvidenceLocker.Application/Api/Capsules/CapsuleSigningKeyEndpoints.cs.
• [ ] OfflineKit NIS2 SoA custody: Export:Nis2Soa:SigningKeyId, SigningAlgorithmId and SigningProviderHint resolve the intended key. Mounted custody uses the authoritative operator-owned read-only SigningPrivateKeyPemFile; a bad configured file cannot fall back to inline material. Provider-held custody requires both private-material inputs absent and the key enrolled. No private PEM belongs in deployed configuration. Source: Nis2SoaExportOptions and OperatorMountedSigningKeys under src/OfflineKit/__Libraries/StellaOps.ExportCenter.Application/.
• [ ] SoA artifact verification: complete matching public TrustRoots, validity, fingerprint and ExpectedSignerKeyId are configured; POST /api/offlinekit/v1/exports/nis2/soa/runs succeeds with verification.isValid=true, and its exact returned asymmetric bundle verifies offline. The SoA group requires export.viewer and the POST run route adds export.operator; the caller must satisfy both plus the host’s configured resource-server RequiredScopes. The descriptive export:operate metadata is not that complete authorization requirement. Re-verify configured defaults; Operator does not imply Viewer. stella export nis2-soa creates a separate local HMAC bundle and does not verify this server artifact.
• [ ] Provider posture: the selected provider is enabled, supports the actual configured algorithm and owns the operation’s key. Test simulation providers are excluded from release evidence and cloud-managed KMS is not a default.
• [ ] Qualified-signing claim: software provider selection is not presented as qualified or certified custody. Any stronger claim has its own accepted provider and artifact evidence, as described in the runbook §6.

Authority / anonymous-fallback guardrails (audit finding A3)

The Scanner and Signals services both enforce a fail-fast on production startup if Authority:AllowAnonymousFallback is left enabled or if Authority:Enabled is false. The validators are:

• StellaOps.Scanner.WebService.Hosting.ScannerRuntimeConfigurationValidator (Sprint 20260430-003 SCAN-FALLBACK-01).
• StellaOps.Signals.Hosting.SignalsRuntimeConfigurationValidator (existing; Sprint 20260430-003 SIG-FALLBACK-01 lifted it from a top-level local function so it is unit-testable).

The two validators do not short-circuit identically (verified against source 2026-05-30):

• Scanner (ScannerRuntimeConfigurationValidator.Validate) returns early for TestingLocalHarness, for Development/Testing with Scanner:LocalHarness:Enabled=true, and for a bare Development or Testing environment unconditionally.
• Signals (SignalsRuntimeConfigurationValidator.Validate) returns early only for TestingLocalHarness or for Development/Testing with Signals:LocalHarness:Enabled=true. A plain Development/Testing host without that opt-in still runs the checks. (Signals additionally enforces an explicit cache connection string and rejects the filesystem artifact-storage driver in production — Sprint 20260430-003 / 20260502_013.)

Reviewers must verify, before approving a production release tag:

• [ ] devops/compose/docker-compose.stella-services.yml declares SCANNER_SCANNER__AUTHORITY__ENABLED: "true" and SCANNER_SCANNER__AUTHORITY__ALLOWANONYMOUSFALLBACK: "false" on the scanner-web service.
• [ ] The same compose file declares Signals__Authority__Enabled: "true" and Signals__Authority__AllowAnonymousFallback: "false" on the signals service.
• [ ] No production override file (e.g. an environment-specific docker-compose.<env>.yml) loosens those values back to true.
• [ ] The release notes call out that any local developer run that previously relied on the credential-derived AllowAnonymousFallback=true now requires either ASPNETCORE_ENVIRONMENT=Development or the explicit <Service>:LocalHarness:Enabled=true opt-in.

If any of the above fails, the release is blocked until the compose profile is fixed; the services are designed to refuse to start, but the explicit env declaration prevents an operator from silently inheriting the credential-derived default at runtime.

Zastava admission webhook fail-open posture (audit finding A6) — RETIRED

RETIRED 2026-05-12 (SPRINT_20260512_018). No longer a release gate. The Zastava module — including the zastava-webhook admission service and the ZastavaWebhookRuntimeConfigurationValidator referenced below — was a Kubernetes-native admission flow that conflicts with the non-Kubernetes deployment posture asserted in the “Unsupported deployment targets” section above. It was fully retired and the source moved to docs-archive/code-snapshots/zastava-2026-05-12-retired/. The compose stacks no longer wire a zastava-webhook service: slot 43 is held vacant in devops/compose/docker-compose.stella-services.yml (the legacy monolith compose that carried a matching decommission note was deleted 2026-09-01, SPRINT_20260824_010 P8-12). The zastava__webhook__admission__failOpenByDefault and acknowledgeFailOpenRisk keys exist only in the archived snapshot — there is nothing for a release reviewer to verify, and the verification steps that previously lived here are no longer applicable.

Runtime-admission responsibilities were absorbed by the deployment agent (StellaOps.Agent.Host); see docs-archive/modules/zastava/architecture.md (public retirement record) and docs/modules/release-orchestrator/architecture.md (replacement runtime-observation design). The historical fail-open audit events and the runbook owner assignment that this section described are no longer emitted by any live service.