What BCILattice Is

BCILattice is a desktop application for BCI and neurophysiology research. You install it on your own machine, and that machine does the work, importing recordings, filtering signals, designing paradigms, training models, and writing reports. There is no analysis server sitting between you and your data. The heavy compute happens on the workstation in front of you.

There is also a cloud side, BCINexus, but it is deliberately optional and deliberately narrow. It handles the things that only make sense across machines and people: your account, publishing studies, sharing studies with a team, browsing community work. Your raw brain recordings are not part of that picture unless you decide, file by file, that they should be.

The Local-First Idea

Everything else about the architecture follows from one decision: the most sensitive asset in the whole system, the raw signal recording, never leaves your machine on its own. It is not synced in the background. It is not uploaded "for processing". It sits in a directory you control until you take an explicit action to move it.

That constraint buys you a few things at once. The attack surface is small, because there is nothing inbound to attack. Data governance gets simpler, because for most workflows the answer to "where is the patient data?" is just "on the researcher's encrypted disk, and nowhere else". And you can run the whole app with the network cable pulled out, which matters a lot in a clinical or air-gapped setting.

How the App Is Put Together

What looks like a single desktop program is really three pieces running side by side on your machine: a native interface, a local service that does the actual work, and a set of local stores that hold the results. They all talk to each other over the loopback address, so none of that traffic ever reaches the network.

Desktop Interface

The window you interact with is built with PySide6, so it renders as a real native application on Windows, macOS, and Linux rather than a browser tab pretending to be one. Live signal views use PyQtGraph for GPU-accelerated plotting, and the heavier analysis figures come from Matplotlib. The interface itself holds almost no logic, when you click "train" or "preprocess", it hands the request to the local service and shows you what comes back.

Local Service

Behind the UI runs a FastAPI service, bound to 127.0.0.1 only. This is the part that reads files through MNE-Python, runs the filters, trains scikit-learn and PyTorch models, and generates reports. When you launch BCILattice, there is a short pause while this service comes up, that is the app getting its engine running. Because it listens on loopback and nowhere else, no other computer on the network can reach it.

Local Data Stores

Three things persist your work locally. A PostgreSQL database holds structured records: studies, sessions, pipeline history, settings. It is password-protected and, like the service, bound to loopback. MLflow keeps the experiment log, every training run with its parameters, metrics, and model artifacts. And a plain data directory on your filesystem holds the recordings and the derived arrays. The database remembers what you did; the filesystem holds the actual signals.

Modules

Inside a study you move between a set of modules, each one a stage in the research workflow. You don't have to use all of them, and you rarely go straight through in order, but this is roughly what each one is for.

How Data Moves Through a Study

A typical study runs as a pipeline, and it helps to see it as one. Here is the path a recording takes from the moment it lands on your disk to the moment it turns into a figure in a report.

1. Import. Data Manager reads the raw file through MNE-Python. The original is never edited in place, BCILattice works on derived copies in its own data directory.
2. Preprocess. Filters, referencing, and resampling produce cleaned arrays, which are cached so you don't recompute them on every run.
3. Define the paradigm. Neural Flow attaches the task structure, markers and timing, that gives the signal its meaning.
4. Build and train. The ML Suite compiles a graph of blocks, Workflow binds it to specific subjects and sessions, and the local service trains it.
5. Track. Every run is logged to MLflow, so a month later you can still see exactly which parameters produced which numbers.
6. Report. Results and Model Analysis turn the run into plots and tables, and Reports packages the whole thing for export.

Note what is not in that list: at no point does the recording get sent anywhere. The entire loop closes on your machine.

Where Things Live on Disk

The data directory is configurable and defaults to your home directory. BCILattice does not add its own encryption layer on top of these files, local security is your operating system's job, which is why full-disk encryption matters for sensitive work.

The Optional Cloud Half

BCINexus is the account and collaboration layer. You need an account to sign in, but past that point the cloud is something you reach for when you want it, not something running underneath everything you do. When it is in use, it carries metadata and configs, not raw signal, unless you explicitly upload a file.

In transit, all of this rides over TLS 1.3. At rest on the server side it is AES-256. Passwords are hashed with bcrypt and never stored in plaintext. The details, including HIPAA and GDPR readiness, live in Security & Compliance.

Network Topology

This is the part IT teams usually care about most, so it is worth being blunt. BCILattice does not accept any inbound connections. The local service and the local database are both bound to 127.0.0.1, which means another machine on the same network cannot see them at all. The only traffic that leaves your workstation is outbound HTTPS on port 443, and only when you use a cloud feature.

The AI Assistant

AI Chat is worth calling out separately, because it is the one place where the local-first rule bends, and you should know exactly how. It connects the desktop to a model of your choosing: a remote provider, or a local Ollama endpoint running on your own hardware.

The distinction matters. If you point it at a remote provider, the content of your prompt goes to that provider, that is simply how those APIs work. If you point it at local Ollama, nothing leaves the machine. For studies under a local-only data policy, use Ollama, or keep restricted content out of the prompt. The assistant is good for interpreting results, drafting report language, and untangling a training problem, but it is not a substitute for actual methodological review, and it shouldn't be treated as one.

Deployment Models

There is more than one way to get BCILattice onto a machine, and the right one depends on whether you are a single researcher or an IT department standardizing a lab.

For managed or on-premise deployments, including external database configuration and restricted-network activation, the Enterprise Guide is the place to start, or email [email protected].

Where to Go Next

Depending on what brought you here:

• Want the exact libraries and versions? Tech Stack lists every dependency and its licence.
• Sizing a machine or planning a rollout? System Requirements has the hardware, GPU, and network tables.
• Running a security review? Security & Compliance covers controls, encryption, and compliance readiness.
• Just want to use the thing? Getting Started gets you from install to first experiment.