Trace issue sources before readiness.
A visible decoding issue could come from the model, sensor placement, protocol design, or the interaction itself. Separating those sources gave the team a way to decide what changed next.
The Meta Neural Band used EMG to read wrist muscle signals and turn them into gesture-based input. Handwriting was one of the most complex interactions it supported. Because session data fed model training, every session shaped what the system learned.
When a character was misread or a gesture went unrecognized, the cause was not obvious. The signal could be noisy, sensor placement could drift, task wording could create ambiguity, or the interaction could ask for a gesture pattern people did not naturally produce.
Treating those issues as interchangeable sent teams in the wrong direction.
The system was under active development. Model updates, firmware changes, and prototype iterations overlapped with testing, requiring a protocol flexible enough to keep up without losing consistency across sessions.
Which issues were ready for system-level action, which pointed to model or sensor work, and which required stronger evidence before anyone could make a readiness call.
Training data needed defensible QA.
Training data was accumulating continuously. Readiness and future model behavior both depended on knowing which sessions were valid and where each issue came from.
Every session that passed QA entered the training set. Every invalid session that passed silently introduced noise that would shape model behavior for future users. The difference was whether the team had defined what counted as valid data.
Calling the system ready without knowing which issues were actionable, and by which team, risked shipping prematurely or delaying work that already had enough evidence behind it. On a fast-moving R&D program with short iteration cycles, both were costly.
Participant intake and wrist measurement, EMG calibration and signal quality checks at session start, real-time protocol adaptation, end-of-day QA, and cross-functional reporting to research scientists and engineers.
Sixteen participants per day across two daily sessions. Every decision about what counted as valid data compounded into the training set.
Separate system and participant behavior.
Recognition scores alone could not tell the team who needed to act. I used clear issue categories and RITE so validated changes could reach the next session.
-
RITE testing
Protocol and configuration adapted between sessions based on observed issues. Validated changes could be applied to the next session without waiting for a formal review cycle.
-
Observe natural handwriting
Daily in-lab sessions tracked how participants produced handwriting input and how natural variation affected recognition. The goal was to distinguish what participants were doing from what the system was doing, without directing them to change how they wrote.
-
Validate builds before sessions
New builds and firmware updates were validated with Python-based signal checks before participants arrived. Catching issues before a session prevented unreliable data from entering model training undetected.
-
Define valid data
Daily quality checks flagged missing data, signal anomalies, and protocol deviations. Explicit criteria defined what made a session valid for model training, creating consistency across a long-running, multi-study program.
Early issues were system-level.
The clearest findings were not about recognition rates. They showed which assumptions were wrong and what needed to change before the evidence could be trusted.
-
Setup quality drove early recognition issues
Early QA logs showed elevated gesture recognition issues that did not correlate with participant behavior. The pattern pointed toward sensor positioning, which made recalibration a required session-start step rather than a late response to signal problems.
-
Natural handwriting was the signal
Session reviews consistently showed participants who wrote loosely or inconsistently were producing exactly the data the model needed. Coaching them toward neater writing would have biased the training set and undermined the model's ability to handle real-world variation.
-
Most issues routed to model or sensor work
Documented issue patterns pointed more often to model classification limits or sensor signal quality than to the interaction design. That distinction changed where engineering attention needed to focus.
-
Parallel studies needed clean routing
When participant pools overlapped across concurrent studies, session data could not be cleanly tied to a single protocol. Without explicit routing, mixed data would have been indistinguishable from clean data, making validity criteria unenforceable.
Define valid sessions before outputs.
The recommendation made the evaluation system explicit: what to measure, how to classify issues, and where each issue should go.
| Issue type | Routed to / next step |
|---|---|
| Model issue | Research science team / training data workflow |
| Sensor issue | Setup protocol / hardware calibration |
| Protocol issue | Task wording / study flow redesign |
| Design issue | Interaction pattern / design follow-up |
-
Start with recalibration
Make calibration a required session-start step instead of something handled only after signal problems appeared. Consistency at setup was the precondition for interpretable gesture data.
-
Judge setup, not handwriting style
Valid data meant clean signal, correct sensor placement, confirmed task comprehension, and an intact protocol. Not controlled handwriting. Participants who wrote naturally were producing exactly what the model needed.
-
Route every ambiguous issue
Each ambiguous session received a documented classification: model issue, sensor issue, protocol issue, or design issue. Uncertain cases escalated to research science review rather than defaulting to pass/fail.
-
Separate studies at launch
Participant routing, data labeling, and protocol tracking needed to be distinct across studies running in parallel. Retrofitting those boundaries mid-program was expensive. Building them in at study launch was not.
Decision Impact
Issues became routed QA criteria.
- Issue routing
- A classification system separating model, sensor, protocol, and design issues, with documented reasoning and a defined escalation path for ambiguous cases
- Training data criteria
- QA criteria established with research scientists that defined valid sessions for model training, applied across a multi-study program running in parallel
- Publication
- Data contributed to foundational muscle-signal research and a peer-reviewed Nature publication on neuromotor interfaces
The issue-routing framework replaced priority debates with evidence. The model and implementation teams had shared criteria for what the data could support and a clear path for what each issue type required next.
Protocol quality is data quality.
Do not train away natural variation
The instinct to standardize handwriting was reasonable, but it conflicted with the system goal. The model needed natural variation, not idealized behavior.
RITE needed same-day coordination
Adjusting protocol between sessions required same-day alignment across engineering, research science, and program management. The loop worked because findings had a clear path into decisions. Without that infrastructure, findings arrived faster than anyone could act on them.
Validity mattered more than scores
The most useful output was not a gesture recognition pass rate. It was a precise definition of what made a session valid for model training. That gave the model team something to act on and the research team criteria it could defend.