# Oshun: whole-monorepo Rust migration audit
**Date:** 7 September 2026
**Audited source:** `a55b2610459a777d86cc4683acf564e901cece5c`
**Decision context:** A substantial rewrite is acceptable. Recommendations
prioritize the intended long-term architecture over minimizing rewrite cost.
**Deliverable:** Architecture and migration assessment; no application migration
is implemented by this report.
## 1. My recommendation
**Make Rust Oshun’s default language for owned backend services, durable
workflows, domain computation, local engines, native daemons, and
performance-sensitive shared libraries. Keep the languages that own the relevant
platform or ecosystem.**
Your proposed split is broadly right, but it needs several additions:
- **TypeScript:** browser UI, React, Next.js rendering, React Native UI, browser
extensions, editor integrations, and JavaScript tooling that must run in its
host. Some small web-specific server adapters can remain TypeScript.
- **Kotlin:** native Android UI, Android services, permissions, notifications,
platform integrations, and Wear OS. Put reusable domain logic below those
interfaces in Rust.
- **Swift:** native Apple UI and platform integrations across iOS, macOS,
watchOS, and other Apple surfaces. Again, reusable logic can live in Rust.
- **Python:** model research, training, fine-tuning, scientific exploration,
notebooks, ComfyUI nodes, and adapters for Python-hosted tools. Move ordinary
Python service orchestration and business rules to Rust; do not confuse those
with the model ecosystem itself.
- **C++ and a little C:** Unreal integration, engine/plugin ABI boundaries,
vendor libraries, selected hardware interfaces, and specialized native/GPU
interoperability. Rust can own more of the underlying computation without
requiring Unreal to become a Rust engine.
- **C#:** Unity integration and Unreal’s C# build rules. Those files exist
because their hosts require them.
- **Solidity:** existing EVM smart contracts. Rust backend services do not
replace the execution language of those contracts.
- **SQL, shader languages, infrastructure definitions, and small shell
scripts:** keep these in their native representations. They are not language
sprawl to eliminate.
**I would not add Go, Java, Dart, Elixir, Zig, Julia, or another general-purpose
application language as a new platform default.** Keep a language-specific
public SDK when customers need it. Keep specialist scientific or vendor code
behind a boundary when it is useful. Neither exception requires using that
language for Oshun’s own backend.
The preferred result is a **Rust-centered polyglot platform**, with thin
platform shells and deliberate boundaries. The success measure should be how
much authoritative behavior Rust owns, how reliable the products are, and how
well the code is reused—not the percentage of files ending in `.rs`.
### The expensive rewrites I would actually approve
1. Replace most first-party TypeScript and ordinary Python backend execution
with Rust.
2. Extract canonical domain rules from the main BFF, shared contract
implementations, and large agent packages into cohesive Rust libraries.
3. Consolidate overlapping implementations in Neith, Maya, Euterpe, Oya, and the
V-series around explicit owners and conformance tests.
4. Introduce a common Rust service, persistence, workflow, telemetry, and
release foundation.
5. Move shared offline/local computation into Rust libraries used by desktop,
native mobile, and selected browser WASM clients.
6. Prefer native Kotlin/Swift for flagship mobile experiences where platform
integration is central; decide that per product, independently of the backend
rewrite.
7. Replace Yemaya’s Electron host with a Rust/Tauri host if its required desktop
behavior passes a concrete compatibility suite.
I would **not** make replacement of Unreal, PyTorch, ComfyUI, browser rendering,
or vendor GPU libraries a prerequisite for this migration. Building replacements
for those systems is a separate product and research program, even with a large
budget. It can be pursued deliberately, but it should not hold the backend
architecture hostage.
## 2. Scope, method, and limits of the audit
This is a whole-tree inventory plus a focused source-level architectural audit.
It covers all tracked paths, all discovered JSON/TOML project manifests, all 48
registered domains, the platform groups, application groups, V1–V10, SDKs,
native integrations, infrastructure, and verification configuration.
The inventory used `git ls-files`, not an unrestricted filesystem walk. This
excludes untracked dependency installs and local build products. It parsed every
tracked `package.json`, `project.json`, `Cargo.toml`, and `pyproject.toml`;
categorized source by extension; counted physical lines; inspected declared
dependencies and targets; and grouped results by directory and nearest explicit
Nx project.
The source review followed representative entrypoints and boundaries: BFF
startup and assistant execution, durable run/effect contracts, contract-derived
persistence, queues/events, Python services and model packages, Rust service
entrypoints, desktop and FFI integrations, audio/WASM, robotics, and CI. The
domain-by-domain recommendations combine those findings with each domain’s
source inventory and registry description. **They are not a claim that every
function in every domain was manually reviewed.**
The tree contains tens of millions of physical source lines. An architectural
audit can cover its structure comprehensively without claiming a line-by-line
security review, mathematical correctness certification, hardware qualification,
or production readiness assessment of every implementation.
### What the measurements mean
- **Physical lines** include comments, blanks, tests, declaration files, and
source-like fixtures. They are not semantic lines of code or effort estimates.
- An additional heuristic separates paths resembling tests, generated files,
vendor/build directories, and documentation/evidence. It is useful for
screening, not a reliable production-code census.
- Rust frequently embeds tests in ordinary source files. Those tests remain in
the “non-test-path” count. Comparing that number directly with TypeScript’s
separate test files would mislead.
- Package dependencies are declarations, not observed runtime imports. A package
can be unused, indirectly consumed, or loaded through a native boundary.
- Explicit `project.json` counts are **not** the complete inferred Nx graph and
are **not** deployable counts.
- A Cargo manifest can be a workspace root rather than a package. A package, a
workspace member, an Nx project, and a service are different units.
- Historical verification records were used to understand the test portfolio;
their pass counts were not credited as fresh results.
- No credentials, private environment files, live databases, or external
production accounts were needed for this audit.
Git submodule entries are inventoried as pointers; their external contents,
engine installations, model weights, and untracked local files are not
recursively audited.
The accompanying [evidence bundle](rust-migration-2026-09-07/README.md) contains
the reproducible inventory program, summary, complete project and Cargo
catalogs, and verification receipts. Recommendations below are engineering
judgments; measurements and demonstrated source behavior are identified
separately.
## 3. Measured state of the repository
### 3.1 Repository and build structure
| Measurement | Observed value |
| -------------------------------------------- | -------------: |
| Tracked paths at the audited revision | 143,396 |
| Files with a recognized source/DSL extension | 103,082 |
| Physical lines across those files | 45,801,902 |
| Explicit `project.json` files | 3,505 |
| `package.json` files | 3,324 |
| `Cargo.toml` files | 953 |
| Cargo manifests declaring a package | 938 |
| Manifests containing a `[workspace]` table | 18 |
| Tracked `Cargo.lock` files | 94 |
| `pyproject.toml` files | 83 |
| Swift package manifests | 6 |
| Go module manifests | 3 |
| `.csproj` files | 2 |
| Unreal `.uproject` files | 8 |
| Prisma schema files | 16 |
| Protobuf source files | 48 |
| Filenames containing `Dockerfile` | 160 |
| Filenames containing `playwright.config` | 61 |
| Filenames containing `vitest.config` | 2,716 |
| Registered domain entries | 48 |
All enumerated JSON/TOML project manifests parsed successfully. The inventory
found no missing local Cargo dependency manifest among directly declared package
dependency paths. That is a limited structural result; it does not establish
that dependencies resolve, workspaces admit every package, or code compiles.
The root remains a Node/pnpm/Nx workspace. Its manifest specifies `pnpm@10.25.0`
and Node `>=22.0.0`. There is no root Cargo workspace. Rust is organized into
several domain/product workspaces plus standalone or explicitly isolated
packages. See [root package configuration](../../package.json),
[Nx configuration](../../nx.json), and
[workspace package configuration](../../pnpm-workspace.yaml).
### 3.2 Languages
| Language or representation | Files | Physical lines | Architectural interpretation |
| --------------------------------- | -----: | -------------: | ------------------------------------------------------------------------- |
| TypeScript, including TSX/MTS/CTS | 79,857 | 36,763,420 | UI, server behavior, domain algorithms, contracts, tests, tooling |
| Rust | 9,306 | 4,316,485 | Large existing engine/core portfolio; smaller service and binding surface |
| Python | 4,759 | 1,683,876 | Significant services as well as model/scientific code and tools |
| JavaScript, including MJS/CJS | 4,477 | 1,597,923 | Tooling, scripts, configuration, tests, runtime modules |
| C++ sources and `.hpp` headers | 1,731 | 646,249 | Unreal and native integrations |
| C/C++ headers | 1,140 | 289,932 | Engine/native interfaces; not all attributable to C++ by extension alone |
| CSS | 446 | 207,366 | Browser presentation |
| Terraform HCL | 223 | 52,949 | Infrastructure definitions |
| SQL | 206 | 45,352 | Storage definitions, queries, migration history |
| Solidity | 77 | 40,640 | EVM contracts, including tests |
| Kotlin | 118 | 39,015 | Android/native integrations and tests |
| Shell | 197 | 37,329 | Build, deployment, and verification glue |
| Swift | 91 | 23,407 | Apple/native integrations |
| Protobuf | 48 | 18,385 | Wire definitions |
| Java | 71 | 17,044 | Existing Android code and SDKs |
| C# | 269 | 13,859 | Predominantly Unreal build rules, plus Unity and SDK code |
| Objective-C | 13 | 3,585 | Apple/React Native integration |
| C | 4 | 1,781 | Small native integration surface |
| Go | 8 | 1,066 | One self-hosted server and SDK surfaces |
| WGSL | 19 | 1,047 | GPU shaders |
| Kotlin build DSL | 16 | 903 | Gradle configuration |
| Lean | 1 | 147 | A targeted formal-verification artifact |
| Unreal shader source | 1 | 89 | Engine shader source |
| Lua | 4 | 53 | Small embedded integration surface |
There were no tracked `.cu` files in this snapshot. CUDA belongs in the
exception policy because of the model/GPU ecosystem, not because this inventory
found a large owned CUDA codebase.
The heuristic leaves 23,970,549 TypeScript physical lines outside identified
test paths and excluded/generated indicators. **Do not turn that number into a
rewrite quote.** It still includes comments, wrappers, data, mixed-purpose
libraries, and potentially redundant behavior. First classify capabilities and
reachable product paths.
### 3.3 Rust is already substantial, but concentrated
| Area | Cargo manifests | Rust files in `libs/` | Rust physical lines in `libs/` |
| ------- | --------------: | --------------------------: | -----------------------------------: |
| Neith | 603 | 7,024 | 2,496,895 |
| Maya | 154 | 1,452 | 1,312,876 |
| Galatea | 54 | 118 | 35,127 |
| Kalika | 41 | 205 | 142,595 |
| Oya | 24 | 231 | 125,418 |
| Euterpe | 8 | 62 | 26,818 |
| Iris | 8 | 24 | 5,788 |
| Uzume | 7 | 8 | 18,059 |
Neith and Maya together account for roughly **88% of tracked Rust physical
lines**. The migration is therefore partly a matter of making Rust authoritative
across the product, rather than introducing Rust for the first time.
Examples already available to reuse include:
- [Neith’s 600-member umbrella workspace](../../libs/neith/Cargo.toml).
- [Maya’s 86-member engine workspace](../../libs/maya/engine-core/Cargo.toml).
- [Oya’s Rust workspace](../../libs/oya/Cargo.toml), Node/WASM bridges, and
[differential comparator](../../libs/oya/engine/parity/check.mjs).
- [Euterpe’s DSP WASM interface](../../libs/euterpe/audio-engine/crates/dsp-wasm/src/lib.rs).
- [Kalika’s 34-member umbrella workspace](../../libs/kalika/Cargo.toml).
- [Iris’s native computer-use workspace](../../libs/iris/agents/computer-use/native/Cargo.toml).
- Existing Rust services under [V3](../../apps/v3/Cargo.toml),
[V4](../../apps/v4/Cargo.toml), [V6](../../apps/v6/Cargo.toml), and
[V7](../../apps/v7/Cargo.toml).
These are starting points, not blanket endorsements. Their integration and
release evidence must be assessed separately from their size.
### 3.4 Runtime dependencies show what must move
Across parsed package manifests, including runtime and development declarations
where present, there are 96 declarations of Fastify, 53 of Hono, 16 of NestJS,
16 of BullMQ, 66 of Drizzle, 43 of `pg`, and 13 of Prisma’s client. There are 29
Next.js declarations, 13 React Native declarations, and eight Expo declarations.
These counts overlap and are not service counts.
Python manifests declare NumPy in 40 packages, PyTorch in 28, and FastAPI in 17.
The Python portion is therefore not just scripting. For example,
[Metis’s Python service](../../apps/metis/service/pyproject.toml) combines
FastAPI, SQLAlchemy, Alembic, Redis/Celery, document processing, telemetry, and
pinned executable-mathematics dependencies. Its tree contains 1,428 Python
files.
Rust has substantial serialization/error-handling adoption, while Axum is
directly named in only four Cargo package manifests and SQLx in one.
Dependencies inherited through workspace catalogs or wrappers can change that
picture, but the observed Rust portfolio is much more engine-oriented than a
unified backend service platform.
## 4. Findings that materially change the migration plan
### F1. The main BFF is a major domain execution boundary, not just an HTTP adapter
**Observed:** [BFF package configuration](../../apps/oshun/bff/package.json)
declares 184 runtime dependencies. The nearest explicit BFF project owns 665,584
physical source lines under the inventory’s method.
[Startup](../../apps/oshun/bff/src/server.ts) wires persistence, domain state,
idempotency, review/audit stores, privacy deletion, assistant services, and
cross-domain sources.
**Implication:** Replacing Fastify with Axum does not migrate the BFF’s real
responsibilities. Those dependencies must become Rust libraries, generated
clients, or explicit service calls. Otherwise the new Rust API simply proxies
into the existing TypeScript platform.
**Recommendation:** Extract bounded modules first: identity/tenant context,
content and contract persistence, review authority, durable run execution,
assistant policy, domain adapters, and presentation aggregation. Deploy ordinary
business modules together initially where that simplifies transactional
consistency. Split processes for independent scaling, hardware, security, or
failure isolation—not one service per Nx project.
### F2. The contract layer contains behavior that schemas alone cannot preserve
**Observed:**
[Durable effect identity](../../libs/contracts/src/run-protocol/durable-effect-protocol.ts)
uses Zod refinements, uniqueness/sorting rules, lineage restrictions, and
canonical digests.
[The persistence registry](../../libs/oshun/persistence/src/contract-persistence-registry.ts)
imports a broad set of executable schemas.
[The Prisma schema](../../libs/oshun/persistence/prisma/schema.prisma) is
generated from this contract/persistence machinery.
**Implication:** Generating Rust structs from JSON Schema or copying TypeScript
interfaces would drop validation and identity semantics. A changed hash, enum
spelling, timestamp precision, optional field, or default can invalidate
existing records or cause duplicate effects.
**Recommendation:** Separate structural wire definitions from executable
invariants. Establish a language-neutral fixture corpus containing accepted and
rejected inputs plus canonical serialized bytes and hashes. Port invariants into
Rust and retain independent cross-language conformance checks. Keep database
migration ownership separate from DTO generation.
### F3. Queue and event semantics need their own migration
**Observed:** [The queue](../../libs/shared/queue/src/queue.ts) wraps BullMQ and
translates priorities, retry policies, job envelopes, and retention options.
[The event bus](../../libs/shared/event-bus/src/event-bus.ts) uses Redis Pub/Sub
with TTL-bounded stored envelopes, scheduling, acknowledgements, replay, and
dead-letter behavior. The architecture document’s description of local Redis
Streams does not match this inspected implementation.
**Implication:** A Rust Redis client is not a BullMQ-compatible worker, and
ordinary Pub/Sub is not a durable workflow engine. Translating transport calls
would risk losing ordering, acknowledgement, replay, or retry guarantees.
**Recommendation:** Define one owned job/effect protocol. Bridge existing BullMQ
workers during transition; drain old jobs and scheduled/retry state before
retiring the bridge. Prefer a transactional PostgreSQL outbox plus durable
worker leases for ordinary business work. Adopt JetStream where durable
fan-out/replay materially helps, after a broker decision record. Keep Kafka
where an established stream workload justifies it. Avoid introducing three
equivalent messaging stacks during the rewrite.
BullMQ documents its Redis-based job system, while NATS distinguishes Core NATS
delivery from JetStream persistence/replay. The proposed architecture is a
choice based on those capabilities, not a claim that their delivery semantics
are interchangeable. [BullMQ](https://docs.bullmq.io/),
[JetStream](https://docs.nats.io/concepts/jetstream).
### F4. Some narrow Nx targets invoke whole Rust workspaces
**Observed:** Eighteen explicit project configurations contain the Neith
umbrella `cargo test --manifest-path libs/neith/Cargo.toml` command under
build/test screening; the same count references its umbrella release-build
command. [Neith core](../../libs/neith/core/project.json) and
[AI runtime](../../libs/neith/ai-runtime/project.json) are examples.
[Kalika CAS](../../libs/kalika/cas-engine/project.json) runs
`cargo test --workspace` from a directory beneath the Kalika umbrella.
**Implication:** A command named after one library can compile/test hundreds of
workspace members. Running many such Nx targets can duplicate scheduling and
contention, especially on this 16 GiB host.
**Recommendation:** Model Cargo package dependencies in the affected graph. Give
each target explicit package selection and correct transitive inputs; schedule
umbrella checks once. Include workspace manifests, lockfiles, toolchains, build
scripts, native sources, generated bindings, and relevant environment/tool
versions in cache keys. Cargo documents workspace defaults and explicit package
selection.
[Cargo workspace semantics](https://doc.rust-lang.org/cargo/reference/workspaces.html).
### F5. A Rust implementation is not automatically a production service
**Observed:**
[V6 world-server startup](../../apps/v6/egbe-world-server/src/lib.rs) binds a
`TcpListener`, handles connections serially, reads a 1 KiB buffer, and serves a
health response or 404 through that entrypoint. The file also contains extensive
simulation/domain logic.
[V7 Moremi](../../apps/v7/moremi-realm-server/src/lib.rs) has a broader
hand-written HTTP path with a request bound and read timeout, but still uses a
serial accept/handle loop.
**Implication:** Capability lists, domain tests, and a healthy port do not
establish a networked multiplayer service or production-grade API behavior. V6’s
inspected health entrypoint in particular must not be counted as exposing all
its library capabilities.
**Recommendation:** Standardize service hosting on a reviewed HTTP stack and
explicitly integrate the domain engine. Test concurrency, malformed/partial
requests, backpressure, disconnects, authentication, persistence, and process
restart behavior. This finding is about the inspected entrypoints; it is not a
claim about every V6/V7 runtime path or deployment.
### F6. The current verification portfolio is large, but pass labels have different meanings
**Observed:** 3,460 explicit projects declare `test`; 1,323 declare `typecheck`;
other names also exist. The BFF’s explicit `e2e` target prints a scaffold
message, despite real route/contract tests elsewhere. There are 249 project
`test` target configurations containing `passWithNoTests`.
[Typecheck documentation](../../tools/typecheck/README.md) explicitly says a
passing baseline ratchet can retain known app errors and exclude located
dependency errors.
**Implication:** Neither target presence nor a green task label proves migration
parity. This does not imply those projects have no tests: it means actual
discovered tests and assertions must be recorded.
**Recommendation:** Carry forward existing suites, add black-box tests against
each old/new implementation, and require nonzero expected discovery. Label
evidence as unit, contract, database integration, browser/native E2E, real
provider, engine, hardware, or live operation. The repository already applies
this distinction in its
[historical test-coherence record](../../evidence/v1-v9/AUD-007/test-coherence.generated.md);
extend it to the Rust program.
### F7. Toolchain and supply-chain policy is uneven
**Observed:** 460 tracked Rust toolchain files select `stable`; two select
`1.85.0`; one selects `1.95.0`. Rust security audit actions appear in V3 and V6
workflows. The broader
[dependency security workflow](../../.github/workflows/security-deps-and-secrets.yml)
gates pnpm findings and secrets while making its OSV cross-check informational.
**Implication:** Replacing npm packages does not automatically produce pinned or
comprehensively audited native artifacts. Native dependencies, platform
libraries, build scripts, and shipped binaries add their own release
obligations.
**Recommendation:** Pin a reviewed compiler per supported release lane; define
an MSRV separately; use committed lockfiles for shipping workspaces; add a
complete lockfile-to-release-artifact inventory with enforced Rust
advisory/license checks, SBOMs, signatures, and symbol retention. Verify which
existing pipelines already provide each piece before adding another scanner.
This is a coverage/configuration finding, not a discovered vulnerability report.
### F8. Public SDK languages and host-required files must not be counted as failed migration
**Observed:** Go is only eight source files: the
[Neith self-hosted blob server](../../libs/neith/vault-selfhost/server.go) and
SDK surfaces. Solidity lives under
[Lilith contracts](../../apps/lilith/contracts). C# includes Unreal
`Build.cs`/`Target.cs` and [Unity integration](../../libs/bellona/unity-agent).
Apple/Android interfaces already exist in applications, wearables, and SDKs.
**Recommendation:** Port the owned Go server to Rust if consolidating backend
operations is the objective. Retain Go/Python/C#/Swift/Kotlin/TypeScript SDKs
according to users’ needs. Preserve host build rules and blockchain contracts.
Language policy should distinguish owned runtime implementation from
consumer-facing bindings.
### F9. Nine existing Rust manifests fail workspace discovery
**Demonstrated:** A serial sweep ran the following command against all 953
tracked manifests with installed Cargo 1.96.1:
```sh
cargo +stable metadata --offline --locked --no-deps --format-version=1 --manifest-path
```
**944 succeeded; nine exited 101** because the package believes it belongs to an
enclosing workspace but is not a member:
| Failing manifest | Enclosing workspace |
| ------------------------------------------------------------------- | ------------------- |
| `libs/euterpe/instrument/Cargo.toml` | `libs/euterpe` |
| `libs/kalika/crystallography/rust/Cargo.toml` | `libs/kalika` |
| `libs/kalika/experiment-orchestration/rust/Cargo.toml` | `libs/kalika` |
| `libs/kalika/functional-materials-rs/Cargo.toml` | `libs/kalika` |
| `libs/kalika/materials-platform/crate/Cargo.toml` | `libs/kalika` |
| `libs/kalika/research-ops/rust/Cargo.toml` | `libs/kalika` |
| `libs/kalika/thermodynamics-rs/Cargo.toml` | `libs/kalika` |
| `libs/neith/crash-telemetry/validation/sentry-reference/Cargo.toml` | `libs/neith` |
| `libs/neith/stream-client/native/Cargo.toml` | `libs/neith` |
**Recommendation:** Decide membership deliberately. Production crates should
normally join their intended workspace; independent reference/validation tools
may be explicitly excluded and isolated. Re-run metadata for every manifest,
then targeted compilation/tests. Do not indiscriminately add everything to the
umbrella: validation fixtures may intentionally need different dependencies.
The [metadata receipt](rust-migration-2026-09-07/cargo-metadata.json) records
every result. `--no-deps` checks manifest/workspace structure; it does **not**
verify resolved dependency graphs, lockfile completeness, MSRV compatibility,
linking, or runtime behavior. The `+stable` override intentionally avoids
downloading hundreds of directory-local toolchains and therefore does not test
those pins. Successful metadata calls resolved 150 distinct roots, including
standalone packages; this is different from the 18 explicitly declared workspace
tables. Repeated warnings also identified ignored profile settings in non-root
manifests; release optimization settings must be verified at their effective
workspace root.
## 5. Target language policy
### 5.1 Where Rust should become authoritative
| Layer | Target | What remains outside Rust |
| -------------------------------------------- | --------------------------------- | --------------------------------------------------------------------- |
| Domain rules and reusable computation | Rust libraries | UI-specific formatting and interaction state |
| HTTP APIs and background workers | Rust | Narrow web-host adapters; temporary migration bridges |
| Long-running assistant/workflow execution | Rust | Model runtimes, prompts/data, provider-specific temporary adapters |
| Persistence, transactions, outbox, leases | Rust plus SQL | Existing migration history and database engine |
| Real-time simulation and state replication | Rust where engine-independent | Unreal lifecycle/reflection/replication adapters where still required |
| Audio DSP, asset pipelines, geometry, codecs | Rust for owned algorithms | Vendor codec/SDK and platform audio boundaries |
| Native desktop processes and local services | Rust | Platform UI and OS-specific adapters |
| Browser compute | Rust compiled to WASM when useful | TypeScript UI, DOM, web platform glue, worker/worklet setup |
| Native mobile shared core | Rust | Kotlin/Swift platform lifecycle and UI |
| Robot/fleet logic and supported firmware | Rust | Vendor HAL, certified controller interfaces, device tooling |
| Internal operational CLIs | Rust | Small shell invocations and host-specific tooling |
This is intentionally broad. Given your cost tolerance, I would not permanently
exempt ordinary CRUD, scheduling, business policy, retrieval orchestration, or
API adapters merely because TypeScript/Python are adequate. Consolidation itself
is a legitimate benefit. I would still require a coherent module boundary and
replacement tests.
### 5.2 TypeScript: keep the web ecosystem, shrink backend authority
Keep React components, Next layouts/rendering, accessibility behavior, design
tokens, CSS, browser storage integration, service workers, React Native views,
Storybook, Playwright, and host-required extension code.
A Next route handler may remain TypeScript when it handles cookies, SSR
composition, a framework callback, or a thin proxy. It should not become a
second implementation of billing, permissions, workflow recovery, scientific
algorithms, or canonical content rules. Those should execute in Rust services or
shared Rust libraries.
Do not move every frontend utility to WASM. Formatting a label, managing a
dialog, or validating a form’s presentation state does not need a native
boundary. Move substantial reusable computation: audio DSP, geometry, search
indexing, document analysis, simulation, binary parsing, and offline domain
behavior. Validate bundle size, startup time, copying costs, browser support,
and worker scheduling before claiming a performance improvement.
[wasm-bindgen guide](https://rustwasm.github.io/docs/wasm-bindgen/).
The large [workbench-kit package](../../libs/oshun/workbench-kit/package.json)
particularly needs a responsibility split. Its presentation and accessibility
components stay TypeScript. Any authoritative publication, trust, evidence, or
workflow rules mixed into that package should move below the UI boundary.
### 5.3 Native mobile versus React Native
**My preference, with rewrite cost accepted:** use Kotlin/Compose and
Swift/SwiftUI for flagship mobile products whose quality depends on deep
platform behavior—voice/capture, background execution, offline data, media
playback, wearables, device control, and extensive accessibility. This is a
product-engineering preference, not a measured finding that the existing React
Native apps are inadequate.
For content-oriented companion apps and admin utilities, React Native remains a
reasonable permanent choice. It can use the same Rust core. Choose **one primary
UI implementation per product/platform**; do not maintain equivalent React
Native, SwiftUI, and Compose versions of the same screen without a specific
product reason.
A practical mobile structure is:
```text
Rust domain/local core
├── Swift binding → SwiftUI / UIKit / Apple frameworks
├── Kotlin binding → Compose / Android framework
└── React Native module boundary → TypeScript UI
```
Use generated, coarse-grained interfaces. UniFFI is a candidate for Swift/Kotlin
bindings. For React Native, its C++ TurboModule/JSI architecture requires an
appropriate wrapper; a Node-API addon is not a direct Hermes module. Verify
thread ownership, callbacks, cancellation, handle disposal, exception/panic
behavior, and app suspension on actual devices.
[UniFFI](https://mozilla.github.io/uniffi-rs/latest/),
[React Native C++ modules](https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules).
Kotlin is aligned with Android’s documented Kotlin-first approach, and SwiftUI
supports Apple’s UI platforms. These are sound platform choices; they do not
require that all business logic be implemented twice.
[Android](https://developer.android.com/kotlin/first),
[SwiftUI](https://developer.apple.com/swiftui/).
Current anchors include
[Oshun mobile automation targets](../../apps/oshun/mobile/project.json),
[Oshun wearable sources](../../apps/oshun/wearable),
[Iris mobile](../../apps/iris/mobile), and the Psyche/consumer SDKs. Preserve
existing deep links, secure storage, push tokens, purchases, offline stores, and
account recovery during any client rewrite.
### 5.4 Python: retain the model/science ecosystem, migrate ordinary services
**Keep Python permanently** for training and model research unless an individual
workload has a demonstrated replacement with the capabilities you need. Examples
include [Nous Dreamer](../../libs/nous/dreamer/pyproject.toml), other Nous
research packages, Gaia forecasting, and
[ComfyUI worker integration](../../docker/runpod/comfyui).
**Move to Rust** ordinary HTTP service hosting, tenancy, identity, rate limits,
worker scheduling, retrieval orchestration, structured ingestion, durable jobs,
and business rules.
[Psyche orchestration](../../apps/psyche/orchestrator/pyproject.toml) is a
strong candidate. Metis should be split: API/course/job/permission logic can
migrate, while its executable math/science and document/model adapters remain
isolated until replacement correctness is demonstrated.
Do not move tensor operations to Rust merely to remove the Python caller. Much
of the actual compute already executes in native libraries. PyTorch supports
both Python and C++ interfaces; that does not establish feature parity with an
arbitrary Rust framework. Keep the best-supported model backend behind a stable
protocol and evaluate exported/native inference per model.
[PyTorch frontend documentation](https://docs.pytorch.org/cppdocs/frontend).
Use process isolation for GPU workers and tools with large or conflicting
environments. Use PyO3 for local Rust computation embedded in Python when
sharing buffers and avoiding process overhead materially helps. Document
ownership, dtype/layout, device placement, and cancellation. A Python extension
may still depend on Python’s lifecycle and packaging. [PyO3](https://pyo3.rs/).
### 5.5 C++, C, shaders, and engine integration
Keep Unreal-facing `UObject`/actor/component code, reflection metadata,
Blueprint exposure, editor modules, engine callbacks, and platform integration
in C++ where required by the current engine. Move reusable simulation rules,
parsers, networking services, asset processing, and deterministic algorithms to
Rust with narrow interfaces. Epic’s documented programming model remains C++ and
Blueprint.
[Unreal’s programming model](https://dev.epicgames.com/documentation/en-us/unreal-engine/coding-in-unreal-engine-blueprint-vs-cplusplus).
For owned C++ libraries without deep Unreal/vendor coupling, Rust is a strong
rewrite destination. For mature external kernels, keep a wrapper until there is
a compelling reason to replace the kernel itself. CXX or a deliberately designed
C ABI can bridge supported boundaries; CXX does not make arbitrary Unreal APIs
directly usable from Rust. [CXX](https://cxx.rs/).
Keep WGSL, HLSL, Metal, GLSL, and CUDA where the execution platform needs them.
Rust can generate or dispatch GPU work without replacing the shader/kernel
language. NVIDIA’s CUDA programming model and C++ support are independent of
which host language orchestrates the workload.
[CUDA documentation](https://docs.nvidia.com/cuda/cuda-programming-guide/).
If you eventually want to retire Unreal for an owned Neith/Maya engine, define a
separate engine-replacement program: content import, editor workflow, rendering,
animation, networking, profiling, platform packaging, game feel, authoring
tools, and compatibility. The existence of millions of Rust lines is
insufficient evidence to retire Unreal.
### 5.6 Other languages: specific decisions
| Language | Decision | Oshun-specific reasoning |
| ---------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Go | No new owned backend default; port the small owned server if desired | `vault-selfhost` is a tractable migration; keep public Go SDKs |
| Java | Migrate owned Android implementation to Kotlin as part of native work | Keep third-party APIs and compatibility glue as required |
| C# | Keep at host boundaries | Unity integrations, public SDKs, Unreal build rules |
| Solidity | Keep for current EVM contracts | A chain/runtime decision would be needed to change this; Rust API migration is separate |
| SQL | Keep and strengthen | Explicit transactions, constraints, indexes, migration history, explain plans |
| Python | Permanent bounded exception | Research, training, scientific tools, Python plugin hosts |
| Shell | Keep small launch/build glue | Port complex long-lived orchestration to Rust CLIs where it improves reliability |
| HCL/YAML/JSON/TOML | Keep declarative infrastructure/config | Moving them into Rust adds an interpreter/generator layer without removing the underlying platform |
| TypeScript IaC/tool plugins | Keep when required or particularly useful in the host | Existing Pulumi and Nx tooling do not justify another general backend language |
| Lean | Keep targeted verification artifacts | The existing vault proof file is not a reason to make Lean a product runtime |
| Julia/R/Fortran | Allow specific research or trusted external kernels only | No need to introduce them as general-purpose platform languages |
| Zig/Dart/Elixir and similar alternatives | Do not add as a new default | They would overlap the responsibilities already assigned above |
| Lua or other plugin scripting | Keep only within an explicit host/sandbox contract | Content/plugin authoring is a different concern from trusted server implementation |
Solidity is specifically intended for smart contracts, including EVM execution.
Preserve deployed-contract compatibility and upgrade semantics rather than
treating `.sol` files as ordinary server code.
[Solidity documentation](https://docs.soliditylang.org/en/latest/).
## 6. Proposed architecture
### 6.1 Separate authoritative behavior, interfaces, and external engines
```mermaid
flowchart TD
WEB[TypeScript web and PWA]
RN[TypeScript React Native]
NATIVE[Kotlin and Swift clients]
DESKTOP[Desktop UI and Rust host]
API[Rust API and identity boundary]
DOMAIN[Rust domain modules]
RUN[Rust durable workflow and assistant runtime]
DATA[PostgreSQL, object storage, cache, outbox]
MODEL[Python model and scientific workers]
ENGINE[Unreal, DCC tools, GPU and vendor engines]
CORE[Shared Rust local and compute libraries]
WEB --> API
RN --> API
NATIVE --> API
DESKTOP --> API
API --> DOMAIN
DOMAIN --> DATA
API --> RUN
RUN --> DATA
RUN --> MODEL
RUN --> ENGINE
RUN --> DOMAIN
CORE --> WEB
CORE --> RN
CORE --> NATIVE
CORE --> DESKTOP
```
The diagram is a proposed ownership model, not a deployment graph extracted from
the repo. It deliberately allows several Rust modules to share a process.
Network boundaries should follow operational requirements; library boundaries
should follow domain ownership.
### 6.2 Rust foundations to standardize
| Concern | Recommended default | Conditions |
| ---------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| HTTP/service hosting | Tokio, Axum, Tower | Common middleware, limits, shutdown, structured errors, readiness and health |
| Serialization | Serde plus explicit schema/validation contracts | Validate invariants; do not rely only on deserialization |
| Database access | PostgreSQL with SQLx and explicit SQL | One migration owner per schema; verified transactions and query plans |
| Internal RPC | Protobuf/gRPC where justified | Add Rust generation and cross-language compatibility fixtures |
| Events/jobs | Outbox/inbox and durable leases; broker where needed | Reproduce actual ordering, replay, retry, and cancellation semantics |
| Observability | Structured tracing, metrics, trace-context propagation | Preserve existing operational dashboards and incident identifiers |
| CLI tooling | A small shared Rust CLI foundation | Versioned output and exit-code contracts |
| Native/browser compute | Runtime-neutral core plus separate adapters | Keep server, GPU, platform, and `no_std` features separable |
| Tests | Unit/property tests, differential tests, black-box integration | Hardware/browser/model/engine tests stay in their own evidence lanes |
| Build orchestration | Cargo within Rust workspaces, Nx across technologies | Model actual dependencies and avoid repeated umbrella builds |
Axum is designed around Tokio/Hyper and Tower middleware; SQLx supports
PostgreSQL and explicit checked SQL workflows. These are recommended defaults,
not claims that the existing services already use this uniform stack. Keep
chosen versions pinned and qualify them against the project’s targets.
[Axum](https://docs.rs/axum/latest/axum/),
[SQLx](https://github.com/transact-rs/sqlx).
### 6.3 Workspaces and crate boundaries
Do not create a crate for every current TypeScript package. Many packages are
feature-sized, generated, or have tight coupling to a larger capability. A
direct 3,324-package translation would preserve the fragmentation while adding
Rust compilation complexity.
Prefer a small number of deliberate workspaces: platform/services, selected
native engine families, scientific compute, embedded robotics, and externally
published SDKs where independent release requirements justify isolation. The
current workspaces can be evolved toward this model; do not nest a new root
workspace around them without a membership migration plan.
Within each domain, separate:
1. Pure types, value objects, and deterministic rules.
2. Domain application operations.
3. Persistence/provider ports.
4. Concrete adapters.
5. Executable entrypoints and platform bindings.
Avoid a giant cross-platform crate that unconditionally depends on Tokio, SQLx,
a GPU runtime, Python, Tauri, and Android/Apple frameworks. A browser or
`no_std` consumer should not resolve a server stack. Compile features and
target-specific dependencies must be tested as a supported matrix, not assumed
to compose.
### 6.4 FFI and wire-boundary rules
| Boundary | Preferred mechanism | Mandatory correctness concerns |
| ---------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------- |
| Browser ↔ Rust compute | WASM with generated TypeScript interface | Startup, memory copies, worker scheduling, cancellation, bundle size |
| Node ↔ Rust during migration | Node-API/napi-rs | ABI/platform packaging, async work, process crashes, structured errors |
| Swift/Kotlin ↔ Rust core | Generated bindings such as UniFFI, or reviewed C ABI | Lifetimes, thread confinement, errors, callbacks, cancellation |
| React Native ↔ Rust | Platform modules or C++ TurboModule wrapper | Hermes/JSI lifecycle, UI thread, codegen, device integration |
| Python ↔ Rust compute | PyO3 or process/RPC boundary | Buffer ownership, GIL behavior where relevant, interpreter shutdown |
| C++/Unreal ↔ Rust | CXX for supported shapes or explicit C ABI | No unwinding across ABI, pointer/handle ownership, engine lifecycle |
| Service ↔ service | Versioned HTTP/Protobuf messages | Auth context, idempotency, deadlines, retries, pagination, streaming |
| Untrusted plugin ↔ runtime | Restricted sandbox/component contract | Explicit capabilities, CPU/memory limits, filesystem/network authority |
Use coarse operations such as “evaluate this document” or “advance this
simulation batch,” not thousands of fine-grained calls across a bridge. Define
who allocates and frees buffers, how handles expire, whether cancellation
interrupts work, and how errors are encoded. Do not pass Rust’s native ABI
across independently released binary boundaries.
napi-rs explicitly distinguishes its Node-API ABI level from the operating
systems/architectures tested by a package. Treat artifact distribution as part
of the migration.
[napi-rs packaging model](https://napi.rs/docs/introduction/getting-started).
For untrusted generated code and plugins, Rust compilation is not a security
boundary. Wasmtime can supply a sandbox, but host functions still require
carefully scoped capabilities, quotas, and lifecycle controls.
[Wasmtime security model](https://docs.wasmtime.dev/security.html).
## 7. Domain-by-domain migration decisions
The table covers **all 48 registered domains**. `L/A` counts explicit
library/application `project.json` files under that domain. `RS` counts Rust
files under both its library and application directories. These counts are
measured at the audited revision and can differ from older narrative counts in
`domains.json`. Source sizes include tests and do not establish feature
maturity.
For every row, retain the relevant web UI in TypeScript and native platform
interfaces in Kotlin/Swift. The last column identifies additional exceptions or
particularly important acceptance evidence. Recommendations are at the
capability level; the
[complete project catalog](rust-migration-2026-09-07/projects.csv) provides
every explicit project path for implementation planning.
| Domain | L/A | RS | Rust destination | Additional exception / acceptance focus |
| ----------------------------------- | -----: | ----: | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| [aglaea](../../libs/aglaea) | 94/0 | 0 | Style analysis, recommendations, catalog/commerce policy, try-on orchestration | Keep model execution in its best-supported worker; verify recommendation fixtures and provenance. |
| [airmid](../../libs/airmid) | 19/0 | 0 | Botanical knowledge rules, evidence processing, dose/unit computation, ingestion | Preserve scientific libraries where needed; validate units, evidence quality, and adverse-case behavior independently. |
| [aja](../../libs/aja) | 41/3 | 0 | Motion preprocessing, retargeting, geometry, job coordination, content policy | Keep Python model/Blender adapters and engine hooks; verify trajectory, skeleton, coordinate, and timing parity. |
| [aje](../../libs/aje) | 39/0 | 0 | Wallet/service orchestration, indexing, off-chain finance, transaction policy | Keep chain-native contracts and consumer SDKs; exact integer/decimal arithmetic, signing, nonce and replay tests. |
| [annapurna](../../libs/annapurna) | 21/0 | 0 | Kitchen/menu/inventory/dispatch rules, scheduling and business operations | Retain device/payment interfaces; verify order idempotency, stock accounting and kitchen safety constraints. |
| [aphrodite](../../libs/aphrodite) | 187/17 | 0 | Streaming control, consent/age/entitlement authority, tipping, chat, device coordination | Keep media/WebRTC engines and native capture; preserve consent revocation, tenant isolation, payment and haptic limits. |
| [arete](../../libs/arete) | 12/3 | 0 | Habits, goals, progress, scheduling, coaching policy and storage | Keep UI/session interactions local; verify calendar/time-zone semantics, privacy and offline reconciliation. |
| [asase](../../libs/asase) | 28/5 | 0 | Agriculture/value-chain planning, geospatial rules, pricing and operations | Keep forecasting/research workers; validate local units, supply-chain state and intermittent-network recovery. |
| [athena](../../libs/athena) | 42/0 | 14 | CAD topology, CAM computation, manufacturing planners, job control | Build on existing Rust topology; keep CAD/vendor adapters and firmware bindings; verify geometry and machine envelopes. |
| [bellona](../../libs/bellona) | 41/12 | 0 | Remote-control daemon, build/render orchestration, asset interchange and transport | Keep Unreal C++, Unity C#, DCC Python and Apple capture hooks; preserve command authority, cancellation and tool compatibility. |
| [brigid](../../libs/brigid) | 24/5 | 0 | Engineering calculations, industrial operations, code-generation core | Keep PLC/vendor formats and interfaces; require reference calculations and hardware/instrument conformance. |
| [calliope](../../libs/calliope) | 30/0 | 0 | Artist lifecycle, campaign/content workflows, budgets, rights and publishing rules | Keep generation/model workers; verify authorizations, identity continuity, artifact lineage and delivery retries. |
| [cybele](../../libs/cybele) | 19/5 | 0 | Geodesy, site/structure calculations, project finance, construction APIs | Keep trusted scientific/geospatial tools; differential numeric checks and provenance for design assumptions. |
| [demeter](../../libs/demeter) | 27/3 | 0 | Garden planning, growing-system rules, persistence, recommendations | Keep sensor/mobile interfaces and Python SDK; validate units, schedules, offline changes and alert behavior. |
| [euterpe](../../libs/euterpe) | 51/1 | 67 | DSP, sequencing, music theory, rendering/export core and distribution workflow | Reuse existing Rust DSP/MRT2; retain plugin ABIs, audio APIs and model workers; test callback deadlines and audio goldens. |
| [freya](../../libs/freya) | 26/5 | 0 | Catalog, provenance, luxury/retail business rules, inventory and operations | Keep payment/vendor adapters as needed; preserve provenance, currency, inventory and order invariants. |
| [gaia](../../libs/gaia) | 9/0 | 4 | GRIB/forecast data services, orchestration, codecs and bounded numerical kernels | Keep Python weather-model research/training; validate forecast skill, grids, units and reproducible runs. |
| [galatea](../../libs/galatea) | 37/0 | 118 | Kinematics, control, supported firmware, sensor fusion, fleet logic | Reuse no_std Rust where qualified; keep vendor HAL/ML; test devices, timing, fault injection and physical stopping behavior. |
| [hathor](../../libs/hathor) | 21/7 | 0 | World/lore compiler, graph rules, simulation, narrative validation and persistence | Keep authoring UI; centralize shared simulation with Maya/Neith deliberately; verify determinism and content compatibility. |
| [hestia](../../libs/hestia) | 14/3 | 0 | Recipe/nutrition rules, kitchen planning, API and social workflow | Keep model/science tools when justified; reference nutrient/unit/allergen rules and transactional user state. |
| [iris](../../libs/iris) | 262/9 | 39 | Assistant runtime, memory authority, retrieval, privacy, tools and desktop daemon | Reuse native computer-use crates; keep platform permissions/capture and model workers; adversarial tool/identity/cancellation tests. |
| [isis](../../libs/isis) | 79/6 | 0 | Provider routing, scheduling, budgets, jobs, output registry, media governance | Keep ComfyUI/PyTorch/model-specific Python and vendor processors; real-provider artifact and recovery evaluations. |
| [kalika](../../libs/kalika) | 194/6 | 205 | Symbolic/numeric kernels with proven parity, compute services and research operations | Keep Python/Jupyter/scientific engines; repair workspace membership; validate references, tolerances and stability. |
| [kuanyin](../../libs/kuanyin) | 17/0 | 0 | Moderation policy, protective friction, escalation and restoration state | Keep model classifiers as workers; independent adverse-case tests, appeals, policy versioning and auditability. |
| [lakshmi](../../libs/lakshmi) | 24/6 | 0 | Budgeting, debt, tax/rule execution, financial planning and persistence | Retain bank/market adapters when necessary; exact money, calendar and transaction semantics; reference rule fixtures. |
| [lilith](../../libs/lilith) | 9/75 | 5 | Consumer service fleet, partner/AI orchestration, business and safety rules | Keep mobile/web, EVM contracts and native shell; separate the very large svc-ai behavior into bounded modules. |
| [maat](../../libs/maat) | 18/10 | 0 | Business intelligence computation, planning, risk, capital and operating workflows | Keep analytics/scientific engines as needed; preserve approval authority, data lineage and business metric definitions. |
| [maya](../../libs/maya) | 163/0 | 1,452 | Continue Rust engine/world/UGC work; consolidate duplicative TypeScript computation | Keep browser tooling, shaders and content adapters; qualify engine integration, sandboxing, determinism and performance. |
| [meditation](../../libs/meditation) | 8/0 | 0 | Reusable timer/session/progress/breathing domain core where worthwhile | Keep platform audio, notifications, haptics and view state; test interrupted sessions and background-clock behavior. |
| [metis](../../libs/metis) | 28/5 | 0 | Course/assessment services, durable authoring, orchestration and deterministic learning rules | Retain Python math/science verification and model/document adapters; migrate Alembic/data semantics carefully. |
| [mnemosyne](../../libs/mnemosyne) | 19/0 | 0 | Spaced repetition, assessments, learning state and cultural-content rules | Keep editorial/research interfaces; preserve time-based scheduling, psychometric fixtures and provenance. |
| [neith](../../libs/neith) | 598/4 | 7,027 | Consolidate and productionize existing Rust engine/media/compute/security stack | Keep OS/plugin/vendor boundaries; qualify actual adapters rather than treating model/config structs as deployed capabilities. |
| [nisaba](../../libs/nisaba) | 24/0 | 4 | Script/text processing, corpus indexing, alignment, reference and annotation rules | Keep browser editing/fonts/shaping interfaces; test Unicode, normalization, canonical references and export round-trips. |
| [nous](../../libs/nous) | 52/0 | 8 | Inference control plane, model registry, serving orchestration and bounded native kernels | Keep Python research/training/RL/interpretability; per-model native inference qualification before changing execution backends. |
| [nyx](../../libs/nyx) | 75/22 | 0 | Coordinates/time/ephemerides, astronomy services, ingestion and catalog processing | Keep web/WebGPU visualization and scientific adapters; validate reference ephemerides, leap seconds and numerical tolerances. |
| [oshun](../../libs/oshun) | 59/12 | 0 | BFF authority, persistence, identity, billing, privacy, review and durable agent operations | Keep shell/workbench UI, web/RN/native clients and host tooling; contract, database, recovery, security and product E2E gates. |
| [oya](../../libs/oya) | 18/15 | 231 | Continue TypeScript-to-Rust drone/robot core migration and fleet services | Preserve and extend existing 120-output parity oracle; hardware-in-loop, replay and real-time qualification remain separate. |
| [phoebe](../../libs/phoebe) | 30/0 | 7 | Psychometric rules, signal/data processing, research operations and service authority | Keep Python research/model workers; validate instrument scoring, scientific assumptions, consent and data handling. |
| [psyche](../../libs/psyche) | 134/17 | 0 | Python service control plane, conversational state, tool orchestration and transport coordination | Keep perception/voice/avatar model workers and platform SDKs; qualify streaming latency, cancellation and memory isolation. |
| [saraswati](../../libs/saraswati) | 24/0 | 0 | Industrial/energy/mobility planning, deterministic models and operating services | Keep specialized simulators/ML and device adapters; preserve units, physical constraints and operational approval rules. |
| [seshat](../../libs/seshat) | 11/0 | 0 | Spatial/design calculations, workshop/planning rules and domain persistence | Keep design UI and CAD/device interfaces; reference geometry/material calculations and fabrication constraints. |
| [shakti](../../libs/shakti) | 28/0 | 0 | Movement/fitness rules, motion analysis kernels, progression and session services | Keep capture/health-platform interfaces and pose models; verify coordinate transforms, safety limits and personal-data boundaries. |
| [sophia](../../libs/sophia) | 29/4 | 0 | Ingestion, retrieval orchestration, graph/document processing, citation and credibility rules | Keep embedding/reranking model workers and existing databases; evaluate retrieval quality, evidence lineage and freshness. |
| [tara](../../libs/tara) | 9/3 | 0 | Session/content/progress services, offline domain logic and canonical authoring rules | Keep RN or native UI and OS media behavior; preserve safe catalog boundaries, downloads, playback and account recovery. |
| [themis](../../libs/themis) | 71/0 | 0 | Originality pipeline orchestration, policy, evidence, governance and off-chain computation | Keep fingerprint/model kernels where justified and chain-native interfaces; verify adversarial detection, appeals and provenance. |
| [uzume](../../libs/uzume) | 22/0 | 8 | Show-control protocols, scheduling, timeline execution and device coordination | Expand existing Rust protocol engines; keep vendor console/plugin integrations; test timing, failover and physical-device behavior. |
| [veritas](../../libs/veritas) | 65/13 | 0 | Ingestion, newsroom workflow, grounding, verification, publication and distribution | Keep language/media models and native clients; enforce source provenance, corrections, editorial review and idempotent publishing. |
| [yemaya](../../libs/yemaya) | 59/6 | 4 | Studio/agent orchestration, assets, production state, local desktop host and compute | Keep creative UI and DCC/model adapters; unify shared artifact/workflow ownership and verify export/tool round-trips. |
### 7.1 Where the major domains need more than translation
**Oshun/Eve/Iris/Psyche:** distinguish the conversation transport, tool
authority, durable run executor, memory stores, and actual model inference. Rust
should own the first four where they are product authority. Preserve the current
[agent-turn semantics](../../apps/oshun/bff/src/assistant/agent-turn-runner.ts):
streaming, tool-result feedback, iteration limits, the bounded argument-repair
extension, provider refusal, and error propagation. Preserve server-injected
identity in [agent tools](../../apps/oshun/bff/src/assistant/agent-tools.ts). A
rewrite must not allow the model to choose its own authenticated tenant/user or
fabricate successful actions.
**Isis/Nous:** organize around a Rust control plane and isolated model workers.
The [GPU worker](../../apps/isis/gpu-worker) already mixes TypeScript executors
with Python pipelines for mesh/splat/texture processing. Port orchestration and
stable CPU algorithms first; replace a model implementation only after output
quality, determinism where promised, throughput, VRAM use, failure recovery, and
artifact compatibility meet explicit gates. A Rust API in front of a Python
model is a valid target architecture, not an unfinished migration.
**Metis/Kalika/Sophia/Nyx/Gaia:** preserve an independent correctness oracle. A
Rust reimplementation and its own tests can agree on an incorrect formula. Use
reference datasets, trusted external implementations, properties such as
conservation/monotonicity, and scientific tolerances suited to each algorithm.
Do not use one universal float epsilon. Metis’s explicitly pinned
SymPy/Pint/mpmath verifier is a good example of an ecosystem dependency to
retain until a replacement proves the same verification contract.
**Neith/Maya/Euterpe:** assign ownership across overlapping engine, audio,
rendering, compute, scene, and authoring capabilities. A common Rust language
does not resolve architectural duplication. Reuse a canonical subsystem through
adapters when its behavior and deployment fit; retain distinct engines when they
serve materially different requirements. For example, a domain state model such
as
[Neith’s launcher state](../../libs/neith/android/crates/neith-android-ui/src/launcher.rs)
is useful Rust code, but is not by itself an Android launcher surface integrated
with the OS.
**Oya/Galatea/Uzume/Brigid:** keep real-time/control execution separate from
request/response services and LLM scheduling. Oya’s numerical parity is useful;
it does not prove flight control. Galatea’s
[safety controller](../../libs/galatea/firmware/src/safety-controller/rust-safety-controller/src/lib.rs)
explicitly models watchdog and stopping faults. Preserve timing, fault
transitions, device behavior, and physical interlocks under hardware testing; a
memory-safe language does not establish those properties.
**Bellona/Yemaya:** distinguish remote-control authority and transport from the
application-specific plugin. Rust is a strong owner for the daemon, command
envelope, job lifecycle, transfer, and state. Python/C++/C#/Swift remain at the
tool or OS boundary. Preserve cancellation, access scopes, path restrictions,
user/session ownership, application versions, and artifact provenance. Test
against the actual supported creative applications, not only mocked command
responses.
## 8. Products, clients, SDKs, and other repository areas
### 8.1 V1–V10
| Product | Observed source anchors | Migration recommendation |
| ----------------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| V1 platform | `apps/oshun`, domain apps, `libs/oshun`, shared/contracts | Rust backend authority with TypeScript web/admin and chosen mobile shells; migrate core platform operations by bounded vertical slice |
| V2 fighting-game product | `V2/ue`, 95 explicit projects under `apps/v2`, Neith/Maya reuse | Rust services and independent game/simulation kernels; retain Unreal C++/Blueprint/content and C# build rules until an engine-replacement program proves readiness |
| V3 embodied/metaverse product | `apps/v3` Rust workspace and web clients; `libs/v3`; `V3/ue` | Extend existing Rust services/protocols; standardize hosting, auth and telemetry; retain UI/engine adapters |
| V4 tactical product | Rust online services/telemetry/shared crates; TS web/spectator/companion; `V4/ue` | Keep the existing Rust service direction; migrate remaining service/domain logic, preserve UI and Unreal |
| V5 open-world product | 19 explicit `apps/v5` projects, mostly service-facing TS; `V5/ue` | Strong backend rewrite candidate; consolidate auth/friends/parties/matchmaking/ledger/replay/DSAR around shared Rust platform authority |
| V6 companions/world | `apps/v6`, `libs/v6`, `V6/ue` | Integrate and qualify existing Rust cognition/world code as real service/runtime paths; preserve deterministic replay and UE boundaries |
| V7 creator republic | `apps/v7`, `libs/v7`, `V7/ue` | Rust realm/identity/UGC/sandbox substrate; standard HTTP hosting, bounded plugin authority and cross-realm isolation |
| V8 detective product | `apps/v8`, `libs/v8`, `V8` | Rust case constraints, proof/gates and provenance; keep authoring/presentation and generation integrations |
| V9 learning flagship | `libs/v9`, `V9`, Metis/shared domains | Rust solve/verify/lesson assembly state; retain scientific/model workers and client UI; preserve evidence grounding |
| V10 Rail | `apps/v10` Tauri/web/mobile/TV-related surfaces; `libs/v10`; `V10` | Rust local host and reusable delivery/policy state where appropriate; keep web/native presentation and OS authority; preserve consent and notification/loudness rules |
Do not migrate ten copies of identity, billing, consent, workflow recovery,
telemetry, artifact metadata, or deletion independently. Specify the shared
authority and each product’s adapter. Keep genuinely game-specific protocols,
simulation timing, and privacy boundaries distinct.
### 8.2 Desktop, mobile, wearables, extensions, and embedded views
- **Desktop:** Five desktop `src-tauri` roots appear across Euterpe, Iris,
Lilith, Neith Vault, and V10, plus a nested Euterpe core crate.
[Yemaya desktop](../../apps/yemaya/studio-desktop/package.json) explicitly
uses Electron. Favor Rust-native hosting; qualify screen capture, audio, file
access, updates, plugin hosting, GPU integration and platform accessibility
before removing Electron. Tauri’s Rust core/webview split fits a TypeScript
creative UI. [Tauri architecture](https://v2.tauri.app/concept/architecture/).
- **Mobile:** Thirteen app manifests explicitly declare React Native. Eight
declare Expo. These overlap. Rust-core adoption does not force replacing the
UI. Native UI rewrites should be justified by each product’s experience, not
by a language quota.
- **Wearables/XR/TV:** retain their native integration surfaces and platform
toolchains. Test actual target support for each Rust dependency, particularly
on constrained targets; do not infer a working app from a compiler target’s
existence.
[Rust target support](https://doc.rust-lang.org/rustc/platform-support.html).
- **Extensions/embedded web:** browser extensions, Telegram miniapps, widgets,
and any editor/webview shells remain TypeScript where required. Backend bots,
indexing, account linkage and durable delivery are Rust candidates.
- **Native Java/Objective-C:** treat these as interop debt to reduce where
useful, not files to delete mechanically. Some glue remains necessary even
with Kotlin/Swift/Rust as the preferred languages.
### 8.3 Platform groups and non-domain applications
| Area | Decision |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `libs/shared` | Establish Rust equivalents for identity/auth context, database, storage, queues, eventing, resilience, metrics/tracing, crypto usage, rate limiting, policy and content evidence; keep host-specific JS helpers |
| `libs/contracts` | Separate schema/data definitions from behavior; build Rust invariant modules and generated client types; preserve independent conformance fixtures |
| `libs/proto` | Add a deliberate Rust generation lane; current Buf config lists TypeScript, Go and JSON Schema plugins, not Rust |
| `libs/openapi` and `tools/codegen` | Keep existing generators during transition; publish canonical versioned specs consumed by Rust and all clients; retiring TS generator code is lower priority than removing dual authority |
| `apps/concordia/orchestrator` | Rust candidate for durable orchestration; inspect and preserve coordination/retry/authority semantics |
| `apps/infra` | Rust candidates for dispatcher-worker and metrics collection; keep deployment definitions declarative |
| `sdks` and SDKs under domain libraries | Preserve consumers’ language APIs; generate transport models, maintain ergonomic host wrappers and cross-SDK fixtures |
| `scripts`, `tools`, generators | Port complex, broadly used operational tools when useful; retain Playwright/Nx/ESLint/host plugins in their native environment |
| `docker`, `infra`, CI | Adapt builds, runtime images, health checks, resource requests, secrets injection, rollback and telemetry for Rust; retain databases/brokers/vendor services |
| `docs`, `DOMAINS`, `V*`, walkthroughs, evidence | Preserve specifications and historical evidence; regenerate derived indexes from source and clearly label obsolete deployment claims |
The inventory includes more top-level app/library scopes than the 48 registered
domains, including `concordia`, `infra`, and V2/V4/V5. They are explicitly
covered here rather than silently omitted from the domain matrix.
### 8.4 Data, infrastructure, and operating model
Keep PostgreSQL, Redis, object storage, vector/search/graph stores, and model
infrastructure when they meet the product’s requirements. The language used to
implement those dependencies is not the same decision as the language used for
Oshun-owned code.
Audit actual deployed dependencies before consolidating stores. The repo
contains many Docker/Compose/Kubernetes/Terraform definitions; a checked-in
deployment manifest does not prove that a service is deployed or used. Establish
a deployable register containing owner, source revision, image/binary,
environments, databases, incoming clients, outgoing dependencies, and rollback
procedure.
For storage migrations:
1. Retain current SQL and migration history, including Prisma and Alembic
histories, until a defined ownership transfer.
2. Map every old field/default/index/constraint/enum to the replacement.
Preserve row-level/tenant access semantics and soft-delete/erasure rules.
3. Choose one schema migration authority for each database during transition. Do
not let Prisma, Alembic, and SQLx independently own the same schema history.
4. Rehearse backfills, interrupted migrations, snapshot restore and rollback
with representative data volumes.
5. Verify SQL query plans and connection pool behavior. Rust will not fix a
missing index or unbounded query.
6. Use an outbox/change log and reconciliation for dual-running periods. Do not
introduce uncoordinated application-level dual writes.
For production delivery, adapt the existing CI/container/signing/observability
workflows. A Rust binary may still require shared libraries, TLS roots, codecs,
GPU drivers, dynamic plugins, or platform entitlements. Build and test the
actual shipping artifact rather than assuming everything can use a minimal
static Linux image.
## 9. Migration sequence and priorities
### Phase 0: make the migration measurable
**Do this before mass translation.**
- Repair or explicitly classify the nine workspace-membership failures.
- Establish an authoritative capability/deployable inventory: implemented,
reachable, exercised against a real dependency, deployed, or
historical/reference-only.
- Map Cargo dependencies into Nx’s affected graph and remove repeated umbrella
execution from narrow targets.
- Pin toolchain/release policy and enumerate supported
desktop/mobile/server/embedded targets.
- Record current behavior for API/schema, database, queue/effect, and
client-boundary contracts.
- Establish baseline latency, memory, startup, throughput, correctness, binary
size, and build/CI cost on representative workloads.
- Assign one owner to each duplicated platform capability and identify intended
Rust implementations for adoption, consolidation, or rewrite.
**Exit:** all intended manifests discoverable; each pilot has a working
baseline, a measurable acceptance contract, and a rollback path. Do not count a
newly named Rust crate as migrated behavior.
### Phase 1: prove three different migration patterns
| Pilot | Why it is useful | Concrete exit criteria |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Neith self-hosted blob server, Go → Rust | Small owned service; exercises real I/O and a public SDK protocol | Same HTTP/status/header behavior, auth checks, path handling, checksum validation, atomic writes, list/get/delete, interruption and SDK interoperability |
| Oya math/control boundary, TS → existing Rust | Existing differential oracle and Node/WASM integration direction | Preserve current 120 outputs and 46 unit tests; add input-generation, boundary/failure, ordering and missing/extra-key checks; quantify native/bridge performance |
| One Oshun authoritative content/run vertical slice, TS → Rust | Exposes the difficult BFF/contracts/persistence/identity/UI dependency chain | Same tenant checks, wire format, durable state/effect identity, failure recovery, audit events and browser/native client behavior through the real API |
The third pilot should be selected from a concrete runtime ownership map. Prefer
a bounded artifact/run read-and-transition flow with a known canonical store,
not the entire Eve conversation loop or billing ledger as the first replacement.
The blob server pilot is small relative to the portfolio, but not disposable:
preserve its security and atomic-write behavior. The Oya pilot is
algorithmically useful, but must not be credited as hardware qualification. The
platform pilot is the architectural proof that Rust can become authoritative
without leaving hidden TypeScript state behind.
### Phase 2: build the common Rust backend substrate
Create shared conventions and implementation for authenticated tenant context,
service hosting, structured errors, typed IDs, tracing, database pools,
transactions, outbox/inbox, durable leases, idempotency, storage, feature flags,
and shutdown.
Port the **behavior** behind `libs/shared` and the authoritative pieces of
`libs/contracts`/`libs/oshun/persistence`. Keep the current stores and protocols
stable while replacing implementations. Generate clients for existing
TypeScript/native consumers. Use the pilot’s compatibility suites as the
standard service template.
**Exit:** one real product path uses Rust from API entry to persistence and
survives restarts, retries, denied requests and rolling mixed-version operation.
The old path can be disabled without silent fallback.
### Phase 3: move broad business/domain services
Migrate domains with ordinary service and deterministic business logic in
batches: Arete, Demeter, Hestia, Asase, Freya, Cybele, Maat, selected Lilith/V5
services, and comparable domains. Rust is the default destination even if a
particular handler has no measured CPU bottleneck.
Each batch should retire a coherent old ownership boundary. Reuse the new
service substrate. Preserve protocol adapters for unmigrated callers. Avoid a
“Rust copy” that remains unused beside the TypeScript implementation.
**Exit per batch:** old state writer retired, production path switched,
backfill/reconciliation complete, equivalent or improved service objectives, all
client suites passing, rollback rehearsed, obsolete dependencies removed.
### Phase 4: migrate agent execution and generation orchestration
Move Eve/Iris/Psyche control logic, Isis job/provider control, Yemaya production
orchestration, Metis authoring workflow and Sophia retrieval authority to Rust.
Keep Python/GPU execution workers and required host adapters behind protocols.
This phase has high semantic risk. Re-run the existing assistant evaluation
families, prompt-injection cases, grounding/citation checks, tool authority
tests, review/approval rules, recovery certification, budget tests and
real-provider release gates. Preserve prompt/model/config versions when
comparing orchestration so changes in generated output have an interpretable
cause.
**Exit:** durable runs/effects survive process termination and retry; denied
tool calls remain denied; user/tenant boundaries remain intact; generated
outputs carry correct lineage; real-provider artifact quality meets the existing
gates.
### Phase 5: consolidate native compute and clients
Expand shared Rust cores across desktop, selected WASM browser workloads, and
mobile. Consolidate Neith/Maya/Euterpe/Uzume compute where ownership is
genuinely shared. Rewrite remaining suitable TS/C++ algorithms once reference
tests exist.
Run any native mobile UI program alongside this phase, using the same Rust core
and stable protocols. This is separately releasable from backend migration. The
mobile team should not wait for every domain crate, and the backend should not
wait for every native screen.
**Exit:** signed artifacts, real-device/simulator coverage, offline migration
and rollback, resource/lifecycle correctness, accessibility and product flow
parity. Native ABI compatibility and artifact distribution must be part of the
release.
### Phase 6: retire legacy authority and pursue optional engine replacement
Remove obsolete implementations, adapters, deployment targets and dependencies
once mixed-version clients/jobs no longer need them. Preserve historical
migration records and externally supported SDK contracts.
If the product strategy still calls for replacing Unreal or major model/media
engines, run that as a separate, milestone-driven program with its own product
acceptance suite. The core Rust migration can be complete while those ecosystem
exceptions remain.
### Sequencing rules
- Fix build/contract foundations before adding hundreds of crates.
- Move domain ownership before changing broker or database technology unless the
old semantics cannot meet requirements.
- Use shadow execution only where it cannot create duplicate side effects.
- Use one writer during transition; compare read models or proposed decisions
before switching authority.
- Switch by tenant/cohort/operation where possible, with versioned routing and
observable fallback.
- Keep old SDK/wire versions supported for the required client-upgrade window.
- Make old implementation deletion an explicit acceptance criterion.
### Scope and staffing
The inventory is too large and heterogeneous for an honest duration estimate
based on line counts. It includes usable foundations, speculative/reference
surfaces, tests, generated structures, and duplicated implementations. A
credible estimate requires classifying actual capabilities and measuring the
three pilots.
I would organize the program around platform/backend, clients/bindings,
engines/media/robotics, model/science integration, and verification/release
ownership. These are engineering responsibility lanes, not a recommendation to
create five disconnected frameworks. Shared contracts, telemetry, release policy
and test fixtures should be maintained centrally.
Do not promise a complete rewrite in a single quarter from this evidence. The
first planning horizon should deliver Phase 0 and representative vertical
slices, then reforecast from observed throughput and acceptance failures.
Accepting high cost makes the desired scope broader; it does not make unknown
scope measurable.
## 10. Verification and release requirements
### 10.1 Test the behavior across language boundaries
| Concern | Required evidence before switching authority |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Wire/schema contracts | Golden requests/responses, positive/negative validation, optional/null/default behavior, enum names, error codes, pagination, streaming and version negotiation |
| Canonical identity | Identical canonical bytes and hashes, stable effect/run IDs, integer widths, Unicode normalization and timestamp precision |
| Persistence | Real database tests for transactions, isolation, uniqueness, tenant filtering, query plans, migration/backfill, restore and concurrent writers |
| Jobs and workflows | Kill/restart at each durable boundary, lease expiry, retry deduplication, delayed work, cancellation, poison messages, replay and dead-letter recovery |
| Auth/privacy/review | Denial tests, role/tenant separation, token rotation/revocation, session recovery, export/erasure, consent changes and approval-version checks |
| Assistant behavior | Existing eval corpus, tool injection/argument attacks, bounded loops, refusals, grounded citations, truthful action claims, budgets and real-provider outcomes |
| Scientific/numerical code | Independent reference outputs, properties, valid tolerances, overflow/underflow, conditioning, NaN/Inf, coordinate/units/time correctness |
| Browser/PWA/admin | Real Playwright flows against Rust APIs, accessibility automation, downloads/uploads, streaming, offline/retry and visual checks where behavior is affected |
| Mobile | Existing Maestro/Detox/native harnesses, simulator plus physical devices, suspension/resume, background tasks, permissions, secure storage and deep links |
| Desktop/native FFI | Supported OS/architecture builds, ABI smoke tests, callbacks/lifetimes, cancellation, crash/symbol reports, updater/signing and file/permission behavior |
| Media | Real model/codec/plugin runs, valid decodable artifacts, quality thresholds, audio glitches, frame timing, color/geometry round-trips and provenance |
| Unreal/engine | Engine build/cook/package and actual gameplay/network/content automation; wrapper tests alone do not qualify the engine integration |
| Robotics/show control | Hardware-in-loop, watchdogs, stale sensors, timing jitter, fault transitions, emergency stop and loss-of-connectivity behavior |
| Performance/reliability | Representative cold/warm load, p50/p95/p99, memory/RSS, startup, queue lag, backpressure, sustained load, failures and recovery |
| Supply chain/release | Locked dependencies, advisories/licenses, reproducible artifact inputs, SBOM/signatures, symbol retention, upgrade/rollback and provenance |
Preserve the repository’s current automation lanes rather than replacing them
wholesale with Rust unit tests. Playwright, pytest, native mobile harnesses,
Unreal automation and provider evaluations remain useful regardless of
implementation language.
### 10.2 Semantic traps to cover explicitly
- JavaScript numbers versus Rust integer widths, overflow behavior and float
conversion.
- Decimal money versus binary floating point; rounding rules, currency scale,
tax/fee order and refund reversals.
- `undefined` versus absent fields versus JSON `null`; unknown fields and
default insertion.
- Date/time-zone handling, daylight-saving boundaries, monotonic time versus
wall time, replay clocks and leap-second assumptions.
- Unicode normalization, grapheme boundaries, text offsets, regex behavior and
locale-sensitive ordering.
- Hash-map iteration versus explicit sorting; canonical JSON versus arbitrary
serializer output.
- Promise cancellation/disconnect behavior versus Rust task cancellation;
abandoned effects that still complete externally.
- SDK-specific streaming/tool-call/refusal/error formats; retries after partial
delivery.
- Filesystem paths, symlinks, permissions, atomic rename, crash durability and
Windows/macOS/Linux differences.
- Rust `panic`, poisoning, deadlock and unsafe/FFI behavior; memory safety does
not remove these failure classes.
- Embedded/real-time allocation, locking and blocking I/O on critical threads;
absence of a garbage collector does not establish deadline guarantees.
### 10.3 Rollout contract for each replacement
Every migration ticket should identify:
1. The old and new authoritative owner and the externally visible behavior being
replaced.
2. Current consumers, wire versions, data stores, scheduled jobs and side
effects.
3. Compatibility fixtures and independent acceptance tests.
4. Performance/reliability baselines and required product objectives.
5. Data/backfill/migration steps and the rollback point beyond which reverse
conversion is required.
6. Shadow/canary strategy, observability and stop conditions.
7. Old implementation, dependency, build-target and deployment deletion
criteria.
8. The exact shipped artifact and revision credited by the evidence.
This avoids a permanent two-language implementation of the same business rule.
Temporary coexistence is a migration mechanism, not the target ownership model.
## 11. Expected benefits and what to measure
Rust is a strong fit for explicit data ownership, memory-safe native
computation, predictable allocation choices, shared local/server code and
consolidated backend operations. Oshun has enough existing Rust that this would
build on real foundations.
The main expected benefits are:
- Common implementation of domain rules across service/local/native/WASM
consumers where sharing is useful.
- Reduced Node/Python authority in long-lived services and operational daemons.
- Better control over CPU-heavy computation, memory layout, native resources and
concurrency.
- Smaller and more direct native service deployment units where dependencies
permit.
- Stronger compile-time modeling of state transitions, units, identifiers and
ownership.
- Fewer duplicate runtime frameworks once the old implementations are actually
retired.
These are opportunities, not benchmark results. LLM latency, GPU kernels,
database queries, storage access and network round trips may dominate a
product’s performance. As an illustrative upper bound, if replaceable
orchestration is only 5% of request time, making it infinitely fast improves
total latency by only about 1.05×. Measure the actual fraction before promising
speedups.
Track migration progress with:
| Metric | Why it matters |
| ----------------------------------------------------------- | ------------------------------------- |
| Authoritative capabilities migrated and old writers retired | Measures completed ownership transfer |
| Production traffic/jobs served by the new path | Measures actual adoption |
| Compatibility corpus passes, including negative cases | Measures preserved behavior |
| Recovery/duplicate-effect/tenant-leak failure rate | Measures operational correctness |
| End-to-end latency and sustained throughput | Measures user-visible benefit |
| RSS, CPU, queue lag, GPU utilization and artifact size | Measures resource efficiency |
| Real-device/native/browser/engine evidence by target | Measures platform readiness |
| Build/test wall time and affected-graph correctness | Measures development scalability |
| On-call incidents and rollback success | Measures operational cost |
| Old packages/deployables removed | Measures reduced complexity |
Do not use Rust line count, crate count, test count alone, or a green ratcheted
task as the program’s completion metric.
## 12. Verification performed for this report
The work changed documentation and audit evidence only. It did not change UI,
API, contracts, database schemas, assistant behavior, or model pipelines.
Consequently, the document checks and the explicitly selected architectural
probes below are the relevant verification for this deliverable; the entire
application release matrix was not executed.
| Check | Result | What it establishes |
| ------------------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Tracked-tree language/project inventory | Passed; 143,396 tracked paths and 103,082 recognized source files inventoried | Complete structural enumeration under the documented method |
| JSON/TOML project-manifest parsing | Passed; zero parser/read errors | Syntactic readability of the enumerated manifests |
| Direct local Cargo dependency path existence | Passed; zero missing target manifests found | Narrow path integrity, not dependency resolution |
| Cargo metadata sweep | 944 passed, nine workspace-membership failures | Concrete existing Rust topology defects, listed in F9 |
| Oya locked Rust parity producer build | Passed with one Cargo build job | Selected Rust producer and its dependencies compile on this macOS ARM64 host |
| Existing Oya differential comparator | Passed: 120/120 outputs; maximum relative error `2.88e-15` | Agreement for the comparator’s selected fixture outputs, not complete Oya parity |
| Targeted Oya math unit tests | Passed: 46; zero failed/ignored; zero doctests discovered | Narrow library test baseline, not hardware/control-system qualification |
| Report formatting, local links and evidence consistency | See the bundle’s verification receipt | Integrity of the delivered Markdown and supporting catalogs |
The first offline Oya attempt could not find `criterion` in the local Cargo
cache. Running the selected producer with `--locked` and network access
installed dependencies and built successfully; the subsequent offline comparator
passed. No tracked lockfile or application source changed.
This host has 16 GiB RAM, 3 GiB configured swap and approximately 24 GiB disk
available at inspection. macOS `sysctl`/`vm_stat`, `df`, and process listings
supplied the resource checks corresponding to the Linux commands in `AGENTS.md`.
Cargo work was serial with one compilation job. No full Nx sweep, Next
production build, Expo export, Tauri packaging, Unreal build, real-provider run,
or hardware test was launched. Those gates are required for relevant future
implementation changes, not evidence furnished by this report.
The nine metadata failures are **existing audit findings left unchanged**, not a
claim that the monorepo passes all builds. The completed deliverable is this
assessment and its evidence, not remediation of the codebase.
## 13. Decision I would adopt
Adopt the following policy for new owned implementation and planned rewrites:
> Rust owns backend/domain/local-engine authority by default. TypeScript owns
> web and selected React Native presentation. Kotlin and Swift own their native
> platform experiences. Python remains a bounded research/model/science/plugin
> ecosystem. C/C++/C#/Solidity and shader languages remain where engines, hosts,
> devices or chain runtimes require them. Declarative schemas, SQL and
> infrastructure definitions remain explicit. Public SDKs serve their consumers’
> languages.
Then start with build topology, executable contract parity, and the three pilots
in Phase 1. Your willingness to fund a costly rewrite supports a broad migration
of ordinary backend behavior to Rust. The strongest final architecture still
retains a small, deliberate set of ecosystem languages and verifies the boundary
between each of them.