Download protocol (Markdown)

Online stop-signal task: full administration and separate short pilot

Prepared 20 October 2026 · implementation sst-2026-10-20.3

Purpose and interpretation

This is a new standalone task for the existing HAWTIEL website. It measures performance in a two-choice visual stop-signal procedure. Its primary research outcome is an estimate of stop-signal reaction time (SSRT), conditional on data-quality checks. It does not diagnose impulsivity or a clinical condition. SSRT includes detection of the stop cue as well as the processes involved in cancelling a response.

The methodological basis is Verbruggen et al. (2019), A consensus guide to capturing the ability to inhibit actions and impulsive behaviors in the stop-signal task, eLife 8:e46323, DOI 10.7554/eLife.46323. The publisher page was blocked during retrieval; the paper was read through the author manuscript at King's College London, including the methods, reporting checklist and simulation appendices. The PMC record identifies the same article and its CC BY licence. The exact schedules, interface, timing limits, and technical exclusion policies below are implementation decisions, not a task prescribed or validated by the paper.

The paper is a consensus methodology guide, not evidence that this particular browser implementation has established validity. Its simulations show why few stop trials, go omissions and skewed response times can undermine estimation. More trials generally help, but do not guarantee reliable individual scores. The power simulations also show that unequal go performance between groups can bias comparisons even with the preferred estimator. Plan sample size using the intended population and effect size; use the authors' simulation resources if appropriate. No sample-size claim is made for this implementation.

Two separate schedules

These durations include an allowance for instructions and short breaks; trial presentation itself takes about 9 minutes 28 seconds in the full task and 2 minutes in the pilot, before frame rounding. Breaks are self-paced. The full task exceeds the paper's rule of thumb of at least 50 stop trials for standard group comparisons. Sixty is not a reliability guarantee, particularly for individual differences. The pilot deliberately falls below that threshold and is solely for testing comprehension, presentation, keyboard input, feedback, interruptions, exports and database submission. Do not combine its data with the full sample or present its stopping rate as an ability score. Use a new session for each run.

Task and timing

Participants press the physical left or right arrow key for the corresponding central arrow. On stop trials a large red XX appears above the arrow. The arrow stays visible to avoid erasing its directional information. Shape as well as colour identifies the stop cue. No sound or external stimulus downloads are required.

Every trial has 500 ms fixation, a 1,000 ms response interval from arrow onset, and 500 ms intertrial time. The trial does not terminate on a response. The stop cue is still presented after an early response on a stop trial. Practice feedback occupies the intertrial interval; main trials have no immediate performance feedback. The response deadline is enforced by the response handler, even if the display callback is late.

A single adaptive staircase starts at 300 ms SSD in mixed practice, resets to 300 ms at the first main block, and carries across subsequent main blocks. It rises 50 ms after a successful stop and falls 50 ms after any failed stop, including a wrong arrow response or response before the stop cue. Bounds are 0–900 ms. These bounds are engineering choices to keep the cue inside the response interval. Trials affected by a technical disruption do not update the staircase. Record boundary occupancy during analysis; frequent hits at 0 or 900 ms warrant inspection.

Each block contains exactly 25% stop trials. Fisher–Yates shuffling randomizes all trial positions without forced initial go trials or restrictions on consecutive stops. Directions are as balanced as possible within go and stop trials, with the extra direction alternating across main blocks. Since each full block has odd counts of go and stop trials, single blocks have a two-trial direction imbalance; the complete main schedule is exactly balanced. The seed and actual schedules are exported for reconstruction.

Participant instructions and practice

The participant is told to respond as quickly and accurately as possible, release each key, and avoid waiting for a possible stop cue. They are told that stop timing adjusts and that responding on about half of stop trials is expected even when trying their best. This is not an instruction to deliberately respond on half the stop trials: they should always try to stop when XX appears.

Arrows-only practice must reach at least 80% correct, technically valid responses. Below this implementation-defined threshold, the session ends with an invitation to review instructions with the researcher and begin a fresh session; practice data can be downloaded. Mixed practice demonstrates stopping, followed by feedback on mean go RT, missed arrows, and stop response rate. Researcher review is advisable if mixed practice shows misunderstanding; no automatic mixed-practice repeat is imposed because the short sample gives a very coarse stopping rate.

