Disciplines · Decisions (ADRs)

ADR-0052: OSHUN Studio Launch Readiness Governance

Studio delivery spans Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian.

Accepted · 2026-02-23
10sections4 minread
Markdown source
On this page

Status: Accepted
Date: 2026-02-23
Authors: OSHUN Studio Architecture, OSHUN Program Operations, OSHUN Web Engineering, OSHUN BFF Engineering, Platform SRE
Reviewers: Domain Leads (Yemaya, Isis, Hathor, Aja, Bellona), Project Obsidian Program Design, Security and Compliance

Context and Problem Statement#

Studio delivery spans Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian. Each release currently composes readiness evidence from different dashboards, documents, and manual sign-off workflows.

Without a canonical launch readiness governance surface, Studio risks:

  • inconsistent release gates between domains and teams
  • unclear ownership for unresolved launch blockers
  • missing auditability for go/no-go decisions
  • late discovery of quality, security, or operational regressions
  • weak cross-domain coordination during staged and production rollouts

Decision Drivers#

  • Release safety: production promotion must be policy-gated and repeatable.
  • Operator ergonomics: one place to understand readiness posture and blockers.
  • Traceability: every readiness decision requires durable, auditable evidence.
  • Consistency: shared governance model across all Studio domains.
  • Operational scale: support many concurrent launches with deterministic controls.

Considered Options#

Option 1: Domain-Local Readiness Checklists#

Each domain keeps separate launch criteria and approval workflows.

Pros:

  • High local autonomy and rapid domain-specific iteration.

Cons:

  • Uneven release quality and governance drift across domains.
  • Harder cross-domain go/no-go decisions for integrated launches.

Option 2: CI-Only Readiness Gate#

Rely primarily on CI pipelines and deployment jobs for launch approvals.

Pros:

  • Lower short-term UI implementation overhead.

Cons:

  • Weak operator visibility into contextual blockers and ownership.
  • Limited support for cross-domain exception and waiver governance.

Option 3: Canonical Studio Launch Readiness Governance Workspace (Chosen)#

Adopt one Studio launch-readiness contract covering readiness scorecards, blocker workflows, policy-aware approvals, and telemetry/audit continuity.

Pros:

  • Consistent release governance posture across all domains.
  • Clear ownership and accountability for blockers.
  • Strong evidence trail for compliance and post-incident analysis.

Cons:

  • Requires ongoing governance maintenance across product, platform, and security/compliance teams.

Decision Outcome#

Chosen option: Option 3.

Studio launch-readiness governance requirements:

  1. Readiness scorecard contract for quality, security, performance, operations, and compliance dimensions.
  2. Blocker lifecycle contract for open, triage, mitigated, approved, deferred, and closed states.
  3. Policy-aware approval contract for role/tier/CAB/waiver-governed go/no-go actions.
  4. Release channel contract for preview, staging, and production readiness transitions.
  5. Telemetry/audit continuity contract for readiness decisions and escalation evidence.

Normative Rules#

Launch Readiness Scorecard Rule#

  • Every launch candidate must publish a scorecard across required readiness dimensions.
  • Scorecard dimensions must include owner, status, target threshold, and latest evidence timestamp.
  • Missing required dimensions must fail readiness evaluation closed.

Blocker Lifecycle Governance Rule#

  • Readiness blockers must be reason-coded, severity-ranked, and owner-assigned.
  • Blocker transitions must be explicit and auditable (open, triage, mitigated, approved_exception, closed).
  • Production readiness must be denied while blocking items remain unresolved unless approved exception policy is satisfied.

Go/No-Go Approval Rule#

  • Go/no-go actions must enforce role and permission-tier policy.
  • Production promotion requires valid approval evidence (CAB ticket or approved governance exception with rationale).
  • Unauthorized approvals must emit deny-path audit evidence.

Cross-Domain Dependency Rule#

  • Launch readiness must account for upstream/downstream domain dependencies.
  • Dependency health regressions must be surfaced as first-class readiness blockers.
  • Dependent-launch exceptions must be time-bounded and owner-approved.

Telemetry and Audit Continuity Rule#

  • Readiness state transitions, approval actions, and blocker lifecycle events must emit structured telemetry and audit records.
  • Missing telemetry/audit continuity must trigger degraded-observability mode.
  • Governance exports must include actor, domain scope, release channel, action, outcome, and trace lineage.

Architecture Implications#

  • Studio web introduces a dedicated launch-readiness governance workspace and route.
  • BFF requires launch-readiness APIs for scorecards, blockers, approvals, and release transitions.
  • Domain services must expose readiness signals with stable contract versions.
  • Operational runbooks and dashboards must include launch-readiness SLOs and escalation mappings.

Acceptance Criteria (OST-00313)#

OST-00313 is complete only when:

  1. ADR exists at docs/adr/ADR-0058-oshun-studio-launch-readiness-governance.md.
  2. ADR defines options, trade-offs, and selected strategy.
  3. ADR defines readiness scorecard, blocker lifecycle, go/no-go approval, cross-domain dependency, and telemetry/audit rules.
  4. ADR aligns with ADR-0007 through ADR-0051, especially ADR-0012, ADR-0041, and ADR-0051.
  5. ADR aligns with existing release governance, resilience, and compliance surfaces.
  6. ADR explicitly covers Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian.

Consequences#

Positive#

  • More deterministic and safer release promotions across Studio domains.
  • Faster go/no-go decisions with clear owner and blocker visibility.
  • Stronger compliance evidence for launch approvals and exceptions.

Negative#

  • Added governance process complexity for launch workflows.
  • Requires sustained alignment between web, BFF, platform, security, and program operations.
  • docs/adr/ADR-0013-oshun-shell-architecture-and-domain-adapters.md
  • docs/adr/ADR-0018-analytics-taxonomy-and-event-naming.md
  • docs/adr/ADR-0041-oshun-studio-review-and-approval-workflows.md
  • docs/adr/ADR-0047-oshun-studio-observability-and-operational-dashboards.md
  • docs/adr/ADR-0057-oshun-studio-backup-and-disaster-recovery-ux.md

References#

  • docs/releases/v1/runbooks/studio-review-and-approval-workflows-runbook.md
  • docs/releases/v1/runbooks/studio-observability-and-operational-dashboards-runbook.md
  • docs/releases/v1/runbooks/studio-security-hardening-program-runbook.md
  • docs/releases/v1/runbooks/on-call-runbook.md