Privacy & Your Data
Every EEG recording you load into the Coherence Workstation stays on your computer. The processing pipeline runs locally. The reports are generated locally. The stage files, the spectral maps, the connectivity matrices, the ICA decompositions—all of it lives on your disk, in your workspace folder, under your control. Nothing is uploaded to our servers, nothing is streamed to the cloud, nothing leaves your machine without your explicit knowledge.
That’s the baseline. But there are two features that do communicate over the network, and you deserve to know exactly what they send.
The AI Research Assistant
Section titled “The AI Research Assistant”When you use the AI Research Assistant, the application sends anonymized analysis context—summary statistics, spectral features, connectivity metrics, interpretive markers—to the AI provider you’ve configured. It sends analysis, not recordings. No raw EEG timeseries data ever leaves your machine through this channel. No filenames. No patient identifiers.
The AI Research Assistant is covered in more detail on its own page. The key point here is that it’s opt-in, it sends derived features rather than source data, and you can see exactly what’s being sent before it goes.
Crash Reporting
Section titled “Crash Reporting”Software crashes. When it does, the question isn’t whether to report the error—it’s whether the report can be trusted not to carry something it shouldn’t.
The Coherence Workstation includes an optional crash reporting system that sends anonymous technical data when something goes wrong: stack traces, error messages, the application version, your operating system. The kind of information a developer needs to find and fix a bug. It does not send EEG data, patient names, session content, or clinical results. Ever.
But “we don’t send patient data” is easy to say. The harder question is: what about file paths? A stack trace might include /Users/clinician/Cases/John_Smith/intake_recording.edf—and now a patient’s name is sitting on a server somewhere. That’s not acceptable.
How PHI Scrubbing Works
Section titled “How PHI Scrubbing Works”Every crash report passes through a scrubbing layer before it leaves your machine. This isn’t a server-side filter—it runs locally, before the data is transmitted. The scrubbing is aggressive and specific:
File paths are stripped to basenames. If an error involves /Users/dr.martinez/Clients/Jane_Doe/2024-03-15/resting_eo.set, the crash report sees only resting_eo.set. The directory structure—which is where patient-identifying information typically lives—is removed entirely. This applies to stack frames, error messages, and breadcrumb logs.
Request bodies are dropped. Any HTTP request data attached to an error event is discarded before transmission. The crash report carries the fact that an error occurred during a particular operation, not the content of that operation.
Breadcrumb messages are scrubbed. The application logs a trail of recent actions leading up to a crash (clicked a button, loaded a view, switched a tab). Any file paths embedded in those breadcrumbs are stripped using the same basename rule.
The scrubbing runs in both the desktop application and the processing pipeline independently. Both use the same logic: detect anything that looks like a file path, reduce it to the filename alone.
What a Crash Report Actually Contains
Section titled “What a Crash Report Actually Contains”After scrubbing, a typical crash report includes:
- The error type and message (e.g., “Cannot read property ‘channels’ of undefined”)
- A stack trace showing which functions were executing, with filenames reduced to basenames
- The application version and operating system
- Which part of the dashboard was active (e.g., “Connectivity step, Eyes Open tab”)
- Timestamps
It does not include session data, spectral values, connectivity matrices, patient identifiers, or anything derived from the recording itself. The report tells us where the code broke. It tells us nothing about whose data was loaded when it happened.
Your Control
Section titled “Your Control”On first launch, the application asks whether you’d like to enable crash reporting. You can change your answer at any time in Settings, under the Privacy section. When crash reporting is off, nothing is sent—errors are still logged locally to your machine’s log files, but they stay there.
If you ever need to share detailed debugging information with us—log files, reproduction steps, specific session data—that happens out of band, directly between you and Peak Mind, on your terms. The crash reporting system is for automated, anonymous, scrubbed error telemetry. Anything beyond that is a conversation, not a feature.
Exporting Logs
Section titled “Exporting Logs”The application maintains local log files for both the desktop interface and the processing pipeline, capped at 10 MB each with automatic rotation. You can export these at any time through Help, then “Export Logs”—the application bundles both log files into a zip archive and lets you choose where to save it. These logs stay on your machine unless you choose to send them to us.
The Short Version
Section titled “The Short Version”Your EEG data never leaves your computer. Crash reports are scrubbed of file paths and patient-identifying information before transmission, and you can turn them off entirely. The AI Research Assistant sends derived analysis features, not raw recordings. Log files are local. If we need more information to debug a problem, we’ll ask you directly—and you’ll decide what to share.