Consent, safety and dates: the whole flow

This page follows one session from the lab administrator's setup to the last file it can write, and says at each step what the toolbox records and what it refuses. It is a map: every mechanism is explained once, in the page it links to. Read it first, then follow the links for the detail.

What the toolbox does not do

Stated first, because the rest of the page can read as more than it is.

• It does not give ethics approval, and it does not replace it. Whether a study may collect data, under which wording and with which hardware, is decided by whoever governs your research. The toolbox enforces the constraints it was given and states them. It records no approval decision of its own: the approval-envelope id a run may carry is what the site configured, not a verdict that the study is approved.
• It shows participant screens only for research and teaching. A research session whose option the participant gives on screen gets the safety screen, the consent form (on_screen protocols) and the data-use question at lock. A teaching session gets the safety screen alone. Pilot sessions, and research where the operator enters the option under a paper or none protocol, see no participant screen, so their safety screening belongs in the study's own materials. See who enters the option and safety screening.
• It cannot verify what happened in the room. The operator's entry of a choice, and the attestations on a pilot, are records of what the operator says. Safeguards help an operator avoid mistakes. They do not police an operator who misstates a purpose.
• It does not hide everything about when a recording was made. Dates are shifted, but file-system timestamps, the toolbox version and free text are not covered. See dates.
• It does not migrate old data. A recording made before the stamp existed is refused by every gate, apart from the teaching rule in what each stage refuses.

1. The administrator sets the frame

Three things are set before any participant arrives.

What	Where	Effect
The kind of machine (lab, teaching, generic)	The site profile (Site profile)	Decides which purposes the machine offers, and whether a research protocol with no wording is refused (lab) or given the built-in generic wording (generic).
Who enters a research participant's option (data_use.tier_entry)	The site profile, §6b	participant (default) or operator.
The wording, the tiers offered and the minimum	The protocol's data_use block (Protocols and sessions)	The words the participant is given, verbatim, and the lowest option that lets a session be recorded.

A site profile can only make the toolbox more restrictive. No key in it widens what a tier allows.

2. Purpose and tier

Set up Session asks for the purpose first, offering only what the machine's kind allows, then asks only what that purpose needs.

• research: a participant consented and chose a tier.
• pilot: a member of the team volunteered. The operator attests that the volunteer is a team member and that they consented orally. No name is recorded.
• teaching: a class. Course use only, or observer only.
• bench: nobody is in the chair, so every participant-facing step is skipped.

The tier is what the participant agreed to, and tiers are cumulative: 0 observer only, 1 this study only, 2 this study and future research by the team, 3 share openly. At lock, the purpose and tier are stamped into every file the session writes. One matrix decides what each stamp allows, and every gate reads it: Data governance has the table.

Who enters the option

data_use.tier_entry says how the choice reaches the toolbox.

• participant (the default): the participant chooses on screen. Pressing Lock runs the participant screens on the stimulus monitor, after every operator-side check: the safety screen, the consent form (on_screen protocols only), then the data-use question, which is asked in every consent mode. The session locks only once the participant has chosen, and the stamp records entered_by: "participant". Esc at any point, a safety statement that applies, declining the form, or an option below the minimum leaves the session unlocked with nothing written. Mouse and keyboard both work: Site profile §6b.
• operator: the operator enters the option the participant stated, after the participant has been given the protocol's wording in the study's own materials. The stamp records entered_by: "operator". A protocol whose consent is on_screen cannot be locked as a research session here: on-screen consent needs participant. Use a paper or none protocol.

Teaching, pilot and bench sessions do not read the setting.

Option 0: observer only

The participant takes part and nothing is kept. The session runs, with its questionnaires, and nothing is written: no recording, no questionnaire answer, no impedance log, not even briefly. There is nothing to delete later because nothing existed. An option below the protocol's minimum is a decline: the session does not run.

Lowering, never raising

While a session is locked, Lower data-use option offers only options below the current one. Any purpose with a person present can be lowered to observer only. The operator enters the participant's new choice. After unlock nothing can be lowered, since nothing links the recording to the person any more.

