Latent Representation Overview

Latent Representation Overview

The representation layer is where raw body data becomes a compact state that the
rest of the system can use.

The current source does not justify saying there is one canonical "LIM-RPS"
runtime brain. The verified names are:

• `EchelonCore`
• `LatentUpdater`
• `SimpleLatentUpdater`
• `LearnedLatentUpdater`
• `DellLatentUpdater`
• `SANPipeline`
• `DiffusionService`
• `ClaimBridge`

`LIM-RPS` remains a real term in older/research code, especially
`motion-bridge/src/lim_rps.rs`, but docs should treat it as historical/research
vocabulary unless discussing that file directly.

Problem

Raw body data is not a clean control signal:

• mocopi bones are high-dimensional;
• camera pose can drop or mirror;
• watch data arrives at a different rate;
• phone IMU and camera features have different noise;
• MotionMix BodyTruth can stall if the hub is overloaded.

The representation layer exists to make those signals usable by audio, visuals,
AirDeck, and inscription.

Verified Representation Pieces

`EchelonCore`:

- lives in Rust `cc-brain`;
- owns state machine, latent updater, lexicon controller, sensor buffer, temporal
state, and related adapters;
- exposes FFI reads such as `echelon_get_latent`,
`echelon_get_lexicon`, and `echelon_get_dynamics_128`.

`LatentUpdater`:

• is the Rust trait for latent update backends;
• currently has simple, learned, and DELL implementations.

`EchelonBridge`:

• is the Swift runtime coordinator;
• defaults to backend `.simple` unless a call site selects another backend;
• caches pose, mocopi, pocket IMU, and watch features.

`getDynamics128()`:

- is a Swift overlay helper that starts from Rust dynamics and overlays pose,
modality mask, mocopi, pocket IMU, and watch features.

`SANService`:

• runs Rust SAN against the Echelon core;
• loads `san_weights.bin` and `san_manifest.json`;
• logs training/capture frames through `SANTrajectoryLogger`.

`DiffusionService`:

• builds a dynamics vector for generation;
• uses a temporary 104D encoder input;
• calls `ConditioningEncoder` and `FlowGenerator1Step` when available.

Documents In This Section

- [128d-canonical-vector.md](128d-canonical-vector.md): audits the competing
128D paths and the slot conflicts.
- [dell-architecture.md](dell-architecture.md): explains what DELL is in source
and what is not proven.
- [echelon-bridge.md](echelon-bridge.md): documents the Swift/Rust runtime loop.
- [equilibrium-diffusion.md](equilibrium-diffusion.md): corrects diffusion
claims and explains the one-step flow path.
- [lim-rps-theory.md](lim-rps-theory.md): term audit and demotion of old
overclaims.

Correct Language

Use:

EchelonCore computes and publishes body state.
LatentUpdater selects the body-state update strategy.
SAN consumes Echelon state and emits output parameters.
DiffusionService contains a CoreML conditioned one-step flow path.
ClaimBridge maps dynamics to controlled N'Ko motion claims.

Avoid:

LIM-RPS is the heart of the system.
The 16D latent is the heart of everything.
LIM-RPS and diffusion are the same deployed model.
SAN was trained on DELL output.
The current runtime is a full 128D diffusion model.