V6 — Dependency Registry (Egbe: The Agentic Companion Universe)

Scope: Dependencies that V6 launch depends on — Unreal Engine 5.5 LTS and its plugins, the agent-cognition model stack, the Vac voice stack, Pixel Streaming infrastructure, the V3 metaverse substrate reused wholesale, the V1 foundations reused, data stores, cloud / infrastructure, language runtimes, build tooling, and the cross-game Aye Bridge dependencies. This file also carries the canonical AI cost-budget figures that V6_ARCHITECTURE.md and V6_TODOS.md §36 defer here. Out-of-V6 dependencies are catalogued in the whole-monorepo /DEPENDENCIES.md and in V1/DEPENDENCIES.md. Companion docs: V6/V6_features.md, V6/V6_TODOS.md, V6/V6_ARCHITECTURE.md. Date: 2026-05-21

Purpose#

This file is the V6-scoped dependency contract. For each dependency it answers three questions a reviewer needs before launch:

1. What is it — one sentence on the dependency itself.
2. Where does V6 use it — the V6 features / TODOS / architecture sections that need it.
3. How is it wired — package paths, version source, env vars where relevant.

Pinned versions live in V6/ue/V6.uproject, each plugin's *.uplugin, each *.Build.cs, the per-platform configs in V6/ue/Config/, pnpm-workspace.yaml (TypeScript), each Rust service's Cargo.toml, and the per-service Docker compose files. This document references those sources of truth rather than duplicating them.

Cross-Reference Convention#

Throughout the V6 docs, bare §N and §N.M references resolve to V6_TODOS.md (the canonical backlog). Within this file, bare numeric references (e.g., §14, §19) point to this document's own sections. Explicit doc prefixes are used where ambiguity matters:

• todos§40 → V6_TODOS.md §40.
• arch§"<anchor>" → V6_ARCHITECTURE.md by section anchor.
• features§"<anchor>" → V6_features.md by section anchor.
• v1deps§N → V1/DEPENDENCIES.md §N (V1 dependencies reused as-is).
• v3deps§N → V3/V3_DEPENDENCIES.md §N (metaverse-substrate dependencies V6 reuses); v2deps§N → V2/V2_DEPENDENCIES.md §N (shared UE5 patterns).

Table of Contents#

1. Internal Packages — V6 Modules
2. Internal Packages — V1 Foundations Reused
3. Internal Packages — V3 Metaverse Substrate Reused
4. UE5 Engine Version
5. UE5 First-Party Plugins
6. UE5 Third-Party Plugins
7. Pixel Streaming Infrastructure
8. Application Runtimes
9. Backend Frameworks (Services)
10. Web Shell + Pixel Streaming Player
11. Tier-2 Fallback Web Client Stack
12. Mobile — Steward App + UE Mobile
13. VR / AR / XR Stack
14. Generative AI — Agent Cognition Models
15. Generative AI — Voice and Speech
16. Generative AI — Agent Creation (Ninhursag Foundry)
17. Generative AI — Story Generation (Clio)
18. Embeddings and Agent Memory
19. AI Cost Budget and Fidelity Tiering
20. Multiplayer Networking and SFU
21. Physics
22. Spatial Audio and DSP
23. Animation and Avatar Pipeline
24. Data Stores
25. Object Storage and CDN
26. Identity, Auth, and Provisioning
27. Payment, Billing, Commerce
28. Provenance and C2PA
29. Observability and Telemetry
30. The Aye Bridge — Cross-Game Dependencies
31. Cloud Providers and Infrastructure
32. Build, Cook, Patch (UE5)
33. CI/CD and Build Tooling
34. Source Control
35. Testing and Eval Tooling
36. Security and Secrets
37. Containerization and Local Development
38. Compliance, Age Gating, Rating Boards

1. Internal Packages — V6 Modules#

The UE5 project and the TypeScript libraries:

