research: state the build the participant instructions describe

[ErikBjare]

Follow-up to #181, which added a canonical participant-instructions page.

(Revised: an earlier version of this issue proposed Read the Docs versions. That is withdrawn — see "Rejected" below.)

The residual risk, stated narrowly

#181 fixed stale per-study instruction copies circulated over email. The inverse worry is that a study runs against one fixed build for months while the canonical page tracks master, so a participant could follow instructions edited for a newer release.

That risk is real but smaller than it first looks. A study going through ethics review already freezes its participant materials — the ethics submission carries a fixed attachment, which is standard practice. Studies snapshot; they do not generally point participants at a live URL.

So what actually went wrong in the cases #181 corrected was not the canonical page drifting under a study. It was studies freezing from email copies that were already stale at freeze time (pre-b5 autostart, the per-bucket export menu). The fix for that is having a correct, maintained source to freeze from, and #181 delivered it.

What remains is the narrow case: a study that links the live page instead of snapshotting, or a researcher re-reading it mid-study and finding it changed. That deserves a label, not infrastructure.

Proposal

1. Replace the italic Last reviewed: 2026-09-16, against v0.14.0b5-research line with a prominent banner near the top of research/participant-instructions: these instructions describe build X; if your study gave you a different build, ask your researcher. A participant who hits a mismatch should be able to notice it without knowing what a release is.
2. Fix the stale version in src/conf.py:91 — it declares version = "0.13" / release = "v0.13.1" while the product ships 0.14.0b5. There is an existing # TODO: Automatically detect version (possibly using git tags) immediately above it.
3. Note in the "Notes for researchers" section that studies should snapshot the page into their participant materials at study start, rather than linking it live, and record which build they snapshotted against.

Hosting-agnostic, no new files, no version infrastructure.

Rejected: Read the Docs versions

The original proposal here was to tag the docs repo per research build and activate those versions in RTD, giving studies a frozen /en/<build>/... URL. Withdrawn: the project is likely to move off Read the Docs to GitHub Pages or Cloudflare Pages at some point, so building a participant-facing URL scheme on RTD-specific versioning would be laying down something we would then have to migrate or break. Frozen study links are exactly the URLs that must not rot in a hosting move.

Worth revisiting after any such migration, where archived paths are a committed directory rather than a hosting feature — but only if there is demand, which there is not yet.

Rejected: per-study pages

research/participant-instructions/study-abc-YYYY.rst frozen per study. Rejected because:

• It duplicates the mechanics per study, which is what docs: add a Research section with participant instructions #181 removed.
• It makes error fixes worse than release changes. The export fail-closed note added in docs: add a Research section with participant instructions #181 was a correction, not a version change: with one page that was one edit; with frozen copies every running study needs patching, or knowingly keeps wrong instructions live.
• It puts another institution's ethics wording, contact details and upload location in this repo, which the project cannot vouch for and which goes stale on the study's schedule.

Separate, still open

A template marking which slots a study fills in (study name, contact, upload location, translations, ethics wording), with the mechanics linked rather than copied. Useful to any researcher evaluating the instrument, and independent of everything above.