Disciplines · Launch

Oshun V1 Go/No-Go

Before the go/no-go meeting opens:

12sections5 minread
Markdown source
On this page

Gate owner: Release Captain. Cross-functional decision authority: release captain, security lead, privacy lead, product lead, support lead, engineering lead. Required for §33.2. Each launch consumes one signed instance of this checklist at docs/releases/v1/verification/go-no-go/YYYY-MM-DD.md.

OSHUN V1 enters General Availability only when every item below is either checked or has an explicit signed waiver from the appropriate decision authority recorded in §10.

1. Pre-gate dependencies#

Before the go/no-go meeting opens:

  • Dogfood drill closed with signoff (docs/launch/dogfood-drill.md §6).
  • Safety review pass closed with three-board signoff (docs/launch/safety-review.md §5).
  • Quality review pass closed for every domain and every eval suite (docs/launch/quality-review.md §4).
  • Private beta closed with signed exit criteria (docs/launch/private-beta.md §6).
  • Beta-blocking-issue remediation reports clear (docs/launch/beta-blocking-remediation.md §9).

A missing pre-gate dependency stops the go/no-go meeting. The release captain announces the new earliest-possible-meeting date in the same channel.

2. Security and compliance#

  • DAST + SAST + dependency + secret scan + SBOM checks green on the release tag (docs/security/v1-release-security-gates.md).
  • External penetration-test signoff captured (docs/security/pentest/signoff.md).
  • Provenance audit complete on a random sample of 100 published items per customer domain (full source → model → prompt → reviewer → policy-version chain present).
  • Watermark offline-verifier audit passes ≥ 99.9 % (docs/runbooks/watermark-verification-failure.md).
  • Records-of-processing and DPIA reviewed for the launch surfaces.
  • Tenant-isolation test suite passing (tests/security/tenant-isolation/).
  • Cross-tenant data exposure incidents in beta: zero.

3. Quality, content, and AI evals#

  • All eval-suite floors in docs/launch/quality-review.md §1.8 met on the release tag.
  • Per-domain content review checklists passed for all bundled content.
  • Persona-tone audit drift ≤ 1 σ on rolling 14-day window for every enabled persona.
  • Localization launch coverage hit per docs/launch/locale-coverage.md.
  • Accessibility floors hit per docs/launch/quality-review.md §3.6 Lighthouse Accessibility ≥ 95 + axe-core no critical violations.

4. Critical-journey automation#

  • All 14 critical journeys in §33.3 have green Playwright / mobile / admin runs on the release tag (docs/launch/critical-journeys.md).
  • Lighthouse budgets enforced in CI for every customer route (docs/testing/automation-matrix.md).
  • Visual regression CI clean (docs/testing/automation-matrix.md).
  • Contract / event-schema / replay / dead-letter / migration / analytics / audit / seed / synthetic-data tests green.

5. Operations readiness#

  • All runbooks signed-off for currency in the last 30 days (docs/runbooks/).
  • On-call rotations confirmed (primary + secondary) for the first 14 days post-GA.
  • Status-page integration verified (libs/oshun/tenant-console/src/status-page).
  • Support, moderation, review, persona, model, privacy, compliance, product, and launch-support training complete (docs/training/).
  • Kill-switch fire + fallback recovery drill completed in the last 14 days.
  • DSAR drill (export + delete + restore-blocked) completed in the last 14 days.

6. Rollout plan (canary % schedule)#

The rollout plan is approved separately at docs/launch/rollout-plan.md. Required for this gate:

  • Per-substrate canary % schedule reviewed and signed (web, mobile-iOS, mobile-Android, BFF, services, workers, ML inference).
  • Promotion gates between stages (1 → 5 → 25 → 50 → 100 %) reviewed with dashboard thresholds.
  • Auto-promotion versus manual-promotion choice documented for each substrate.
  • Canary cohort definitions reviewed (employee cohort, pilot tenants, regional cohorts) — see libs/oshun/search-discovery/src/experiments/canary.ts.

7. Rollback plan (per substrate)#