Rust crates under apps/v6/*/Cargo.toml and shared crates under libs/v6/*:

2. Internal Packages — V1 Foundations Reused#

V6 reuses V1's foundational packages without duplication. See v1deps for the full registry; the V6-critical-path entries:

3. Internal Packages — V3 Metaverse Substrate Reused#

V6 reuses the V3 Lilith metaverse substrate rather than rebuilding it (arch§"The Two Substrates"). These V3 packages are dependencies of V6:

V6 tracks V3's UE5 version and patch cadence (§4) so the substrate stays in sync.

4. UE5 Engine Version#

V6 shares the UE5.5 LTS choice with V2 and V3 (v2deps§1, v3deps§3). Sharing the engine version simplifies the toolchain, plugin compatibility, and shared patch / hotfix processes across the products.

The V6 cross-platform certification release gate reuses the V3 platform-cert posture and requires green Apple, Google, Meta, Sony, Valve, and Epic checklists for the exact V6 BuildGraph cooks before launch signoff.

The V6 cross-progression continuity gate depends on the Ori event log and projection store as the single source of truth. Its release manifest fails closed unless household, roster, reputation, and homestead state stay portable across client surfaces without introducing platform-local saves.

5. UE5 First-Party Plugins#

Enabled in V6/ue/V6.uproject. V6 reuses the V3 plugin set (v3deps§4) and adds the Mass framework, which is central to V6's agent-density architecture.

The UE-side V6Tests CI gate uses UnrealEditor-Cmd in null-RHI mode to run the foundation spec, the Gauntlet driver contract, and the golden-replay harness from the V6Tests module on the self-hosted Unreal runner.

6. UE5 Third-Party Plugins#

Third-party plugin decisions track v3deps§5; V6 introduces no third-party UE plugin V3 did not already vet.

7. Pixel Streaming Infrastructure#

V6 reuses the V3 Pixel Streaming infrastructure wholesale (v3deps§6): the UE Pixel Streaming Signalling Server per POP, the Rust matchmaker / relay (apps/v6/egbe-pxstream-relay/), WebRTC transport (H.264 broad / AV1 modern), and the pooled UE worker processes (one process per concurrent browser session). V6-specific note: an Orun ground is agent-dense, so a Pixel Streaming worker is sized lower than a V3 venue worker — see §19 and arch§"Pixel Streaming Infrastructure".

8. Application Runtimes#

9. Backend Frameworks (Services)#

10. Web Shell + Pixel Streaming Player#

11. Tier-2 Fallback Web Client Stack#

V6 reuses the V3 Tier-2 stack (v3deps§11):

12. Mobile — Steward App + UE Mobile#

13. VR / AR / XR Stack#

V6 reuses the V3 XR stack (v3deps§13): OpenXR for Quest 3, Vision Pro, PSVR 2, and SteamVR; UE hand-tracking and full-body IK; foveated rendering where supported; the V3 VR comfort framework. No V6-specific XR SDK is added.

14. Generative AI — Agent Cognition Models#

The agent mind is assembled from V1 substrates and adds no new model infrastructure; cognition calls route through @oshun/embodiment-psyche and the V1 model-ops control plane, governed by Isis. The Moirai kernel right-sizes the model to the tier (arch§"AI Cost and Fidelity Tiering").

[P2] Distilled / fine-tuned variants for the high-volume Lachesis and Atropos tiers are a Year-1 cost optimisation; the launch path uses the model classes above. Any model change re-runs the §35 eval gates.

15. Generative AI — Voice and Speech#

The Vac pipeline (features§"Communication — The Vac Layer", arch§"The Vac Communication Pipeline"):

ASR and TTS run server-side at the gateway, not as UE plugins, so the Tier-2 fallback and the Steward App get identical voice capability. Provider selection and residency follow the V1 voice-provider posture; agent voices are governed by Isis (no real-person voice cloning — features§"Governance, Safety, and Trust").

16. Generative AI — Agent Creation (Ninhursag Foundry)#

Foundry generation is one-time per agent (a heavy Opus-class call) and is not on the per-tick cognition budget of §19.

The Ninhursag foundry readiness verifier (verify:v6 ninhursag-foundry-readiness) is backed by V6/release/ninhursag-foundry-readiness.v6release.json and pins the §14 discovery-seed pool at 150 grounded Wilds/Commons agents, plus player raising, rearing-period, and provenance evidence in egbe-foundry-service.

17. Generative AI — Story Generation (Clio)#

The returning-player Chronicle has a few-second latency budget (§19, §42 in TODOS); bulk Book generation is fully batched and not latency-critical.

18. Embeddings and Agent Memory#

Memory retrieval for a cognition call is a recency-and-salience-weighted vector query; embedding model selection follows the V1 Iris posture.

19. AI Cost Budget and Fidelity Tiering#

This section is the canonical cost-budget source that arch§"AI Cost and Fidelity Tiering" and todos§36 defer to. The hard architectural contract is the per-tier token budget and the concurrency caps; the dollar figure floats with provider pricing and is tracked live on the model-ops cost dashboard.

Per-tier token budget (input + output combined, per agent; launch targets):

Concurrency caps:

Model routing — Clotho → Opus-class, Lachesis → Sonnet-class, Atropos + Vac → Haiku-class (§14). Cost levers — the Moirai tiering itself, cognition caching and reuse on the Ori, cross-tier batching of Lachesis/Atropos work, model right-sizing, and Commons interest-managed cognition.

Launch DAU projection (canonical planning assumption, adopted 2026-06-12). The "launch DAU projection" that gates Moirai cost/load readiness (todos§"V6 Exit Criteria", todos§48, arch§"Launch Readiness", features§"Launch Readiness") was previously never quantified anywhere; it is quantified here as a stated planning assumption, not a market-derived forecast:

• Launch DAU: 30,000 (assumption adopted 2026-06-12), spread across the 3 launch regions of the sustained-load manifest (V6/performance/sustained-load.v6perf.json: region:iad, region:fra, region:sin) ≈ 10,000 DAU per region.
• Peak concurrency: 10% of a region's DAU online at peak ≈ 1,000 concurrently active players per region (assumption).
• Agents per concurrently active player: ≈ 10.2 (≈ 10 Lachesis-resident + 0.2 Clotho-active). Rationale from the docs' own numbers: a steward's bonded household at the intended "a company you can know" scale (features§"The Household Roster") keeps ≈ 10 agents at Lachesis-or-better fidelity per active player at any instant, and live Clotho dialogue is active for roughly 1 in 5 concurrent players — 200 Clotho per region ≈ 13 full active scenes at the ≤ 16-per-scene design target (the sustained-load manifest's clothoActiveSceneCount: 13).
• Concurrently resident agents per region: ≈ 10,200 = 1,000 players × 10.2 — i.e. exactly the fixed per-region mix the §42 load test exercises (10,000 Lachesis + 200 Clotho). Equivalently, 10,000 Lachesis per region supports ≈ 25–66 fully resident Solo worlds at the 150–400-per-world design range; the per-player decomposition reflects peak-hour mixing across Solo, Co-op, and the interest-managed Commons, where most concurrent players do not have a fully resident 150–400-agent world at the same instant.

If launch marketing or beta telemetry produces a real forecast above 30,000 DAU, the per-region mix and the §42 load tests must be re-derived from this arithmetic before the Moirai readiness gate may be considered meaningful.

Cost gate. A V6 release is blocked if a change exceeds a per-tier token budget above when measured against staging telemetry (todos§36, todos§41). The blended dollar cost per player-active-hour is a tracked dashboard metric, not a fixed constant — the token budgets are the contract that keeps it bounded. The Moirai cost/load readiness verifier (verify:v6 moirai-cost-load-readiness) is backed by V6/release/moirai-cost-load-readiness.v6release.json and aggregates the §8, §9, §36, and §42 evidence before launch.

20. Multiplayer Networking and SFU#

The Vac communication readiness verifier (verify:v6 vac-communication-readiness) is backed by V6/release/vac-communication-readiness.v6release.json and aggregates the §20 voice-to-intent, intent grammar, conversation, squad-comms, and negotiation gates with the §39 no-microphone and transcript accessibility gates.

21. Physics#

22. Spatial Audio and DSP#

V6 reuses the V3 spatial-audio stack (v3deps§22): MetaSounds + Steam Audio in the canonical client, Web Audio + WASM HRTF in the Tier-2 fallback, the @oshun/spatial-audio runtime. V6 adds no new audio middleware.

23. Animation and Avatar Pipeline#

V6 reuses the V3 avatar and animation pipeline (v3deps§23, v3deps§25): VRM 1.0 import via VRM4U, MetaHuman avatars, rig retarget, costume slots, motion matching. V6-specific additions are content, not new dependencies: emotion-driven gait/posture/expression and visible life-stage aging marks (arch§"Avatar and Animation Pipeline").

24. Data Stores#

25. Object Storage and CDN#

26. Identity, Auth, and Provisioning#

V6 reuses the V1 identity stack (v1deps): V1 OAuth and account, @oshun/identity RBAC (V6 adds steward and operator scopes), @oshun/auth-primitives JWT extended with steward and shard claims. The V3 embodied-identity bridge pattern is reused for the account ↔ UE session binding.

27. Payment, Billing, Commerce#

V6 reuses the Aje crypto-payment substrate (libs/aje/*) and the V1 billing stack for the base purchase, cosmetic / expansion content, Egbe Studio capacity, and Yemaya keepsake editions, and for routing creator royalties. No agent, bond, fate, or capability is ever a purchasable SKU; there is no gacha or loot-box dependency (features§"Commerce and Rights").

28. Provenance and C2PA#

V6 reuses the V1/V3 provenance stack (v3deps§30): Isis-signed provenance bundles on every Ori, every generated artifact, and every incarnation journal; C2PA manifests on exported media (Chronicle reels, Book editions); the V3 takedown cascade.

29. Observability and Telemetry#

All telemetry honours V1 consent and residency; player conversation content is governed by Iris boundaries and excluded from training without explicit consent.

30. The Aye Bridge — Cross-Game Dependencies#

The meta-hub (features§"The Meta-Hub — Incarnation in Aye", arch§"The Aye Bridge"). V6 depends on the four destination realms only through the bridge's per-destination adapters and the passport / journal envelope:

Each adapter is versioned against its destination realm's contract; an Aye realm that is not itself live simply has its Threshold disabled. There is no other coupling between V6 and V2–V5.

31. Cloud Providers and Infrastructure#

32. Build, Cook, Patch (UE5)#

V6 reuses the V3 UE5 build/cook/patch pipeline (v3deps§35): per-platform cooks of V6/ue/ via BuildGraph, the headless server-rendered Pixel Streaming worker cook, Game Feature Plugins included/excluded per platform/region, day-one patch and hotfix paths. Contracts in libs/contracts/src/v6/ codegen UE C++, Rust, and TS bindings as a pre-build step.

33. CI/CD and Build Tooling#

34. Source Control#

Git, the git@github.com:GreyChimp/oshun.git monorepo. UE binary assets under V6/ue/Content/ use Git LFS, consistent with V2/V3. The V6 UE plugin surface also carries the VRM4U submodule at V6/ue/Plugins/VRM4U; .gitmodules pins the upstream URL and shallow = true so CI clones the plugin contract without pulling full history.

35. Testing and Eval Tooling#

The Rust coverage gate (verify:v6 rust-coverage-gates) is backed by V6/testing/rust-coverage-gates.v6qa.json and pins the named cargo packages, required test functions, and the adjacent Aye/Vac release gates.

The Browser automation gate (verify:v6 browser-automation) is backed by V6/testing/browser-automation-gates.v6qa.json and pins the Pixel Streaming, Tier-2 fallback, egbe-steward-app-browser, and Egbe Studio Playwright specs.

The operator runbook gate (verify:v6 operator-runbooks) is backed by V6/release/operator-runbooks.v6release.json and pins the five on-call-ready V6 operator procedures under docs/runbooks/v6-*.md.

The production setup/manual-QA gate (verify:v6 production-setup-manual-qa) is backed by V6/release/production-setup-manual-qa.v6release.json and pins the new-environment bootstrap runbook plus the manual signoff recipes.

The docs drift gate (verify:v6 docs-drift) is backed by V6/release/docs-drift.v6release.json and checks shipped behavior contracts, canonical V6 doc coverage, source-control submodule claims, and cross-doc anchors across the feature, architecture, and dependency docs.

The Orun shard/district readiness gate (verify:v6 orun-shard-district-readiness) is backed by V6/release/orun-shard-district-readiness.v6release.json and aggregates the §21 shard-continuum gates, the §22 Commons gates, the §28 district scene promotion gates, the district Game Feature manifests, and the Solo / Co-op / Commons shard-mode plugins.

The Ninhursag foundry readiness gate (verify:v6 ninhursag-foundry-readiness) is backed by V6/release/ninhursag-foundry-readiness.v6release.json and aggregates the §14 foundry-service evidence, the 150 grounded Wilds/Commons launch seed pool, Grove/Wilds scene bindings, foundry provenance, and the Egbe foundry operator gates.

The Moirai cost/load readiness gate (verify:v6 moirai-cost-load-readiness) is backed by V6/release/moirai-cost-load-readiness.v6release.json and aggregates the §8 tier-assignment and escalation-rehydration coverage, the §9 Clotho / Lachesis / Atropos tier evidence, the §36 staging cost-budget harness, and the §42 sustained-load and Commons-scale load manifests.

The Vac communication readiness gate (verify:v6 vac-communication-readiness) is backed by V6/release/vac-communication-readiness.v6release.json and aggregates the §20 voice-to-intent, constrained grammar, conversation routing, squad-comms, and negotiation gates with the §39 no-microphone and transcript accessibility gates.

The Fate, legacy, and Clio readiness gate (verify:v6 fate-legacy-clio-readiness) is backed by V6/release/fate-legacy-clio-readiness.v6release.json and aggregates the §24 objective, goal-arc, life-arc, and Crossroads gates, the §25 Ereshkigal departure, transcendence, death, and Ancestor Grove gates, and the §26 Clio Chronicle, emergent-arc, Book of the Ori, and narrative-reconciliation gates.

The Aye Threshold readiness gate (verify:v6 aye-threshold-readiness) is backed by V6/release/aye-threshold-readiness.v6release.json and aggregates the §27 Aye Bridge gates for passport minting, destination adapters, incarnation journals, round-trip integrity, and incarnation governance with the Threshold district contract, integration-tested against per-destination adapters and realm stubs. It does not prove V2, V3, V4, or V5 is an operational live realm — production liveness of each destination realm is an external dependency tracked outside V6 and re-verified at each realm's GA (as of 2026-06-12 none of V2–V5 is live, per the in-repo V2/V4/V5 audits).

The Governance/safety/operator readiness gate (verify:v6 governance-safety-operator-readiness) is backed by V6/release/governance-safety-operator-readiness.v6release.json and aggregates the §30 operator surfaces, §31-§33 safety and welfare policy, §34 reporting / review / Themis routes, the operator runbooks, and the §41 behavior, consistency, safety, telemetry, and release-gate evidence.

The Accessibility/localization/security/cert/region rollout readiness verifier (verify:v6 accessibility-localization-security-cert-readiness) is backed by V6/release/accessibility-localization-security-cert-readiness.v6release.json and aggregates the §39 accessibility gates, §40 localization / region-rating / residency posture, §44 security/privacy/compliance gates, and §45 certification and cross-progression continuity evidence.

The V6 exit criteria readiness verifier (verify:v6 exit-criteria-readiness) is backed by V6/release/v6-exit-criteria-readiness.v6release.json and closes the release checklist by ignoring fenced example checkboxes, requiring every real task checkbox in V6_TODOS.md to be checked, and aggregating the production setup, docs drift, Orun, Ninhursag, Moirai, Vac, Fate/Clio, Aye, governance/safety/operator, and accessibility/localization/security/cert readiness gates.

36. Security and Secrets#

V6 reuses the V1 security posture (v1deps): the V1 secrets manager, the audit platform on every operator action and Ori read, cargo audit and dependency scanning in CI. The Aye Bridge passport is minimised to the destination realm's need; cognition-call logs are retained under the V1 retention policy. The Pixel Streaming relay reuses the V3 abuse-posture release gate and exposes the V6 admission-evaluation path before any browser session receives a worker lease.

37. Containerization and Local Development#

Local development brings up the V6 stack via the compose overlay; the UE5 client connects to the local world server, and the Moirai cluster can run against a development model endpoint per the V1 model-ops dev posture.

38. Compliance, Age Gating, Rating Boards#

V6 reuses the V1/V3 compliance stack: GDPR / CCPA / DSA / DSAR and data-portability (Ori export, consent scoping, retention), age gating and the minor-protection mode (todos§33), and region rating-board submissions per shipped locale. The Ori event log is consent-scoped and residency-tagged; generated agent content carries provenance for rating and takedown.