Architecture Alignment - N'Ko, MAOE, Motion, LUME CC, and AirDeck

Architecture Alignment - N'Ko, MAOE, Motion, LUME CC, and AirDeck

Date: 2026-05-27

Source Of Truth

This folder uses N'Ko as an architectural and cultural reference point, not as
a required dependency for AirDeck or MotionMix gesture control.

It also uses N'Ko as an implemented inscription layer. The important distinction
is:

N'Ko audio / ASR
  speech -> trajectory CTC -> N'Ko text -> MAOE correction/admissibility

N'Ko motion inscription
  body -> LUME CC / Echelon dynamics -> ClaimBridge -> N'Ko claim sigil

Those two lanes share operator culture and future convergence goals, but they
are not the same model.

The correct relationship is:

N'Ko ASR
  trained / verified: trajectory-biased Transformer CTC
  not yet verified: MAOE correction improves CER over the CTC anchor

MAOE-NKo
  implemented as: partition + expert-routing + admissibility control around ASR
  not implemented as: the trained acoustic model that produced 20.57% CER

Computational choreography / AirDeck
  current need: camera/body trajectory gesture recognition and K11 safety gates
  borrowed lesson: trajectory bias + partitioned intent routing
  not required: N'Ko ASR or MAOE-trained ASR

Comp-Core / LUME CC inscription
  current implementation: ClaimBridge maps 104D/128D latent dynamics to the
  ten N'Ko inscription claims
  current persistence: Convex inscription mutations for motion/speech/conversation
  current limitation: no fully trained shared body+speech+N'Ko latent yet

What Is Actually Trained

Trained / Verified

• N'Ko Trajectory CTC anchor in `Desktop/nko-brain-scanner`.
• Reported result: 20.57
• Mechanism: trajectory-biased Transformer CTC.
• Key components:
• `UnifiedCTCHead`
• `AudioTrajectoryScalars`
• `TrajectoryBiasNetwork`
• `TrajectoryTransformerLayer`

Implemented But Not Yet Proven As A Better ASR Model

- MAOE-NKo bridge in `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge`.
- It routes already-produced ASR chunks into authority partitions:
- stable
- boundary
- uncertain
- recovery
- novelty
- It controls when AGP / retrieval / correction proposals are allowed.
- It has not yet proven `CER after MAOE < CER before MAOE` on a full
same-snapshot replay.

Implemented Motion-To-Inscription System

- `ClaimBridgeService` in MotionMixApp.
- Rust `ClaimBridge` in `cc-brain/src/san/claim_bridge.rs`.
- FFI in `cc-brain/src/ffi.rs`.
- `cc-inscription` typed claim IR and N'Ko surface rendering.
- Convex `inscriptions.ts` mutations.
- `cc-semantic-language` N'Ko segmentation, operator assignment, grammar
validation, invariance scoring, and lifecycle transitions.

This is the current place where "movement becomes words." The words are
controlled N'Ko operator claims, not yet arbitrary natural-language sentences.

Not Trained Yet

- A shared N'Ko/body/music latent space.
- A movement MAOE model.
- An AirDeck gesture model trained from the full physical rehearsal library.
- Any separate voice-ASR architecture for AirDeck. Voice commands are a different
runtime lane from N'Ko ASR and from motion inscription.

How The Systems Align

The systems align by signal geometry:

continuous signal
  -> trajectory-aware state
  -> partitioned intent / authority
  -> safety gate
  -> output

For N'Ko:

audio
  -> trajectory-biased CTC
  -> ASR text + confidence / trajectory telemetry
  -> MAOE-NKo partition router
  -> admissible correction or preserve-ASR decision
  -> N'Ko text

For AirDeck:

camera / mocopi / SensorLogger / body state
  -> BodyTruth + hand/wrist trajectory windows
  -> gesture intent partition
  -> K11 promotion / dry-run / safety gate
  -> Rekordbox command

For future computational choreography:

body motion + sound + N'Ko speech/text
  -> timestamped multimodal training sessions
  -> aligned latent space
  -> music, inscription, and movement generation

For current LUME CC inscription:

body / sensors
  -> Echelon dynamics
  -> ClaimBridge
  -> N'Ko claim sigil + confidence + behavior vector
  -> inscription mutation
  -> corpus / training evidence

Why N'Ko Matters Here

N'Ko matters because it clarifies the kind of system being built:

• culturally grounded;
• trajectory-sensitive;
• resistant to generic defaults;
• explicit about authority boundaries;
• built from practice, not from abstract labels alone.

It does not mean every movement-control system must run N'Ko ASR.

It does mean the docs should treat N'Ko inscription as a real system component,
not as branding or a late-stage metaphor.

Why MAOE Still Matters

MAOE is useful as an authority-routing pattern:

• stable: preserve current state;
• boundary: allow small completion;
• uncertain: observe / record before acting;
• recovery: debounce or repair under tight limits;
• novelty: quarantine and archive for corpus growth.

That maps cleanly to AirDeck:

• stable: no Rekordbox command;
• boundary: hand entering a deck zone;
• confirmed: gesture can be promoted after physical proof;
• uncertain: dry-run record only;
• recovery: cooldown / cancel accidental motion;
• novelty: save as a possible future gesture.

The important discipline: do not call MAOE a trained ASR model unless that
training and evaluation actually exist.

Current Implementation Boundaries

AirDeck live Rekordbox control should remain K11-owned:

Unity / Mac4 / sensors
  -> state only
  -> MotionMix / BodyTruth
  -> K11 bridge
  -> Rekordbox

No Unity, Mac4, mocopi, SensorLogger, or N'Ko component should send direct
Rekordbox commands. They can provide evidence. K11 decides.

Practical Wording Going Forward

Use this:

> The N'Ko ASR anchor is trajectory-biased Transformer CTC. MAOE-NKo is a
> routed correction and admissibility layer around that anchor. Computational
> choreography borrows the trajectory-bias and partitioned-authority pattern,
> but AirDeck does not depend on N'Ko ASR.

Avoid this:

> MAOE is the trained N'Ko CTC model.

Avoid this:

> LIM-RPS and N'Ko CTC are the same architecture.

Avoid this:

> A separate voice-command ASR lane is part of the current AirDeck/N'Ko alignment.