Every intervening main-block break shows mean go response time, go omissions with a reminder to aim for zero, and percentage of stop trials with a response with an approximately 50% expectation. It repeats the instruction not to wait. The final screen reports completion and saving, not a participant-facing ability score.

Scoring and quality rules

Practice data are always excluded from main estimates. Keep all raw trials and report exclusions. Technical invalid trials are omitted from the working summary but retained with explicit reasons. Because removing trials can change estimates, report their frequency and inspect sensitivity to exclusion in the study analysis.

The race-model ordering check compares mean failed-stop RT against mean RT of all responded go trials, including choice errors and premature responses. The same inclusive response policy is used for the integration distribution. Responses during fixation are recorded with a negative RT relative to the subsequent arrow; responses after the arrow but before the stop cue count as failed stops. Only the first response is scored; subsequent presses are counted. Key autorepeat is ignored. A key held over from the previous trial without a new keydown is a technical flag, not a fabricated response.

The integration estimator sorts all go RTs, replacing each omission with the largest observed go RT in the usable main sample. The rank is ceil(number of go trials × probability of responding on stop trials), using a one-based rank; the explicit ceiling convention avoids ambiguity for noninteger ranks. Subtract the mean observed stop delay from this ranked RT. Mean go RT minus mean SSD is not used. Browser-observed onset differences are used for the primary estimate; requested delays are retained for auditing.

SSRT is set to null, with reasons, if any of these apply:

• Pilot edition or incomplete session.
• Fewer than 50 technically valid main stop trials.
• Stop response probability below .25 or above .75 (boundary values are allowed).
• No usable go responses or failed-stop responses.
• Mean failed-stop RT is greater than mean responded-go RT.
• Go omissions exceed 10% or go choice errors exceed 10% of technically valid go trials.
• More than 5% of attempted main trials are technically invalid.
• The resulting SSRT is zero or negative.

The .25–.75 bounds and race-model ordering check follow the paper. The 10% omission/error thresholds, 5% technical threshold, 50 valid-stop requirement and nonpositive-estimate guard are explicit conservative defaults for this implementation. The paper does not prescribe a universal omission cutoff. Review and preregister thresholds for the intended population before collecting research data. Passing these checks does not prove all independent-race-model assumptions.

The estimator does not model stop-trigger failures. This follows the paper's warning that standard nonparametric SSRT can be biased by failures to initiate stopping. No dedicated zero-SSD diagnostic trials are added. Staircase trials that naturally reach zero are retained and must not be mistaken for a separately powered trigger-failure diagnostic.

Browser measurement and interruptions

Visual updates use requestAnimationFrame and response timestamps use performance.now. Exported onset values describe browser callback timing, not independently measured physical light onset or keyboard latency. Display refresh quantizes cue timing. Validate on the browsers and devices you intend to support; hardware timing validation is required for claims about physical timing accuracy.

A frame gap exceeding 50 ms during fixation or the response interval marks that trial invalid. This threshold, fixed across devices, is a technical policy rather than a physiological standard. A missing stop presentation also invalidates the trial. Losing focus or hiding the tab ends the current trial as invalid and pauses before proceeding. Interrupted trials are not silently repeated, replaced or counted as successful stops. Remaining trials continue after the participant explicitly resumes. A session with extensive interruptions may therefore have no SSRT.

Escape ends the session. Refreshing cannot resume an unfinished task: it offers recovery of existing trial data and a fresh session. This avoids undocumented restarts of the adaptive process. The tab keeps a sessionStorage backup between trials, including its authentication token; exports omit the token. Closing the tab removes that backup. Avoid running extensions or other heavy software during testing.

Administration on HAWTIEL

Upload the new public_html/stop-signal/ directory to /stop-signal/ on the existing HTTPS website. It reuses api/bootstrap.php and the existing private MySQL configuration. It does not require a schema migration: the existing task_name and study_id columns are VARCHAR fields. The current two-task battery, its links and completion checks are unchanged.

Participant links:

• Full entry: /stop-signal/consent.html?edition=full (the existing /stop-signal/full.html link also redirects here for a new participant)
• Pilot entry: /stop-signal/consent.html?edition=pilot (the existing /stop-signal/pilot.html link also redirects here for a new participant)
• Researcher landing page: /stop-signal/
• Whole-flow previews: append &demo=1 to either consent entry link. These do not create database participants or upload consent/demographics/results; use fictional answers. Direct task previews with ?demo=1 remain available for task-only testing.