The rollback plan is approved separately at docs/launch/rollback-plan.md (itself referencing docs/reference/rollback-procedures.md). Required:

  • Web rollback procedure verified by a dry-run in the last 14 days.
  • Mobile (iOS + Android) rollback procedure documented and rehearsed.
  • BFF rollback via ECS task-definition revert verified.
  • Services rollback (per service) verified.
  • Database-migration rollback strategy verified (per migration shipped in this release).
  • Persona rollback procedure rehearsed (docs/runbooks/persona-rollback.md).
  • Model/workflow rollback procedure rehearsed (docs/runbooks/model-workflow-rollback.md).
  • RTO ≤ 1 h, RPO ≤ 15 min validated for every substrate.

8. Post-deploy monitoring and canary analysis#

  • All dashboards in docs/launch/post-deploy-monitoring.md live and pulled into the launch war-room.
  • Canary analysis automation enabled per docs/launch/canary-analysis.md and exercised end-to-end.
  • Alert routes verified for the on-call rotations (paging tests in last 7 days).
  • Customer-experience monitors (synthetic + RUM) live.

9. Public communications#

  • Public website + app-store listings final (apps/oshun/web/public/).
  • Deep-link routing verified (apps/oshun/web/e2e/lilith-public-routes.spec.ts).
  • Minimum-version / forced-update path verified (apps/oshun/web/e2e/pwa-install-update-offline.spec.ts).
  • Public status page populated and pre-warmed for launch.
  • Release notes published.

10. Decision capture (GA approval)#

The General Availability approval is captured here only when every signatory replies APPROVE with timestamps and links. Anything other than APPROVE (HOLD / OBJECT / ABSTAIN) blocks GA.

text
# GA approval
date: YYYY-MM-DD
release tag: vX.Y.Z
release commit: <sha>

| Role | Signatory | Decision | TS | Evidence |
| --- | --- | --- | --- | --- |
| Release Captain | <name> | APPROVE / HOLD | YYYY-MM-DDTHH:MM | <link> |
| Security Lead | <name> | APPROVE / HOLD | YYYY-MM-DDTHH:MM | <link> |
| Privacy Lead | <name> | APPROVE / HOLD | YYYY-MM-DDTHH:MM | <link> |
| Product Lead | <name> | APPROVE / HOLD | YYYY-MM-DDTHH:MM | <link> |
| Support Lead | <name> | APPROVE / HOLD | YYYY-MM-DDTHH:MM | <link> |
| Engineering Lead | <name> | APPROVE / HOLD | YYYY-MM-DDTHH:MM | <link> |

waiver(s): (each waiver requires the dissenting authority's name and a
linked rationale; waivers are valid only against §4-§9 — never §1-§3)

resulting decision: GO | NO-GO

next earliest meeting (if NO-GO): YYYY-MM-DD

Commit the signed file to docs/releases/v1/verification/go-no-go/YYYY-MM-DD.md.

11. Rollback triggers (auto-rollback)#

Any of these triggers, sustained for the indicated window, auto-rollback the current stage and freeze further promotions:

  • Unresolved critical security issue.
  • P0 data-loss signal.
  • Cross-tenant leakage signal.
  • Grounded-answer rate < 0.90 (assistant or Metis) for 15 min.
  • Crisis-flow safe-route hit rate < 1.00 for any single case.
  • Crash-free sessions < 99.0 % (iOS or Android) for 30 min.
  • API uptime < 99.0 % for 30 min.
  • API p95 latency > 1 s for 30 min.
  • Moderation backlog SLA breach > 24 h.
  • Tenant-isolation test failure in production.
  • Watermark verification rate < 99.0 % for 30 min.

Auto-rollback uses the per-substrate procedure in docs/launch/rollback-plan.md.

12. Cross-references#

  • Dogfood drill: docs/launch/dogfood-drill.md.
  • Safety review: docs/launch/safety-review.md.
  • Quality review: docs/launch/quality-review.md.
  • Private beta: docs/launch/private-beta.md.
  • Beta-blocking remediation: docs/launch/beta-blocking-remediation.md.
  • Rollout plan: docs/launch/rollout-plan.md.
  • Rollback plan: docs/launch/rollback-plan.md.
  • Post-deploy monitoring: docs/launch/post-deploy-monitoring.md.
  • Canary analysis: docs/launch/canary-analysis.md.
  • Critical journeys: docs/launch/critical-journeys.md.
  • Exit criteria signoff: docs/launch/exit-criteria-signoff.md.