memlnaut-nisps/ALIGNMENT.md

ALIGNMENT

Opinionated diagnosis of how well the codebase serves its mission, ranked by impact. Dated entries; remove when resolved rather than checking off. Pruned every few weeks — a stale diagnosis is worse than none.

Mission

A research platform for interactive ML control of audio. We're building it to figure out what works and what doesn't — different ergonomics and ergodynamics of parameter sets, modes, ML architectures, audio engines, UI, and UX. Therefore: keep most/all parameters tweakable, ML/engine/UI/UX should each be configurable on their own axis, and the codebase has to enable/assist agentic AI coding patterns (confident changes, verifiable without hardware).

Target vision (operator, 2026-07-20): (1) one C++20 NISPS core serving RP2350 firmware and the browser, performance-sensitive on the MCU; (2) firmware modes runnable as modes in Manifold; (3) Manifold defaults to curated presets/modes, with the maximalist surface behind an "advanced" dev mode used to author them; (4) PlatformIO for hardware, no more .ino; (5) Manifold doubles as interface/editor for the hardware MEMLNaut (settings, presets, training, examples, visualisation).

The clean-slate rewrite (2026-04-29) consolidated everything into one C++20 codebase compiling to firmware AND WASM. Since 2026-07-13 (P1) the sole browser app is the React Manifold. JSON schemas remain the firmware↔browser parameter contract. A full-repo audit (2026-07-21, docs/specs/recon/simplification-audit-2026-07.md) grounds the entries below; mitigations are phased in docs/specs/plans/simplification-plan.md.

Top defects (ranked by mission impact)

1. The mode layer is not shared: WASM re-orchestrates modes by hand (2026-07-21)

What. nisps/modes/ — the CRTP layer binding ML config, engine, voice-space and I/O — compiles only into firmware. nisps/wasm/bindings.cpp includes engines and ML primitives but zero mode headers, and Manifold re-assembles mode behaviour (jolt stepping, OU, routing) in TS. "Firmware and WASM share the same modes" is true only at the engine level; every ModeBase behaviour must be mirrored browser-side by hand.

Why it blocks the mission. Vision bullet 2 is precisely this. Until the control-tick orchestration exists once in C++, every new mode behaviour is a dual implementation with drift risk.

Rough cost. Spec first, then ~a week: storage-policy the ModeBase orchestration the way P2 did MLPCore (verified shape in plan §6.5a — not binding monolithic mode objects, which would contradict the locked two-instance RT architecture). Related honesty gap: Manifold currently catalogues 4 modes that structurally cannot run in the browser (no mic input, event-only engines) — plan §6.5b (absorbs the old C15/mic-input defect; C15 itself lives on archive/playground-solidjs).

2. No curated/advanced split and no in-UI mode picker — the UI fights vision 3 (2026-07-21)

What. Manifold is 100% dev-maximalist: five drawers of everything, no preset data model to author against, and mode switching exists only via the debug hook — there is no instrument picker in the UI at all (the plumbing, ctx.modes/setModeId, already exists unused). A stratum of decorative controls (training-param sliders, master volume, bpm, A/B, snapshots, fabricated gradient health) renders real-looking UI that drives nothing.

Why it blocks the mission. The default experience is supposed to be curated presets; the advanced surface is the authoring tool. Neither exists, and the decorative stratum actively misleads research use.

Rough cost. Product-model decision first (plan §7.6), then incremental: picker is days; the curated-preset model seeds from backends/presets.ts + schemas; disclosure via per-drawer depth levels — which as of §6.5e (2026-07-21) has its first genuinely advanced-only consumer, the training-health panel, so the mechanism is proven rather than theoretical. The decorative stratum itself went in the Phase-1 sweep.

3. Manifold-as-hardware-editor is a facade (2026-07-21)

What. Vision bullet 5 exists as a 237-line Web Serial shell: sound connect lifecycle, zero protocol (saveModel/restoreModel/getSettings are literal stubs), and firmware has no serial command surface or on-device persistence to talk to.

Why it blocks the mission. The hardware research loop (train on device, inspect/curate in browser) is closed only by this bridge.

Rough cost. Week+, spec-first (plan §6.5d). The right discipline already exists in-repo: useq-celium's C-header wire truth + TS mirror + parity test; settings payloads should derive from schema codegen.

4. Dead mass and registry sprawl across every layer (2026-07-21)

What. Phase 1 landed 2026-07-21 and removed the bulk of this: the dead focus/altitude UI system, the decorative control stratum, 12 dead WASM API entries across the 5-file registration chain, the vendored daisysp tree, retired-playground artifacts and root planning relics, 5 unused primitives, the duplicate backend editor and catalogue, voice_space.hpp, fixed_buffer.hpp, the dead perf-macro regime, and the OSC bridge twin. What remains is the registry half: mode identity spread across ~6 hand-maintained registries with demonstrated drift, MLP dims typed twice, per-mode schema blocks hand-written in C++, and assorted stale specs presenting a deleted world as present tense.