• Lowering to another option rewrites the tier in every file the session saved. Every file is checked first, and one that cannot be lowered refuses the whole change.
• Lowering to observer only after something was saved is a deletion of the whole session's output, including its BIDS view, its analysis and any pooled contrast report that named it. The operator is told before it happens. When that deletes a participant's last session, the code is kept as an empty sourcedata/sub-XXX/.retired marker so it is never offered to anyone else (#141): the marker holds no data, no date and no name, so "nothing is written" for the participant still holds, and it is the one thing left of them. A deletion made by hand outside the toolbox leaves no marker and cannot be caught.
• Locking the same session again never raises the option.

Held pushes

Research and pilot sessions are not pushed to lab storage while they are locked, because a file already on a server is one a lowering cannot reach. Unlocking asks whether the session has ended and pushes what was held, or unlocks without pushing (to correct a detail and lock again); held files then wait for Review / push. Teaching data is never pushed. A bench session pushes as each run ends. The push guide that ships with a lab deployment has the detail.

3. Safety screening and flicker risk

• The photosensitivity safety screen is the first participant screen of a research session the participant answers on screen, and the only one of a teaching session. It shows the toolbox's core statements and any the protocol adds (a protocol can add statements and can never remove or reword a core one: Protocols and sessions), and takes one answer for the whole list. "One or more of these applies to me" ends the session before anything exists; the operator is told only that it can't go ahead, and the answer is recorded nowhere. A teaching session's student sees it at every lock, with no consent form and no data-use question, since a class is not human-subjects research. The policy flags every purpose with a person present as needing the screen (bench is the exception), but pilot and operator-entry research sessions do not run the participant screens in this version, so for them screening is done in the study's own materials.
• Flicker risk is graded at lock. The toolbox grades every run the way the builder does, shows the operator the session's highest grade and what raised it, and records both. A high grade with a human present needs an operator acknowledgement, which records the operator's id and a date-shifted time and nothing about anyone else. Cancel leaves the session unlocked. Bench sessions are not asked.
• An FPVS run is graded too. Its picture stream is flicker at the base rate, so its manifest describes it to the grading as the worst case it can be, a full-contrast white patch the size of the largest item, and it is acknowledged at lock like any other high grade (FPVS).
• Each run's sidecar carries its own grade, taken from the manifest actually run. The grade is separate from the data-use stamp and travels as one of four closed values (low, moderate, elevated, high). A recording made before grading existed has none recorded, which is never read as low.
• Nothing here refuses a stimulus, apart from an approval envelope a site chose to configure (Site profile), which, on a lab profile, applies to research sessions, only warns on pilots and does not apply to bench. The builder's photosensitivity warnings and the always-available abort are never weakened by any setting. The acknowledgement is described in Protocols and sessions, and the literature in the photosensitivity bibliography.

Dates are shifted as they are written

Every wall-clock time written into a participant's files passes through one function that moves it back by a random whole number of days. The offset exists only in memory and is written nowhere, so nobody, the lab included, can recover a real date from the data.

Two costs follow. A restart mid-session draws a new offset, and a multi-session study loses the interval between visits. Not hidden: file-system timestamps (an export regenerates files and fixes their times), the toolbox version, free text, and LSL sample times. Data governance has the full list.

4. What each stage refuses

Stage	Refuses
Lock	A research session with no recorded wording on a lab machine; a choice below the protocol's minimum; a research session under tier_entry: participant until the participant screens have produced the participant's answer (Esc or a safety stop leaves it unlocked); a research session under an on_screen protocol where the operator enters the option; a teaching session whose safety screen was stopped or answered "applies"; a subject or session label that reads as a date. A high flicker grade waits for an acknowledgement.
Recording	Anything at all under option 0. A timestamp that is not shifted is written as null, never as a real date.
Lowering	A change that cannot be applied to every file of the session, or that would raise the option.
Push	Any session whose stamp does not allow it, or whose stamp is missing or unreadable. Research and pilot sessions are held while locked. The push guide of a lab deployment.
BIDS conversion and analysis	A recording with no readable stamp, or one the matrix does not allow converting. Analysis follows conversion, so a refused recording never returns through a report. BIDS conversion
Contrasts	Anything but one purpose per contrast. Each excluded recording is listed with its reason. Between-condition contrasts
Export	Pilot, teaching and bench recordings always; research below tier 2 for future use, below tier 3 for public share; any unreadable stamp. Export and sharing

A missing or unreadable stamp reads as "no" at every stage. The one exception is an unstamped recording that counts as teaching, the most restrictive purpose: one that says it was made on a teaching machine, or one read on a teaching machine that names no kind or generic. One that says it was made on a lab machine is refused everywhere, and so is one carrying a legacy pilot marker.

For the administrator: a checklist

• Set the site kind and tier_entry in the site profile.
• Put the wording your ethics board approved into the protocol's data_use block, with the tiers your study offers and the minimum it requires.
• Confirm that any hardware or method the toolbox enables is covered by your approval before collecting. That is yours to do, and nothing in the toolbox records that it has been done.
• Tell operators who enters the participant's option on this machine (the participant on screen at lock, or the operator), and that lowering is available only before unlock.