Implementation Confirmation - MAOE vs Trajectory Bias

Implementation Confirmation - MAOE vs Trajectory Bias

Date: 2026-05-27

Verdict

You were right: the verified N'Ko ASR number comes from the anticipatory /
trajectory-biased Transformer CTC model, not from MAOE routing.

The strongest local evidence is in:

• `Desktop/nko-brain-scanner/HANDOFF.md`
• `Desktop/nko-brain-scanner/asr/trajectory_asr.py`
• `Desktop/nko-brain-scanner/constrained/trajectory_bias.py`
• `Desktop/MAOE-NKo-Technical-Architecture.md`

What Was Actually Used For The ASR Anchor

The verified model is:

• model: N'Ko Trajectory CTC
• checkpoint family: Paper 4 reproduction
• reported held-out result: 20.57
• architecture: `UnifiedCTCHead`
• decoder: 6-layer Transformer
• key mechanism: trajectory-bias injection
• trajectory components:
• `AudioTrajectoryScalars`
• `TrajectoryBiasNetwork`
• `TrajectoryTransformerLayer`

That is the path that trained toward the ASR number.

Where MAOE Actually Fits

MAOE is not the acoustic model that produced the verified ASR checkpoint. In the
current local architecture, MAOE is the routed correction and admissibility layer
around the ASR anchor.

The implemented bridge pieces are:

- `partition_policy.py`: classifies ASR telemetry into `stable`, `boundary`,
`uncertain`, `recovery`, or `novelty`.
- `expert_router.py`: maps each partition to an expert lane and safety contract.
- Rust/admissibility layer: decides whether a proposed correction is allowed.

So the correct stack is:

audio
  -> Whisper / acoustic features
  -> trajectory-biased CTC ASR anchor
  -> ASR hypothesis + trajectory telemetry
  -> MAOE partition / expert routing
  -> AGP or retrieval proposal, only when allowed
  -> deterministic admissibility gate

Does This Matter For Computational Choreography?

It matters for naming and transfer, not because AirDeck is training ASR.

For AirDeck and computational choreography, the useful lesson from the ASR work
is trajectory bias: current motion should be interpreted through where the
motion has been and where it is about to go. That maps directly to DJ gestures:
scratch, swipe, hand raise, platter spin, safe stop, loop, and cue should use a
short hand/wrist trajectory window rather than a single pose frame.

MAOE is still useful as a safety architecture, but it should be described as a
gesture-intent routing layer:

• stable: preserve current deck state
• boundary: allow small transport intent
• uncertain: observe and record, do not fire
• recovery: debounce or cancel accidental motion
• novelty: archive for later gesture-library growth

The movement system should not claim that it is using the trained MAOE ASR
model. It can borrow the MAOE routing pattern after the camera/motion trajectory
features are reliable.

Practical Correction

Use this wording going forward:

> N'Ko ASR is anchored by a trajectory-biased Transformer CTC model. MAOE-NKo is
> the routed correction/admissibility layer around that anchor. For AirDeck, we
> should transfer the trajectory-bias idea first, then use MAOE-style partitions
> as a safety gate for gesture intent.