Lilith Handbook — Lilith Metaverse

Lilith is an overloaded name in Oshun. This handbook separates each meaning and then provides a complete reading map for the member persona, the V1 policy substrate, the standalone meditation/consciousness product domain, and V3 Lilith Metaverse.

Disambiguation first#

Name in context	What it is	Canonical home
Lilith, member assistant	The customer-facing identity of the shared V1 assistant. Builders/operators use the Eve identity.	Member persona and experience
Lilith persona-policy substrate	A V1 policy library for tone, crisis, voice, spiritual-domain, cultural-sensitivity, and unsafe-claim behavior. It is not a deployed service.	V1 Lilith Persona Policy
`/lilith` design-system showcase	A V1 web route that presents the Oshun design language. It is not the crisis-policy mount or the V3 world.	`apps/oshun/web/src/app/lilith/page.tsx`
Lilith product/domain	The separate `apps/lilith` and `libs/lilith` consciousness/meditation application estate and service domain.	Lilith domain
Lilith Metaverse (V3)	Oshun's embodied multi-user product: shared worlds, Tara Studio, Saraswati Stage, and Lilith Commons.	V3 overview

The names relate by product history and shared trust goals, but code, deployment, status, and ownership claims must identify which Lilith they mean.

Coverage map#

Aspect	Start here	What it covers
Member assistant	Member persona and experience	Identity boundary with Eve, rooms, handoffs, voice/avatar, memory disclosure, grounding, crisis, and release scope.
Embodied platform	Metaverse worlds and presence	Launch tiers, UE5 and fallback clients, world authority, rooms, presence, avatars, audio, transport, accessibility, and persistence.
Tenant experiences	Tara, Saraswati, and Commons	Practice/class experiences, AI artists and concerts, contemplative civic rooms, programming, and cross-tenant seams.
Creator workflows	Studio, creator, and media pipelines	Lilith Studio, personas, scenes, asana, music, concerts, assets, generation, review, provenance, and release.
Trust	Identity, memory, safety, and rights	V1 identity/memory bridge, embodied policy, recording/voice consent, moderation, provenance, C2PA, commerce, disputes, and takedown.
Services and data	Platform services, data, and integrations	`apps/lilith`, `libs/lilith`, V3 Rust/TypeScript/UE estates, contracts, schemas, events, APIs, V1 domain bridges, and external boundaries.
Operations and release	Operations, performance, testing, and release	Observability, capacity, latency, client tiers, incidents, deployment, validation, accessibility, localization, stores, and launch gates.

Product relationship map#

flowchart TD E[Eve builder/operator identity] --> S[Shared assistant runtime] L[Lilith member identity] --> S P[V1 persona-policy substrate] --> S P --> B[V3 body policy] D[apps/libs Lilith domain] --> X[Consciousness and meditation product] V[V3 Lilith Metaverse] --> B V --> T[Tara Studio] V --> A[Saraswati Stage] V --> C[Lilith Commons] V --> R[V1 identity, memory, grounding, generation, rights]

Arrows show composition or policy reuse, not one deployment. In particular, the V1 persona-policy library, the apps/lilith service estate, and V3's Rust/ Unreal stack are separate runtime shapes.

V3 product promise#

Lilith Metaverse carries V1 trust guarantees into embodiment. A V1 account can enter a shared world, bind an avatar, join a class or concert, speak through spatial voice, and create or capture media without dropping identity, consent, grounding, persona safety, provenance, or rights policy at the 3D boundary.

The product has three flagship tenant experiences:

Tara Studio — verified and supervised practice, breathwork, meditation, classes, coaching, sequence authoring, and instructor economics.
Saraswati Stage — persistent AI virtual artists, governed music/voice creation, discographies, live performances, fan participation, and royalties.
Lilith Commons — open contemplative venues that re-render Oshun domain experiences as shared rooms.

The canonical feature inventory is V3 Features, and the architecture is V3 Architecture.

Honest status rules#

V3 documentation distinguishes code and contracts that are on disk from deployed capacity, commissioned media, populated catalogs, and production certification. A schema, gate constant, Unreal module, Game Feature descriptor, or deterministic simulation is not by itself proof of a live fleet, complete art inventory, real users, or a passed store launch.

Use these labels consistently:

Real/on disk — implemented source, contract, test, or tracked asset exists.
Uneven/partial — the spine exists but some modules, fan-out, content, or end-to-end wiring is incomplete.
Gated — the feature needs provider credentials, GPU fleet, policy approval, tenant/release flag, commissioned content, or store/platform acceptance.
Target/specification — the document defines a requirement or acceptance threshold without claiming the underlying content/deployment exists.

Read the V3 product review and current backlog (V3/V3_TODOS.md in the repository) for completion state rather than inferring it from this handbook.

Reading paths#

Members and support: member experience, tenant experiences, and trust/rights.

Creators: Studio and media pipelines, tenant experiences, and trust/rights.

Engineering: worlds and presence, services/data/integrations, and operations/testing/release.

Trust, safety, and operations: identity/safety/rights, services/data/integrations, and operations/testing/release.

Canonical companion libraries#

Keeping this handbook true#

Update the focused topic when contracts, clients, tenant responsibilities, policy reuse, service boundaries, release gates, or operational procedures change. Preserve the disambiguation table whenever a new Lilith-named surface is introduced. Prefer links to canonical generated/source references over copied volatile counts, then run the Docs Center and V3-affected verification gates.