# V3 Documentation Guide 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](./lilith/README.md), which disambiguates the member persona, V1 policy substrate, service domain, and V3 product. ## Documentation map ```mermaid mindmap root((V3 documentation)) Member world Rooms presence and multiplayer Avatars nameplates and spatial audio Tiered clients and accessibility Identity safety and provenance Tenant experiences Tara classes and coaching Saraswati artists and performances Commons venues and live service Lilith Studio creator tools Platform World server and gateway Pixel streaming and fallback web Content and asset pipelines Data commerce rights and operations Delivery truth V3 backlog and dependencies Product review and GA inventory Validation reports and runbooks Region rollout and certification ``` 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](../V3_features.md) and [focused feature index](../features/README.md) | Worlds, client tiers, avatars, tenants, creation, trust, commerce, quality, and launch. | | How does a member enter and remain in a room? | [World/presence features](../features/world-rooms-presence-multiplayer.md), [world server](../architecture/world-server-and-gateway.md), and [netcode](../architecture/netcode-protocol-and-physics.md) | Join, authority, presence, replication, physics, reconnect, and failure behavior. | | How do client tiers differ? | [Client-tier feature guide](../features/client-tiers-fidelity-stadium.md), [tier router](../architecture/tier-routing-and-pixel-streaming.md), [UE client](../architecture/tier1-ue5-client.md), and [fallback client](../architecture/tier2-fallback-web-client.md) | Eligibility, routing, fidelity, assets, capacity, degradation, and accessibility. | | How do Tara, Saraswati, and Commons remain distinct? | [Lilith handbook](./lilith/README.md), [Tara architecture](../architecture/tara-classes-aja-and-commons.md), and [Saraswati pipeline](../architecture/saraswati-stage-pipeline.md) | Tenant identity, authoring, runtime boundaries, rights, and shared-world composition. | | How are identity, consent, provenance, and rights enforced? | [Identity/safety foundations](../features/identity-safety-provenance-foundations.md), [persona policy](../architecture/persona-policy-provenance-and-rights.md), and [data/tenancy](../architecture/data-tenancy-and-residency.md) | Account bridge, body policy, recording consent, C2PA, tenancy, residency, takedown, and DSAR. | | What is actually launch-ready? | [V3 backlog](../V3_TODOS.md), [GA inventory](../GA_INVENTORY.md), [launch readiness](../LAUNCH_READINESS.md), validation records, and current release gates | Evidence-backed status by surface, platform, region, provider, and operational capability. | | Which systems are shared? | [Dependency registry](../V3_DEPENDENCIES.md) and [V1 integration](../architecture/v1-integration-and-identity-bridge.md) | V1 identity/contracts/audit plus shared generation, payment, safety, and platform dependencies. | | Where are the visuals? | [V3 diagram atlas](./diagram-atlas.md) and the generated diagram gallery | Curated client/world/content/trust models and every authored visual. | ## Truth and rollout model ```mermaid stateDiagram-v2 [*] --> Designed Designed --> Implemented: code contract or authored asset exists Implemented --> Integrated: client edge world and shared services compose Integrated --> Validated: target-tier functional and quality evidence passes Validated --> Certified: platform region rights and operations gates pass Certified --> Released: enabled cohort receives the supported capability Implemented --> TierLimited: supported only on named client or fidelity tier Integrated --> RegionLimited: residency rights provider or policy boundary Validated --> Withheld: required evidence or production dependency absent Released --> Regressed: newer quality safety or operations evidence fails Regressed --> Implemented: repair returns below rollout readiness ``` 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 ```mermaid journey title From V3 experience to supported rollout section Orient Choose member tenant creator or operator path: 5: Reader Pair feature promise with architecture boundary: 5: Product, Engineering section Trace Follow client routing identity and world authority: 5: Engineering Inspect asset rights consent and durable data: 5: Governance, Engineering section Verify Run tier platform accessibility and reconnect journeys: 5: QA Inspect capacity provider and regional evidence: 5: SRE, Release section Roll out Certify gated cohort and rollback path: 5: Release Update docs atlas runbooks and evidence: 5: Owners ``` ### Product and experience design Use the [feature index](../features/README.md) 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](../architecture/README.md) 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](../features/README.md) — 16 focused topics across product orientation, metaverse platform, Tara, Saraswati, Commons/creation, and trust/commerce/quality/operations. - [Architecture index](../architecture/README.md) — 16 focused topics across client tiers, realtime, embodiment, tenant experiences, authoring/data/V1 integration, trust, commerce, and launch. - [Lilith handbook](./lilith/README.md) — eight cross-cutting identity/product topics that prevent the Lilith names from being conflated. - [V3 diagram atlas](./diagram-atlas.md) — 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.