Brain Neural API

Signals need context. Not guesswork.

Explore brain-signal data interfaces through channel metadata, timing, research consent, and reproducible processing.

01 / THE BOUNDARY

Describe the recording

Identify channels, units, sampling information, and what each timestamp represents.

02 / THE BOUNDARY

Preserve the provenance

Keep source recordings and derived data distinguishable, with documented transformations.

03 / THE BOUNDARY

Review before interpreting

Test the software with synthetic fixtures and avoid unsupported claims about a person.

A data interface is not a mind-reading interface

This brain neural API track concerns research-oriented biosignal data processing. It is separate from an ordinary language-model API. The central contract describes measurements: channels, units, sampling information, timestamps, and the conditions under which data was collected.

No example on this site diagnoses a condition, interprets someone's private thoughts, or provides medical guidance. Use synthetic fixtures or appropriately authorized recordings for initial software tests. Claims about people require evidence and review beyond a working data pipeline.

Preserve meaning at the acquisition boundary

Describe every channel

Keep device-specific channel mapping and transport details inside a documented acquisition adapter. Downstream code should receive explicit labels and units rather than assume that a copied array index always represents the same measurement. A missing channel must remain different from a measured zero.

Name the timestamp

A timestamp may describe measurement, transmission, receipt, or application processing. Those are different events. Preserve the intended meaning and known timing uncertainty. Test gaps, duplicate packets, reordered blocks, and reconnects before treating a sequence as continuous.

Record the transformation

Keep raw and derived records distinguishable where the research and retention policy permits. Record the source session, transformation settings, and software configuration. Do not silently overwrite a source recording with a filtered version that a later reviewer cannot reconstruct.

Use synthetic data to test the plumbing

Start by validating storage, channel order, units, export, and visualization with fixtures whose expected structure is known. Include a missing channel, an empty block, and a timestamp discontinuity. Label synthetic sessions in both the files and the interface so they cannot be confused with participant recordings.

A smooth chart is not evidence that the pipeline preserved every measurement or that an interpretation is scientifically valid. Show units, time range, raw-versus-derived status, and known gaps beside any visualization. Avoid decorative cognitive or health scores unsupported by the specific research.

Design participant protections before collection

Define purpose, consent, access, retention, and withdrawal handling before collecting data from people. Consider metadata and notes as well as the signal itself. Separate re-identification information where appropriate and avoid uploading sensitive recordings to a general AI service merely because it accepts files.

For model evaluation, preserve participant and session boundaries. State whether the experiment tests a new segment, a new session, or a new person. A software interface can be well engineered while the interpretation remains unvalidated; keep those achievements separate in reports and product language.