Feature status

This page tracks how much of each topic in this manual is actually built, and explains how we decide. Every page also carries its own badge under the title.

Note

Status reflects what is deployed, not what is merged: portal and API 1.3.21 (10 September 2026) and participant app 1.2.14 (build 87, 13 August 2026). A feature is only counted once it has reached researchers and participants.

Reviewed 10 September 2026 against the code and against the open issues in tinnitus-api and tinnitus-app.

What the badges mean

• 🟢 Live works end-to-end in the deployed build, is covered by tests, and has no open high-severity defects.

• 🟠 In progress the code exists but is not fully wired, is mid-refactor, or has a known defect that blocks someone.

• 🔵 Portal-only built and configurable, but switched off until a researcher enables it, so a trial set up from the defaults does not get it.

• ⚪ Planned not built yet: a placeholder, a stub, or absent.

How we decide

For each topic we check, against the deployed build:

1. End-to-end wired? The backend serves it, the portal configures it, and the participant app renders or acts on it.

2. Code state. Committed and integrated, work-in-progress, a placeholder, or absent.

3. Tests. Does it have automated tests that pass?

4. App parity. Does the participant app act on the portal’s configuration, or is the behaviour hardcoded or a placeholder?

5. Open defects. Any open severity:critical or severity:high issue against a topic keeps it out of 🟢 Live, however complete the code looks.

A topic is 🟢 Live only when all five hold. If the app is hardcoded or the work is unfinished it is 🟠 In progress; if the capability exists but nothing uses it until a researcher turns it on, it is 🔵 Portal-only; if there is nothing to use yet it is ⚪ Planned.

Every row cites a file or an issue number. A row that cites neither is an opinion.

Status by topic

Topic	Status	Notes
Getting started	🟢 Live
About the trial	🟢 Live	unmodulated washout ⚪ Planned; the debrief does not reveal which arm you were on
Core concepts	🟢 Live	unmodulated washout ⚪ Planned
Setup wizard	🟢 Live	all 8 steps complete, each with its own readiness gate
Step 1 Identity	🟢 Live
Step 2 Assessments	🟢 Live	enables schedules; see the Assessments row for what ships enabled
Step 3 Treatment Phases	🟢 Live	the enrolment plan is configured on Step 4
Step 4 Schema	🟢 Live	crossover fully supported; carries the enrolment plan (targets per pathway, rate, live read-out). Editing quirks: #46, #47
Step 5 Sessions	🟢 Live
Step 6 Audio	🟢 Live	protocol values are read-only; unmodulated-washout audio ⚪ Planned
Step 7 Compliance	🟢 Live
Step 8 Launch	🟢 Live	checks each required audio slot, not just the file count
Running a trial	🟠 In progress	dashboard and both recruitment gates live; no adherence or compliance figures exist and there is no per-participant progress view (#50). Participants are contacted from the trial’s support address, not automatically
Enrolment and randomisation	🟠 In progress	allocation and weighting work (per randomisation pathway, not per arm). #38 is fixed and live: nothing names the treatment group any more. One narrower gap remains until 1.3.22 — the assigned sound file’s name reveals the modulation band, which differs by group (#64)
Participants and lifecycle	🟠 In progress	withdrawal is recorded with its cause; inactivity dropout and data deletion only run when someone runs them by hand (see Scheduled jobs). Open: #42, #43
Assessments	🔵 Portal-only	the engine, scoring and all nine questionnaires are built, but the reference configuration only enables three baselines, the blinding guess and screening. Daily check-in, before/after-listening and the final assessment ship switched off and must be enabled on Step 2
Participant app experience	🟠 In progress	last shipped 13 August 2026, before the current portal releases. Listening-rating sliders are still hardcoded; five participant-blocking defects are open (#16, #17, #18, #19, #22). Unmodulated washout ⚪ Planned
Audio pipeline	🟠 In progress	matching and delivery work; one file per slot, replaced on upload. But assignment fails silently in twelve places with no logging, and the participant’s matched frequency is re-derived from a float each time rather than stored (#41). Files are served by 1-hour signed URLs, with no authenticated media endpoint. Unmodulated-washout playback ⚪ Planned
Data export	⚪ Planned	there is no participant-data export. The only export in the portal is the frequency-mapping lookup table
Notifications and reminders	⚪ Planned	no email, no push, no reminders. In-app messaging is a fixed banner per trial state (#23)
Adherence and compliance	⚪ Planned	sessions are recorded, but nothing computes adherence, streaks or missed sessions
Scheduled jobs	🟠 In progress	process_dropouts and process_deletion_requests exist and work, but nothing schedules them — including GDPR deletion
Access management	🟢 Live	roles and ownership transfer are covered by tests; document preview is not yet scoped to the owning trial (#45)
Reference	🟢 Live

The short version

The researcher portal is in good shape. All eight setup steps are complete and gated, roles and access are covered by tests, and the launch check now verifies every required audio slot rather than counting files.

Three things are not what an earlier reading of this page implied.

Blinding is nearly, but not quite, closed. 1.3.21 fixed the serious part and is live: the app no longer names the treatment group anywhere, and the debrief opens only once a participant completes the trial (#38).

One narrower gap remains. The assigned sound file’s name contains the modulation band, the band differs between groups, and the frequency-to-band table is published, so someone who looks it up can work out their group. The app-side fix is merged and ships in 1.3.22; the file URL itself is tracked separately as #64.

Nobody has been affected, because nobody has enrolled yet. The thing that matters is sequencing: recruitment must not open until 1.3.22 ships.

The participant app is a release behind. It last shipped on 13 August 2026, before the portal work described here, and five participant-blocking defects are open against it. Anything on this page that depends on the app reflects that older build.

Several measures ship switched off. The daily check-in, the before/after-listening questionnaires and the final assessment are all built, but the reference configuration does not enable them. A trial created from it collects three baselines, one blinding guess and screening, and nothing else, until someone enables the rest on Step 2.

Beyond that: there is no participant-data export, no reminders or notifications of any kind, and no adherence tracking. Inactivity dropout and GDPR deletion both work but must be run by hand.

Unmodulated-washout audio remains unbuilt end to end: the model allows it, but it cannot be uploaded or played.