Disciplines · Decisions (ADRs)

ADR-0053: OSHUN Customer Information Architecture and Tara-Centered Spine

OSHUN already has a unified shell architecture, shared route contracts, and implemented customer surfaces for Home, Explore, Activity, and Profile.

Accepted · 2026-03-24
9sections5 minread
Markdown source
On this page

Status: Accepted
Date: 2026-03-24
Authors: OSHUN Product, OSHUN Design, OSHUN Web Engineering
Reviewers: Tara, Arete, Veritas, Nyx leads
Supersedes: N/A
Superseded by: N/A

Context and Problem Statement#

OSHUN already has a unified shell architecture, shared route contracts, and implemented customer surfaces for Home, Explore, Activity, and Profile. What it still lacks is one canonical IA rule that explains what those surfaces orbit around emotionally and behaviorally.

Without that rule, the customer shell drifts toward a flat launcher:

  • every domain can appear equally important at first glance
  • search and discovery can overpower the product's contemplative identity
  • progress and continuity can read like disconnected utilities instead of one practice arc
  • home can become a generic dashboard instead of the place where OSHUN begins

The PRD and gap-analysis documents already point in the same direction:

  • Tara is the contemplative and emotional center of gravity
  • supporting domains should deepen that center rather than compete with it
  • home should open with presence first, then branch outward into action, clarity, and awe

That product intent needs a normative IA decision and a reusable contract, not just descriptive prose.

Decision Drivers#

  • Narrative cohesion: the shell should feel like one product with one center of gravity.
  • Entry clarity: users should understand where to begin without scanning a flat grid of peers.
  • Continuity: cross-domain movement should feel like one practice loop, not app switching.
  • Extensibility: future IA work should extend a clear center rather than renegotiate the product spine each time.
  • Contractability: route, content, and UX work should be able to point at a shared definition.

Considered Options#

Option 1: Keep the customer shell as a flat set of peer surfaces#

Description: treat Home, Explore, Activity, and Profile as neutral utilities with no declared product center.

Pros:

  • Low documentation effort.
  • No need to explain why one domain is privileged.

Cons:

  • Breaks the Tara-centered product philosophy already accepted elsewhere.
  • Makes the shell feel more like a dashboard hub than a contemplative product.
  • Encourages drift where search or domain grids become the real center.

Option 2: Make search or discovery the customer entry point#

Description: treat discovery as the main organizing shell surface and let Tara compete inside it.

Pros:

  • Strong for content density and browse-first behavior.
  • Easy to align with generic multi-domain aggregation patterns.

Cons:

  • Conflicts directly with the PRD's Tara-led daily-flow model.
  • Reframes OSHUN as a content browser instead of a contemplative product.
  • Makes continuity secondary to consumption.

Option 3: Establish a Tara-centered customer IA spine (Chosen)#

Description: declare Tara as the customer product center and define every top-level shell surface in relation to that center.

Pros:

  • Matches the accepted product philosophy.
  • Gives home a non-negotiable purpose.
  • Preserves a coherent center while still allowing supporting domains to shine.
  • Creates a reusable contract for future UX and route work.

Cons:

  • Requires discipline so supporting domains do not drift into equal-first presentation on home.
  • Requires follow-on IA work for Nisaba and assistant/library relationships.

Decision Outcome#

Chosen option: Option 3 - Tara-centered customer information architecture.

Normative IA Rule#

For the customer shell, Tara is the product center.

That means:

  • Home must begin with Tara-led presence, reset, ritual, or reflection.
  • Explore must feel like branching out from center, not replacing it.
  • Activity must summarize one continuity loop anchored in practice, not separate domain logs.
  • Profile must reinforce identity, memory, privacy, and preference controls that keep the practice loop trustworthy and durable.
  • Search may be powerful, but it is a supporting utility rather than the shell's emotional anchor.

Companion-Layer Rule#

During this IA slice, Tara's companion layers are:

  • Arete for embodiment and execution
  • Veritas for clarity and discernment
  • Nyx for awe and temporal perspective

These layers deepen the current Tara context. They do not replace Tara as the entry point.

Home Entry Sequence (Normative)#

The customer home surface must follow this order of intent:

  1. Tara centering
  2. Cross-domain continuity
  3. Companion-domain bridges
  4. Direct domain launches

This sequence defines what "Tara-centered home" means in practice. It prevents OSHUN home from collapsing into a flat dashboard or domain launcher.

Contract Publication#

The shared representation of this decision lives in libs/oshun/navigation/src/customer-ia.ts.

That contract is now the canonical source for:

  • the customer product center
  • the Tara-centered meaning of each shell surface
  • the required home-entry sequence
  • the companion-domain ordering for this slice

Scope Boundaries#

  • This ADR does not yet formalize Nisaba as a first-class customer IA layer. That expansion belongs to V1-UX-002.
  • This ADR does not yet define the full relationship among home, explore, activity, library, assistant, and profile. That work belongs to V1-UX-003 and V1-UX-004.
  • This ADR does not require a finished visual redesign of home. It defines the IA spine that future UI work must honor.

Architecture Implications#

  • Shared navigation code can reference one canonical customer IA contract rather than relying on comments or scattered docs.
  • Home/dashboard work must justify any composition that places non-Tara content ahead of Tara centering.
  • Search, recommendations, and domain launch patterns should be evaluated against whether they preserve the Tara-centered entry model.
  • Future Nisaba and assistant IA work can extend this spine instead of replacing it.

Acceptance Criteria#

V1-UX-001 is complete only when all criteria below are true:

  1. A canonical ADR declares Tara as the customer product center.
  2. The ADR defines the Tara-centered meaning of Home, Explore, Activity, Profile, and Search.
  3. The ADR defines the required home-entry sequence.
  4. A shared code contract publishes the same model for route and UX consumers.
  5. Oshun shell documentation no longer describes the customer IA as a flat set of peer surfaces.
  • docs/adr/ADR-0013-oshun-shell-architecture-and-domain-adapters.md
  • docs/adr/ADR-0014-oshun-web-and-pwa-strategy.md
  • docs/adr/ADR-0015-deep-linking-and-cross-domain-routing.md
  • docs/adr/ADR-0016-shared-identity-and-cross-domain-session-model.md
  • docs/adr/ADR-0018-analytics-taxonomy-and-event-naming.md

References#

  • docs/releases/v1/specs/web-app-admin-v1-prd.md
  • docs/releases/v1/reports/unified-product-gap-analysis-and-nisaba-integration-report-2026-03-22.md
  • docs/releases/v1/domains/oshun/feature-inventory.md
  • apps/oshun/web/README.md
  • libs/oshun/navigation/src/routes.ts