Why it blocks the mission. The registries are dual-truth bugs waiting to fire (one already did: the selftest table). Stale specs are agent-confusing surface area.

Rough cost. Plan phase 3 (~2–3 days, codegen takes ownership) plus the docs disposition pass (§8). The behaviour bugs found en route (dataset-cap divergence, VCV 2-D input truncation, VCV audio-thread race and JSON) were fixed in phase 2 on 2026-07-21.

5. Performance is measured on the host but not on the target that constrains it (2026-07-21)

What. Mostly closed 2026-07-21. Size: the Phase 4 firmware CI job reports per-variant flash/RAM on every push. Time: scripts/bench-engines.sh now reports per-engine ns/sample, blocks/s and realtime factor on native AND WASM from one source (tests/cpp/engine_bench.cpp), engines driven into a working state, with --compare for per-engine deltas and a report step in CI. An engine getting 3x slower is now visible.

What is left. The numbers are HOST numbers. The mission's performance constraint is the RP2350 at 150 MHz, and nothing measures there — a host realtime factor of 100x says nothing about whether an engine fits in the MCU's per-block budget, and the two targets have different FPU, cache and memory behaviour. The honest next step is an on-device timing report (cycle counter around the audio callback, published over the existing display/serial surface), which lands naturally with the hardware editor (defect 3) since that is what gives firmware a command surface to report through.

Rough cost. Host half is done. On-device: ~a day, and it wants defect 3's serial protocol to have somewhere to send the number.

6. SGD-vs-RMSProp is not a research axis — it silently invalidated every ported hyperparameter (2026-04-29; re-ranked 2026-07-25)

What. training.hpp ships SGD only. Upstream memlp (pinned ea777502 by upstream/main) applies gradients with RMSProp everywhere — Layer.h:239, the m_sq_grad_avg running squared-gradient average at Layer.h:601, StaticMLP.h:268 "Mini-batch RMSProp training". This was filed as an optimiser-choice research question and ranked last. That was wrong, and the 2026-07-25 benchmark work shows why.

Why it blocks the mission. Every learning rate ported from upstream landed in a different optimiser than the one it was tuned for. RMSProp normalises each step by the running gradient magnitude, so lr=1e-3 there is a normalised step; under SGD it is literally 1e-3 x raw gradient. The two numbers are unrelated. Concretely: feedback.hpp:789 carries geo_lr_ = 0.001f // upstream InterfaceRL.hpp:312 — an RMSProp LR pasted into a single SGD step. tests/cpp/ml_bench.cpp D1 measures the result: the geometric dislike aims at a target 0.5 output-units away and moves the mapping by 5.1e-5, linearly, so ~10,000 presses would be needed for one press's intended effect. Meanwhile likes train at lr 1.0 x 1000 iterations, making a like ~2e6x stronger than a dislike and heaving the whole mapping on every press (ml_bench U1/U4: lurch_max ~1.1 against a [0,1] output range).

Rough cost. A day for the port plus batch-convergence tests — but it must come BEFORE any retuning of geo_lr, kGeometricPushScale or the neg-LR base, or those constants get tuned twice.

6b. The geometric dislike was ported from a superseded upstream design (2026-07-25)

What. geo_push.hpp/replay.hpp cite memllib @ 0a541cc. upstream/main now pins e291192, where the same code has been deliberately redesigned. Upstream: kGeometricPushScale 1.0 (ours 0.5); neg-LR base 1.5 (ours 0.5, geo_push.hpp:92); the /(1+len) taper deleted, with the comment "a 'no' should clearly move the mapping away even from a sound already far from the liked region (the taper used to kill exactly that case)" — ours still applies it at geo_push.hpp:66; negatives trained as a batch over ALL of them every tick rather than one item one step; and a fixed kDislikeLifetimeMs = 2500 full-strength lifetime replacing the proportional decay we ported. On the shared constants (dedup radius 0.05, kCentroidK 4) we match.

Why it blocks the mission. We are carrying a design upstream diagnosed and fixed, and the fix is documented in their source comments. Compounded with defect 6 the ported dislike is ~9.4x weaker on constants alone before the optimiser mismatch.

Rough cost. Small once defect 6 lands — mostly deleting the taper and re-basing three constants, then re-running scripts/bench-ml.sh D1/A4/A7 to confirm.

6c. InterfaceRL — the reference implementation — is not in the tree (2026-07-25)

What. It lives in memllib/examples/, and the vendoring dropped examples/ (VENDORED.md). So the source of truth for our most contested subsystem is absent, and the divergences in 6b went unnoticed for months. Either vendor examples/InterfaceRL.{hpp,cpp,tpp} read-only alongside the rest, or record its pinned commit and a fetch recipe in VENDORED.md.

Open mission questions

Q1: Per-mode MLP architectures or one shared shape? (2026-04-29)

