ZUNA in the Pipeline: Foundation Model Denoising and Channel Reconstruction for EEG Preprocessing

Introduction

Every EEG preprocessing pipeline makes a bet about what "clean signal" looks like. Bandpass filters assume oscillatory structure in known frequency bands. ICA assumes statistical independence of source components. Artifact rejection thresholds assume that bad segments can be identified from amplitude or gradient alone.

These bets pay off most of the time — but they share a fundamental limitation: they reconstruct signal from signal. None of them have seen the brain before.

ZUNA takes a different approach. It is a generative foundation model trained on population-scale EEG data, and it ships in Nimbus Studio as the zuna preprocessing node. Instead of applying hand-coded transformations, ZUNA learns a prior over EEG structure — and uses it to denoise recordings, impute missing or corrupted channels, and optionally upsample bandwidth-limited data before any spatial filter is applied. If you're comparing foundation-model preprocessing approaches, REVE is the complementary node in Nimbus Studio — see EEG Foundation Models in Practice: What REVE Brings to BCI Preprocessing.

This post explains what ZUNA does, where it belongs in a Nimbus Studio pipeline, and when to reach for it versus simpler preprocessing methods.

What ZUNA Does — and What It Does Not

ZUNA solves three preprocessing problems simultaneously:

Denoising. Muscle artifacts, line noise, and amplifier interference corrupt EEG in ways that are difficult to separate from neural signal without a strong prior. ZUNA's generative model has that prior — trained over many subjects and sessions, it knows what plausible EEG looks like across scalp topographies and time, and uses that knowledge to suppress noise that does not fit the learned distribution.

Missing channel reconstruction. Real recordings routinely have bad electrodes — broken contacts, high impedance sites, bridging. Interpolating from neighbors is the standard fix, but it introduces spatial smoothing that degrades downstream spatial filters like CSP. ZUNA imputes missing channels from learned cross-channel correlations, producing estimates that are topographically consistent without artificially flattening the data.

Upsampling. Some hardware configurations or legacy recordings have limited bandwidth. ZUNA can upsample the temporal resolution of EEG data, recovering high-frequency structure that simpler resampling methods cannot.

One critical caveat: ZUNA outputs are model-imputed signals, not clinical ground truth. The node documentation is explicit about this. For research preprocessing — building better training sets, improving SNR before spatial filtering, recovering usable data from imperfect recordings — ZUNA is excellent. For clinical validation or regulatory submissions, treat its outputs as processed research data, not raw measurement.

Where ZUNA Fits in a Nimbus Studio Pipeline

ZUNA is a batch-only, build-mode node. It does not run on the live streaming path, which means it belongs in your training and research pipelines — not in your deploy graph. This is the right constraint: denoising with a generative model takes real compute, and you do not want that latency in a real-time loop.

The canonical position for ZUNA is after initial frequency filtering and before epoching and spatial filtering (and if you plan to carry this pipeline into a live deploy graph later, make sure the rest of your preprocessing chain is streaming-safe — Causal Filters for Streaming BCI is the practical reference):

custom_data / public_data
  → bandpass_filter + notch
  → ZUNA (denoise / reconstruct)
  → epoching
  → csp
  → NimbusLDA / NimbusQDA
  → results_output

Applying bandpass and notch before ZUNA is intentional. You want to remove gross line noise and drift before handing data to the generative model — this prevents ZUNA from "explaining" artifacts that are definitionally not neural signal. After ZUNA, the denoised data feeds into epoching and CSP exactly as raw data would, with no changes to downstream node configuration. (If your recordings are dominated by eye blinks, muscle bursts, or electrode pops, you may still want a classical cleanup stage; see ICA, Artifact Rejection, and EOG Removal in Nimbus Studio.)

Cloud GPU via Modal. ZUNA is a large foundation model and runs slowly on CPU. Nimbus Studio supports offloading ZUNA to Modal's cloud GPU infrastructure — enable this in the node's settings when iterating on datasets that would otherwise require multi-hour local runs. Note that Modal cold starts add latency; caching model weights between runs is strongly recommended when running repeated experiments.

When to Use ZUNA — and When Not To

ZUNA is worth adding to your pipeline when:

