DELL Architecture Audit

DELL Architecture Audit

DELL means Dual Equilibrium Latent Learning. It exists in the Comp-Core Rust
source, but older docs overstated what is proven about it.

Verified source:

• `Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/latent/dell.rs`
• `Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/latent/mod.rs`
• `MotionMixApp/Services/EchelonBridge.swift`

What Is Verified

`DellLatentUpdater` is one implementation of the `LatentUpdater` trait.

The Rust source includes:

• default dimension around 32;
• `num_limbs = 27`;
• fast equilibrium iterations;
• slow equilibrium iterations;
• fast/slow state;
• synthetic limb embedding generation from available sensor data.

The important source caveat is in `dell.rs`: the current implementation creates
synthetic embeddings from available sensor data, while production-quality limb
embeddings would come from the sensor fusion pipeline.

That means the docs can describe DELL as an implemented backend, but not as a
fully proven, trained, full-body production foundation.

Backend Status

`EchelonBridge.Backend` defines:

case simple = 0
case learned = 1
case dell = 2

The initializer default is `.simple`. Therefore:

- `.dell` is available;
- `.dell` is not the default unless a specific call site selects it;
- docs must not say all runtime audio/SAN behavior uses DELL unless source proves
that call path.

What DELL Should Mean In The Docs

Use DELL for:

• the Rust latent updater backend in `latent/dell.rs`;
• a dual-timescale latent update idea;
• a potential stronger body-state model for mocopi/pose-heavy runtime.

Do not use DELL for:

• the entire computational choreography architecture;
• the default iPhone runtime without checking the backend;
• SAN training provenance;
• diffusion generation;
• N'Ko ASR architecture.

Relationship To LIM-RPS

Older docs said "DELL is the brain of LIM-RPS." That is too broad.

Corrected wording:

> DELL is one Rust `LatentUpdater` backend. LIM-RPS is a historical/research term
> present in the motion bridge code. Current docs should name the concrete source
> components instead of treating LIM-RPS as the deployed architecture.

Relationship To SAN

There is no local source proof that current SAN weights were trained on DELL
output. The verified runtime relation is:

EchelonBridge
  -> Rust EchelonCore
  -> SANService.step(core:)
  -> Rust SAN FFI

The training provenance for `san_weights.bin` needs its own manifest/report. Until
that exists, docs must not say "SAN was trained on DELL output."

Relationship To Diffusion

DELL is not the deployed diffusion model.

`DiffusionService.swift` is a separate Swift/CoreML service that builds a dynamics
vector, truncates to a temporary 104D encoder input, and runs:

ConditioningEncoder -> FlowGenerator1Step

The mathematical idea of fixed-point flow and generative flow can be compared in
research writing, but the source does not support the claim that DELL/LIM-RPS and
the app's diffusion path are the same deployed dynamical system.

Promotion Criteria

DELL can be promoted from "implemented backend" to "primary production body state"
only after docs point to:

• the call sites selecting `.dell`;
• a sensor-fusion input path feeding real limb embeddings;
• performance/latency checks;
• training or calibration provenance if learned weights are claimed;
• comparison against `.simple` for the relevant live workflows.