Schemas declare per-mode dims and since P5.3 both targets honour them. Is the mission served by maintaining per-mode shapes (research diversity) or collapsing to one (simpler ops)? Note the audit found all 9 mode schemas share copy-pasted ML defaults and 20 params are anonymous placeholders — the per-mode diversity is currently nominal (plan L40).

Q2: Engine event taxonomy (2026-04-29)

ControlEvent is a flat enum consumed by the two sequencer modes. Revisit when a third event-emitting mode lands.

Q3: Should Manifold stay desktop-first? (2026-04-29)

Legacy a-immersive was mobile-first; Manifold is desktop-first. Defer until user data exists.

Deferred / accepted debt

• EOC effects chain, ShapeSeq sequencer, modular engine (Phase E) — legacy features consciously out of the v1 rewrite; revisit only if a mode wants them.
• Inputs multi-source composition (2026-06-28, reaffirmed 2026-07-21) — mix-and-match pad+gamepad+MIDI is a recorded, unreversed decision; the UI currently enforces exclusive single-source and the composition machinery sits dormant by design. Schedule or keep dormant — but the inputs-spec must stop presenting composition as current behaviour (plan §8).
• Schema content is partially placeholder (2026-07-21) — 20 anonymous "Param NN" slots across paf_synth/channel_strip/xiasri and copy-pasted ML defaults across all 9 modes. Name them during the first curated-preset pass per mode (plan §6.5c), or shrink output_size where the engine allows.
• Geometric-dislike deliberate divergences (2026-07-14, one-core P3): (1) the degenerate-branch RNG draws from the controller's deterministic nisps::Rng, not libc rand() — native==WASM parity holds; (2) upstream's async shuffled two-LR optimise() is collapsed into one synchronous dislike_geometric() training only the pressed negative's target — behavioural, not bitwise, parity with firmware upstream, by design; (3) RandomiseMlp uses draw_weights(spread) rather than the old asymmetric ranges. All intentional.
• Manifold dock splits state/muted/armed (2026-06-28) — deliberate divergence from the deployed conflated frozen↔muted model (dock-spec §3.3). muted-downstream and the soloMode gradient-mask variants remain UI-only; the C API exposes set_focus but no per-mode gradient masking yet. (The audit found soloMode behaviourally inert in the controller — plan L20 trims it until train_masked exists.)

Recently resolved (delete after a few weeks)

• 2026-07-21: Q4 (who owns memllib) closed. Vendored at firmware/MEMLNaut-NISPS/lib/memllib/ from upstream e291192; the submodule and the fork are both gone. Q5 (legacy feedback modes) closed — operator kept all four (RandomiseOutputs/RandomiseMlp/Diffuse/on_drag) as building blocks for comparing how instruments feel under different behaviours, which upholds rather than reverses docs/adr/rl-feedback-design.md.

• 2026-07-21: Training-health telemetry (old defect 6) is gone — the browser reads the real per-iteration loss the core records, both fabrication sites are deleted (wasm-worker.ts's 1-element array AND wasm-iml.ts's sync-train twin, which the audit missed), and the display sits behind the existing expanded drawer depth. The firmware buffer stays, per the L25 call.

• 2026-07-21: Training-health telemetry (old defect 6) is real. nisps_ml_loss_history now crosses all five WASM registration layers, so the browser reads the SAME per-iteration curve the firmware MLP records; wasm-worker.ts's 1-element new Float32Array([loss]) fake is gone from both the sync and the async train paths; and the curve + the already-plumbed get_layer_stats render in manifold/src/console/TrainingHealth.tsx at the Learning drawer's expanded depth. The firmware buffer stays, per the operator call — it is the record the hardware editor (defect 3) will read. One more fabrication went with it: ConsoleCtx.loss, a synthetic prev * 0.82 series no drawer read. With no history the panel says "no training run yet" rather than drawing a plausible curve.

• 2026-07-21: Arduino-CLI build machinery (old defect 3) is gone. Phase 4 replaced it with a PlatformIO project: one [env:] per variant is now the only variant registry, the .ino-mutating Python/sed machinery and the NISPS_ST_* token-paste table and the sketch symlink forest and the global TFT_eSPI mutation are all deleted, memllib is vendored (no submodule), and firmware finally entered CI — three representative envs per run, which is what would have caught the SelfTest variant sitting broken. All 16 envs build; sizes match arduino-cli within ~520 bytes.

• 2026-07-21: Full-repo simplification audit landed (recon + plan + this rewrite). Superseded entries removed: "browser-only engines incomplete" (→ defect 2/plan 5b), "loss curve not plumbed" (→ defect 7), "NISPS_AUDIO_FUNC misshapen" (→ plan Phase 1, S21/L13), stale "VCV not currently maintained" note (vcv/ is active and consumes nisps/ directly post-P6).

• 2026-07-18: Browser curve maths unified onto the canonical nisps/core/math.hpp catalog at P4; four silently-divergent TS curves re-baselined.

• 2026-07-14: WASM MLP fixed-architecture defect resolved by P2 (MLPCore<Storage>; browser runtime-shaped, firmware zero-heap fixed).