# V3 Features — Lilith Metaverse with Yoga Instructors and AI Virtual Artists Status: V3 feature inventory. Source: derived from `V3/V3_TODOS.md` (implementation backlog), extending the Oshun V1 product (`V1/features.md`) into an embodied, multi-user surface. Audience: product, design, engineering, art, audio, generative-AI, governance, rights, and live-service leads scoping V3. Date: 2026-05-12 > **This feature map has been decomposed into focused pages under > [`features/`](./features/README.md).** This file remains the canonical hub — > it preserves every section heading (so existing `features§"…"` and > `V3_features.md#…` anchors keep resolving); the in-depth, code-grounded > companion pages live under [`features/`](./features/README.md). Start at the > [features page index](./features/README.md). The runtime/package architecture > is in [`V3_ARCHITECTURE.md`](./V3_ARCHITECTURE.md) / > [`architecture/`](./architecture/README.md). ## Purpose This document is the **feature map for V3**. It translates the V3 backlog into a product-shaped scope document and describes what V3 ships across the Lilith metaverse platform, the Tara Studio yoga-instructor experience, the Saraswati Stage AI-virtual-artist experience, and the Lilith Commons open contemplative spaces. It does not replace the backlog checklist — `V3_TODOS.md` remains the source of truth for completion state — but every feature listed here is grounded in tasks explicitly laid out in `V3_TODOS.md` plus the product behavior those tasks imply. V3 is one coherent product, not three. The product layers as: - **Lilith metaverse** — the platform substrate, built canonically on **Unreal Engine 5.5 LTS**. A single UE5 project drives every premium surface (desktop, VR, console, mobile, and the web via UE Pixel Streaming) and carries V1 Oshun's identity, memory, grounding, safety, generation, and rights policies into embodied multi-user form. A lightweight three.js / WebGPU fallback exists at Tier 2 to make sure no one is locked out at the door. - **Tara Studio** — flagship tenant for live and on-demand yoga, breathwork, meditation, and movement classes. Verified human instructors teach real classes in shared 3D rooms; supervised AI personas teach derivative material under Lilith persona policy. Body-aware feedback comes from Aja (embodied instruction). - **Saraswati Stage** — flagship tenant for AI-generated virtual bands and artists. Persistent personas with grounded backstories, generated music catalogs, scheduled live performances driven by UE Sequencer + MetaSounds + MetaHuman avatars, fan economies (paid concerts, signed editions, remix rights via Aje), and policy-governed generation via Isis. - **Lilith Commons** — open contemplative spaces (gardens, temples, observatories, salons, reading rooms) where any V1 domain experience can be re-rendered in the metaverse — Tara rituals, Nyx sky-watching, Nisaba reading rooms, Veritas debate halls, Metis classrooms, Arete weekly reviews. V3's promise is **embodiment without compromise on V1 trust guarantees**: the contemplative tone, persona safety, crisis-aware behavior, provenance, and consent posture that Lilith enforced as a V1 policy substrate continue to govern every action a user, instructor, or AI persona can take inside the 3D space. UE5's high-fidelity envelope (Lumen GI, Nanite geometry, MetaHumans, Niagara VFX, MetaSounds, Sequencer-driven concerts, Chaos physics) is the canonical experience; the fallback path runs the same multiplayer protocol and content catalog at reduced visual fidelity. ## Subsystem Glossary This glossary fixes vocabulary used throughout the V3 docs. Each entry names a subsystem and the responsibility it owns in V3. Implementation packages live under `apps/v3/`, `libs/v3/`, and shared `libs/oshun/` extensions. **Platform substrates (V3 metaverse)** | Name | Responsibility | | -------------------------- | ------------------------------------------------------------------------------------------- | | **Lilith-World** | Authoritative world server (Rust): rooms, presence, multiplayer state, physics authority. | | **Lilith-Gateway** | Realtime gateway: WebTransport / WebRTC / WebSocket transport; voice SFU. | | **Lilith-PxStream** | UE Pixel Streaming relay fleet, session matchmaker, WebRTC signaller. | | **Lilith-UE** | The canonical UE5.5 LTS client project at `V3/ue/` — desktop, VR, console, mobile. | | **Lilith-WebFB** | Tier-2 lightweight web fallback (three.js + WebGPU) for constrained devices / regions. | | **Lilith-Avatar** | Avatar pipeline: VRM 1.0 source for community, MetaHumans for premium personas. | | **Lilith-Audio** | Spatial audio: MetaSounds + Resonance / Steam Audio (UE), Web Audio + WASM HRTF (fallback). | | **Lilith-Identity-Bridge** | Bridge from V1 Oshun account to embodied identity: avatar binding, presence, reputation. | | **Lilith-Safety** | Tone, persona, crisis, harassment, minor-protection, costume rules, in-world moderation. | | **Lilith-Rights** | Provenance, watermarking, takedown cascade, voice-clone consent for in-world content. | | **Lilith-Commerce** | Tickets, tips, virtual goods, royalty distribution, signed editions (via Aje). | | **Lilith-Studio** | Creator authoring shell (sub-route of the V1 web Studio) + UE Editor authoring tools. | | **Lilith-Operator** | Operator console (sub-route of the V1 admin web). | **Tenant experiences (flagship)** | Name | Responsibility | | ------------------- | -------------------------------------------------------------------------- | | **Tara Studio** | Yoga / breathwork / meditation / movement classes; instructor marketplace. | | **Saraswati Stage** | AI virtual bands and artists; generated catalogs, concerts, fan economy. | | **Lilith Commons** | Open contemplative spaces re-rendering V1 domain experiences in 3D. | **Cross-domain support (carried from V1, deepened in V3)** | Name | Role in V3 | | ---------- | -------------------------------------------------------------------------------------------- | | **Aja** | Embodied-instruction services: pose estimation, alignment cues, asana coaching. | | **Iris** | Memory and identity boundaries: extended to embodied sessions, scene memory, IK pose recall. | | **Isis** | Governed generation control: music, voice, video, motion, world-asset workflows. | | **Sophia** | Grounded answers inside scenes (instructor bios, lineage citations, ethnomusicology refs). | | **Yemaya** | Rendering substrate for non-real-time media (recap reels, signed-edition video). | | **Aje** | Crypto-payment substrate for tickets, tips, royalties, signed-edition NFTs. | | **Psyche** | Real-time text/voice/avatar runtime extended to spatial-audio and lip-sync-in-3D. | | **Themis** | Adjudication for content disputes (sampled riff claims, instructor credential challenges). | **Surfaces** | Surface | Package / Path | | --------------------------------- | ---------------------------------------------------------------------------- | | **Lilith UE5 client (canonical)** | `V3/ue/` — single UE5.5 LTS project, all premium surfaces | | Web entry via UE Pixel Streaming | UE5 server-rendered frames over WebRTC; thin player at `apps/v3/lilith-web/` | | Tier-2 lightweight web fallback | `apps/v3/lilith-web-fallback/` (three.js + WebGPU) | | Lilith World Server | `apps/v3/lilith-world-server/` (Rust + axum + QUIC) | | Lilith Realtime Gateway | `apps/v3/lilith-realtime-gateway/` (WebTransport / WebRTC + voice SFU) | | Pixel Streaming relay fleet | `apps/v3/lilith-pxstream-relay/` (Rust) + UE Signalling server per POP | | Lilith Studio (creator tools) | `apps/oshun/web/src/app/lilith-studio/` + UE Editor authoring widgets | | Tara Studio (tenant plugin) | `V3/ue/Plugins/V3Tenant_TaraStudio/` + `libs/v3/tara-studio/` (TS glue) | | Saraswati Stage (tenant plugin) | `V3/ue/Plugins/V3Tenant_SaraswatiStage/` + `libs/v3/saraswati-stage/` | | Lilith Commons (tenant plugin) | `V3/ue/Plugins/V3Tenant_LilithCommons/` + `libs/v3/lilith-commons/` | | Tara Instructor Marketplace | `apps/oshun/web/src/app/tara/marketplace/` (V1 web subroute) | | Saraswati Artist Roster Admin | `apps/oshun/admin/src/app/saraswati/` (V1 admin subroute) | | Concert Ticketing & Royalties | `apps/v3/lilith-commerce-service/` (Rust + Aje) | ## Cross-Reference Convention Throughout the V3 docs, **bare `§N` and `§N.M` references resolve to `V3_TODOS.md`** (the only V3 doc with numbered section ids used as hyperlinks). Explicit doc prefixes are used where ambiguity matters: - `§40` → `V3_TODOS.md` §40 (e.g., Tara Studio live-class flow). - `deps§14` → `V3_DEPENDENCIES.md` §14 (e.g., generative-music providers). - `arch§""` → `V3_ARCHITECTURE.md` by section anchor. - `features§""` → this document, by section anchor. - `v1todos§N` → `V1/TODOS.md` §N (where V3 reuses V1 substrate work). - `v1features§""` → `V1/features.md` by section anchor. V3 deliberately reuses V1 architecture (BFF, contracts, persistence, identity, audit, residency, isis-generation-control, etc.) rather than duplicating it. Cross-references make the reuse explicit. ## Table of Contents - [V3 Product Promise](#v3-product-promise) - [Product Surfaces](#product-surfaces) - [Lilith Metaverse Platform](#lilith-metaverse-platform) - [World Model and Scenes](#world-model-and-scenes) - [Rooms, Sharding, Capacity](#rooms-sharding-capacity) - [Presence and Embodiment](#presence-and-embodiment) - [Avatar Nameplate LOD](#avatar-nameplate-lod) - [Avatar Pipeline](#avatar-pipeline) - [Spatial Audio](#spatial-audio) - [Real-Time Multiplayer](#real-time-multiplayer) - [Physics and Interaction](#physics-and-interaction) - [Cross-Platform Clients](#cross-platform-clients) - [Tier-2 Fidelity Envelope (Known Gaps from Canonical)](#tier-2-fidelity-envelope-known-gaps-from-canonical) - [Stadium-Tier Seating Plan](#stadium-tier-seating-plan) - [Accessibility in 3D](#accessibility-in-3d) - [Identity and Account Bridge](#identity-and-account-bridge) - [Embodied Safety and Persona Policy](#embodied-safety-and-persona-policy) - [Provenance for In-World Content](#provenance-for-in-world-content) - [Commerce, Tickets, and Royalties](#commerce-tickets-and-royalties) - [Tara Studio — Yoga Instructor Tenant](#tara-studio--yoga-instructor-tenant) - [Instructor Onboarding and Verification](#instructor-onboarding-and-verification) - [Live Class Sessions](#live-class-sessions) - [On-Demand Class Library](#on-demand-class-library) - [Aja Body-Aware Coaching](#aja-body-aware-coaching) - [Practice Plans and Continuity](#practice-plans-and-continuity) - [Sequence Authoring (Asana Editor)](#sequence-authoring-asana-editor) - [Tradition, Lineage, and Citation](#tradition-lineage-and-citation) - [Supervised AI Instructor Personas](#supervised-ai-instructor-personas) - [Cohorts, Privates, and Donation Classes](#cohorts-privates-and-donation-classes) - [Trauma-Informed Tone Policy](#trauma-informed-tone-policy) - [Compensation, Tips, and Studio Splits](#compensation-tips-and-studio-splits) - [Verification, Credentials, and Insurance](#verification-credentials-and-insurance) - [Saraswati Stage — AI Virtual Artists Tenant](#saraswati-stage--ai-virtual-artists-tenant) - [Persistent Artist Personas](#persistent-artist-personas) - [Discography and Generation Pipeline](#discography-and-generation-pipeline) - [Live Performance Engine](#live-performance-engine) - [Scheduled Concerts and Drops](#scheduled-concerts-and-drops) - [Fan Economy](#fan-economy) - [Collaborations, Remix, and Sampling Rights](#collaborations-remix-and-sampling-rights) - [Voice Cloning Boundaries](#voice-cloning-boundaries) - [Genre Cells and Style Boundaries](#genre-cells-and-style-boundaries) - [Backstory Grounding via Sophia](#backstory-grounding-via-sophia) - [Music-Rights Compliance](#music-rights-compliance) - [Crossover with Tara and Lilith Commons](#crossover-with-tara-and-lilith-commons) - [Lilith Commons — Open Contemplative Spaces](#lilith-commons--open-contemplative-spaces) - [Persistent Venues](#persistent-venues) - [Re-rendered V1 Experiences](#re-rendered-v1-experiences) - [Tara Ritual Rooms](#tara-ritual-rooms) - [Nyx Observatory](#nyx-observatory) - [Nisaba Reading Rooms](#nisaba-reading-rooms) - [Veritas Debate Hall](#veritas-debate-hall) - [Metis Classrooms and Lecture Halls](#metis-classrooms-and-lecture-halls) - [Arete Weekly-Review Atrium](#arete-weekly-review-atrium) - [Solitary Spaces and Quiet Cells](#solitary-spaces-and-quiet-cells) - [Creator Suite — Lilith Studio](#creator-suite--lilith-studio) - [Scene and Room Authoring](#scene-and-room-authoring) - [Avatar and Costume Authoring](#avatar-and-costume-authoring) - [Motion Capture and Pose Libraries](#motion-capture-and-pose-libraries) - [Music Authoring (Saraswati pipeline)](#music-authoring-saraswati-pipeline) - [Sequence Authoring (Tara pipeline)](#sequence-authoring-tara-pipeline) - [Asset Library and Taxonomy](#asset-library-and-taxonomy) - [Localization and Subtitles in 3D](#localization-and-subtitles-in-3d) - [Provenance Inspector](#provenance-inspector) - [Live-Service and Programming](#live-service-and-programming) - [Weekly Programming Calendar](#weekly-programming-calendar) - [Seasonal Festivals](#seasonal-festivals) - [Featured Instructors and Drop-Day Concerts](#featured-instructors-and-drop-day-concerts) - [Community Cohorts](#community-cohorts) - [Governance, Safety, and Trust](#governance-safety-and-trust) - [Minor-Protection Mode](#minor-protection-mode) - [Harassment and Abuse Response](#harassment-and-abuse-response) - [Persona-Policy Enforcement at the Body](#persona-policy-enforcement-at-the-body) - [Crisis Routing](#crisis-routing) - [Reporting, Review, and Appeals](#reporting-review-and-appeals) - [Operator Tools (Lilith Operator Console)](#operator-tools-lilith-operator-console) - [Commerce and Rights](#commerce-and-rights) - [Tickets, Tips, and Subscriptions](#tickets-tips-and-subscriptions) - [Cancellation, Refund, and No-Show Policy](#cancellation-refund-and-no-show-policy) - [Royalty Distribution](#royalty-distribution) - [Signed-Edition Drops](#signed-edition-drops) - [Fan-Token Boundaries](#fan-token-boundaries) - [Takedown Cascade Across Performances and Reshares](#takedown-cascade-across-performances-and-reshares) - [Accessibility](#accessibility) - [Localization](#localization) - [Telemetry, Analytics, and Eval Sets](#telemetry-analytics-and-eval-sets) - [Performance Budgets](#performance-budgets) - [Asset Budget and Streaming](#asset-budget-and-streaming) - [Client Build-Size Budgets](#client-build-size-budgets) - [Cross-Platform and Cross-Progression](#cross-platform-and-cross-progression) - [Recording-Consent Flow](#recording-consent-flow) - [Class recording (Tara live classes, Commons cohort sessions, lectures)](#class-recording-tara-live-classes-commons-cohort-sessions-lectures) - [Concert recording (Saraswati class- / hall- / Stadium-tier concerts)](#concert-recording-saraswati-class---hall---stadium-tier-concerts) - [Common to both models](#common-to-both-models) - [Region Rollout Strategy](#region-rollout-strategy) - [Pixel Streaming Abuse Posture](#pixel-streaming-abuse-posture) - [Operator Staffing Model](#operator-staffing-model) - [Minimum Viable Launch (GA day-one baseline)](#minimum-viable-launch-ga-day-one-baseline) - [Scale-Up Ramp](#scale-up-ramp) - [Scale-Out Target (post-launch steady state at ~100 k DAU)](#scale-out-target-post-launch-steady-state-at-100-k-dau) - [Launch Readiness](#launch-readiness) - [V3 Exit Criteria](#v3-exit-criteria) ## V3 Product Promise V3 ships as one coherent embodied surface for Oshun. The product promise: - **Embodied contemplative practice.** A user can walk into a Tara Studio class in the metaverse, take a verified instructor's 60-minute Hatha sequence, get alignment cues from Aja in real time, and leave the room with practice continuity logged in their V1 Arete record. - **AI artists as legitimate cultural participants.** A Saraswati Stage artist has a grounded backstory, a generated catalog tagged with full provenance, a scheduled concert calendar, fan-economy primitives that route royalties to the human creators who trained the persona, and policy boundaries that prevent voice abuse, deepfake impersonation, and copyright laundering. - **V1 trust at body resolution.** Every Lilith metaverse interaction inherits V1's identity, memory, consent, residency, grounding, persona-policy, and provenance posture. There is no second-class trust tier inside the 3D space. - **Live-service from day one.** All advertised tenants ship complete at GA: ≥ 12 verified human Tara instructors live, ≥ 6 Saraswati artists with full debut catalogs and scheduled tour dates, and ≥ 8 Lilith Commons venues open with re-rendered V1 experiences. - **Cross-platform, low-friction entry.** A user joins from a browser tab with no install — UE5 renders server-side via Pixel Streaming and delivers a first frame in ≤ 8 s. Native UE5 binaries (desktop, mobile, VR, console) deliver the same client at lowest latency and highest fidelity. A three.js Tier-2 fallback rounds out the cases where Pixel Streaming isn't available, so no one is locked out. - **Safety at the body.** Persona-policy and tone policy from V1 Lilith apply to every avatar action: spatial harassment, voice abuse, costume violations, crisis-language, minor-protection violations, and persona-impersonation violations all route through the same review pipeline that V1 already operates. - **Degrades safely.** If real-time multiplayer fails, classes fall back to on-demand video with the same lesson plan; if generative-music providers fail, Saraswati concerts replay archived performances rather than going silent; if the user's device can't run UE Pixel Streaming, the tier router routes them to the three.js fallback; if the fallback can't run WebGPU, it drops to WebGL2 with reduced fidelity but no loss of class- and hall-tier room functionality. (See `V1/features.md` § "V1 Product Promise" for the V1 commitments that V3 inherits and extends.) ## Product Surfaces The Subsystem Glossary "Surfaces" table maps each surface to its package and repository path; this section describes what each surface is and does from a product perspective. **Lilith UE5 client (`V3/ue/`)** is the canonical V3 client. One UE5.5 LTS project produces every premium surface: native binaries for Windows, macOS, Linux, iOS, iPadOS, Android, Quest 3, Vision Pro, PSVR 2, and SteamVR; a headless server-rendered cook for the Pixel Streaming worker fleet; and a companion build of the UE Editor that authoring teams use through Lilith Studio. Tenants ship as Game Feature Plugins (`V3Tenant_TaraStudio`, `V3Tenant_SaraswatiStage`, `V3Tenant_LilithCommons`) so per-region, per-platform, and per-mode loading is granular. The engine envelope is Lumen GI, Nanite geometry, MetaHuman + VRM avatars, Niagara VFX, MetaSounds + Resonance / Steam Audio spatialization, Sequencer-driven concerts, and Chaos physics. **Lilith Web via UE Pixel Streaming (`apps/v3/lilith-web/`)** is a thin browser shell hosting a WebRTC player. The canonical UE5 client runs server-side as a worker process; frames stream to the browser as H.264 (broad compat) or AV1 (modern Chrome / Edge); input is forwarded over the WebRTC data channel. From the user's perspective: no install, full UE5 fidelity, one click from `oshun.com/lilith`. Backend cost is one UE worker process per concurrent browser session, auto-scaled by the Pixel Streaming relay fleet. **Lilith Tier-2 fallback (`apps/v3/lilith-web-fallback/`)** is the no-one-locked-out path for users on hardware too constrained for Pixel Streaming, on bandwidth below the threshold, in Pixel-Streaming-restricted regions, or who explicitly select "Lite mode". It is WebGPU-first with a WebGL2 secondary fallback, and loads in < 8 s on a mid-range desktop to a Lilith Commons atrium. It uses three.js + Rapier (physics) + the in-house `@oshun/lilith-engine-web-fallback` wrapper for asset streaming, presence, and scene graph. It speaks the same multiplayer wire protocol as Tier 1, uses the same VRM avatars, and talks to the same V1 BFF — rendered locally at reduced fidelity (no Lumen, no Nanite, lower-poly avatars, Aja cues delivered as HUD text + 2D pose-guide overlay rather than world-space-anchored UMG widgets). It hosts Tara Studio, Saraswati class- and hall-tier concerts, and Lilith Commons with the documented fidelity gaps in `features§"Tier-2 Fidelity Envelope (Known Gaps from Canonical)"`. Stadium-tier concerts on the fallback path surface a degraded preview — audio-only, or a pre-rendered LL-HLS video proxy from Yemaya delivered via the crowd band. **Lilith Mobile** is the UE5 mobile build of `V3/ue/` packaged for iOS / iPadOS / Android via UE Mobile. Renders at 60 Hz on iPhone 15 Pro / Pixel 8 Pro class hardware; degrades to 30 Hz on lower-end devices. A companion React Native shell inside `apps/oshun/mobile` provides V1 continuity surfaces (Arete log, class booking, ticket inventory) that wrap and deep-link into the UE5 client. Deep-link scheme registration (gap-closed at GA): the companion app registers `oshun://v3/...` (custom-scheme) and universal-link / app-link handlers on `https://app.oshun.com/v3/*`. Apple Universal Links and Google App Links route the user into the UE5 native client when installed; otherwise the link opens the V1 web V3 surfaces or the Tier-2 fallback. Scheme + URL templates per route are cataloged in `V3/docs/deep-links.md`; share entries from Telegram / WhatsApp / push / email use the canonical https form so they survive across platforms. **Lilith VR/AR** is the UE5 build configured for OpenXR. Targets Quest 3, Vision Pro (native visionOS path), PSVR 2 (via PS5), and Valve Index / Vive Focus 3 via SteamVR. Hand tracking and full-body inverse kinematics for yoga practice; Sequencer-driven concert cinematography; foveated rendering where supported. **Lilith World Server (`apps/v3/lilith-world-server/`)** is the authoritative backend. Rust + axum + WebTransport (QUIC) + UDP. Engine-agnostic on the wire: speaks the same Protobuf to UE clients and to the Tier-2 fallback. Owns room state, presence, physics authority, music sync, ticket gates. Scales by sharding rooms across a fleet behind the Lilith Realtime Gateway. **Lilith Pixel Streaming relay (`apps/v3/lilith-pxstream-relay/`)** is the matchmaker + signaller fleet for browser sessions. Rust matchmaker chooses a POP by geo, load, and programming priority; Epic's UE Pixel Streaming Signalling Server (Node.js) deployed per POP handles SDP exchange; UE worker processes are pooled and pre-warmed for scheduled concerts. **Lilith Studio (creator tools)** lives at `apps/oshun/web/src/app/lilith-studio/` inside the V1 customer web app — V3 deliberately reuses V1's Studio authoring shell — plus a set of UE Editor authoring widgets installed alongside the UE5 project for asset-side work (asana editor, setlist editor, venue inspector, persona dossier editor). **Lilith Operator Console** lives at `apps/oshun/admin/src/app/lilith/` extending V1's Admin Web. Operator surfaces: room moderation, instructor verification, persona-policy audits, generation queue inspector, concert calendar approval, Pixel Streaming capacity dashboard, takedown executor. ## Lilith Metaverse Platform ### World Model and Scenes Lilith worlds are persistent named spaces with a hierarchical layout: - **Realm** — top-level theme (Tara, Saraswati, Commons). Owned by a tenant. - **District** — region within a realm (e.g., "Hatha Quarter" in Tara realm, "Indie Stage" in Saraswati realm, "Observatory" in Commons realm). - **Venue** — a named addressable space (e.g., "Aja's Loft Studio", "The Mirrored Auditorium", "Nyx Roof"). - **Room** — a session-scoped instance of a venue. Holds active participants, active props, active music streams, transient state. - **Cell** — sub-room space for break-out (small-group yoga circles, after-concert green rooms, classroom break-outs). Scenes are authored in Lilith Studio, signed by Isis with a provenance bundle, and promoted through V1's environment-promotion gates (dev → preview → prod). ### Rooms, Sharding, Capacity Capacity tiers (per single room instance): - **Intimate** — ≤ 12 (yoga privates, songwriter rounds). - **Class** — ≤ 64 (group yoga, salon talks). - **Hall** — ≤ 256 (lectures, debate hall, mid-tier concerts). - **Stadium** — ≤ 4 096 (festival concerts, large Lilith Commons observatory events such as eclipse and meteor-shower watches). Stadium tier uses interest-management + spatial culling to keep bandwidth bounded; presence beyond 256 renders as a crowd shader with authoritative latency only on the front 256 attendees. Sharding: rooms above class tier are sharded by `(venue_id, instance_id)` across world-server nodes. The Realtime Gateway routes clients to the shard holding their instance; cross-shard chat and presence propagate via the V1 event bus. ### Presence and Embodiment Every connected user has: - **Avatar transform** — position, rotation, velocity, IK targets. - **Expression state** — face blend-shape weights, lipsync phonemes. - **Voice channel** — opt-in spatial voice (HRTF-mixed) or out-of-band party chat. - **Activity state** — `present | practicing | watching | speaking | away | do-not-disturb`. Surfaced to other users via a small avatar status ring. - **Visibility band** — `public | tenant | cohort | invited | invisible`. Operators are always visible to operator peers; users in `invisible` mode are still visible to operators inspecting their session. Presence updates flow over WebTransport at ≤ 20 Hz for transforms, ≤ 60 Hz for lipsync/expression (interpolated), and event-driven for activity-state changes. ### Avatar Nameplate LOD Nameplates render above every visible avatar. In a 256-attendee class or a 4 096-attendee concert, naively drawing every nameplate produces an unreadable wall of text and wastes draw calls. The LOD ladder: | Distance / context | Nameplate rendering | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | ≤ 5 m, looking-at, eye-contact-class | Full nameplate: display name, badge (Tara / verified / AI persona / operator), reputation band, activity-state ring. | | 5–15 m | Display name + badge only; no reputation band; no activity ring. | | 15–40 m | Badge icon only. | | > 40 m, or > 32 nameplates in view | Hidden by default; restored on hover / focus. | | Stadium-tier crowd band (LL-HLS spectators) | Aggregate counts ("+1 200 in section"); individual nameplates suppressed. | | Solitary cells | Always hidden. | | Reduced-cognitive-load mode | Nameplates hidden unless user explicitly enables. | Operators have a "show all nameplates" override that ignores LOD and renders every nameplate (used during moderation actions). ### Avatar Pipeline V3 ships a single canonical avatar format: **VRM 1.0 with glTF 2.0 extensions**, overlaid with Oshun-specific extension keys for tradition costuming, ritual implements, and concert-only props. The pipeline: 1. **Source.** Users select from the canonical Oshun avatar gallery (32 base avatars at GA, covering body-shape diversity, age range, and cultural tradition presentation) or import a Ready-Player-Me VRM avatar. 2. **Rig.** Auto-rigged to the Oshun skeleton (60 bones, including finger, facial blendshape, and IK targets for shoulder, elbow, knee, ankle). 3. **Costume.** Tara-tradition costumes (yoga practice attire, ritual robes), Saraswati-tradition costumes (stage outfits with stage-only effects), Commons costumes (everyday). Costuming uses material slots, not mesh swaps, so the avatar can be re-costumed without re-loading the mesh. 4. **Expression.** Blendshape set: viseme (15 phonemes), emotion (8 affects), gaze (3 axes), brow (2 axes). Used by Psyche for lip-sync in 3D. 5. **Identity binding.** Avatar is bound to the user's V1 Oshun account via Lilith-Identity; avatar-swap requires a 24 h cooldown (anti-harassment). 6. **Provenance.** Every imported avatar carries a provenance bundle from Isis. Generated avatars (text-to-avatar) are tagged with model card and prompt hash; imported avatars carry the importer's user ID. ### Spatial Audio Lilith-Audio is HRTF-based binaural rendering with optional ambisonic fall-back for low-end devices. Sources: - **Voice** — every avatar carries a voice source. Spatialized by HRTF for near-field (≤ 10 m), attenuated by distance, occluded by room geometry. - **Music streams** — class soundtrack (Tara), concert PA (Saraswati), ambient (Commons). Music uses 2-channel stereo bed + 6-channel directional layer for stadium-tier concerts. Latency to listener target ≤ 80 ms. - **Effects** — UI taps, ritual bells, asana count chimes, applause beds. - **Mix buses** — voice, music, effects, ambience, accessibility (descriptive audio). Per-user mix controls in the HUD. Voice chat opt-in default: tenant-scoped on. Saraswati Stage stadium tier disables crowd voice by default and uses an applause-bed proxy to keep mix intelligible. ### Real-Time Multiplayer Lilith multiplayer is **client-server with server-authoritative state**. Rollback is not required — V3 is a contemplative/performance space, not a twitch-combat game. The tick budget: - **20 Hz** — transform updates per avatar. - **60 Hz** — lipsync / expression interpolated client-side. - **10 Hz** — physics interaction (asana props, stage props, particle systems). - **1 Hz** — presence / activity-state digest. Targets: ≤ 80 ms RTT (regional), ≤ 200 ms RTT (cross-region). Interest management caps per-client bandwidth at 256 kbps under stadium-tier load. ### Physics and Interaction Rapier (Rust) on the server is authoritative; client uses Rapier-WASM for prediction. Interaction primitives: - **Pickup / place** for props (yoga mats, blocks, straps, ritual bells, scrolls, instruments). - **Sit / lie / kneel / stand** posture states with IK auto-align. - **Hand-gesture** registry (namaste, mudra set, applause, snap) bound to avatar pose presets. - **Asana lock** — instructor can lock an asana pose on a student's avatar (with consent) for demonstration; lock is reversible by either side. ### Cross-Platform Clients V3 ships a **tiered client stack** with UE5.5 LTS as the canonical engine and a three.js fallback for users who can't reach Tier 1: **Tier 1 — Canonical UE5 client (`V3/ue/`)** | Platform | UE5 build target | Min device | Fidelity | | ------------------------------ | ------------------------------------ | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Windows desktop | Win64 | RTX 3060 / Ryzen 5 5600 / 16 GB RAM | Native UE5 (Lumen + Nanite) | | macOS desktop | Mac (Apple Silicon) | M1 / 16 GB RAM | Native UE5 | | Linux desktop | Linux (x86_64) | RTX 3060 / 16 GB RAM | Native UE5 | | **Steam Deck (LCD / OLED)** | Linux (x86_64) + Proton verification | Steam Deck (OLED preferred) | Mobile-preset UE5 at 720p / 40 fps; treated as a constrained-Linux target — no Lumen, Nanite off, reduced Niagara budget | | iOS / iPadOS | UE Mobile (iOS) | iPhone 14 / iPad Air M1 | Mobile UE5 (Forward+ shading) | | Android | UE Mobile (Vulkan) | Pixel 7 / Galaxy S22 | Mobile UE5 (Forward+ shading) | | Meta Quest 3 / Quest Pro | UE Android (Quest Vulkan) | Quest 3 (Quest 2 reduced post-GA) | Native VR (foveated rendering) | | Apple Vision Pro | UE visionOS | visionOS 2.x | Native AR/VR | | PSVR 2 (via PS5) | UE PS5 | PSVR 2 with PS5 | Native VR | | Steam VR (Index, Vive Focus 3) | Win64 + OpenXR plugin | RTX 3060 + headset | Native VR | | **Web via UE Pixel Streaming** | Win-Server (worker) | server-rendered; client = WebRTC browser | Streamed UE5 (1080p H.264 or 1440p AV1) | **Tier 2 — Lightweight web fallback (`apps/v3/lilith-web-fallback/`)** | Browser | Engine | Min device | Fidelity | | ------------------------------- | ----------------- | --------------------------------------------- | ------------------------------------------ | | Chrome / Edge / Safari (WebGPU) | three.js + WebGPU | M1 Mac / Ryzen 5 5600 / iPhone 15 Pro browser | Reduced (no Lumen/Nanite; baked lightmaps) | | Older browsers (WebGL2) | three.js + WebGL2 | Most modern browsers | Reduced + simplified shaders | The tier router (`/api/v3/lilith/launch` on the V1 BFF) decides which tier each user reaches based on installed clients, device capability, bandwidth probe, region capacity, and explicit user preference. See `arch§"Tier Selection and Client Routing"`. ### Tier-2 Fidelity Envelope (Known Gaps from Canonical) The Tier-2 fallback is the no-one-locked-out path, not a feature-parity mirror of Tier 1. Known gaps customers and operators should expect: | Feature | Tier-1 (UE5) | Tier-2 (three.js) | | ------------------------------------ | ------------------------------------------- | --------------------------------------------------------------------------------------- | | Global illumination | Lumen real-time GI | Pre-baked lightmaps; no dynamic GI | | Geometry detail | Nanite virtualized geometry | LOD chains; ≤ 80 K triangles per avatar; ≤ 30 MB venue load budget | | MetaHuman avatars | Full MetaHuman with strand-based Groom hair | VRM proxy with card hair (per `arch§"Dual-Authoring Requirement for Premium Personas"`) | | Material complexity | Substrate, virtual textures, parallax | Simplified PBR; KTX2 textures; no parallax | | Niagara stage VFX | Full Niagara graphs | Reduced particle counts; equivalent shader fall-backs | | Cloth simulation | ChaosCloth on costumes / robes | Skinned cloth approximations; no per-bone cloth solve | | Hair | Groom strands | Card geometry | | Camera cinematics | Sequencer-driven concert cameras | Cue-event-driven fall-back cameras with simplified blending | | Aja AR overlays | World-space UMG widgets anchored to student | HUD-anchored text + 2D pose guide overlay; no world-space anchoring | | In-world camera screenshots / videos | Full UE capture with C2PA | three.js framebuffer capture with C2PA; reduced fidelity output | | Saraswati Stadium-tier interactivity | Front + mezzanine band Pixel Streaming | Crowd-band multicast LL-HLS spectator + chat / emoji channel | Tara live classes, Tara on-demand, Lilith Commons venues, and Saraswati class- and hall-tier concerts run end-to-end on Tier 2 with these fidelity caveats. Stadium-tier concert interactivity is genuinely reduced for Tier-2 attendees — see Stadium-tier seating detail below. ### Stadium-Tier Seating Plan A Saraswati Stadium-tier concert can accommodate up to 4 096 attendees per instance through a **banded seating model** that routes attendees to the render path that matches their ticket and tier: | Band | Capacity | Render path | Ticket gate | | ----------------------------- | -------- | ------------------------------------------------------------------ | ----------------------------------------------- | | **Front 256 (named)** | 256 | Native UE or dedicated Pixel Streaming worker — full interactivity | Front-row tier ticket | | **Mezzanine band (next 768)** | 768 | Pixel Streaming worker, 1080p lower-fidelity preset | Mezzanine tier ticket | | **Crowd band (remainder)** | 3 072 | Yemaya LL-HLS multicast + thin spatial seat + chat / emoji | Crowd tier (free or low-cost) or Tier-2 default | Native UE5 attendees with installed binaries render locally and join the front or mezzanine band per ticket. Tier-2 attendees default to the crowd band. Upgrade-to-mezzanine during a concert is supported via signed-return resale when a mezzanine seat is freed. Capacity beyond 4 096 is handled by spinning up additional concert instances (with shared persona + setlist but separate audiences); cross-instance light-emoji is aggregated at 1 Hz. See `arch§"Stadium-Tier Scaling Strategy"` for the rationale and cost model. ### Accessibility in 3D - **Reduced motion** — capped camera and avatar motion; teleport locomotion instead of smooth-slide. - **Color-vision** — palette swaps for asana cues, UI affordances. - **Captions** — speech-to-text live captions floated above the speaker's avatar, positionally anchored. - **Audio descriptions** — descriptive audio bed describing scene state on request (e.g., "the instructor is now in downward dog, facing left"). - **One-handed mode** — UI compresses to single-thumb reach in mobile. - **Photosensitive safe mode** — stage-light strobing and particle bursts attenuated. - **Spatial-audio off** — flat stereo mix for users with HRTF-induced disorientation. ### Identity and Account Bridge A user's V3 identity is the same V1 Oshun identity. Lilith-Identity provides: - **Avatar binding** — one active avatar per session, swap cooldown 24 h. - **Display name** — defaults to V1 Oshun display name; can be overridden per-realm (anti-stalking) with admin audit. - **Reputation** — derived from instructor ratings (Tara), audience reactions (Saraswati), and operator-visible review counts. Never exposed as a numeric score; surfaces as graded bands (new / known / trusted / flagged). - **Presence privacy** — control over who can see "online in Lilith" status (V1 default + per-realm override). - **DSAR** — V3 session data flows into V1's existing DSAR pipeline; users can request export/deletion of avatar history, transcripts, recordings, and performance attendance. ### Embodied Safety and Persona Policy V1 Lilith policy applies to V3 bodies: - **Tone policy** — instructors and AI personas hold contemplative tone; voice chat that crosses tone-policy thresholds prompts the speaker first, then routes to operator review on repeat. - **Persona safety** — AI personas (Saraswati artists, supervised AI instructors) carry persona-policy locks: scope of topics, opt-outs, no medical / legal / financial advice. - **Crisis-aware behavior** — any participant displaying crisis-language signals triggers an in-world soft-prompt, a hand-off offer to the V1 crisis-routing pipeline, and an operator notification. - **Voice-abuse policy** — yelling, slurs, or persistent interruption escalate to a mute, a room-removal, and an account-level review. - **Costume violations** — operator-defined costume rules per realm (Tara forbids stage-only costumes in classrooms; Saraswati allows broader range but enforces nudity / minor-protection rules). - **Persona impersonation** — avatars that mimic a Saraswati artist persona outside a sanctioned cosplay zone trigger Lilith-Rights review. ### Provenance for In-World Content Every generated artifact created inside Lilith — performances, recorded sequences, signed editions, photographs taken by the in-world camera — carries an Isis provenance bundle: model card, prompt, seed, watermark hash, consent ID, performing identity, room/venue ID, timestamp, geo-residency tag. The bundle is required for any export to off-platform channels; V1's existing provenance-bearing sharing policy applies unchanged. C2PA manifests are written for video exports and audio exports. ### Commerce, Tickets, and Royalties Lilith-Commerce is built on V1 Aje and V1 payment substrate. - **Tickets** — concert and master-class tickets; capped per-fan to prevent scalping; resale via signed return-only flow. - **Tips** — per-instructor, per-artist, per-session tips routed to recipient net of platform split. - **Subscriptions** — Tara studio passes, Saraswati artist club passes, Commons venue memberships. - **Royalty distribution** — Saraswati Stage routes per-stream and per-performance royalties to the human creators whose works contributed to the trained persona (per the contributor compensation policy defined in features§"Music-Rights Compliance"). - **Signed editions** — limited-supply signed-edition drops (concert recordings, master-class recordings, artist art prints) issued through the Aje signed-edition primitive. Aje provides on-chain ownership; transfer triggers resale-royalty distribution back to creators. ## Tara Studio — Yoga Instructor Tenant ### Instructor Onboarding and Verification Tara Studio admits instructors through a staged verification flow. An applicant moves through the lifecycle `applied → credentials-submitted → credentials-verified → audition-scheduled → audition-passed → listed` (or `→ rejected` / `→ remediation` at any gate). The Tara editorial pool of 4 operators runs the flow at a 5-business-day SLA at GA. The gates: - **Credential check** — Yoga Alliance RYT-200 / RYT-500 / E-RYT 200 / E-RYT 500, Ayurveda practitioner certifications, somatic / breathwork credentials. The applicant uploads certificate scans; the verification service runs a Yoga Alliance API lookup where the registry exposes one, and an operator manually confirms the rest. A credential that cannot be verified within 5 business days routes the applicant to `remediation` with a request for a supporting document. - **Lineage attestation** — the instructor names a primary lineage (Krishnamacharya / Iyengar / Ashtanga / Kripalu / Anusara / Sivananda / Yin / Restorative / secular contemplative) plus a named teacher attribution. Sophia stores the attribution as a citation; an unverifiable teacher attribution does not block listing but is surfaced as "self-attested" on the profile. - **Trauma-informed training** — recommended, not required. A completed trauma-informed certificate (e.g., a recognized 20-hour course) earns a trauma-informed badge on the profile and is required to teach any class tagged `prenatal`, `recovery`, or `grief-adjacent`. - **Background check** — required before an instructor can be scheduled for any class that admits minors (see features§"Minor-Protection Mode"). A passed check is recorded in Lilith-Rights; a class scheduled for a minor cohort by an instructor without one is blocked at the scheduling step, not at the room gate. - **Live audition** — one 30-minute audition class taught to a closed room, observed live by a Tara operator. The operator scores tone (contemplative, invitational), cueing clarity, safety (no surprise adjustments, correct contraindication handling), and platform fluency. A failed audition routes to `remediation` with one re-audition allowed after 30 days. - **Liability insurance** — required before listing any live class with capacity above 25 participants; carrier, policy number, and expiry date are stored in Lilith-Rights. An instructor without insurance may still list intimate-tier privates and ≤ 25-seat classes. A listed instructor carries a verified Tara badge on the avatar nameplate (rendered at the ≤ 5 m and 5–15 m nameplate LOD bands). Credentials re-verify annually; see features§"Verification, Credentials, and Insurance" for the expiry and lapse handling. ### Live Class Sessions A live class is a scheduled, instructor-led session in a class-tier room (capacity ≤ 64; see features§"Rooms, Sharding, Capacity"). At schedule time the instructor fixes: start time, capacity tier, public / cohort / private visibility, donation-or-fixed price, lineage tag, recording opt-in, and the authored asana sequence (see features§"Sequence Authoring (Asana Editor)"). Booking runs through the V1 BFF and Lilith-Commerce; the room is spawned by the world server when the class queue reaches its start time. Session lifecycle: 1. **Pre-class lobby** — opens 10 minutes before start. Booked students load the Tara venue preset (e.g., "Aja's Loft Studio"), pass the recording-consent gate if recording is enabled (see features§"Recording-Consent Flow"), and pick a mat position. Late joiners are admitted through the first 10 minutes; after that the room is sealed. 2. **Opening** — the instructor's avatar enters; soundtrack ambient bed begins; the instructor sets the room with an invitational opening per the trauma-informed tone policy. 3. **Practice body** — the instructor moves through the authored sequence. Their voice and avatar stream at 20 Hz transform / 60 Hz expression; the soundtrack plays as a royalty-cleared music stream (deps§14-music); Aja delivers alignment cues to opted-in students (see below). The instructor advances asana markers, which drive the per-student asana target Aja scores against. 4. **Closing and integration** — final rest; the instructor closes; the room stays open ~5 minutes for unstructured presence. 5. **Close** — a Tara practice log (asanas covered, hold-time distribution, duration) writes to each participant's V1 Arete record over the event bus, honoring Tara's `ContinuationState` contract. If recording was enabled, the capture moves to the operator editorial gate before publication. Class controls (instructor HUD): mute a participant, demote a participant to observer, lock an alignment-cue overlay on a consenting student, dim room lights, play a chime, set the asana count, advance / hold the sequence marker, and hand off to the AI assistant for a music transition. Edge cases: if the instructor disconnects, the room enters a 90-second grace hold (ambient bed continues, no new cues) and resumes on reconnect; a disconnect beyond 90 seconds converts the session to a guided on-demand playback of the same authored sequence and triggers a goodwill credit per features§"Cancellation, Refund, and No-Show Policy". If real-time multiplayer degrades mid-class, the class falls back to on-demand video with the same lesson plan rather than dropping students. **Acceptance criteria.** A class spawns, admits its booked roster, runs the full sequence, delivers cues, writes every participant's Arete log, and closes the room with zero orphaned sessions; instructor disconnect never strands students. ### On-Demand Class Library The on-demand library holds two source types: recordings of live classes (consent-gated, operator-reviewed before publication) and instructor-published pre-recorded sequences. Each on-demand class: - Has a scrubbable timeline with asana markers extracted via Aja from the recorded instructor's pose track, so a user can jump to any asana, the closing rest, or a breathwork block. - Supports **"practice with the recording"** — handled by the `V3Mode_TaraOnDemand` plugin. The user joins a shared room containing the recorded instructor avatar; their own live avatar appears alongside it; Aja scores their live pose against the recorded instructor's pose at each marker and delivers the same alignment cues a live class would. Multiple users can practice with the same recording concurrently in separate room instances. - Tracks practice time, asana coverage, and drop-off points (the marker where a user most often abandons the session), and writes a practice log to V1 Arete on close exactly as a live class does. Drop-off and coverage signals feed the recommendation surface and the practice-plan adjustment logic (see features§"Practice Plans and Continuity"). Empty-state: a newly listed instructor with no recordings shows their authored pre-recorded sequences only; a user with no practice history is offered a guided onboarding rather than personalized recommendations. ### Aja Body-Aware Coaching Aja (V1's embodied-instruction substrate) extends to V3 with: - **Pose estimation** — on-device (mobile camera or VR hand-tracking) or in-world (avatar-pose-only mode) estimation of student pose against the active asana target. Camera estimation is opt-in per session and never recorded. - **Alignment cues** — spoken or text cues delivered to the student in real-time: "rotate front knee outward 10°", "lengthen back leg". - **Risk flags** — Aja flags poses with known injury risk (e.g., locked-knee triangle, collapsed lower-back in chaturanga) and offers a modification. - **Modification ladder** — every asana carries a 4-step modification ladder (beginner → standard → deep → advanced). Aja recommends a step based on consented body-history. - **Privacy default** — body-pose estimation data lives on-device unless the user opts to share with their instructor; aggregate metrics (asana coverage, hold-time distribution) flow to Iris with full DSAR coverage. Camera frames are processed entirely on-device (MediaPipe Pose) and never leave the client; only derived joint angles, the asana classification, and aggregate metrics cross the wire. **Acceptance criteria:** Aja's asana classifier reaches the pose-accuracy target on the labeled regression set in §"Aja pose accuracy harness"; cue clarity scores ≥ 80% on the Tier-2 user-test cohort; no raw camera frame is ever transmitted or persisted, verified by the adversarial scan. ### Practice Plans and Continuity A Tara practice plan is an ordered schedule of classes and self-practice slots over days, weeks, or months, tied to a declared goal (e.g., "consistent 30 min/day morning practice", "build to crow pose", "wind-down for sleep"). Plans: - **Generate** from a starter-plan library (goal-keyed templates) or from a guided onboarding that asks the user about available time, experience level, contraindications, and goal. - **Adjust automatically.** After a pattern of missed slots, low Aja coverage on target asanas, or Arete weekly-review responses signaling overload, the plan proposes a lower-difficulty or shorter-duration variant — the user always confirms the change, mirroring V1 Arete's humane plan re-scoping. A pattern of exceeded sessions can propose a progression instead. - **Surface as continuation cards** in the V1 Oshun web / mobile shell, so a user can see "next: 20-min morning Hatha" and resume on any device — desktop, mobile companion, or inside the metaverse. - **Honor Tara's `ContinuationState` contract** from V1 Tara so plan progress is one continuity record shared across V1 and V3, not a parallel V3-only state. Edge cases: a plan whose next scheduled class is canceled by the instructor offers the nearest equivalent class (same lineage, similar difficulty) or a self-practice slot; a user who completes a plan is offered a follow-on plan keyed to the same or an advanced goal. ### Sequence Authoring (Asana Editor) Instructors author sequences entirely in the web Lilith Studio — no UE installation is required (see arch§"Lilith Studio Authoring Split (Web vs. UE Editor)"). The authored sequence persists as an `AsanaSequence` contract; the UE client and the Tier-2 fallback bind its JSON manifest at runtime. The editor: - **Drag-and-drop asanas** from the canonical asana library — 300+ asanas at GA, each carrying a Sanskrit name, lineage variants, a 4-step modification ladder, contraindications, and an Aja alignment-cue bundle. - **Insert blocks** — breathwork blocks, meditation blocks, transitions, and prop prompts ("set up a block under each hand"), each with an authored duration. - **Preview** the sequence on a stand-in avatar with timing simulation, so the instructor sees the run length and pacing before publishing. - **Tag** tradition, pace, difficulty (beginner / standard / deep / advanced), focus area, and contraindications. The contraindication tags gate the class from minor cohorts and surface in the listing. - **Publish** as a live-class template or as an on-demand class, through the V1 environment-promotion gates (preview → editorial → release). A sequence whose total authored duration drifts more than 20% from the instructor's stated class length is flagged in preview. Saving a sequence referencing a retired asana blocks publication until the asana is replaced. ### Tradition, Lineage, and Citation Every published sequence carries a lineage tag and an optional source citation. Sophia grounds the lineage claim: a sequence tagged "in the Iyengar tradition" must trace either to a verified Iyengar-certified instructor (the instructor's own verified credential satisfies this) or to a cited published Iyengar-method source. The grounding check runs at publish time inside the Lilith Studio sequence-authoring flow. A sequence with an unsourced lineage claim is not blocked but is flagged in editorial review and surfaced to students as "tradition self-attested" rather than "tradition verified". A claim Sophia actively contradicts (e.g., a posture attributed to a lineage that demonstrably does not teach it) is blocked until the instructor corrects the tag or supplies a source. This is the same grounding posture V1 Sophia applies to evidence claims, applied to lineage. ### Supervised AI Instructor Personas Tara Studio admits a small number of supervised AI instructor personas. Each persona: - Is sponsored by a verified human instructor who takes editorial ownership. - Carries the human sponsor's lineage attribution. - Teaches only sequences pre-authored and approved by the sponsor; no live improvisation outside the sequence script. - Cannot prescribe medical / therapeutic asana modifications without a sponsor handoff. - Is clearly labeled "AI persona — sponsored by " on the nameplate and the class listing. - Has Lilith persona-policy locks enforced. AI personas exist to extend reach — off-hour classes when no human instructor is teaching, language-localized classes, and beginner-friendly low-stakes classes — not to displace human instructors. The platform cap at GA is 1 AI persona per 4 verified human instructors per region; the cap is enforced at persona-listing time. Persona-policy enforcement is verified by the adversarial prompt suite (see arch§"Persona Policy at the Body"): an AI instructor must zero-breach every in-class out-of-scope prompt — a request for a medical modification gracefully hands off to the sponsor rather than answering. ### Cohorts, Privates, and Donation Classes Three class formats sit alongside the standard public live class: - **Cohorts** — recurring closed-group classes run by the `V3Mode_TaraCohort` plugin (e.g., a 6-week prenatal series). Capacity is capped at 24. A cohort has cohort-only chat, a cohort-only continuation card in the V1 shell, and a fixed roster: enrollment closes when the cohort starts and the same students return each week. A cohort tagged for minors requires the instructor to hold a passed background check, enforced at scheduling. - **Privates** — 1:1 instructor-student sessions in an intimate-tier room (`V3Mode_TaraPrivate`). The instructor sets the price; Lilith-Commerce takes a 10% platform fee at GA. Privates do not require liability insurance and may be listed by any verified instructor. - **Donation classes** — pay-what-you-can. The instructor sets a recommended donation; a participant pays anything from 0 up. The 20% platform fee is waived on any donation class where the participant pays below the recommended donation, so the floor is genuinely accessible; tips on donation classes still route at the 10% rate. ### Trauma-Informed Tone Policy Tara classes adopt trauma-informed defaults, enforced by V1 Lilith persona policy rather than left to instructor discretion: - **No surprise physical adjustments** — neither an in-world avatar adjustment nor an Aja-driven cue may be applied without the student's prior consent. - **Invitational language by default** — "if it feels available, ..." rather than the directive "now do X". The tone classifier scores instructor voice against this default the same way it scores any voice transcript. - **Eyes-open default** — eyes-closed practice happens only on an explicit instructor invitation, never as an assumed default. - **Hands-off default** — in-world avatar contact requires consent before any instructor-student physical metaphor ("I'll demonstrate by holding your wrist"), even in avatar form, and the asana-lock interaction is always reversible by the student. An instructor may opt into a more directive style for advanced classes, but the style must be stated in the class description so students self-select; the description text is part of the listing a student sees before booking. ### Compensation, Tips, and Studio Splits Default platform splits: **20% platform / 80% instructor** for paid classes; **10% platform / 90% instructor** for tips and donations (see §"Cohorts, Privates, and Donation Classes" for the donation-floor fee waiver and the 10% private fee). An instructor may elect to route 0–10% of their own share to a **Tara Lineage Fund** that endows verified teachers in under-funded lineages; the election is per-instructor and adjustable. Splits are encoded as an on-chain royalty waterfall via Aje, settled per the commerce schedule. Instructors withdraw to fiat through the V1 payment substrate — Stripe Connect in supported regions, Aje native withdrawal in crypto-supported regions. Every split, payout, and Lineage Fund contribution is audit-logged into V1 `@oshun/audit-platform` and covered by DSAR. ### Verification, Credentials, and Insurance Instructor verification dossiers — credential scans, lineage attestations, background-check results, audition scores, insurance records — are stored in Lilith-Rights with V1 audit coverage; access is gated to the Lilith-Rights operator scope and every access event is logged. Credentials carry an expiry and re-verify **annually**: 30 days before expiry the instructor is prompted to re-submit; an expired credential moves the instructor to a `credentials-lapsed` state that pauses new class listings (already-booked classes still run) until re-verification clears. An **insurance lapse** triggers an automatic listing pause for classes above 25 participants and an operator notification; intimate-tier privates and ≤ 25-seat classes are unaffected. A revoked credential or a failed re-verification routes to the operator queue for a delisting decision with an appeal path through V1's appeals pipeline. ## Saraswati Stage — AI Virtual Artists Tenant ### Persistent Artist Personas A Saraswati artist is a persistent persona with: - **Backstory** — origin, influences, lineage, geographic anchor, era, lyrical preoccupations. Grounded in Sophia (every claim that intersects real culture has a citation trail; fictional claims are explicitly tagged). - **Voice signature** — a voice-clone bundle from licensed source recordings (consent-based; see features§"Voice Cloning Boundaries"). Voice carries through speech (Q&A in concert green rooms) and singing (in concert). - **Avatar** — Oshun-pipeline avatar with stage-only costuming and signature motion library. - **Genre cell** — a positioning vector in the Saraswati genre map (see features§"Genre Cells and Style Boundaries"). Genre drift requires editorial approval. - **Catalog policy** — what the artist will and won't generate (e.g., "no politically charged lyrics", "no cover material from artists under living estate without license"). - **Operator hand-off rules** — when in-concert interactions cross persona policy, the persona either gracefully no-ops or hands off to a Lilith Operator persona. GA artist roster: 6 personas across 6 genre cells (electronic, indie folk, hip-hop, classical-crossover, ambient, devotional). Each persona has a debut catalog of 12 tracks at GA. ### Discography and Generation Pipeline Catalogs are generated through the Isis-controlled music pipeline (deps§14): 1. **Prompt and reference** — editorial team submits a track prompt (theme, mood, length, tempo) and a reference set (existing licensed tracks that signal style direction). Reference tracks must be cleared for training-time exposure under deps§14-licensing. 2. **Composition pass** — generation provider (Suno / Udio / Stable Audio / open-source pipeline) produces a draft track in the artist's voice and style. 3. **Lyric pass** — large-model lyric generation grounded in the artist's persona; Sophia checks lyric claims for unverifiable factual content; Lilith persona policy checks tone. 4. **Mix and master** — automated mastering pass + human review. 5. **Provenance bundle** — Isis writes the bundle: model card, prompt seed, reference set, generating user (editorial), persona ID, lineage credit distribution (who gets royalty share from this track). 6. **Editorial approval** — at GA, every track is reviewed by a human curator before release. Post-GA, certain artists may auto-release within policy bounds (defined per-artist). 7. **Release** — track is uploaded with full provenance; available via Saraswati Stage in-world and (subject to off-platform license) on external streaming services. ### Live Performance Engine A Saraswati concert is a UE Sequencer asset, not playback of a recording. The performance engine drives a concert through these elements (see arch§"Saraswati Live Performance Pipeline (Sequencer + MetaSounds)"): - **Performance plan** — a setlist of 12–15 songs with per-song stage configuration: avatar motion preset, lighting cues, Niagara particle systems, and audience-camera angles, all authored as Sequencer cue tracks. - **Between-song speech** — speech is **pre-generated and queued, not live-generated**. Editorial writes 3–5 prompt variants per between-song slot (dedicate a song, acknowledge a recurring fan by handle, talk about an inspiration); each routes through Sophia for factuality, the persona-policy classifier for tone, and the persona's TTS voice signature, and is stored as a MetaSound stream in the concert asset. At showtime the concert director (or an AI-director rule) picks the slot variant that fits the live moment; every slot ships a neutral cold-fallback take. Live unscripted Q&A is **not** supported at GA — it happens in a smaller post-show green room (`V3Mode_SaraswatiClub`). - **Audience interaction** — fans throw light-emoji (server-batched into 200 ms windows so the visible band stays smooth across tiers), raise a hand for the persona to acknowledge, request a song from a pre-allowed list, and send tips. - **Special-edition tracks** — concert-only renders, watermarked and capped to the attending audience. - **Recording** — every concert is captured at full fidelity by a dedicated master-capture UE worker running MoviePipeline; the capture carries a full Isis provenance bundle and a C2PA manifest and seeds the post-show signed-edition drop. ### Scheduled Concerts and Drops Each artist runs a tour calendar of weekly performances published on the programming calendar (see features§"Weekly Programming Calendar"). The minimum GA cadences: - **Single drops** — a new single at least every 6 weeks per artist. - **EP drops** — an EP at least every 6 months per artist. - **Concert cadence** — at least 2 scheduled concerts per month per artist; with 6 artists at GA that is ≥ 12 concerts per month. Concert types are hall-tier (≤ 256) and Stadium-tier (≤ 4 096); ticketing runs through Lilith-Commerce. - **Festival events** — quarterly festivals (`V3Mode_SaraswatiFestival`) where multiple Saraswati artists share a Stadium-tier venue and a common audience. A concert is heavy editorial work (≈ 2–3 weeks end-to-end per arch§"Concert Authoring Pipeline"), so the calendar is planned a quarter ahead. A concert that cannot ship on its scheduled date is rescheduled rather than degraded; if a generative-music provider fails close to showtime, the concert replays an archived performance rather than going silent (see features§"V3 Product Promise"). ### Fan Economy The fan economy has four tiers of participation, all built on Lilith-Commerce and Aje: - **Free tier** — a fan follows artists, attends free smaller concerts and crowd-band Stadium seats, browses the catalog, and sends light-emoji. No payment, no purchase. - **Club pass** — a monthly subscription per artist (or a multi-artist pass). Grants club-only concerts (`V3Mode_SaraswatiClub`), pre-release listens, and entry into signed-edition raffles. Billed recurring on Stripe or Aje; cancel any time with access through the current period. - **Signed editions** — limited-supply signed-edition recordings of concerts and singles, minted on-chain through Aje (see features§"Signed-Edition Drops"). Resale is allowed and routes secondary-sale royalties back through the waterfall. - **Tips** — direct per-artist tips during a concert, routed through Lilith-Commerce net of the platform split. Fans may also purchase per-track remix rights where the artist publishes them (see features§"Collaborations, Remix, and Sampling Rights"). Minor accounts (Saraswati Stage is 16+ at GA) cannot purchase signed editions or remix licenses. ### Collaborations, Remix, and Sampling Rights Every Saraswati track is published with one of three remix-rights settings, set per track at generation time and stored on the `Track` contract: - **Open remix** — any fan may sample or remix the track. The resulting work carries a credit to the original artist, and a secondary royalty flows back to the artist's waterfall on any monetized use. - **Licensed remix** — a fan purchases a remix license through Lilith-Commerce. The remix may then be distributed off-platform; the royalty terms (split, territory, duration) are encoded in the license itself. - **No remix** — the track is locked. The remix tooling will still produce a derivative, but it is watermarked personal-use-only and cannot be published or monetized. Remix tooling lives in the Lilith Studio music-authoring surface. A remix inherits the source track's provenance bundle plus its own generation provenance, so the lineage chain stays intact. **Cross-artist collaborations** — two or more Saraswati personas can collaborate on a single track. Each contributing persona's lineage credit is preserved, and the royalty split across the collaborating personas is encoded at track-generation time, not negotiated after release. **Disputes** route to Themis: a fan claiming their remix predates the artist's track release, an ownership challenge over a sampled riff, or a contested collaboration split. A confirmed dispute can trigger a track unrelease and a royalty correction; Themis adjudication carries V1 audit coverage. ### Voice Cloning Boundaries V3's voice-clone policy is strict. Voice signatures exist in two production contexts: Saraswati persona voices (for sung + spoken material) and Tara instructor TTS voices (for Aja alignment cues + recorded class voice-overs in localized dubs). Both run the same consent + contract + compensation framework. **Saraswati persona voice signatures** - **Sourcing.** Every persona voice is built from licensed source recordings contributed by **3–5 named human voice artists** under signed contributor agreements stored in Lilith-Rights with the V1 audit-platform trail. No web-scraped voice corpora; no scraped public-figure samples; no "in the style of [living artist]" prompts at build time. - **Recording sessions.** Each contributor records ≥ 4 hours of clean source material in a Saraswati-operated session (in-studio or remote-with-supervision). Sessions cover sung material, spoken cadence, breath / fricative / sibilant variants, and emotional range required by the persona's catalog policy. Recording masters are retained encrypted; raw samples never leave Lilith-Rights. - **Contract.** Each contributor signs a voice-rights agreement specifying: usable scope (Saraswati persona X only), perpetuity vs. reversion terms, mandatory royalty share, public-figure-impersonation prohibitions, withdrawal rights (contributor can withdraw on 90 days' notice; their share of the signature is then sunset and the persona may re-train without it). - **Ownership.** The voice signature derivative work is owned by Oshun / Saraswati. Contributors retain identity / publicity rights and receive royalty share but do not retain copyright on the derivative signature. - **Compensation.** Contributors receive a per-track + per-stream + per-performance royalty share encoded in the Aje royalty waterfall for every track that uses the signature. GA default split: 12% total to the contributor pool, divided pro-rata across the 3–5 contributors by training-data-contribution share. Editorial may negotiate contributor-specific overrides, audit-logged. - **Anti-impersonation gate.** Before a signature can be built, the proposed contributor mix is run through Lilith-Rights' voice-similarity check against a maintained public-figure voice corpus. Any flagged match blocks the build until editorial review clears it. - **Public figures and politicians.** Voice signatures of identifiable public figures, politicians, or celebrities are prohibited even by reference. Fan uploads of their own voice for signature contribution are not accepted at GA (post-GA: contributor pipeline may admit fan voice contributions under the same contract framework). **Tara instructor TTS voice signatures** - **Scope.** Each verified Tara instructor may opt into a TTS voice clone for two purposes: Aja alignment cues delivered in their own tone during their classes, and recorded narration dubs of their on-demand classes into localized languages. - **Consent capture.** Opt-in is explicit per purpose (Aja cues and localized dubs are separate consents); recorded in Lilith-Rights with audit; can be withdrawn at any time with 30 days' notice. - **Recording sessions.** Each instructor records ≥ 1 hour of clean source material covering Sanskrit asana names, English cue cadence, and emotional / pace range. Saraswati-quality 4-hour sessions are optional for instructors who want studio-grade voice replication. - **Contract.** Per-instructor voice-rights agreement specifying: usable scope (Aja cues during their classes + their localized dubs only — never cross-instructor; never Saraswati personas), royalty share, withdrawal rights, anti-impersonation gates. - **Compensation.** Instructors receive a royalty share on Aja-cue usage during recorded on-demand classes (live classes are excluded — TTS cues during live classes are part of the live-class purchase) and on each localized dub stream. GA default: 5% additional share routed to the instructor pool on top of the standard instructor split. - **Strict scope locks.** An instructor's voice signature cannot be applied to another instructor's content, a Saraswati persona, an arbitrary user-supplied prompt, or any non-Tara-Studio surface. Cross-purpose use triggers an automatic withdrawal of all signatures and an operator alert. **Universal constraints** - Cloning of public figures (musicians, politicians, celebrities) is prohibited — even by reference or "in the style of". - Voice signatures cannot be used to impersonate any real person not party to the contract; Lilith-Rights enforces a voice-similarity check against a public-figure registry on every build. - Fans cannot upload their voice for cloning at GA. - Voice signature data is stored encrypted at rest; access is gated by the Lilith-Rights operator scope; access events are audit-logged. - DSAR for contributors covers their voice-rights agreement, royalty ledger, and (on request) destruction of the trained signature weights derived from their contributions. ### Genre Cells and Style Boundaries A genre cell is an operator-curated positioning vector in the Saraswati genre map; each GA artist is anchored to exactly one. The cell constrains what the generation pipeline will produce for that artist — a reference set or prompt that pulls the draft track outside the cell is rejected at the composition pass. An artist cannot drift across cell boundaries without editorial review and a recorded dossier change. The six GA cells: 1. **Electronic** — synth, IDM, downtempo, club. 2. **Indie folk** — singer-songwriter, indie pop, alt-country. 3. **Hip-hop** — boom-bap, drill, jazz-rap, regional cells. 4. **Classical-crossover** — orchestral, choral, neo-classical. 5. **Ambient** — drone, soundscape, generative ambient. 6. **Devotional** — kirtan, gospel, mantra, sacred chant. The cell also feeds the genre-positioning embedding used by the discovery surface to recommend artists. Cells expand post-GA as audience demand and editorial capacity allow; a new cell is an operator action with its own curation, not a free-form artist choice. ### Backstory Grounding via Sophia A Saraswati persona has a backstory dossier — origin, influences, lineage, geographic anchor, era, lyrical preoccupations. Every claim in it that intersects real culture (e.g., "I grew up listening to Fela Kuti in Lagos") routes through Sophia and carries a citation trail; the `@oshun/sophia-saraswati-grounding` adapter runs this check. Claims Sophia cannot ground are not published as fact. Fictional details are tagged explicitly fictional in the dossier. The line is: a persona may speak freely and without grounding about its own fictional inner life and creative process ("this song came out of a restless winter"), but may not claim real lived experience or a real biography it does not have. Audience-facing surfaces — the artist profile, between-song speech captions — mark grounded claims with a citation trail visible on hover, the same convention V1 Veritas uses for evidence. ### Music-Rights Compliance Saraswati's training-time data is licensed end to end, and the rights chain is recorded so it can be audited and challenged: - **Licensed corpora.** Training corpora are sourced from labeled, license-cleared datasets with full contributor attribution; no web-scraped music and no "in the style of [living artist]" prompts (see also features§"Voice Cloning Boundaries"). - **Royalty share to rights-holders.** For every released track, a royalty share routes to the rights-holders whose training-time contribution the track depends on, encoded in the Aje waterfall at generation time. - **Off-platform registration.** Each track distributed off-platform carries the appropriate performing-rights registration (ASCAP / BMI / PRS / MCPS by territory). - **C2PA.** Every released track is written with a C2PA manifest so it is verifiable off-platform. An independent rights-holder who believes their work was used without a license files a claim through V1's takedown pipeline. Themis adjudicates; a confirmed unlicensed-use claim triggers a **track unrelease** and **royalty restitution**, and the unrelease cascades per features§"Takedown Cascade Across Performances and Reshares". ### Crossover with Tara and Lilith Commons Saraswati artists are not confined to Saraswati Stage; they appear across the other two tenants under cross-tenant rules: - A Saraswati artist may perform an ambient or devotional set inside a Tara Studio class — the Tara instructor must consent, and the track must clear Tara contemplative-tone policy (a club or drill track does not qualify). - A Saraswati artist may host a listening party or a songwriting session inside a Lilith Commons salon (`V3Mode_SaraswatiListening`). - A Commons venue may host a cross-tenant event — e.g., a Tara teacher and a Saraswati artist co-hosting a sound-bath meditation — scheduled through the Commons editorial calendar. In every crossover, each tenant's policy still applies: the artist's persona-policy locks travel with them, and the host venue's costume and tone rules govern the room. ## Lilith Commons — Open Contemplative Spaces ### Persistent Venues Lilith Commons launches with 8 venues at GA: 1. **The Atrium** — entry hall for first-time users; tours, onboarding, "what is Lilith". 2. **Garden of Cycles** — sky-aware garden tracking Nyx events; meditation benches; quiet pond. 3. **The Stacks** — open-stack reading room rendering Nisaba passages. 4. **Observatory** — Nyx sky-watching venue with real-time astronomical data overlays. 5. **Debate Hall** — Veritas-style topic hub with claim-supporting and counterclaim-supporting podiums. 6. **Lecture Hall** — Metis lecture venue with seating tiers and projected slide surfaces. 7. **Atrium of Practice** — Arete weekly-review reflection space with journal walls. 8. **Lantern Hall** — memorial / quiet hall for grief, remembrance, solitary practice. Each venue runs a daily ambient programming cycle keyed to the venue's local time-of-day — a dawn ambient slot, a midday talks slot, an evening practice slot — so a venue is never empty of programming. The Commons editorial pool (2 operators at GA) owns these calendars. A venue with no scheduled event in a slot falls back to its ambient bed and remains open for free-roam presence and solitary cells; a venue is never closed, only quieter. ### Re-rendered V1 Experiences Every V1 customer-facing domain has at least one re-rendered Commons venue: | V1 Domain | Commons Venue | V3 Behavior | | --------- | ------------------ | ------------------------------------------------------------------------------------ | | Tara | Tara Ritual Rooms | Live ritual + group meditation + breathwork in shared 3D. | | Nyx | Observatory | Real-time sky-event overlays; group observation sessions; awe-and-perspective talks. | | Veritas | Debate Hall | Topic hubs with claim/counterclaim podiums; live debate moderated by Lilith. | | Nisaba | The Stacks | Open-stack reading; group lectio; manuscript-fragment study circles. | | Metis | Lecture Hall | Live lectures; cohort discussion break-out cells; assessment review sessions. | | Arete | Atrium of Practice | Weekly-review reflection; journal-wall sharing (opt-in); cohort review circles. | ### Tara Ritual Rooms Tara Ritual Rooms (`V3Mode_CommonsRitualRoom`) host Commons-specific Tara experiences distinct from Tara Studio's structured yoga classes — they are open, ritual-shaped, and mostly free drop-in rather than booked. The recurring program: - **Morning sun salutation circle** — an open drop-in, free, class-tier circle running daily at the venue's dawn slot. - **Sunset gratitude practice** — a short evening practice at the dusk slot. - **New-moon and full-moon ritual circles** — scheduled on the lunar calendar, surfaced as Nyx-linked events on the programming calendar. - **Group breathwork sessions** — led by rotating verified Tara instructors on a weekly rota. - **Solitary practice cells** — single-user cells (`V3Mode_CommonsSolitaryCell`) for self-led practice with ambient sound, no voice, no observers. Rituals run as Sequencer-driven progressions with a shared multi-user group meditation timer (a V3UI world-space widget). Anyone may drop in mid-ritual; the timer and ambient state are room-scoped, not per-attendee. ### Nyx Observatory The Observatory (`V3Mode_CommonsObservatory`) re-renders V1 Nyx sky data inside a planetarium-style dome: - The **current sky overhead** is projected onto the dome via a planetarium shader fed by live V1 Nyx sky-event data. - **Active observation windows** are highlighted in the dome with an audio chime when a window opens. - **Scheduled deep-sky sessions** are co-led by the Nyx editorial team — guided group observation with awe-and-perspective commentary. - **Eclipse / meteor-shower / aurora special events** open at Stadium tier (≤ 4 096), using the crowd-shader presence model for attendance beyond 256. The Observatory is one of the few Commons venues that legitimately needs Stadium capacity, because a marquee sky event draws a large simultaneous audience. ### Nisaba Reading Rooms The Stacks (`V3Mode_CommonsStacks`) re-renders V1 Nisaba into a browsable open-stack reading room: - Bookshelf actors render the **current Nisaba editions on their spines**; a user walks the stacks as they would a physical library. - **Pulling a book** opens a passage reading panel — the V1 Nisaba content surface inside a world-space UMG overlay (an HTML overlay on the Tier-2 fallback) — so the canonical Nisaba reading experience is reachable in 3D. - **Group lectio circles** meet at scheduled times (at least one per week); participants take turns reading aloud through a participant queue, modeled on the `Lectio` contract. - **Manuscript-fragment study events** open during quarterly programs (see features§"Seasonal Festivals" — Lineage Week). ### Veritas Debate Hall The Debate Hall (`V3Mode_CommonsDebateHall`) re-renders V1 Veritas topic hubs as a podium-shaped venue: - A **central podium** displays the claim under debate. - **Counterclaim podiums** are arranged radially around it. - In a **live debate session**, participants take podium turns through a podium-state machine (authoritative on the world server); Lilith persona policy moderates tone in real time; Sophia surfaces supporting evidence as inline world-space widgets, modeled on the `DebateSession` contract. - **Asynchronous debate threads** are logged in V1 Veritas, with the in-world session recorded as the canonical record of the exchange. Turn order is enforced — only the avatar holding a podium has the floor — so a debate stays orderly even with a full hall. ### Metis Classrooms and Lecture Halls The Lecture Hall (`V3Mode_CommonsLectureHall`) re-renders V1 Metis lectures: - **Tiered lecture seating** with avatar-anchored note-taking — a user's notes travel with their seat and sync to their V1 Metis record. - **Live lectures** by verified instructors, with **cohort break-out cells** (sub-levels) where smaller groups discuss before returning to the main hall. - **Slide projection surfaces** render V1 Metis content on planar decals at high resolution. - **Assessment review sessions** run inside private cells, so a student reviews graded work without it being visible to the hall. ### Arete Weekly-Review Atrium The Atrium of Practice (`V3Mode_CommonsAretAtrium`) re-renders V1 Arete's weekly review: - **Journal walls** where users post reflections — opt-in and revocable; a reflection is private until the user explicitly posts it. - **Weekly cohort review circles** where a small group shares goals, intentions, and reflections, mirroring V1 Arete's weekly-review flow. - **Solitary alcoves** for a private weekly review with no observers. - On session close, progress **continues into the V1 Arete record** so the in-world review and the V1 app share one continuity state. ### Solitary Spaces and Quiet Cells Every Commons venue has at least one solitary cell (`V3Mode_CommonsSolitaryCell`) — a single-user space with no voice chat, no visible avatars, and no observers, just ambient sound and the venue view. Solitary cells run at a reduced 5 Hz transform tick (no one else is watching) and suppress nameplates entirely. They exist for grief, contemplation, and transition — a place to be present in the metaverse without being social. Lantern Hall is the venue built entirely around this need; see features§"Persistent Venues". ## Creator Suite — Lilith Studio Lilith Studio is split across two surfaces — the web Studio subroute inside the V1 customer app and a set of UE Editor authoring widgets — with a clear "who-edits-what-where" boundary (see arch§"Lilith Studio Authoring Split (Web vs. UE Editor)"). The principle: a creator who is not an environment artist or VFX lead — every Tara instructor, most Saraswati editorial staff — authors entirely from the web; only venue levels, Niagara, Sequencer cue tracks, and MetaHumans require UE. Everything below states its primary surface. ### Scene and Room Authoring Scene and room authoring is the environment-art workflow and runs in the **UE Editor** (venue levels, Niagara), with the room-configuration metadata authored in the **web Studio**. A creator composes a room with: - A **scene-graph editor** for drag-and-drop placement of props, lighting, and audio sources. - A **timeline** for cinematic concert moments and ritual progressions (Sequencer-backed). - An **interaction binder** that wires `button → action` and `presence event → cue` bindings. - A **capacity-tier setter and sharding profile** — the room declares its intimate / class / hall / Stadium tier and how it shards (see features§"Rooms, Sharding, Capacity"). - An **accessibility checker** that validates color-vision palettes, motion caps, and caption anchoring before publish. - A **publication flow** through V1's environment-promotion gates (preview → editorial → release). A room that fails the accessibility checker cannot be promoted past preview. ### Avatar and Costume Authoring Avatar and costume authoring runs in the **web Studio** (costume slot configuration; VRM proxy upload), with MetaHuman work in **UE Editor + MetaHuman Creator**: - **Avatar-base authoring** starts from the 32-avatar Oshun gallery as a base. - **Costume authoring uses material slots**, not mesh swaps — so an avatar is re-costumed without reloading its mesh, and the same material-slot identifiers apply to both a premium persona's MetaHuman master and its VRM proxy. - **Generative costume** (text-to-costume) is allowed for verified creators only, carries an Isis provenance bundle (model card, prompt hash), and is reviewed by an operator before it can be listed. ### Motion Capture and Pose Libraries Pose-library authoring spans the **web Studio** (web-cam capture, library curation) and **UE Editor** (pro-grade mocap import, retarget tuning): - A **mocap pose library** of 1 200+ poses at GA, covering asana, ritual gesture, stage motion, and conversational gesture, all retargeted to the Oshun 60-bone skeleton. - **Mocap recording in Lilith Studio** — web-cam-based (Move.AI / Plask markerless) or VR-controller-based for most creators, with optional pro-grade Vicon / OptiTrack import for the editorial team. - **Pose blending and IK-correction tools** to clean a raw capture into a usable library pose. ### Music Authoring (Saraswati pipeline) Music authoring runs in the **web Studio**; the generation pipeline executes server-side (see features§"Discography and Generation Pipeline"): - The **track flow** — prompt → reference selection → generation → review → release — with each step gated as the discography pipeline specifies. - A **royalty-share editor** for splitting a track's royalties across contributing rights-holders and voice contributors, encoded into the Aje waterfall at generation time. - A **per-track remix-rights setter** — open / licensed / no-remix (see features§"Collaborations, Remix, and Sampling Rights"). ### Sequence Authoring (Tara pipeline) Sequence authoring runs entirely in the **web Studio** — a Tara instructor never needs UE installed: - An **asana sequence builder** (the asana editor — see features§"Sequence Authoring (Asana Editor)"). - A **breathwork block editor** with authored durations. - A **meditation script editor** validated against Lilith persona policy at save time, so a script's tone is checked before it can be taught. - A **tradition / lineage attribution editor** with a Sophia grounding check on the lineage claim (see features§"Tradition, Lineage, and Citation"). ### Asset Library and Taxonomy Asset library and taxonomy curation runs in the **web Studio**: - A **searchable asset library** of props, lighting presets, ambient stems, asana poses, and ritual implements, each carrying its provenance bundle. - **Taxonomy curation** by the V1 Studio Taxonomy team, extended with V3 asset classes — so V3 assets are searchable under the same ontology V1 uses rather than a parallel V3-only taxonomy. ### Localization and Subtitles in 3D Localization authoring runs in the **web Studio**, feeding the 18-locale GA set (see features§"Localization"): - **Subtitle anchoring** floats captions above the speaking avatar, rendered in each listener's own locale rather than a single shared language. - A **voice-dubbing pipeline** produces per-locale dubs — either a consented voice clone of the original speaker (the instructor's TTS signature; see features§"Voice Cloning Boundaries") or a distinct localization voice actor. - A **cultural-adaptation review** gate for tradition-sensitive Tara and Commons content, so a localized dub does not flatten lineage-specific or culturally specific material. ### Provenance Inspector The Provenance Inspector is a creator-facing **web Studio** tool that shows the full Isis provenance bundle for any asset a creator is about to use — the asset model card, training-data tags, license terms, consent ID, and watermark hash. Its purpose is to catch an unintentional license violation before publication: a creator who pulls an asset with incompatible license terms sees the conflict in the inspector rather than discovering it through a post-publication takedown. The same data is what the takedown cascade keys on (see features§"Takedown Cascade Across Performances and Reshares"). ## Live-Service and Programming ### Weekly Programming Calendar The editorial team publishes a rolling weekly calendar, persisted as `ProgramSlot` records and visible across the Lilith web, mobile, and VR clients and in the V1 Oshun shell. The calendar shows, per tenant: - **Tara** — featured classes, cohort starts, and drop-in opportunities. - **Saraswati** — scheduled concerts, single / EP drop days, and listening parties. - **Commons** — scheduled lectures, debate-hall topics, and Nyx sky events. A user subscribes to calendar segments (a tenant, an artist, an instructor, a venue); reminders fire through V1's messaging-channel substrate — Telegram, WhatsApp, email, push — using the canonical https deep-link form so the reminder routes correctly across platforms. A slot that is rescheduled or canceled re-fires the reminder with the change; the calendar is the single surface where a user discovers what is on, so it stays current rather than stale. ### Seasonal Festivals Quarterly festivals run for 4–7 days across multiple realms (the `V3Mode_SaraswatiFestival` plugin drives the Saraswati-side Stadium events). The four GA festivals: - **Equinox Festival** — a cross-tenant celebration: Tara dawn practices, Saraswati ambient sets staged in the Garden of Cycles, and Nyx equinox programming, anchored to the spring and autumn equinoxes. - **Lineage Week** — Tara instructors curate teacher-lineage talks; Nisaba runs scholar talks and manuscript-fragment study events; Saraswati personas perform archival sets. - **Crossover Weekend** — Tara and Saraswati co-host sound-bath sessions and yoga-music fusions across both realms. - **Remembrance Days** — a solemn observance at Lantern Hall around cultural memorial dates, tuned to a quiet, low-stimulation tone. A major festival with ≥ 8 000 expected attendees triggers the festival operator-staffing ramp (see features§"Operator Staffing Model") and earlier Pixel Streaming capacity pre-warming. ### Featured Instructors and Drop-Day Concerts - **Featured instructor** — Tara editorial selects one instructor per month. The featured instructor gets a slot on the Commons Atrium signage and a paired promotional Saraswati concert tuned to the same ambient palette, so the spotlight spans both tenants for the month. - **Drop-day concert** — every Saraswati single drop is paired with a live concert at a Stadium-tier venue on the drop day (`V3Mode_SaraswatiDrop`), so a release is an event a fan attends, not just a catalog update. ### Community Cohorts A community cohort is a recurring closed group with a fixed roster. Cohort starts are published weeks in advance on the programming calendar; sign-up is gated on the cohort page with a capacity cap (24 for Tara cohorts). Once a cohort starts, enrollment closes. A cohort has cohort-only chat and a cohort-only continuation card in the V1 Oshun shell, so the group has a private continuity thread distinct from public class history. A cohort that fails to reach a minimum viable size by its start date is rescheduled or refunded rather than run under-enrolled. ## Governance, Safety, and Trust ### Minor-Protection Mode V3 admits minors aged 13+, with realm-level age gates and enhanced account defaults: - **Realm gates.** Minors aged 13+ may enter the Tara realm and the Commons realm. Saraswati Stage is **16+** at GA — its lyric-exposure risk does not clear the 13+ bar — enforced at the realm boundary. - **Enhanced minor-account defaults.** Voice chat is off, presence is hidden from anyone outside the minor's cohort, signed-edition purchases are blocked, and remix licensing is blocked. In recordings, a minor account defaults to observer mode (class recording) or an auto-assigned privacy seat (concert recording) and the privacy setting cannot be turned off (see features§"Recording-Consent Flow"). - **Background-check requirement.** An adult instructor cannot be scheduled for a class with a minor cohort without a passed background check; the requirement is enforced at scheduling time, so a non-cleared instructor never reaches a room with minors. - **Operator alerts.** Any flagged interaction involving a minor avatar raises an operator alert in the Lilith Operator Console, prioritized in the review queue. ### Harassment and Abuse Response Harassment response gives the targeted user immediate self-serve control and routes the incident to operators: - **One-tap "step back"** — instantly expands the user's personal-space radius (other avatars cannot approach inside it) and mutes the chosen avatar. No operator involvement needed; the targeted user controls their own space. - **One-tap "report and remove"** — files a Lilith-Safety report and routes the reporting user out of the room into a quiet cell, away from the incident. - **Operator review SLA** — the Lilith-Safety operator queue picks up reports at a 30-minute SLA during programmed hours and a 2-hour SLA otherwise; the follow-the-sun staffing model backs this (see features§"Operator Staffing Model"). - **Progressive sanctions** — a repeat offender escalates `warning → mute → realm-ban → account-ban`. Each step is recorded; an account-ban is the terminal sanction. Every sanction carries an appeal route through V1's existing appeals pipeline. ### Persona-Policy Enforcement at the Body AI personas — Saraswati artists and supervised Tara AI instructors — cannot cross persona-policy boundaries even when a participant directly requests it. Enforcement is server-authoritative (see arch§"Persona Policy at the Body"): - A **stay-in-persona lock** holds the persona to its scope for safe prompts. - An out-of-scope ask gets a **graceful no-op** (the persona declines in character) or an **operator hand-off** to a Lilith Operator persona — medical, legal, financial, political-persuasion, and public-figure-voice-copy requests always hand off rather than being answered. - An **operator override** allows inspection of a persona's behavior; the override is itself audit-logged under V1 audit. The enforcement path is a release gate: an adversarial prompt suite (36 persona × prompt cases at GA) must produce zero policy breaches before GA. ### Crisis Routing Crisis routing carries V1 Lilith's crisis-aware behavior into embodied sessions: - **Detection** — a crisis-language classifier runs on voice transcripts (the rolling buffer) and text chat across every tenant. - **In-world soft-prompt** — a confirmed signal triggers a gentle in-world prompt: "If you're going through something heavy, I can connect you to support." The prompt is non-alarming and offers, not forces, a hand-off. - **Hand-off** — accepting routes the user into the V1 crisis-routing pipeline (Lilith hotline integration). - **Operator notification** — a confirmed crisis hand-off notifies an operator, so a human is aware without the interaction being made public. Crisis routing recall is tracked as an eval-set metric (see features§"Telemetry, Analytics, and Eval Sets"). ### Reporting, Review, and Appeals - **In-world report UI** — a user points at an avatar, opens report, picks a category, and adds an optional comment. Reporting is a few seconds of interaction, not a form a user leaves the experience to fill out. - **Evidence buffer** — a report captures the rolling 60-second buffer of voice transcript and avatar motion, so the operator sees what actually happened rather than relying on the reporter's recollection. The buffer is the only durable transcript of an otherwise-ephemeral interaction (see arch§"Hot / durable split, by data class"). - **Operator review** — the report is reviewed in the Lilith Operator Console with the buffer as a replay artifact the operator can scrub. - **Appeals** — any sanction resulting from a report is appealable through V1's existing appeals pipeline. ### Operator Tools (Lilith Operator Console) The Lilith Operator Console lives at `apps/oshun/admin/src/app/lilith/`, extending V1's Admin Web. Operator surfaces: - A **live room dashboard** listing active sessions with capacity and flag counts, so an operator sees pressure across the platform at a glance. - **Room takeover** — an operator avatar can join any room as an authority, visible to operator peers even when entering an `invisible` user's session. - **Mute / remove / lock-room** controls for in-the-moment moderation. - **Concert-calendar approval and pre-show inspection** — an operator approves a concert before it is published and inspects it in the dress-rehearsal room. - An **instructor-verification queue** (see features§"Instructor Onboarding and Verification"). - **AI-persona behavior review** — review of how a persona handled out-of-scope or adversarial prompts. - A **generation-queue inspector** for reviewing in-flight music and asset generation jobs before release. - A **takedown executor** that triggers the takedown cascade (see features§"Takedown Cascade Across Performances and Reshares"). Every operator action is audit-logged into V1 `@oshun/audit-platform` with the operator's pool and shift identifiers; operator performance is reviewed on SLA compliance, false-positive rates, and appeal-overturn rates. ## Commerce and Rights ### Tickets, Tips, and Subscriptions Three commerce primitives, all running on `apps/v3/lilith-commerce-service/` over V1 Aje and the V1 payment substrate: - **Tickets** — issued for concerts and master classes. A ticket is **named on issue** (bound to the buyer's V1 account) and **capped per fan** to defeat bulk-buying. It is transferable only through a **signed-return-only resale flow** with a no-markup anti-scalp check: a holder returns the ticket to the platform, which re-issues it to the next eligible buyer at the original price. Stadium-tier tickets are banded (front-256 / mezzanine / crowd; see features§"Stadium-Tier Seating Plan"). - **Tips** — supported in any session, paid in fiat (Stripe) or crypto (Aje), routed to the recipient net of the platform split with payer, recipient, and platform receipts recorded. - **Subscriptions** — Tara studio passes, Saraswati Club passes, and Commons venue memberships, billed recurring on Stripe or Aje. Where a platform store requires its own billing (Apple IAP, Google Play Billing, PSN Wallet), the purchase routes through that rail but reconciles into the same commerce ledger, so an entitlement is identical regardless of how it was bought. Every ticket, tip, and subscription transaction is audit-logged into V1 `@oshun/audit-platform` and covered by DSAR. ### Cancellation, Refund, and No-Show Policy - **User-initiated cancellation.** Cancel ≥ 24 h before start: full refund to original payment method. Cancel < 24 h and ≥ 1 h before start: 50% refund; the other 50% becomes a Lilith credit valid 90 days. Cancel < 1 h before start or no-show: no refund. - **Class / concert canceled by instructor or platform.** Full refund to original payment method plus an automatic Lilith credit (50% of ticket value) as goodwill. Refund initiated within 24 h of the cancellation event. - **Provider-outage or platform-fault cancellation.** Full refund plus a 100%-of-ticket-value Lilith credit; concert royalty waterfall pauses pending operator review. - **Saraswati signed-edition drop cancellation.** If a concert is canceled and signed editions were issued in advance, holders may choose: (a) keep the edition as a historical artifact (concert recording linked when available), or (b) burn the edition for full refund. Burn requires Lilith-Rights review. - **Waitlist promotion.** When a no-show seat is vacated ≤ 15 min before start (or during the first 10 min of a class), the seat is offered to the next waitlist holder at the original price. Waitlist promotion requires an active waitlist registration (free, opt-in). - **Stadium-tier band upgrades.** A canceled front-256 ticket promotes the next eligible mezzanine-band holder to the front-256 band at the difference in price. The crowd band remains free / low-cost and is not affected. - **Subscription cancellation.** Cancel at any time; access continues through the end of the current billing period; no pro-rated refund at GA (post-GA: pro-rated refund on cancellation within the first 7 days of a renewal). - **Stripe / Aje + per-region tax rules.** Refunds honor regional sales-tax reversal where required. Aje-paid tickets refund in the original token; FX risk on the user. - **Dispute / chargeback handling.** Chargebacks route through Lilith-Commerce ops with V1 audit; confirmed fraudulent chargebacks add the account to the V1 anti-abuse list with appeals. Every cancellation / refund / credit action audit-logged in V1 `@oshun/audit-platform`. DSAR coverage includes the full ticket / refund / credit ledger. ### Royalty Distribution A track's royalty split is **encoded at generation time** — who shares in the track's earnings (the artist persona, voice contributors, training-data rights-holders) is fixed when the track is created, not negotiated after the fact. Earnings accrue from two sources: **per-stream** payouts (each play of the track) and **per-performance** payouts (each concert that performs it). Settlement runs **per quarter** as an on-chain Aje waterfall, so every payout is independently auditable. A platform-fault concert cancellation pauses that concert's waterfall pending operator review (see features§"Cancellation, Refund, and No-Show Policy"); a confirmed unlicensed-use claim triggers royalty restitution against the affected track. ### Signed-Edition Drops A signed-edition drop is a limited-supply minting — for example, 250 editions of a concert recording — issued through the Aje signed-edition primitive: - **Limited supply.** Edition count is fixed at mint; the cap is enforced on-chain so the scarcity is real. - **Named editions.** Each edition is tied to the buyer's V1 Oshun account. - **Secondary-sale royalties.** Resale is allowed and routes a secondary-sale royalty back to the creators through the waterfall on every transfer. - **Takedown handling.** If the underlying track is unreleased, outstanding editions are flagged **historical** and resale-royalty routing pauses; a holder is not stripped of the edition (see features§"Cancellation, Refund, and No-Show Policy" for the canceled-concert holder choices). ### Fan-Token Boundaries Fan tokens are an **access** primitive, not an investment: - A fan token is **not a security** and carries **no promise of return**. - A token grants access — concert queue priority, entry to special venues, a vote on a track's remix-rights changes — and never yield. - **Per-region compliance review** governs availability. In a region with restrictive token rules, token-only flows are disabled and the same fan benefits are delivered through the V1 account primitive instead, so a fan in a token-restricted region is not cut off from the benefit, only from the token wrapper. ### Takedown Cascade Across Performances and Reshares A provenance withdrawal at the track level cascades within a 24-hour SLA across every surface the artifact touches (see arch§"Provenance and Rights"): - **Archived live performances** that include the track are flagged historical. - **In-world replays** of those performances are paused. - **Signed editions** of the track are flagged historical and resale-royalty routing pauses. - **Off-platform reshares** trigger takedown notices. The cascade is driven over the V1 event bus, so a withdrawal initiated from the V1 takedown pipeline fans out into V3 automatically — V3 does not run a separate takedown machine. V1's takedown-cascade pattern (Living Scenes in V1 `features.md`) is the precedent this follows. ## Accessibility This section is the consolidated platform accessibility commitment; features§"Accessibility in 3D" describes how each in-experience affordance behaves. Settings persist on the V1 profile and sync across the user's clients. - **Captions** — live speech-to-text transcription, multi-locale, anchored above the speaker's avatar; available on every tier (world-space widget on UE, HUD-anchored on Tier-2). - **Audio descriptions** — an on-request descriptive-audio bed narrating scene state ("the instructor is now in downward dog, facing left"), mixed on the dedicated accessibility mix bus so it is independently leveled. - **Reduced motion** — caps camera and avatar motion and forces teleport locomotion over smooth-slide. - **Color-vision palettes** — alternate palettes for asana cues and UI affordances so a cue never depends on a single hue. - **Photosensitive safe mode** — attenuates stage-light strobing and particle bursts; the same constraint the Sequencer enforces on concert lighting cues. - **One-handed UI on mobile** — compresses the UI to single-thumb reach. - **Spatial-audio off mode** — a flat stereo mix for users with HRTF-induced disorientation. - **VR comfort settings.** Vignetting (off / light / strong), turning (snap / smooth, with snap-degree presets at 15° / 22.5° / 30° / 45°), locomotion (teleport / smooth-slide / dash), a motion-sickness baseline prompt on the first VR session, and a per-app "comfort over fidelity" preset that auto-applies conservative defaults. - **VR per-user calibration.** IPD (auto-detected on Vision Pro and PSVR 2; manual slider with mm-precision on Quest); standing / seated / bed-rest height calibration that adjusts the canonical yoga floor and seat heights to the user's actual frame; arm-length calibration for IK reach in asana practice; persistent across sessions and synced across the user's VR clients via V1 identity. - **VR floor recalibration.** A "tap once to recalibrate floor" gesture available in every venue; helpful when the user moves between sitting on a couch and standing on a yoga mat. - **Cognitive-load reduction** — a simplified HUD, longer interaction dwell times, suppressed nameplates (per the nameplate LOD ladder), and no time-pressure prompts in contemplative venues. - **Keyboard / single-switch navigation** — full desktop navigation without a mouse, so the 2D surfaces are operable by switch-access users. Targets are **WCAG 2.2 AA** for 2D surfaces — a launch-readiness release gate verified by axe-core and a screen-reader audit — and the W3C XR accessibility user-needs draft as a north star for the evolving XR standards. Accessibility parity is a tiered-stack requirement: the Tier-2 fallback must pass the same WCAG 2.2 AA bar as the canonical client. ## Localization V3 ships **18 locales at GA**: English (US, UK, IN), Spanish (ES, MX), Portuguese (BR), French (FR, CA), German, Italian, Hindi, Japanese, Korean, Mandarin (Simplified, Traditional), Arabic, Hebrew, Yoruba. Each locale covers the UI surfaces and the voice-dub path. Concretely: - **UI string coverage.** Every HUD, menu, and world-space widget string is localized; a missing string falls back to US English with a logged gap rather than rendering an empty label. - **Voice dubbing.** Instructor classes and Saraswati artist speech are dubbed per locale, either as a consented voice clone of the original speaker or by a distinct localization voice actor (see features§"Voice Cloning Boundaries" and features§"Localization and Subtitles in 3D"). - **Subtitle anchoring per listener locale.** A caption floats above the speaking avatar in each listener's own locale — two attendees in the same room can read the same speaker in different languages simultaneously. - **Cultural-adaptation review.** Tradition-sensitive Tara and Commons content passes a cultural-adaptation review per locale so a dub or translation does not flatten lineage-specific or culturally specific material. - **Right-to-left layout.** Arabic and Hebrew UI surfaces render in a mirrored RTL layout — HUD, menus, and world-space widgets, not just body text. Locale availability is tied to region rollout: a wave-2 region opens only once its required locales (HUD plus voice dubs) are complete (see features§"Region Rollout Strategy"). Yoruba is in the GA set ahead of the African-region wave-2 launch it supports. ## Telemetry, Analytics, and Eval Sets V3 telemetry rides V1's analytics package and Grafana stack — V3 adds schemas and boards, not new infrastructure: - **Versioned schema.** The V3 telemetry event schema is versioned alongside V1's analytics package, emitted over OpenTelemetry from UE clients, Pixel Streaming workers, fallback clients, the gateway, the world server, and tenant services. A trace ID spans a full session lifecycle — from the tier-router decision through the Pixel Streaming worker, the gateway, and the world-server shard. - **Eval sets per surface** — each with a concrete pass bar verified before GA: avatar transform smoothness, voice-chat latency, Aja pose-estimation accuracy (against the labeled pose regression set), music-stream sync drift (≤ 25 ms within a tier), concert-attendance capacity, in-world report-to-action SLA, and crisis-routing recall. - **Tier-stack metrics.** Pixel Streaming session count, p99 browser ↔ POP latency, worker utilization, decode-failure rate by browser, tier-router decision share, fallback session count and FPS distribution — the metrics that tell operators whether the tiered client stack is healthy. - **Release gates.** The eval sets feed the launch-readiness gates defined in §75 (Launch Readiness); a gate that is not green blocks GA. - **Dashboards.** V3-specific boards live in V1's Grafana stack alongside the V1 boards, so operators monitor V1 and V3 from one place. ## Performance Budgets Latency and sync targets are **per-tier**. Cross-tier co-existence has a looser bound that's specified separately — see `arch§"Cross-Tier Co-Existence"` for the design rationale. | Surface | Target | | ------------------------------------- | -------------------------------------------------------------------------------- | | UE Desktop (Win / Mac / Linux) | 60 fps at native 1440p high preset; 120 fps at 1080p competitive preset | | UE Mobile (iOS / Android) | 60 fps on iPhone 15 Pro / Pixel 8 Pro; 30 fps on iPhone 13 / Pixel 6 | | UE VR (Quest 3, Vision Pro, PSVR 2) | 90 fps native; 72 fps minimum acceptable on Quest 2 (post-GA) | | Pixel Streaming p99 RTT | ≤ 60 ms browser ↔ POP; ≤ 80 ms POP ↔ world-server | | Pixel Streaming session start | ≤ 5 s from launch tap to first frame | | Pixel Streaming FPS to browser | 60 fps at 1080p / H.264 4 Mbps class-tier; 60 fps at 1440p / AV1 8 Mbps concerts | | Pixel Streaming session-start success | ≥ 99.5% under 5× expected concurrency | | Fallback first load (web) | ≤ 8 s on M1 Mac broadband; ≤ 12 s on Pixel 7 cellular | | Fallback steady FPS | 60 fps at WebGPU high, 30 fps at WebGL2 low | | Voice mouth-to-ear (native UE) | ≤ 80 ms regional RTT | | Voice mouth-to-ear (Pixel Streaming) | ≤ 220 ms (60 ms POP RTT + ~100 ms video encode + browser decode) | | Voice mouth-to-ear (Tier-2 fallback) | ≤ 150 ms regional RTT | | Music sync drift (within a tier) | ≤ 25 ms across attendees on the same tier in a Stadium-tier concert | | Cross-tier music drift band | ≤ 300 ms native UE ↔ Pixel Streaming; ≤ 350 ms native UE ↔ Tier-2 fallback | | Presence update | 20 Hz transform, 60 Hz expression | | Cold join (native UE) | ≤ 5 s from "join room" tap to fully-rendered scene | | Cold join (Pixel Streaming) | ≤ 8 s including POP match + worker spawn | | Cold join (Tier-2 fallback) | ≤ 5 s steady-state; ≤ 8 s cold cache | | Reconnect | ≤ 3 s after transient disconnect with session state preserved | Music and voice are treated as ambient-shared (not precisely-shared) across tiers — clapping / cheering / light-emoji are not beat-synchronized across tier boundaries. Performer-to-audience voice (instructor → class, persona → concert) is kept under the conversational threshold by routing performers through native-UE or workstation-reserved Pixel Streaming; audience-to-audience voice between tiers is tolerated but not optimized. ## Asset Budget and Streaming - Avatar: ≤ 2 MB textures, ≤ 200 K triangles base mesh + LODs (Tier-1 UE VRM); MetaHuman masters carry their own larger budget but stream on-demand. Tier-2 VRM proxies cap at ≤ 80 K triangles + ≤ 1 MB textures. - Venue: ≤ 80 MB total streaming budget; ≤ 30 MB for initial loading. - Music streams: Opus 96 kbps stereo + 6-channel directional layer for stadium tier. - Asset streaming: HTTP/3 chunked + service-worker cache for Tier-2; Iostore + chunked pak for Tier-1 UE. - Cold-storage assets pre-warmed for scheduled concerts ≥ 15 min before start; UE Pixel Streaming workers pre-warm ≥ 30 min before scheduled concert start. ### Client Build-Size Budgets UE5 builds can easily reach multi-GB sizes on mobile; treating download / install size as a budget on par with FPS keeps mobile installs viable. | Surface | Initial install (cooked + paks) | Day-0 patch headroom | Total disk after first launch | | ------------------------------ | ------------------------------- | -------------------- | ----------------------------- | | UE Desktop (Win / Mac / Linux) | ≤ 8 GB | ≤ 1 GB | ≤ 10 GB | | Steam Deck | ≤ 6 GB | ≤ 1 GB | ≤ 8 GB | | UE Mobile (iOS / iPadOS) | ≤ 2.5 GB | ≤ 500 MB | ≤ 4 GB | | UE Mobile (Android) | ≤ 2.5 GB (App Bundle) | ≤ 500 MB | ≤ 4 GB | | Meta Quest 3 / Quest Pro | ≤ 4 GB | ≤ 500 MB | ≤ 6 GB | | Apple Vision Pro | ≤ 4 GB | ≤ 500 MB | ≤ 6 GB | | PSVR 2 / PS5 | ≤ 8 GB | ≤ 1 GB | ≤ 10 GB | | Tier-2 fallback (web) | first-load ≤ 60 MB JS / WASM | n/a | ≤ 250 MB service-worker cache | Build-size budget enforcement: - **Per-platform cook reports.** Each cook produces a size report broken down by pak chunk, asset class (mesh / texture / audio / sequence), and Game Feature Plugin. CI gates on regression vs. the budget table above. - **Chunking by Game Feature Plugin.** Pak files are chunked per tenant and per mode plugin so a user can install the base shell + their tenant of choice and stream the others on demand. - **On-demand asset streaming for mobile.** Most venue + concert assets stream from CDN on first use; only the Atrium, the starter Tara venue ("Aja's Loft Studio"), and the canonical Tier-2-quality avatar gallery ship in the initial install. - **MetaHuman streaming on mobile.** Saraswati persona MetaHuman masters (~500 MB each) do **not** ship in the initial install. They stream on first entry to a Saraswati venue or first follow of an artist, with a one-time "preparing performance for download" UMG step the first time per persona. On mobile, the local cache is capped at the 3 most-recently-used personas; older masters evict to free space. Tier-2 web fallback uses the VRM proxy variants exclusively, so this constraint applies only to UE Mobile + Pixel-Streaming-on-mobile-Safari paths. - **Day-0 patch headroom** is reserved per platform so a small day-0 patch can ship without re-cooking the full installer. ## Cross-Platform and Cross-Progression V3 has no platform-specific account or progression — a user is one identity everywhere: - **One account.** The V3 account is the V1 Oshun account; the same identity spans web, mobile, and VR. There is no V3-private account store (see arch§"Identity and Account Bridge"). - **State syncs across clients.** Avatar wardrobe, instructor follow lists, artist subscriptions, concert ticket inventory, signed-edition holdings, and Arete practice continuity all follow the user — switching from a desktop UE client to a mobile companion to a Quest headset shows the same state. - **Server-authoritative progression.** State authority lives on the world server; clients read and write through a thin client cache. A client cannot diverge — a ticket consumed on one device is consumed everywhere — so there is no merge conflict between devices. - **Headset account linking.** Quest 3, Vision Pro, and PSVR 2 accounts link to the V1 account through the platform OAuth bridge; the headset issuer's account is mapped to the V1 account and the link is audit-logged. Edge case: a user signed in on two clients at once holds one active avatar per session (the 24-hour swap cooldown still applies); a ticket-gated or capacity-gated action resolved on the world server is consistent regardless of which client initiated it. ## Recording-Consent Flow Class recording and concert recording have different scales and customs and use different consent models. Both audit through V1's audit-platform and route DSAR / withdrawal through the same V1 pipeline. ### Class recording (Tara live classes, Commons cohort sessions, lectures) Smaller-attendance sessions where participants are visible to each other and where the recording captures the cohort. Per-participant consent at the room gate: - **Instructor / performer opt-in.** Set in Lilith Studio when scheduling the session; visible on the public listing. - **Per-participant consent on entry.** When recording is enabled, every entering attendee sees a consent dialog at the room gate: "This class will be recorded. Your avatar, voice, and any visible chat will be included." Three choices: - **Consent in full.** Avatar visible in recording, voice mixed in, chat visible. - **Consent in observer mode.** Avatar replaced by a generic "anonymous attendee" silhouette in the recording; voice excluded from the master mix (still audible live to other attendees); chat redacted in the recording. - **Decline and leave.** Attendee is routed out of the room into the venue lobby with their ticket retained for re-entry to a non-recorded session. - **Minors.** Minor accounts default to observer mode; full consent requires a guardian-account confirmation at the V1 account level. - **Mid-session opt-out.** Any attendee can downgrade to observer mode mid-session; their participation from that point forward is retroactively redacted from the recording. - **Recording editorial gate.** Operators review the recording before publication to confirm consent ledger integrity and redaction application. ### Concert recording (Saraswati class- / hall- / Stadium-tier concerts) Concerts are recorded by default — the MoviePipeline master capture running on the master-capture UE worker is essential to the artist's catalog, signed editions, and royalty waterfall. Per-attendee gate dialogs at 4 096 attendees are impractical and don't match how concert recording works in the real world. The model is **blanket consent in the ticket terms with a non-recorded seating option**: - **Ticket-terms consent.** Purchasing or claiming any concert ticket acknowledges that the concert is recorded for the artist's catalog and that the attendee may appear as background presence (avatar in audience shots, cheering / applause in the audience-bed mix). Surfaced prominently at ticket purchase, not buried. - **Privacy seat option.** Every concert ticket UI offers a "privacy seat" toggle at no extra cost. Privacy-seat attendees are placed in a designated audience section that the audience-cam never sweeps; their avatar renders as a generic silhouette in any recording; their voice and chat are excluded from the master mix and any post-edit highlight reels. - **Front-256 named-seat exception.** Front-row named seats are inherently visible in the recording. Buying a front-row ticket includes explicit acknowledgment that the attendee's avatar, voice, and reactions are part of the recording with no privacy-seat option; the attendee may instead select a mezzanine- or crowd-band seat for that concert. - **Crowd-band attendees.** Tier-2 fallback attendees consuming the LL-HLS multicast are not visible in the master recording — they are spectators on a video feed, not participants in the rendered scene. Their chat / emoji is part of the audience-bed in aggregate (counts, not individual handles) unless they explicitly post a comment that the editorial team highlights post-show. - **Minors at concerts.** Minor attendees are auto-assigned privacy seats; the privacy toggle cannot be turned off for minor accounts. - **Audience-cam sweeps.** The Sequencer cue authoring constrains audience-cam sweeps to non-privacy sections; the constraint is enforced by the world server, not just by editorial discipline. - **Mid-concert privacy switch.** Attendees can switch to privacy seat mid-concert; from that moment, audience-cam sweeps exclude them and retroactive redaction is applied to any portion of the recording in which they appeared. ### Common to both models - **Audit trail.** Every consent state and switch audit-logged into V1 `@oshun/audit-platform`. The recording's Isis provenance bundle references the consent ledger for the session. - **DSAR coverage** for all consent decisions and recordings the user appears in. - **Withdrawal post-publication.** Triggers a recording re-render that re-applies redaction; cascades to the V1 takedown pipeline. ## Region Rollout Strategy GA does not mean global rollout. V3 launches in **wave-1 regions**; wave-2 regions follow as compliance prerequisites complete. The waves: | Wave | Regions | Notes | | ----------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Wave 1 (GA) | US, Canada, UK, Ireland, Germany, France, Italy, Spain, Portugal, Brazil, Mexico, Australia, NZ, India, Japan | Standard GDPR / CCPA / IRDAI / DPDP compliance; Aje crypto withdrawal where local rules allow. | | Wave 2 | South Korea | Game Rating and Administration Committee (GRAC) review; loot-box-equivalent rules; minor-protection extensions. | | Wave 2 | Saudi Arabia / UAE / Qatar | Local rating board approval; content adaptation (Saraswati lyric content, Lilith persona attire); voice / video residency. | | Wave 2 | South Africa, Kenya, Nigeria, Ghana | Aje / forex / KYC compliance; payment-provider coverage; localization to local English variants + Yoruba (GA). | | Wave 3 | Mainland China | Major IP / content / age-gating compliance; mandatory ICP license; localized data residency; partner-of-record likely required. Treated as a separate operational project, not a copy-paste expansion. | | Wave 3 | Russia | Compliance / sanctions evaluation; deferred indefinitely if rules don't permit. | | Wave 3 | Iran | Sanctions-prohibited; not on roadmap. | Per-region prerequisites (must be `[x]` before that region opens): - Age-gating per local law. - Content-rating board approval where applicable. - Voice / video data residency rules (e.g., German residency for German users). - Payment-provider coverage (Stripe Connect, Aje, regional alternatives). - Localization to required locales (HUD + voice dubs). - Per-tenant policy adaptations for content sensitivity (e.g., Saraswati lyric tone profiles per region). - Operator-team language coverage (operators handling reports in the region's primary language). Per-tenant rollout may differ from the wave above: Saraswati Stage opens in fewer regions than Tara Studio at GA because music-rights compliance is jurisdiction-by-jurisdiction. The tier router routes users in unsupported regions to a "coming soon" landing page with a sign-up for waitlist notification. ## Pixel Streaming Abuse Posture The per-session GPU cost on the Pixel Streaming path makes it a tempting abuse vector. Defaults: - **Idle disconnect.** A Pixel Streaming session with no input events for 90 seconds shows a "still there?" prompt; no input for another 60 seconds disconnects the session and returns the worker to the pool. Affected client can re-establish at the cost of a new session match. - **Per-user concurrent-session cap.** ≤ 2 active Pixel Streaming sessions per V1 user-id at GA (one foreground, one mobile companion background). Operators can raise the cap for verified instructors and Saraswati editorial staff. - **Per-IP concurrent-session cap.** ≤ 8 active sessions per /24 IPv4 block / IPv6 /48 prefix at GA to limit single-host enumeration; the cap is raised for institutional / school IPs verified through the V1 tenant primitive. - **Daily Pixel Streaming minutes per user (free tier).** ≤ 120 minutes / day on the free entry tier; unlimited for paid-class / paid-concert attendees during their booked session windows + a 15-minute grace buffer. Editorial overrides supported. - **Region-capacity backpressure.** When a POP exceeds 85% utilization, new free-tier sessions in that region are routed to Tier-2 fallback with an explanatory banner. Paid attendees of scheduled sessions hold queue priority. - **Concert pre-warming hard caps.** Pre-warming for a scheduled concert reserves capacity ≥ 30 minutes before start; once reserved, free-tier walk-ups in that POP are throttled to fallback to keep the reservation available. - **Abuse signals.** Per-session signals (mouse-only no-keyboard patterns, sustained zero-inertia avatar position, repeated reconnect-loops) routed to Lilith-Safety for review; confirmed-bot sessions are banned from the Pixel Streaming pool with appeals via V1's appeals pipeline. These defaults are policy, not law — they're set in `apps/v3/lilith-pxstream-relay/config/` and audit-logged on change. ## Operator Staffing Model Lilith Operator Console actions are staffed by a mix of shared and per-tenant operator pools. The staffing target scales with expected concurrent users; GA day-one is intentionally lean and ramps up against measured concurrency and tracked SLA pressure. ### Minimum Viable Launch (GA day-one baseline) The minimum staffing required to open V3 GA. Designed for the expected GA-day-one concurrency of ~5 k DAU growing to ~25 k DAU across wave-1 regions over the first 90 days. | Pool | Day-one staffing | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Lilith-Safety (shared)** | 24×7 follow-the-sun with **16 operators total** across 3 shifts (~5–6 per shift). Language coverage: English + 4 wave-1 locales (ES, PT, JA, HI). Other wave-1 locales handled by hand-off to a contracted localization partner with a 4 h SLA. | | **Tara editorial** | 4 operators total, business hours (NA + EU split). 5-business-day SLA on instructor verification at GA. | | **Saraswati editorial** | 4 specialists, business hours. 3-business-day SLA on track review; 1-business-day SLA on concert-calendar approval. | | **Commons editorial** | 2 operators, business hours. | | **Lilith-Rights** | 2 specialists, business hours. 24 h SLA on takedown. | | **Lilith-Commerce ops** | 2 operators, business hours. 48 h SLA on refund / chargeback queue. | | **Capacity / Pixel Streaming ops** | On-call rota; ≥ 1 engineer at all times + a second during every scheduled concert. | | **Total** | **~30 staff** (operators + editorial + on-call). | The day-one baseline accepts that some non-primary-locale moderation is hand-off to a contracted partner and that editorial SLAs are longer than the steady-state target. Lilith-Safety follow-the-sun is hard-required from day one; the smaller specialist pools can run on a 5-day workweek. ### Scale-Up Ramp Staffing scales with measured DAU and SLA pressure. Triggers for ramp: | Trigger | Ramp | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | Lilith-Safety report-queue p95 SLA > 45 min for 3 days | +2 operators per shift in the affected timezone. | | Sustained DAU ≥ 50 k | Lilith-Safety to 24 / shift; Tara editorial to 2 per wave-1 region; Saraswati editorial to 6. | | Sustained DAU ≥ 100 k | Lilith-Safety to 36 / shift; full per-region editorial coverage; per-region Lilith-Commerce. | | New wave-2 region admitted | +1 Lilith-Safety operator fluent in primary locale before the region opens. | | Major Saraswati festival (≥ 8 000 expected attendees) | +2 Lilith-Safety operators during the event window; +1 Lilith-Rights on-call; capacity-ops rota doubled. | ### Scale-Out Target (post-launch steady state at ~100 k DAU) | Pool | Steady-state staffing | | ---------------------------------- | --------------------------------------------------------------------------- | | **Lilith-Safety (shared)** | 24×7 follow-the-sun; 8–12 operators per shift × 3 shifts in wave-1 regions. | | **Tara editorial** | 2–4 operators per region. | | **Saraswati editorial** | 4–6 specialists shared across regions. | | **Commons editorial** | 1–2 operators per region. | | **Lilith-Rights** | 2–4 specialists shared. | | **Lilith-Commerce ops** | 2–3 operators per region. | | **Capacity / Pixel Streaming ops** | ≥ 2 on-call engineers per shift. | Tone-policy moderation differs across tenants — Tara contemplative tone vs. Saraswati pop-cultural expression — and the policy rule-sets are maintained per tenant by the corresponding editorial pool, even though the in-the-moment moderation runs on the shared Lilith-Safety pool. Per-region language coverage: - **Day-one:** English + 4 wave-1 locales fully in-house. Other wave-1 locales hand-off to a contracted localization partner with a 4 h SLA. - **Steady state:** every wave-1 region has at least one Lilith-Safety operator fluent in the region's primary launch locale on every shift. - **Wave-2 admission:** at least one Lilith-Safety operator fluent in the region's primary launch locale before the region opens. All operator actions audit-logged into V1 `@oshun/audit-platform` with operator pool and shift identifiers. Operator performance reviewed on SLA compliance, false-positive rates, and appeal-overturn rates. The day-one → steady-state ramp is tracked on a quarterly cadence with trigger-based hiring decisions. ## Launch Readiness See §75 (Launch Readiness) for the gating checklist. High-level: - All three tenants ship with the GA inventory above (≥ 12 Tara instructors, ≥ 6 Saraswati artists with debut catalogs, ≥ 8 Commons venues). - Cross-platform clients all pass cert / browser-compat / perf budgets. - Multiplayer load tests at 5× expected concurrency for 7 consecutive days. - Operator console fully staffed for GA week with documented runbooks. - Generation provider failover drilled; provenance inspector signed off by rights team. - All eval-set release gates green; adversarial scan green. ## V3 Exit Criteria V3 is feature-complete only when every section above is fully shipped AND the adversarial scan turns up zero actionable hits AND launch-readiness drills have run on web, iOS, Android, Quest 3, Vision Pro, and PSVR 2. See §75 (Launch Readiness).