Status: Accepted
Date: 2026-02-23
Authors: OSHUN Studio Product, OSHUN Web Engineering, Platform
Architecture
Reviewers: Domain Leads (Yemaya, Isis, Hathor, Aja, Bellona)
Supersedes: N/A
Superseded by: N/A
Context and Problem Statement#
OSHUN has accepted shell architecture decisions for consumer-facing domain experiences (Tara, Veritas, Nyx, Arete), but OSHUN Studio requires a distinct IA model for expert users building AAA games, films, and cross-media productions.
Studio scope is broader and operationally denser than the consumer shell:
- Yemaya: project orchestration, assets, collaboration, production operations
- Isis: generative workflows, GPU operations, outputs, lineage, cost controls
- Hathor: worldbuilding, narrative, simulation, lore validation
- Aja: motion capture, retargeting, animation processing pipelines
- Bellona: engine bridges, build/export, runtime and virtual production
- Project Obsidian: flagship franchise program that spans all five domains
Without a dedicated IA decision and quality bar, Studio risks:
- fragmented workflows across domain UIs
- missing feature exposure for high-value domain capabilities
- inconsistent expert ergonomics and observability
- weak cross-domain traceability from idea to shipped artifact
Decision Drivers#
- Capability completeness: expose all advanced domain capabilities in one web interface.
- Expert ergonomics: support dense, high-throughput, low-friction workflows.
- Cross-domain traceability: every action must preserve project/program lineage.
- Operational safety: explicit validation, approvals, auditability, and rollback paths.
- Parity governance: web surfaces must stay in lockstep with domain API and event contracts.
- Performance and resilience: large-scale production workflows must remain responsive under load and partial outages.
Considered Options#
Option 1: Domain-First Separate Interfaces#
Description: keep each domain web surface as the primary interface and use links between systems.
Pros:
- Minimal central integration ownership.
- Domains iterate independently.
Cons:
- Breaks one-studio promise.
- High cognitive overhead and context switching.
- Weak traceability and inconsistent quality bars.
Option 2: Thin Studio Launcher#
Description: provide one Studio home that only launches domain tools.
Pros:
- Fast initial delivery.
- Low immediate UI complexity.
Cons:
- Does not expose advanced capabilities in a unified operational model.
- Cannot enforce parity, audit, or common approval patterns.
Option 3: Unified Studio IA with Capability-Exposure Contracts (Chosen)#
Description: implement OSHUN Studio as a single expert web application with shared IA primitives, domain capability exposure standards, and cross-domain contracts for context, actions, and observability.
Pros:
- One coherent operational surface.
- Enforceable parity and quality gates.
- Strong cross-domain lineage and governance.
Cons:
- Higher initial integration and governance complexity.
- Requires disciplined domain adapter and contract management.
Decision Outcome#
Chosen option: Option 3 - Unified Studio IA with capability-exposure contracts.
IA Model (Normative)#
OSHUN Studio will use a layered IA model:
- Program Layer: portfolio/program control (
Project Obsidian, etc.). - Workspace Layer: team, domain, and project context switching.
- Capability Layer: domain modules (Yemaya, Isis, Hathor, Aja, Bellona).
- Workflow Layer: end-to-end operational flows across domains.
- Artifact Layer: files, assets, outputs, models, builds, and reports.
- Governance Layer: approvals, audit trail, policy and compliance evidence.
Studio Top-Level Navigation (Normative)#
The primary IA must expose these top-level surfaces:
Studio HomeProgramsProjectsAssetsGenerationWorld & NarrativeMotionBuild & RuntimeReview & ApprovalsObservabilityGovernance
Capability Exposure Standard (Normative)#
For each advanced capability mapped from domain docs, Studio must expose:
- discoverability entry point
- primary workflow (create/execute)
- monitoring/status visibility
- failure diagnostics and recovery actions
- collaboration and approvals
- audit and telemetry events
No capability is considered exposed unless all six exposure criteria are implemented.
Context Model (Normative)#
All studio operations must be contextualized by:
programIdprojectIdworkspaceIddomaincapabilityactorIdrequestId/traceId
This context must persist in route state, API calls, events, and audit records.
Architecture Implications#
apps/oshun/webbecomes the canonical Studio shell for expert workflows.- Domain APIs remain source-of-truth for domain-owned operations.
- Studio adapters normalize domain operations into shared workflow and artifact semantics.
- Shared IA components in
libs/oshun/uiand route contracts inlibs/oshun/navigationbecome mandatory for Studio surfaces.
Acceptance Criteria (OST-00001)#
OST-00001 is complete only when all criteria below are true:
- ADR published at
docs/adr/ADR-0019-oshun-studio-information-architecture.md. - ADR defines explicit IA layers and top-level Studio navigation surfaces.
- ADR defines capability-exposure standard with objective completion rules.
- ADR defines context model required across routes, APIs, events, and audit.
- ADR aligns with existing OSHUN ADRs (
ADR-0007throughADR-0012) without conflict. - ADR names the five Studio domains (Yemaya, Isis, Hathor, Aja, Bellona) and Project Obsidian as governing production scope.
- ADR includes measurable quality and governance implications for implementation.
Consequences#
Positive Consequences#
- One stable IA contract for Studio-scale execution.
- Clear definition of what it means to fully expose a domain capability.
- Reduced UX drift and improved cross-domain operational cohesion.
Negative Consequences#
- Requires stronger integration discipline across domain teams.
- Adds governance overhead for changes that affect shared IA contracts.
Risks and Mitigations#
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Capability exposure drift over time | Medium | High | Add parity checks between docs, API resources, and UI routes in CI |
| Over-complex top-level nav for new users | Medium | Medium | Role-based default layouts + progressive disclosure |
| Cross-domain context loss in long workflows | Medium | High | Enforce context contract in route and API middleware |
| Operational overload from dense interfaces | Medium | Medium | Keyboard-first UX, command palette, saved views, adaptive dashboards |
Monitoring and Observability Requirements#
Track at minimum:
- route-level capability usage and abandonment
- time-to-first-success per capability workflow
- failure rates by domain capability
- approval cycle times and rollback rates
- cross-domain handoff latency
Related Decisions#
docs/adr/ADR-0013-oshun-shell-architecture-and-domain-adapters.mddocs/adr/ADR-0014-oshun-web-and-pwa-strategy.mddocs/adr/ADR-0015-deep-linking-and-cross-domain-routing.mddocs/adr/ADR-0016-shared-identity-and-cross-domain-session-model.mddocs/adr/ADR-0017-offline-caching-and-sync-strategy.mddocs/adr/ADR-0018-analytics-taxonomy-and-event-naming.md
References#
docs/domains/yemaya/features.mddocs/domains/isis/features.mddocs/domains/hathor/features.mddocs/domains/aja/features.mddocs/domains/bellona/features.mddocs/domains/yemaya/api/README.mddocs/domains/isis/api/README.mddocs/domains/hathor/api/README.mddocs/domains/aja/api/README.mddocs/domains/bellona/api/README.mdTODOS.md(Phase 27: Project Obsidian)