Device makers who have built a working research prototype of a neuro-rehabilitation device and are preparing for their first investigational study often hit the same wall. The device works. The firmware is reasonably stable. The signal quality is good enough that the research team is getting consistent results in the lab. Then someone asks what the device logs, how it logs it, and how a clinician or research nurse in a different building would know whether the device is operating correctly during a session. The answer is usually "we'll figure that out."
The figuring-out stage is where many neuro-rehab device timelines slip by twelve to eighteen months. Not because the engineering problem is hard in principle, but because the firmware infrastructure that handles data logging, protocol parameterization, session state management, and fault reporting was designed for bench use, not for a structured protocol validation context. Retrofitting it later is difficult because those concerns touch every layer of the stack.
This post is about the protocol development bottleneck and how the Ruten middleware is designed to narrow it.
What Protocol Validation Actually Requires
Before a neuro-rehab device can be used in an IRB-approved study or a formal clinical evaluation, the device's behavior needs to be documentable in a way that allows a third party to verify that the device was operating as intended during each session. That is a deceptively broad requirement.
At minimum, it means the device must produce a session log that records: stimulation parameters delivered (amplitude, pulse width, frequency, electrode channels), the timing of each stimulation event relative to a synchronized time source, any fault or safety-limit events that occurred, and the neural signal features that triggered any closed-loop adaptations. If the stimulation is adaptive, the log also needs to capture the adaptation rule and the parameter values that resulted from each adaptation step.
None of this is exotic. The challenge is that a research prototype typically records this information in an ad hoc way. Stimulation parameters are set from a debug terminal. Neural signal features are logged to a .csv file that the research engineer generates from a custom Python script. Fault events are handled by a flag in firmware that gets cleared on reset. None of that is traceable in the way that a protocol evaluation requires.
The Firmware Infrastructure Gap
There is a specific version of this problem that we have encountered repeatedly. A device maker builds prototype firmware optimized for research iteration. The firmware is fast to modify: stimulation parameters can be changed by editing a header file and reflashing, neural signal processing can be tuned by adjusting constants in a Python coprocessor script. That flexibility is the right property for research.
The problem is that research-iteration flexibility and protocol-validation traceability are structurally in tension. A firmware where any parameter can be changed at any time with no audit trail is useful for exploration and dangerous for a formal evaluation where the investigator needs to attest that device behavior was consistent with the approved protocol. The device maker ends up needing to build traceability on top of a system designed for flexibility, which is significantly harder than designing for both from the start.
The Ruten middleware approaches this by separating the parameter surface into two layers. The research configuration layer allows free parameter modification during development: thresholds, feature extraction parameters, stimulation waveform shapes, and control policy parameters. The protocol configuration layer is a structured record that specifies the parameter set for a defined protocol session. Once a protocol configuration is loaded, the stimulation command bus and decoder operate within the bounds declared in that record and log any deviation as an anomaly event.
Session State and Safe-State Transitions
A protocol-ready device needs to handle the transition between session states in a documented way. The states that matter for a closed-loop stimulation device are: standby (device powered, no stimulation active), calibration (device collecting baseline neural activity for decoder initialization), running (closed-loop control active), paused (control suspended, device maintaining safe state), and terminated (session ended, logs finalized).
Each transition needs to be: initiated by an explicit command, logged with a timestamp, and reversible only through a specific path. A device that can silently re-enter the running state from a paused state, for example through a firmware watchdog reset, will produce session logs that are difficult to interpret. Was stimulation delivered during the period when the device appeared paused? The firmware needs to answer that question unambiguously.
In the Ruten SDK, the session state machine is implemented in the application layer, but the middleware provides the underlying primitives: the stimulation command bus enforces the inhibit flag that the state machine sets when entering paused or standby states, the decoder output is gated at the application boundary so that no stimulation commands can be generated during a pause, and the event log records every state transition with the timestamp from the acquisition clock.
Data Logging Format and Downstream Usability
A session log that lives on the device's internal flash and can only be extracted through a proprietary debug interface is not useful for protocol validation. The log needs to be extractable in a format that a clinical data management system can read, or at minimum that a researcher can process without writing custom parsing code.
The Ruten SDK session log format is structured binary: a fixed-length header record per session followed by a sequence of typed event records, each with a timestamp, event type, and payload. A reference Python reader is included in the SDK distribution. The format is also designed to be appendable: if a session is interrupted and the device restarts, the log for the resumed session appends to the existing file rather than overwriting it, and the interruption event is recorded as an anomaly.
We made the decision early to not use a custom binary format for the neural signal data itself. The raw neural waveforms and decoded features are logged in a subset of the Neurodata Without Borders (NWB) schema, serialized using a compact binary representation. NWB is the de facto standard for electrophysiology data in the research community, and designing for compatibility with existing NWB tooling avoids the situation where every research partner needs to write a custom data importer. That said, we use a subset of the schema rather than full NWB compliance, because a full NWB implementation is significantly heavier than an embedded device firmware can carry.
Where Middleware Shortens the Gap
The argument for putting protocol infrastructure in middleware rather than requiring each device maker to build it from scratch is the same as the argument for middleware generally: the patterns are repetitive, the failure modes are shared, and the cost of getting it wrong is high.
A device maker building protocol infrastructure from scratch will make the same mistakes that other device makers have made: the session log format will be designed around the research use case and then retrofitted for traceability; the safe-state transition logic will have at least one edge case where stimulation can resume without an explicit command; the data export format will require custom tooling to process. These are predictable outcomes not because device makers are careless but because the requirements are not visible during research-phase development.
The Ruten SDK ships a default session state machine and a default log format as part of the protocol layer. Device makers can override either to match their specific protocol requirements, but the defaults are designed to be acceptable for a first evaluation cycle without modification. That means the firmware engineering effort during protocol preparation focuses on what is genuinely device-specific: the control policy, the user interface, the calibration procedure. The infrastructure for logging, state management, and safe-state handling is already there.
A Realistic View of What Middleware Cannot Do
Middleware cannot substitute for the regulatory strategy work that goes into a formal clinical evaluation. Writing the protocol, defining the primary endpoints, conducting the risk analysis under ISO 14971, and working through the investigational device exemption process: none of that is a software problem. The middleware can ensure that the device logs the data needed to answer the protocol's questions. It cannot determine what questions the protocol should ask.
The protocol development cycle that the middleware shortens is specifically the firmware-readiness portion: getting from a research prototype where stimulation parameters are configured via serial console and logs are custom Python output, to a device where session behavior is defined by a loaded configuration record, all stimulation and anomaly events are logged in a consistent format, and the session state machine prevents unintended state transitions. That transition typically takes a team three to six months when starting from scratch. With middleware that handles the infrastructure layer, the estimate from the device makers we have talked with in early integration discussions is closer to four to eight weeks.