Glossary¶
The toolbox borrows its vocabulary from fMRI convention (already standard in the lab that builds it) and keeps it consistent with BIDS. Every word below has one meaning everywhere in the toolbox — in the GUI, the schemas, the file names, and this documentation. None of them are interchangeable, and two of them (run, protocol) do not mean what they sound like they should mean, so read this before Getting started rather than after guessing.
Trials nest in blocks nest in runs nest in sessions.
| Term | Meaning |
|---|---|
| trial | One cue → stimulus → inter-trial-interval cycle. The smallest unit — a single flicker presentation the participant responds to (or just attends to). |
| block | A group of trials. For example, one trial at each target location, presented once each before the pattern repeats. |
| run | One continuous period of data collection. Everything recorded without stopping the amplifier — several blocks, uninterrupted. One run-NNN file, described by one run manifest. Stopping and restarting acquisition — even for the same design — starts a new run. |
| session | One participant's visit — an ordered set of runs, recorded in one sitting. One ses-YYY directory. |
| protocol | The instructions for running a session: which runs, in what order, what varies across them. A protocol is a template — authored once, reused for every participant who runs it — not a record of what happened to any one person. |
The two that trip people up¶
A run is not a trial, and it is not "a recording of one condition" either. It is bounded by the amplifier staying on, not by the design. A run can contain many blocks and many conditions, counterbalanced within itself, as long as acquisition never stopped.
A protocol is not a session. A protocol is the plan — the ordered list of runs and how each group's order is chosen for whoever runs it. A session is what actually happened when one particular participant ran it: their sub-XXX/ses-YYY, their derived run order, their recorded data. One protocol produces many sessions, one per participant (and, for a participant who returns, one protocol can produce more than one of their sessions too).
Related terms¶
| Term | Meaning |
|---|---|
| run manifest | The saved, versioned file describing one run's design — targets, timing, montage, and (once a protocol stamps it in) acquisition hardware. Never inferred from data; see Design principles. |
| session protocol | The saved, versioned file implementing a protocol: a fixed sequence of groups, each with its own run manifests and an ordering rule. |
| group | A protocol-level grouping of runs that is ordered together — fixed, counterbalanced, or randomized — and that pins the break-time questionnaire, when there is one, to the end of its runs. Not the same word as block: a block is inside a run's design, a group is inside a protocol's structure. |
| paradigm | Which task a run's stimulus presents — ssvep (flicker) or resting (eyes-open/closed, no flicker) — declared in the manifest, never guessed from what the data looks like. |
For how a protocol turns into a participant's actual run order, see Protocols and sessions.