This guide is the curated front door to V3, Lilith Metaverse: an embodied, multi-user world spanning native Unreal clients, pixel streaming, a web fallback, persistent rooms, avatars and spatial audio, Tara classes, Saraswati performances, Lilith Studio, commerce, rights, safety, and global operations. It complements the separate Lilith handbook, which disambiguates the member persona, V1 policy substrate, service domain, and V3 product.
Documentation map#
The feature and architecture sets describe the intended contract and the code-grounded system shape. The backlog, current runtime, builds, provider readback, validation artifacts, operational evidence, and region/certification records determine what can honestly be called supported.
Start with the question#
| Question | Canonical starting point | What it covers |
|---|---|---|
| What experience does V3 promise? | Feature hub and focused feature index | Worlds, client tiers, avatars, tenants, creation, trust, commerce, quality, and launch. |
| How does a member enter and remain in a room? | World/presence features, world server, and netcode | Join, authority, presence, replication, physics, reconnect, and failure behavior. |
| How do client tiers differ? | Client-tier feature guide, tier router, UE client, and fallback client | Eligibility, routing, fidelity, assets, capacity, degradation, and accessibility. |
| How do Tara, Saraswati, and Commons remain distinct? | Lilith handbook, Tara architecture, and Saraswati pipeline | Tenant identity, authoring, runtime boundaries, rights, and shared-world composition. |
| How are identity, consent, provenance, and rights enforced? | Identity/safety foundations, persona policy, and data/tenancy | Account bridge, body policy, recording consent, C2PA, tenancy, residency, takedown, and DSAR. |
| What is actually launch-ready? | V3 backlog, GA inventory, launch readiness, validation records, and current release gates | Evidence-backed status by surface, platform, region, provider, and operational capability. |
| Which systems are shared? | Dependency registry and V1 integration | V1 identity/contracts/audit plus shared generation, payment, safety, and platform dependencies. |
| Where are the visuals? | V3 diagram atlas and the generated diagram gallery | Curated client/world/content/trust models and every authored visual. |
Truth and rollout model#
Always name the client tier, tenant, platform, region, role, entitlement, consent, provider, and rollout cohort that bound a claim. A working UE room does not prove the fallback client; a rendered avatar does not prove consent or rights; a configured pixel-streaming POP does not prove capacity; and a route or fixture is not a deployed world journey.
Recommended reading journey#
Product and experience design#
Use the feature index to choose a member, tenant, creator, trust, commerce, or operations path. Read the companion architecture page before making cross-tier promises. V3 deliberately preserves different fidelity envelopes; accessible equivalence means the same core job and honest disclosure, not pixel-identical realization.
Engineering and content production#
Use the architecture index to trace tier routing, world authority, protocol/versioning, avatars/audio, tenant pipelines, authored assets, data residency, V1 composition, commerce, observability, and release. Follow identifiers and receipts across the BFF, realtime gateway, world server, stores, asset pipeline, and clients.
QA, accessibility, safety, and rights#
Exercise join/rejoin, capacity refusal, degraded tier, stale assets, version mismatch, muted/blocked actors, recording consent changes, takedown, entitlement loss, localization expansion, assistive input, motion/flash/audio alternatives, and provider failure. Safety and rights must remain effective at the embodied surface, not only in a web control plane.
SRE, release, and regional operations#
Pair the operations/launch architecture page with the committed validation, capacity, store-size, transport-security, region, DR, SLO, day-zero patch, and incident runbooks. Treat dated validation as a snapshot; current deployment and provider readback decide whether it is still applicable.
Page-set organization#
- Feature index — 16 focused topics across product orientation, metaverse platform, Tara, Saraswati, Commons/creation, and trust/commerce/quality/operations.
- Architecture index — 16 focused topics across client tiers, realtime, embodiment, tenant experiences, authoring/data/V1 integration, trust, commerce, and launch.
- Lilith handbook — eight cross-cutting identity/product topics that prevent the Lilith names from being conflated.
- V3 diagram atlas — client, room, identity, content, rights, rollout, and operational mental models.
- Root validation, operations, runbook, security, release, legal, and regional records — focused evidence rather than replacements for the canonical model.
Documentation quality contract#
Every canonical feature and architecture topic must remain substantial, reachable exactly once from its index, visually explain its principal complex relationship, distinguish product intent from runtime evidence, and link to the owning contracts/code/tests/evidence. The guide, atlas, Lilith handbook, global search, sibling navigation, diagram gallery, links, and desktop/mobile reader must remain generated and verified.
Edit source Markdown and canonical implementation/evidence, then regenerate the Docs Center. Generated HTML is never the authoring surface.