# ADR-0052: OSHUN Studio Launch Readiness Governance

**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.

## Related Decisions

- `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`