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

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

## Related Decisions

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