Normal sessions now begin with a dedicated study-information and consent page, followed by demographics and a Hawtiel-branded “Get comfortable” page. Participants must confirm they are using a desktop or laptop with a physical keyboard before continuing to the task instructions and keyboard check. The page uses the existing researcher contact and consent structure, adapted to the stop-signal procedure and actual data storage. Review that wording against the intended study before recruitment. The consent and demographics pages use the existing executive-functions study styling. The questionnaire collects gender (Male/Female/Other), age (18–120) only; no names are requested. Consent text describes the coded linkage between the participant record and task results.

Normal sessions create a new participant and browser token when consent is submitted. Demographics are validated and saved to that same participant record before practice. A direct full/pilot task link redirects to consent when the required intake is missing; result submission is also blocked server-side until demographics are saved. The server distinguishes stop_signal_standalone_full from stop_signal_standalone_pilot. Both use task_name stop_signal, associated with distinct participant rows, and order_code SF or SP. Join task_results to participants and filter study_id; historical stop_signal results are a different dataset. The payload is JSON, not the archived task's CSV format.

On completion the endpoint saves the full JSON payload and marks that standalone participant complete in one database transaction. Retries are idempotent for that participant. The endpoint checks the participant token and study edition, expected main-trial count, stop-trial count and completion marker. Client-derived statistics remain untrusted research output: recompute from exported raw records for final analysis. Failed saves offer retry and JSON/CSV downloads; a recovered completed tab can retry. Unfinished sessions are not uploaded as results, although a consented participant row remains. Partial local data can be downloaded.

Demographic answers remain in the participant database record and are not copied into task JSON/CSV or browser backups. JSON contains the full metadata, schedule, timing settings, trial records, events, block summaries, aggregate descriptive statistics, SSRT and withholding reasons. CSV contains individual trial rows with session identifiers, edition, version and seed. Export and store files using your existing study procedures. No public results-listing endpoint is added.

Pre-recruitment validation

1. Upload the directory alongside the existing API. Keep private configuration outside the public root.
2. Complete a short pilot over HTTPS using a physical keyboard. Check both arrows, stop display, practice feedback and between-block feedback.
3. Verify a participant row with study_id stop_signal_standalone_pilot, exactly one task_results JSON row, status complete, 40 main trials and 10 main stop trials, and null SSRT.
4. Disconnect after starting a pilot, complete it, verify a visible saving failure, reconnect and retry. Confirm the same row is updated, not duplicated.
5. Test tab switching, Escape and refresh recovery. Check flags and partial export behavior.
6. Complete a full session. Confirm 240 main trials and 60 stops; examine observed/requested SSDs, omissions, boundary hits, timing flags and any SSRT withholding reasons. A deliberately poor or disrupted run should not produce an SSRT.
7. Check that the existing two-task journey still works. Inspect the intended desktop/browser combinations and only then recruit.

Automated checks cover schedules, estimator examples, invalid-data gates, browser state transitions and existing repository regressions where available. Live PHP/MySQL and physical screen/keyboard timing require deployment testing; neither can be established by static checks alone.

Reporting checklist

Report stimuli, key mapping, equipment, browser restrictions, counts including practice, exact timing, stop-cue position, randomization, staircase start/step/bounds/reset behavior, instructions, break feedback and practice gating. Report the estimator and quantile convention, omission replacement, treatment of errors and premature responses, technical exclusions and prespecified participant exclusions. For every group/condition include go RT and variability, go omissions, go choice errors, stop response probability, mean SSD, failed-stop RT and SSRT. Report excluded participant counts and descriptive performance separately where possible. Retain the implementation version and anonymized trial data to support reproducibility.

Direct-file local previews

Double-click pilot.html or full.html to preview without a server. Open index.html to start with consent and demographics. Direct-file previews never upload data. Keep the folder together. Generated classic scripts avoid the module-loading restriction on local files; rebuild them with self-hosted/build-stop-signal.mjs after source edits. File-based storage restrictions vary by browser; localhost previews remain available.