• You have missing or bridged channels. Standard spherical spline interpolation works but smooths the data. ZUNA's imputed channels preserve more spatial structure, which matters for CSP and xDAWN downstream.
• Your recordings are noisy but recoverable. If a calibration session has high-amplitude EMG bursts or intermittent noise that ICA cannot cleanly separate, ZUNA can recover more usable epochs from the same recording.
• You are building a training set from heterogeneous data. When pooling recordings across sessions, subjects, or hardware, ZUNA can normalize preprocessing quality before you compute features, reducing spurious between-session variance in your training data (and you can sanity-check generalization early by benchmarking on public datasets before you ever deploy).
• You are using the public_data node for benchmarking. Public EEG datasets often have inconsistent preprocessing histories. Running ZUNA as a normalization step before CSP or xDAWN can improve cross-dataset comparability.

ZUNA is not the right choice when:

• You are debugging a pipeline regression. If a change to your pipeline broke something, ZUNA's generative outputs make it harder to trace the root cause. Disable it and compare against simpler denoisers to isolate the issue.
• Your data is already clean. On high-quality recordings with no missing channels, ZUNA adds compute cost without a proportional benefit. Plot raw vs. imputed PSD before committing to it in your pipeline.
• You are preparing a deploy graph. ZUNA is batch-only — it cannot be added to a live streaming pipeline. Your deploy graph should use causal bandpass and notch only (and if you're trying to preserve accuracy across multi-day use, see Decoding Under Drift for how NimbusSTS handles cross-session non-stationarity).

Comparing ZUNA and REVE in Nimbus Studio

Nimbus Studio ships two foundation model nodes: ZUNA and REVE. They solve different problems.

REVE produces embeddings — it takes preprocessed EEG and outputs a learned representation that replaces hand-crafted features like CSP or band-power. REVE is a feature extractor that belongs after preprocessing, before the classifier.

ZUNA operates in the signal domain — it takes raw or lightly filtered EEG and outputs denoised EEG. It is a preprocessing step, not a feature step. ZUNA and REVE can coexist in the same pipeline:

custom_data → bandpass → ZUNA → epoching → REVE → NimbusSoftmax

This combination is computationally expensive but represents the strongest foundation-model preprocessing chain currently available in Nimbus Studio. Both nodes support Modal offload for GPU acceleration.

Practical Notes for Research Pipelines

A few things to keep in mind when running ZUNA in production research pipelines:

Always compare raw vs. imputed PSD. Before trusting ZUNA's output for a new dataset, plot the power spectral density of raw and ZUNA-denoised signals. If ZUNA is suppressing genuine neural oscillations or introducing spectral distortions, you will see it in the PSD before it propagates downstream.

Schedule GPU runs carefully. ZUNA and EEGNet both compete for Modal compute minutes. If your team runs both, coordinate scheduling to avoid contention. Cache ZUNA model weights between executions — reloading from cold storage on every run adds unnecessary latency.

Do not use ZUNA outputs as ground truth for ICA validation. ICA component quality is sometimes assessed against the raw signal. ZUNA-denoised data has already been transformed by the generative model, which can make ICA components appear cleaner than they would on truly raw EEG. If ICA validation matters for your analysis, run it on the pre-ZUNA signal.

Keep ZUNA out of your cross-validation split logic. ZUNA processes the full recording before epoching. If you run ZUNA before splitting into train and test epochs, there is no data leakage in the statistical sense — but ensure your evaluation plan reflects that the preprocessing was applied globally, not per-fold.

Conclusion

ZUNA fills a gap that classical preprocessing cannot: it brings learned population-scale EEG structure into the preprocessing step itself, rather than treating denoising as a purely signal-processing problem. For research pipelines where recording quality is variable, channels are missing, or you need the strongest possible training data for a Bayesian decoder, ZUNA is the right tool to add after your frequency filters and before epoching.

The constraints are real — batch-only, computationally expensive, not for clinical ground truth — but within those constraints, ZUNA gives BCI researchers a meaningful quality floor that hand-tuned classical methods cannot reliably provide.

To add it to an existing pipeline in Nimbus Studio, drop the zuna node between your notch filter and epoching node, enable Modal offload, and compare your downstream classifier metrics against the baseline. On noisy datasets, the improvement in CSP and NimbusLDA performance is often visible in the first run.