Specification: design-prototype handoff for SyRF Prototype v10

Planning specification (prefix DH; tracker row T-DH-00; owner-session amendment OS-A30). This is a design iteration brief. It is written for the Claude Design session that produced the "SyRF Prototype v10" handoff pack, so that Chris can ask that session to update the prototype with every product decision made since 2 October 2026. Owner decisions restated here are planning approval only. Brief approval and implementation authorisation are separate decisions taken per freeze gate (D1-04), and both remain on hold: Chris placed feature implementation on hold on 5 October 2026. No work has started under this document, no gate has passed and nothing is enabled in production. Nothing here authorises implementation, migration, production activation, notification delivery or a change to any running system.

How to use this document. It is self-contained. The design session is not expected to read the SyRF repository, so every rule the prototype needs is restated here. Repository links are extras for human readers and can be ignored by the design session. Section 13 holds a copy-ready prompt that Chris can paste into the design session together with this file.

Open questions before sending. Chris settles this pack's open questions in a Codex session using open questions before the Claude Design handoff. Its class A questions are answered first, and every answer is rolled into this document (section 11, the affected changes and scenarios, and the section 13 prompt) before Chris sends it (T-DH-01). Updated 6 October 2026: Chris answered all five class A questions (DQ-01 to DQ-04 and DQ-46) and the class B question DQ-09 in a Codex discussion (record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18), and the answers are rolled in below. The remaining open questions travel as labelled options with "To be decided" chips. The pack becomes ready for Chris to send only after this integration is checked and merged; recording the answers sent nothing, and sending stays Chris's own step.

Abbreviations for the companion specifications (all in this folder): RD review domain and versioning, DM duplicate merge, SP stage pools, steps and history, RS reconciliation and screening, BC baseline conversion, TI training and inference, RI reporting, imports and AI screening, UX UX, devices and work discovery, ACD access, communications and deletion and, since 6 October 2026, CPR classification, populations and references. "RS-R31" means rule R31 of the RS specification; "UX §3.2" means section 3.2 of the UX specification; "ACD-R14" means rule R14 of the ACD specification. IDs that start "AC-" (for example AC-R3a-13) are acceptance criteria in the package's acceptance criteria document, not rules of the ACD specification. "OS-A12" is an owner-session amendment; section 1.8 lists every one cited here.

Related package documents. Specification overview, rollout plan, implementation tracker, product-owner guide, owner-session integration (OS-A IDs and coverage matrix), archived owner-session bundle, owner ledger of 2–3 October, UX strategy, UI coverage comparison and acceptance criteria §3.

1. Status and boundaries

1.1 What this document is

• A design iteration brief for one existing prototype pack. It lists what to keep, change, add and remove, and how each new behaviour must look and behave.
• A record of the final owner decisions from the session of 4 and 5 October 2026, plus the earlier owner decisions of 2 and 3 October that still stand, phrased as interaction rules.
• A source of acceptance scenarios for judging the updated prototype.

1.2 What this document is not

• It is not implementation approval. A prototype is design evidence. It never proves that a feature exists, and it never authorises building one.
• It is not a message to the design session. No design session has been messaged by this repository or by the session that wrote this file. Sending the prompt in section 13, and so starting a prototype iteration, is Chris's own decision.
• It is not a new prototype. It specifies an iteration of the existing v10 pack.

1.3 Three states that must stay distinct

State	Meaning	Status on 5 October 2026
Planning approval	Chris has decided the product direction	Given for the decisions in this document, except where marked open
Brief approval and implementation authorisation	A workstream brief is approved and building may start, per gate	On hold for every workstream
Work started, gate passed, production enabled	Code exists, a gate has passed, a feature is live	None. Every work item is at most "Brief drafted". G0 is not approved

1.4 Policies that are not approved

The prototype must never present these as available options:

• permanent physical erasure of project data (T-POL-01);
• a separate identity-erasure process (T-POL-02);
• automatic acceptance of several agreeing candidate reviews as an accepted result without a human reconciler's confirmation (T-POL-03);
• any specific numeric threshold (pause limits, operation limits, deduplication parity figures, Unsure bounds beyond the owner's example, capacity defaults, timeouts, pass marks). Where a number is needed, show an example value labelled "Example, not approved" or an empty field.

1.5 Specialist inputs that the prototype must not invent

Input	Tracker row	What the prototype shows meanwhile
Exact PRISMA box mapping for pool history versus review through a stage	T-SI-05	Measures with their own labels and a "Mapping to be decided" note
Agreement statistics methods beyond percent agreement	T-SI-02	Percent agreement with its denominator; kappa marked "Method pending statistical review"
Event-count outcome schema fields and the meaning of "variation"	T-SI-01	The schema listed as "Fields to be decided"
SYRCLE, CAMARADES and ARRIVE template content	T-SI-03	Template names only, marked "Content pending methodologist review"
ASySD deduplication parity method and thresholds	T-SI-04	No figures

1.6 Precedence

1. The owner-session consolidation of 5 October 2026 wins over every older text.
2. This document restates it for the prototype.
3. Where this document and the v10 pack disagree, this document wins.
4. Where this document is silent, keep the v10 behaviour unchanged and list it in the open-question output (section 13) so Chris can confirm it.
5. No owner decision is open. The last one, D2-09 (accepted answers to a question shared by two forms), was decided by Chris on 5 October 2026. Build it as section 5.5 describes ("Questions shared with another form"); DH-U27 in section 11 is marked "Decided (D2-09, 5 October)" and is not a "To be decided" item. Updated 6 October 2026: Chris answered four more items. Training does not hold up the first general release; trainees' feedback follows the recommended default (DH-U19, decided; section 5.15); new questions are required by default, and each question offers its own reasons no value is provided (DH-U38, decided; section 5.24); and answer metadata is configurable per answer state (section 5.24). How clearing an answer is recorded stays an open owner item, shown as a PROPOSAL (section 5.24). Updated again 6 October 2026 (Codex discussion): Chris answered six more inputs. Every project uses one question editor, with each project mode's own saving and assignment behaviour (DH-U41); the editor opens beside a compact tree on wide screens and as a drill-in page on narrow screens (DH-U35); design edits save automatically into the unpublished draft (DH-U37), all in section 5.22; reconciliation and design screens get usable phone layouts without a formal phone acceptance gate (DH-U12, section 7.1); the answer terms are decided (DH-U42, sections 3.2 and 5.24); and rule authoring sits inside the inference beta (DH-U21, sections 5.21 and 5.26). Build each as described, with no chip.

1.7 Data and safety

Use synthetic fixtures only. Never use real project content, real participant data, clinical data or reviewer identities from a live system. Never call a live SyRF service.

1.8 Owner-session amendment IDs (OS-A) cited in this document

The owner session of 4 and 5 October 2026 recorded 30 amendments, OS-A01 to OS-A30. Every one is cited somewhere below, so each is listed here with a one-line plain-English meaning. They are planning decisions only; none approves implementation, migration, production activation or notification delivery. Full wording: owner-session integration §3.4.

ID	Plain-English meaning
OS-A01	Question-management drafts are collaborative: presence, live updates, conflict handling and an audit trail
OS-A02	The annotation form or the screening profile owns reconciliation blinding, and candidate order is unpredictable
OS-A03	Blinded reconciliation keeps no identity continuity across Studies (aliases are Study-local)
OS-A04	Accepted answers appear as labelled hints with explicit click-to-fill; a step may only hide them; nothing is prefilled automatically
OS-A05	Work already started may be finished after a Study leaves a stage pool (default allow; an admin may restrict; where the restriction lives is DH-U04)
OS-A06	A result produced through a stage may change that stage's own pool: commit first, then recalculate membership
OS-A07	Pool-membership changes are recorded as targeted history, while the current pool is still calculated when it is needed
OS-A08	An admin can see an explanation of review activity and inactivity over time
OS-A09	Historical pool coverage feeds flow diagrams; actual review through the stage is the reporting priority (the PRISMA box mapping is a specialist input)
OS-A10	Every pool entry carries an explicit justification
OS-A11	History events are structured and queryable, with the required event queries
OS-A12	The standard reviewer target is part of the form version
OS-A13	Screening tie adjudication is configurable, and the adjudicator can be a member or a group
OS-A14	The conversion wizard shows an explicit mapping of existing activity and gives adoption guidance
OS-A15	Baseline conversion is universal and faithful, with optional redesign inside the new engine afterwards; this replaces the permanent-archive option
OS-A16	Unsure handling is bounded and falls back to adjudication (transitions the owner did not state stay "To be decided", DH-T11)
OS-A17	The exclusion-reason template is guidance and sets no limit on the number of reason questions
OS-A18	Training uses reference answers, scoring, manual assessment, retries and optional group admission
OS-A19	Inference behaviour is agreed, and inference is an opt-in beta for project designers, off by default
OS-A20	External and AI-model-generated screening decisions: who owns model metadata, how a source is identified, and the agreed terminology
OS-A21	The save wording keeps "Draft auto-saved" distinct from "Version checkpoint saved" (wording illustrative; the meanings are fixed)
OS-A22	Making SyRF a PWA, including caching allocated studies, is exploration beyond the MVP; no offline writes
OS-A23	Existing screens get compatible improvements with no change to workflow behaviour
OS-A24	An admin can exclude a member's contributions from current use, with a preview and a reason
OS-A25	Ordinary project deletion is reversible, and an authorised admin can restore the project
OS-A26	Emails are informative and permission-aware, with configurable answer and free-text detail
OS-A27	Reviewers may optionally browse their blinded study pool within a stage
OS-A28	One candidate plus human reconciliation replaces a separate verification engine
OS-A29	Duplicate merge is consolidated, atomic and reversible; it replaces the earlier alias approach (D2-12)
OS-A30	This document: the design-prototype handoff for iterating SyRF Prototype v10; no design session is messaged

2. The source prototype

2.1 Provenance and location

• Pack. "Handoff: SyRF v10: review steps, versioned forms and reconciliation", folder design_handoff_syrf_v10, produced by the Claude Design session and supplied to Chris on 2 October 2026 (file times 2 October 2026 19:22).
• Where the unchanged copy lives (Chris's machine): inside the read-only review package syrf-v10-review-2026-10-02, at /home/chris/.codex/visualizations/2026/09/23/01a0cbec-0c32-7103-ab5a-bfc05665deb7/syrf-v10-review-2026-10-02/source/design_handoff_syrf_v10/. That review package states that source/ is the unchanged supplied pack, kept as historical evidence.
• The planning sources that name it. The UI coverage comparison lists it as asset E ("v10 pack"); the owner ledger describes itself as "the authoritative decision overlay for the interactive review of the Claude Design v10 handoff".

2.2 Files and checksums

SHA-256 values were computed on 5 October 2026 from the copy above.

File	Bytes	Lines	SHA-256
prototype/SyRF Prototype v10.dc.html	751,360	3,337	1f940684e0bbd32e4b04b0e48f50ecf2d371c20ade94f51eb1e9c1e188ecdbe6
prototype/Review Page v10.dc.html	482,819	2,237	29adb6b5cf383e5b273aaac7f8817a0c446c2dd22474b504d5231306c240bdbc
prototype/Review Form v10.dc.html (byte-identical copy of the Review Page)	482,819	2,237	29adb6b5cf383e5b273aaac7f8817a0c446c2dd22474b504d5231306c240bdbc
prototype/Reconciliation Exploration.dc.html	268,785	1,154	8daf4e3a860407691c09cf3de0602f35cd6c6429323c0cb0b9b3c7ffe261e31c
prototype/support.js (runtime)	69,150	n/a	8fe7df74405f3c55f49b7249c74ea1397e65d07dea2b1bd3b4a489bec2e28cbe
README.md	4,946	60	a465c2de79d873345ed2767ed212f0e704ced903d42b1d6fcee1bcb67a20ba10
AGENTS.md	4,433	44	157b102b544eae93e432b1c8b83cdb1bd8940110cfc29940e320d5166acac70d
FEATURES.md	12,324	164	4934e4e865d842bb0b8c993f6b924c7db6de97dd6405e8cf75417766a54ff044
DECISIONS.md	24,154	372	04bec8b3e311bdc461482c6d499237db8e79337d618e0982dca9a896e77992b3
RECONCILIATION.md	17,588	199	26b1b3db720b7302bb3d54fa7855a35b869cd5a282d7c66b1d4bb9bc130df717
IMPLEMENTATION_PLAN.md	6,703	111	1b13a1e6623ef7205aa73da967d088b36d17f6352e780b86febf5e7802401d8d
reference/stage-review-page-handoff.md	26,100	165	0512327a4661800f167b3fb711ff2ed9dacb5ae4d8d3037c66e3db6c92a6ab11

The pack also holds prototype/_ds/ (the SyRF design-system bundle: colors_and_type.css, v2 theme.css, shell.css, surfaces.css, fonts including Roboto and Material Symbols Outlined) and prototype/assets/ (the SyRF brand mark). They exist only to run the prototypes.

2.3 What each file shows

• SyRF Prototype v10.dc.html. The main prototype, covering every page. Project "Livestock TB evidence review". Four chapters:
• classification and cohorts (c1 Concepts & rules to c10 Cohort list);
• review steps, profiles, forms and stages (r1 Screening profiles, r6 Annotation forms, r8 What's different from released SyRF, r2 Stage designer with its Overview and Setup tabs and the Reconcile page, r3 Study selection preview, r4 Reviewer session, r5 History & correction);
• outcome data schemas (o1 Schema catalogue, o2 Outcome entry);
• the reviewer page (p1 Full-text review, which embeds the Review Page file). It has two navigation modes: "steps" (default; a numbered Setup section "1 · Concepts & rules" to "6 · Stages", then Monitor and Data) and "library" (an alternate grouping under a "Library" heading). It contains 9 scenes (s0 Live to s8 Correction draft versus submitted), a Guide with 19 walkthroughs and an Open decisions panel.
• Review Page v10.dc.html (and its copy Review Form v10.dc.html). The reviewer page: study source, screening card and annotation steps, the restored outcome-data matrix with its cell dialog and spreadsheet mode, and the graph panel. Its stepView tweak defaults to stepper, which drives one form area from the selected step; an alternative shows one card per step.
• Reconciliation Exploration.dc.html. Design history for reconciliation. Turn 4 (4a reconciliation form, 4b deviations from the review form) and Turn 3 (3a matching) are the chosen designs. Turns 1 and 2 are history; layouts 1a to 1c are superseded.
• reference/stage-review-page-handoff.md. The reviewer-page specification from Review Prototype v4 (with v5 control notes), including the staging corrections 1 to 11 and the reviewer-efficiency additions. The Review Prototype v4 HTML file itself is not in this pack; it sits in a separate stage-review handover of 21 September 2026. A Review Prototype v5 file was not found anywhere.
• The documents. README.md (overview, fidelity, tokens), AGENTS.md (instructions for a coding agent), FEATURES.md (every page and walkthrough), DECISIONS.md (44 open or resolved decisions: 26 from the prototype, RC and OD and X prefixes, plus RD1 to RD18), RECONCILIATION.md (reconciliation specification) and IMPLEMENTATION_PLAN.md (slices S0 to S10).

2.4 The prototype chrome

The dark bar at the top is prototype chrome and never appears in the product. It contains:

• an Admin / Reviewer role switch and a Reviewing as picker (Alice, Bob, Carol, Dan);
• a Scenario picker (scenes s0 to s8) and a Simulate menu (other reviewers' actions);
• Guide (walkthroughs), Inspector (underlying state) and Open decisions (each decision opens at its location).

A Tweaks panel holds display options, including "Answers both reviewers agree on" (prefillConfirm, the confirm-each rule of RD5), navigation mode, change marks, blinding display, review-step layout, entity mode, density, tab mode, dark theme and design-system scope. The prototype runs by serving the prototype/ folder over HTTP and opening the main file.

2.5 v10 fidelity notes and how they change

v10 fidelity statement	Status now
Reviewer page, reconciliation form (4a) and stage pages are high fidelity: "layout, control types, sizes, copy and states are final"	Layout and control types stay the reference. Copy and several states change: sentence case (D3-04), new save-status states (D3-03 with the U1 amendment), no per-field CONFIRM (RE2), step selector default (Q-12), N candidates (SF4/RE3). Treat "final" as superseded wherever section 9 lists a change
Configuration pages are high fidelity for structure, rules and copy	Structure is kept where section 9 says Keep. Rules change substantially (forms own targets and reconciliation policy; profiles own Unsure, ties, blinding; stages own filters and steps only)
Outcome data entry follows the shipped matrix, cell dialog and spreadsheet pattern (RD16)	Kept; a phone presentation is added (D3-05)
Exploration layouts 1a to 1c are superseded by 4a and 3a (RD17)	Kept as a recommendation to validate with three and four candidates (U1); 4a and 3a stay the design direction
Design tokens: brand ink #1c3053, accent #4b5e84, ALL-CAPS 13px/500 buttons, 4px and 8px radii	Brand colours stay as SyRF tokens. Button and type language changes to Material 3 sentence case and the Material 3 type scale and component shapes (D3-04); see section 7.6

2.6 Rules in the v10 pack that later decisions supersede

v10 statement (file)	Superseded by	New rule
"Every gold-standard answer is the reconciler's own ... agreed answers are prefilled and must be confirmed" (RECONCILIATION §1, §4.2)	RE2 (owner, 2 Oct)	Agreeing answers are filled in with an obvious autofill marker and kept provenance. Completing the reconciliation accepts every valid displayed answer. No per-field confirmation
"Reconcilers see Reviewer A / Reviewer B by default; profile and form settings can show names"; RD7 "most restrictive wins"	Q-28, Q-30, blinding amendment (OS-A02, OS-A03)	The annotation form owns identity blinding for its reconciliation; the screening profile owns blinding for screening adjudication. Blinded by default. Aliases are drawn at random per Study; order is random; no submission times
Step-level "Who reconciles, per part", "Assignment" and "Earlier gold standard: Show / Hide" (RECONCILIATION §2)	PM1 (stage grants), RA1 to RA4, Q-30, Q-28	Reconcile authority comes from grants in Members & groups. Assignment and its optional expiry are audited settings. Accepted answers shown to reviewers follow the form's hint baseline with step hide-only overrides
"Studies where every answer agrees: Reconciler confirms each / Admin may bulk approve"	RE2, Q-11	Optional per-form "bulk acceptance", off by default, needing an explicit reconciler confirmation of the exact list
One reconciliation task is "study × one review step, in ordered parts" (RD4)	RE4	One task per Study × annotation form, reachable through every stage that uses the form. Screening adjudication is a separate task per Study × profile × trigger
"Request another vote" is always available (RD10)	RA5, consolidation §1, tie amendment (OS-A13)	"Request an additional review" needs its own capability and raises the effective target for the chosen Studies. Ties follow the profile's tie policy
"A reconciler must never be offered a study they reviewed" (AGENTS)	Q-36	True by default. An explicit, audited override grant can permit it, and every use is shown in provenance
"Candidate reviewers must never see another reviewer's votes or answers, in any build or any setting" (AGENTS)	D4-02 discussion; hints amendment (OS-A04)	Still true for candidate answers and decisions, with one exception: when a profile enables discussion, the candidates whose submitted decisions conflict see each other's decisions and reasons under aliases, and that exposure is recorded. Accepted answers (never candidate answers) appear as labelled hints
"Reviewer session: Save draft never votes" (FEATURES r4) and "Save draft" buttons	D3-03 with the U1 amendment	No "Save draft" button. Autosave keeps a recoverable draft; "Save progress" creates a version checkpoint; "Complete" validates and completes (section 5.1)
"Form review target: proposed on the annotation form"; "Each step has its own target" (OD19)	SF2, target-versions-form amendment (OS-A12)	The standard reviewer target is part of the immutable form version. No step or stage target
"Copy the prototype's wording exactly unless a decision changes it" (AGENTS)	Many decisions here	Wording changes wherever section 9 says so; status wording stays illustrative (U1 wording flexibility)
IMPLEMENTATION_PLAN slices S0 to S10	The integrated plan's releases and lanes	Do not use v10 slices to order prototype work. Use section 13's order
"Groups are managed in Project › Members & groups. That page is not designed yet" (RD8)	PM1, PM2	Design Members & groups (section 9, DH-C82)
The r2 Reconcile page's held banner offers "Mark compatible" with Undo	D2-02 amended, Q-34 (the publisher's compatibility declaration is immutable)	Remove "Mark compatible" and its Undo; keep "Ask v1 reviewers to update"; a wrong declaration is corrected by "Correct this publication" (DH-C110, DH-C111)
"Question library" and "Entity types & question library" (c2, r6)	Q-13	The page is "Questions and entity types" under Design; reusable items are "question templates" in the Catalogue (DH-C100)

2.7 v10 decision register crosswalk (all 44 entries)

v10 ID	v10 question in brief	Status after 5 October	Governing decisions	Prototype consequence (changes)
RC10	Re-check after a correction when candidates now agree	Decided	R1 final (OS-A28); RS-R07, RS-R08; T-POL-03 not approved	A corrected input marks the task "Inputs changed"; the accepted result stays effective; a human reconciler completes the next version even when the candidates now agree (DH-C41, DH-C75)
RC9	Exclusion reasons versus reason reconciliation	Decided	DP4, DP5, Q-22, D4-13 (OS-A17)	Reasons belong to the screening profile, with a reason-reconciliation toggle and template primary reason; remove the stage-wide reasons setting (DH-C21, DH-C55)
RC6	Skip moves to another study	Open UI choice (validation U2)	Skip records nothing (AC-R3a-13)	Study-level Skip records nothing; per-step Skip shown as an option to test (DH-C64, DH-U09)
RC8	Population chip in the study header	Open layout choice (validation U3)	C1 lane	Keep the chip; label placement "to be validated" (DH-C65, DH-U10)
X2	Which project types become templates	Decided	TC1	Templates default to existing legacy entity types; cohorts, outcome measures and experiments appear only when a form uses extraction (DH-C16)
X3	Decision versus answer reconciliation	Decided	RX1, DP5, OS-A13	Decision tie, unresolved Unsure, reason disagreement and AI sole-source Unsure are separate triggers in the adjudication step (DH-C72, DH-C81)
OD1	Cross-stage dependency defaults	Replaced	Q-15, Q-01; DP1, DP6, DP7 cross-stage parts superseded	No gate into a stage. The stage study filter defines the pool; dependencies exist only between steps in a stage (DH-C34, DH-C35, DH-C36)
OD2	Reservations when half a combined step is sufficient	Brief item	D3-19, Q-24	Own Include tries the dependent place; a refusal keeps the decision and says "Enough reviewers are already working on this"; new combined steps stop extra screening at sufficiency (DH-C36, DH-C63)
OD3	Reconsidering a personal Exclude	Decided	DP2	Correct your own decision from history when review is still possible (DH-C50, DH-C55)
OD4	Surplus counting beyond target	Decided	SF4/RE3; D3-17; Q-28	The target is a minimum; every qualifying candidate enters reconciliation; the capacity cap is separate and off by default (DH-C28, DH-C68)
OD5	Blinding-compatible route warnings	Decided invariant; copy to validate (U5)	SP §6; AC-R3a-09	Messages name the step and the reviewer's own basis, never other reviewers' votes (DH-C63)
OD6	Permissions and confirmations	Decided in part	PM1, PM2, Q-03; consolidation §6	Members & groups with scoped grants; an impact preview before every admin action that affects reviewers; capability names are working names (DH-C82, DH-C84, DH-T07)
OD7	Screening scope mechanism	Decided	DP4, Q-15	Profiles own their eligibility questions; the stage filter decides the pool (DH-C20, DH-C34)
OD8	Automatic decision versus recommendation	Decided	DP3	A derived Include or Exclude is shown with its reasoning and recorded only on explicit submit (DH-C25, DH-C55)
OD9	Initial outcome-schema catalogue	Decided	OC1; Q-17 (T-SI-01)	Legacy-compatible schema, event-count schema (fields to be decided), project custom schemas (DH-C51)
OD10	Schema upgrade UX	Engineering detail	FV1 to FV3, OC2, MIG1	Do not design a schema-upgrade flow; show "To be decided" (DH-C51, DH-T10)
OD11	"Greater is worse" scope	Decided	ODIR1	One versioned direction on the outcome measure, with no per-cohort override (DH-C51)
OD12	Follow-ups outside the classification slice	Deferred	Q-18; follow-up after C2	No rule chaining, set algebra or ontology authoring; other expressions show "Unsupported" (DH-C15)
OD13	Legacy annotation session mapping	Decided (direction)	R4 owner direction, OS-A14, OS-A15	The conversion wizard maps legacy sessions and labels missing history (DH-C87)
OD14	Form submission identity	Decided	SF1	One session per reviewer × Study × form across stages (DH-C48)
OD15	Stage settings and session versions	Decided	PV1, PV2, SL1 to SL3	Stage settings publish as versions; session versions come only from Save progress, Complete and named transitions (DH-C39, DH-C46)
OD16	Cascading effects of corrections	Decided	Q-27, Q-15	Warn before commit at the actor's level of access; inform affected authors; never rewrite dependent results (DH-C47, DH-C75)
OD17	Reproducible outputs	Decided (intent)	GS1, EX1, EX2, OS-A11	Exports offer current, previous versions and as-of state; frozen reports never change (DH-C95)
OD18	Completed stage lifecycle	Decided	RX2, LC1, Q-02	Automatic completion recalculates; manual completion stays until an explicit Reopen; protected changes need approval (DH-C39, DH-C96)
OD19	Form-level review targets	Decided	SF2, OS-A12	The target lives in the form version; no step target (DH-C26, DH-C36)
OD20	Draft model	Decided	SL1 to SL3, consolidation §1, D2-08	One shared session draft with per-answer base checks and a reconstructable change log (DH-C46, DH-C48)
RD1	Suggest entity and branch pairs?	Decided	MG1	Suggestions are required; weights shown read-only and "not approved" (DH-C30, DH-C73)
RD2	Do a one-sided item's child answers come across?	Open in part	RE2, RE5	Keep and Leave out stay; whether kept items are filled in is DH-U06 (DH-C69)
RD3	Where each reconciliation rule lives	Decided	Q-28, Q-30, OS-A02, OS-A04; RS §3.12	Form version, profile version, audited operational settings and step hide-only hints (DH-C27, DH-C37)
RD4	What is one reconciliation task?	Decided	RE4	One task per Study × form; screening adjudication is its own task (DH-C41, DH-C72)
RD5	Must the reconciler confirm agreed answers?	Decided	RE2	Autofill marker, no per-field CONFIRM (DH-C69)
RD6	Free-text gold value	Decided	RE5, NT1	Prefill only on exactly matching text; notes keep their authors (DH-C69)
RD7	Which blinding wins in a combined step?	Decided	Q-28, Q-30, OS-A02 (BL1 superseded)	Each part follows its own owner: form for annotation, profile for screening (DH-C21, DH-C27)
RD8	Where groups are managed	Decided	PM1, PM2	Design Members & groups (DH-C82)
RD9	Assignment, release and timeout	Decided; bulk reassignment open	RA1 to RA4, Q-30	Pool by default; Assign; optional expiry, off by default, unstarted work only; release and reacquire (DH-C41, DH-T17)
RD10	Request another vote	Decided	RA5, consolidation §1, OS-A13	"Request an additional review" raises the effective target and needs its own capability (DH-C41, DH-C85)
RD11	Rationale for reconciled answers	Decided	RE1, Q-32	Optional with a non-blocking reminder; adjudication rationale per profile setting (DH-C21, DH-C70)
RD12	Changing a "Not compatible" publish decision	Decided	D2-02 amended, Q-34, FV4	The publisher's declaration is immutable; correction by guided rollback and republication; an update requirement can be revised (DH-C32, DH-C110, DH-C111)
RD13	Gold-standard numbering and export	Decided	GS1, RS §3.2, EX1	Sequential immutable accepted-result versions with an authority label; any "v2.1" label is display only (DH-C75)
RD14	Agreement and kappa formulas	Specialist input	AG2, AG3; Q-16, D4-12 (T-SI-02)	Percent agreement with denominators; kappa marked "Method pending statistical review" (DH-C95)
RD15	Outcome data reconciliation	Decided in v10	RD15, SF4/RE3	Keep the matrix and dialog; scale to more than two candidates (DH-C74)
RD16	Restore the shipped outcome pattern	Decided in v10	RD16, D3-05	Keep; add a phone presentation (DH-C52)
RD17	4a and 3a over 1a to 1c	Recommendation to validate (U1, U36)	none	Keep 4a and 3a; validate with three and four candidates (DH-C68)
RD18	What a non-admin reconciler sees	Decided	AG1, PM1, Q-03	Agreement figures move behind their own capability under Data; pool context follows grants (DH-C41, DH-C95)

2.8 v10 pages, walkthroughs and scenes crosswalk

Pages (FEATURES.md).

v10 page	Disposition	Reason	Changes
c1 Concepts & rules	Keep, with beta gating	Q-18, Q-19, OS-A19	DH-C15
c2 Entity types	Keep, with template defaults; becomes Design › Questions and entity types	TC1, Q-13	DH-C16, DH-C31, DH-C100 to DH-C103, DH-C117
c3 Question selection (per stage)	Remove	SF1: questions are chosen per form; stages bind forms	DH-C17
c4 Study populations	Keep (lane C1)	Classification lane	DH-C18
c5 Location · Farm A	Keep	Classification lane	DH-C18
c6 Cohorts · Farm A	Keep	Classification lane	DH-C18
c7 Rule example	Change	Inference is a beta, off by default	DH-C19
c8 Withdraw inference	Change	Withdrawal keeps history	DH-C19
c9 Add East	Keep	Count statements only where proven	DH-C18
c10 Cohort list · save	Change	Save labels	DH-C18, DH-C46
r1 Screening profiles	Change	DP4, D4-01, OS-A13, OS-A16, OS-A20	DH-C20 to DH-C25, DH-C118
r6 Annotation forms	Change	OS-A12, OS-A04, RS §3.4, SF1	DH-C26 to DH-C32, DH-C104 to DH-C109
r8 What's different from released SyRF	Change	Notes must match the new rules	DH-C33
r2 Stage designer, Overview, Reconcile page	Change	Q-15, Q-01, Q-02, Q-24, Q-28, RE4, D2-02	DH-C34 to DH-C42, DH-C111
r3 Study selection preview	Change	Monitor capability; reason categories	DH-C43, DH-C44
r4 Reviewer session	Change (merged into the reviewer workspace)	Q-12, D3-03	DH-C45 to DH-C49
r5 History & correction	Change	SL3, DP2, D2-01	DH-C50
o1 Schema catalogue	Change	OC1, ODIR1	DH-C51
o2 Outcome entry	Keep (redirect to the reviewer page)	RD16; phone presentation added	DH-C52
p1 Full-text review	Change	Q-12, D3-03, D3-05, OS-A04	DH-C53 to DH-C67

Walkthroughs (Guide). All 19 are rewritten as DH-S scenarios (DH-C03). The ones whose behaviour still holds keep their story: "Continue a saved draft" (DH-S02), "A step waits for the one before" (DH-S09), "Steps wait for your decision" (DH-S09), "Collective Exclude after you started" (DH-S11), "Collective satisfaction" (DH-S10), the cohort and population walkthroughs (lane C1, kept under DH-C18), "Correct a decision" (DH-S03 history part), "Who is offered which study" (DH-S13) and "History & corrections" (DH-S02, DH-S28). "Concepts & rules" changes to show the beta opt-in (DH-S39). The configuration walkthroughs change as section 9 says.

Scenes.

Scene	Disposition	Change
s0 Live · Full-text review	Keep; targets read from forms; reconciliation settings move	DH-C05
s1 TA then combined FT; Exclude ends route	Keep; express "ends route" as the exclusion-stop setting	DH-C05
s2 Independent diabetes decision	Keep	DH-C05
s3 Facts, screening, outcomes	Keep	DH-C05
s4 Two forms, targets 2 and 1	Keep; targets come from form versions	DH-C05
s5 Collective satisfaction versus personal Exclude	Keep; personal exclusion-stop	DH-C05
s6 Extraction-only step: Skip, not Exclude	Keep; Skip semantics marked for validation	DH-C05, DH-C64
s7 Collective Exclude mid-extraction (surplus)	Change: saved-work completion and the pool-departure variant	DH-C05
s8 Correction draft versus submitted	Change: SL3 status semantics with the new labels	DH-C05

2.9 Owner-ledger entries (2 and 3 October) changed by the 4 and 5 October session

Ledger entry	What changed
BL1 (reconciliation identity blinding stage-owned)	Superseded: form-owned for annotation, profile-owned for screening adjudication; blinded by default; context-local random aliases
VS1 (step-level accepted-answer visibility with a stage default, originally off)	Superseded: the form baseline shows hints by default; a step may only hide them; explicit click-to-fill
EW1 (saved work after collective exclusion: stage default Allow, step override)	Kept and extended: started work may also continue after any filter-driven pool departure by default, with an admin restriction (OS-A05)
RA3 (assignment expiry with a stage default)	Superseded: expiry is optional, off by default, set on the form (tasks) or profile (adjudication), unstarted work only
RA5 (an additional review never changes the normal form target)	Superseded: an additional-review request raises the effective target for each named Study
DP1, DP6, DP7 (cross-stage routing policies)	Replaced: no gate into a stage; the stage study filter defines the pool (Q-15)
LC1 (confirmation before a change reopens a Completed stage)	Amended by Q-02: an automatic Completed stage recalculates as soon as remaining work appears; manual completion stays until explicit Reopen; protected changes to a Completed stage still need approval
RE2, RE4, RE5, MG1, SF1 to SF6, SL1 to SL3, DP2 to DP5, QY1 to QY9, FV1 to FV4, VU1 to VU3, AG1 to AG3, EX1, EX2, PM1, PM2, ODIR1, OC1, TC1	Still stand and are restated in this document where the prototype needs them

3. Product goals, terminology, roles and boundaries

3.1 Product goals

1. One trustworthy evidence record. Every answer, decision and accepted result is an immutable version with its author, time and route. Nothing is silently rewritten. History explains why something happened.
2. Reviewer time is the scarce resource. Screening and annotation are fast by keyboard and by touch, with live completeness and a jump to the next missing answer.
3. Independence and blinding are visible. Candidate reviewers never see each other's work. Reconcilers see random, Study-local aliases by default. The interface says when an answer was informed by an accepted answer.
4. Honest state. Labels never call a draft a version, never call a checkpoint complete and never show a count without a real denominator.
5. Work anywhere. Screening and full annotation work on phones, tablets and desktops at launch, including the largest real form.
6. Explainable availability. An admin can see why a Study was available, reviewed, not reviewed or no longer available, using the rules in force at the time.
7. Reversible operations. Duplicate merges can be unmerged; ordinary project deletion can be restored; contribution exclusion keeps history.
8. One product. Existing projects get the refreshed look and every compatible new feature until they are converted, with their review behaviour unchanged.
9. Consistent and accessible. Material 3, SyRF tokens, light and dark themes, WCAG 2.1 AA at the audit and a WCAG 2.2 AA working standard (PROPOSAL).

3.2 Glossary (plain English, aligned to the specifications)

Terms shown in the interface are in bold. Internal record names are in code and are PROPOSALs that the design session may show in the Inspector only.

Term	Meaning
Study	The item a project reviews. Forms, sessions, targets, decisions and accepted results attach to a Study. Study
Record (imported reference, citation)	One row of one import file, kept unchanged with its source and import time. Citation
Report (source document)	A real paper, abstract or preprint. Two records of one article are one report. Grouping distinct reports of one experiment is deferred
Stage	A named piece of workflow, for example "Full-text review". It owns no evidence
Stage study filter	The rule that decides which Studies are in a stage's pool: clauses on screening results and accepted answers, joined by AND and OR groups. StageStudyFilterVersion
Stage pool	The current Studies that match the stage's filter. Calculated, never stored
Your studies (reviewer study pool)	The part of a stage pool allocated or assigned to one reviewer and currently available to them. ReviewerStudyPool
Step	One unit of work inside a stage: screening, annotation or both. Kinds: review step, adjudication step (system), training step
Depends on	A configured dependency between steps in one stage. Display order is never a dependency
Exclusion-stop	A step setting that says whether an Exclude stops further progression, for the reviewer and for everyone
Screening profile	The eligibility questions, decision rules, Unsure, tie, discussion and blinding settings for one kind of screening. Versioned
Annotation form	A versioned set of questions with its standard reviewer target and reconciliation policy. Shared by every stage that uses it
Form version	An immutable published form. Changing questions, the standard target or the reconciliation policy publishes a new version
Your review (session)	One reviewer's work on one Study and one form, the same through every stage, tab and device. FormSession
Draft auto-saved (illustrative)	Recent edits kept as a recoverable draft. It is never a version or a submission
Version checkpoint saved (illustrative)	The reviewer pressed Save progress; an immutable incomplete version exists and is current
Complete	The review passed whole-form validation; an immutable completed version exists and counts
Standard target	How many qualifying reviews each Study needs for a form. Part of the form version
Study-specific target (override)	A versioned target for one Study and one form. StudyTargetOverride
Effective target	The Study-specific target if one exists, otherwise the standard target
Additional-review request	A request naming Studies, a number and optional people or groups; it raises each Study's effective target
Capacity cap	The maximum number of places on a Study for a form. Separate from the target; off by default (PROPOSAL)
Place (review slot)	A reviewer's held position on a Study for one form, shared by all tabs and stages
Candidate	A reviewer's qualifying completed review used as input to reconciliation
Reconciliation task	The work of turning the candidates for one Study and one form into an accepted result
Accepted answers ("gold standard" in help text on first use)	The current accepted result for a Study and form. Authorities: Single annotator (accepted automatically), Reconciled, Reconciled (one candidate), Adjudicated, Merge-resolved
Your decision	A reviewer's own Include, Exclude or Unsure
Screening result	The collective result for a profile: Pending, Waiting for one more decision, In discussion, Awaiting adjudication, Included, Excluded. Only Included and Excluded are definite
Unsure	A decision that keeps a Study available but never counts as a definite Include. On per profile
Tie	Decisions that do not reach the profile's rule. Routed to extra review (with a bound) or to adjudication
Adjudication	An attributed resolution of tied or unresolved screening decisions by an eligible member, in the adjudication step
Discussion	Optional per profile: after submitted decisions conflict, the conflicting candidates see each other's decisions and reasons under aliases
Accepted-answer hint	An existing accepted answer shown under a question, labelled with its authority and version
Use accepted answer (click-to-fill)	The reviewer's explicit action to copy a hint into their own answer. Recorded; never counted as independent
Informed / independent	Whether an answer was given after seeing accepted answers
Outdated answers	A warning that a session pins an older version of a shared answer. Offers Fix
Needs updating	A publication required this answer to be re-answered; Complete is blocked until it is valid
Saved work	Started work the reviewer may still finish after the Study stopped being offered
Publication	Making a new form, profile or stage-settings version current, after an impact preview and a recorded choice
Compatibility declaration	The publisher's explicit statement that a changed question can or cannot be compared with its earlier version, and whether old options map to new ones
Questions and entity types	The Design page that holds the project's questions, one tree per entity type, numbered as reviewers see them. Never called a "library": "Library" belongs to Study Management (Q-13)
Question templates	Reusable question sets in the Catalogue. Copying one creates new project questions that record what they were copied from
Question version	An immutable published version of one question. Forms pin exact question versions
Option	Only a predefined answer choice of a question (carried from the recommendation; not separately discussed). It keeps its identity when renamed, so answers keep their meaning; Retired when withdrawn, with its answers kept
Answer	What a reviewer records for a question: a value, or a reason no value is provided. Its overall state is its answer status
Answer status (decided, DQ-46, 6 October 2026)	The overall state of a question in a session version: Unanswered; answered with a value (a listed option, Other, please specify with its text, a number, text, a date or a reference); or answered with a configured reason no value is provided. Shown by icon shape and text
Reason no value is provided (decided, DQ-46, 6 October 2026; short form "no-value reason" in dense tables only)	One of a question's designer-configured explicit reasons that no value is given: the defaults Not reported, Not applicable and Unable to assess, the designer's own reasons, and sets copied from catalogue templates such as SYRCLE. Each has a stable identity and its own metadata requirements, kept in versions and exports. Choosing one answers the question: it counts at Complete and in comparison. A risk-of-bias "Unclear" is an ordinary option, never a reason no value is provided. It replaces the retired working term "no-value answer". noValueReasonId (PROPOSAL)
No value to enter (illustrative wording, not a fixed label)	The reviewer's action beside a question that opens its reasons no value is provided (DQ-46)
Other, please specify (decided, DQ-46, 6 October 2026)	A value-bearing answer: the listed "Other" option plus its configured free text, recorded together as the answer's value. Its option identity and the text are kept in versions and exports. Never a reason no value is provided, and never a metadata field
Unanswered	Nothing recorded for a question (carried from the recommendation; not separately discussed). Only an optional question may stay unanswered at Complete. Never shown as "Not applicable"
Not compared (unanswered)	The reconciliation and agreement label for a candidate question with no answer: neither agreement nor disagreement, and it never blocks (carried from the recommendation; not separately discussed). It replaces "Not assessed"
Answer metadata	Extra fields on an answer: comment, unit, evidence quote with its source location, reason. Each is Hidden, Allowed or Required for each answer state. The text of Other, please specify is part of the answer's value, not metadata (DQ-46)
Required / Optional	Whether Complete needs an answer to the question in this form. New questions are Required by default; Optional sits under Advanced settings with a warning
Conditional display	"Only when the parent answer is …": a child question shown only after chosen parent options
Filtered options	Which of a child question's options are offered after each parent answer
Repeated answers	A question answered once for each entity instance, such as each cohort. Chosen when the question is created, then fixed
System question	A built-in question that SyRF controls. Read-only, shown with its system version
Unpublished draft	A named proposal for the next form or profile version. Several may exist for one form. Accepted field changes save into it automatically, and saving never publishes (DH-U37, decided)
Import receipt	The record of one question import: what was added, from which file, by whom and when
Guided correction	Correcting a wrong compatibility declaration or mapping by publishing a new version; the original stays in history marked as corrected
Requirement revision	Dropping an unnecessary re-answer requirement after a publication (FV4), recorded as a new policy generation
Shared answer	One answer that overlapping forms use because they share a question
Impact preview	The screen shown before an admin action that affects people working now
Apply anyway	An explicit choice that releases temporary places made incompatible by a change. Never bypasses permissions or valid configuration
Merge / unmerge	Consolidating duplicate Studies into one new current Study, and reversing that later
Consolidated Study / input Study	The Study a merge creates, and the Studies it consolidated (kept as history)
Contribution exclusion	An admin's recorded decision to take one member's contributions out of current use for a form, profile, stage or project
Deleted project	A project removed from normal use and restorable from Deleted projects
Catalogue	The one application-wide CAMARADES catalogue of reusable definitions; copies carry provenance
Training step, attempt, assessment, admission	Practice against reference answers, one go at it, its scoring, and the group membership a pass can grant
Training guidance (PROPOSAL, DH-U43)	Versioned reading material a trainee sees before an attempt, with an optional "I have read this" confirmation
Inference (beta)	Optional, off-by-default classification reasoning that suggests relationships between cohorts
Entity type (lane C1, Later release)	A kind of record a reviewer creates in a paper: Disease model induction, Treatment, Cohort, or a project type such as "Location". Replaces fixed category tabs
Named record	One thing the paper names, such as "Farm A" or "Treatment X, 10 mg/kg". Its identity never comes from its label
Population / whole-population cohort	An independent set of animals in a Study, and the system group that stands for all of them. It has no size unless the paper reports one
Coverage	Whether a cohort holds every animal in scope that meets its criteria: Complete, Partial or Unknown (default Unknown; wording from the copy deck)
Set annotation	A recorded statement about groups, such as "these share no animals" or "these together cover the population", with its evidence
Reference question (Later release)	A question whose answer points at records of declared types, such as "Housing location" pointing at Location records. It stores the record's identity, never its name
AI screening model	A machine source whose decisions a project imports. Never a person, never a login
AI-model-generated screening decision	One decision from an AI screening model, with its run, version and confidence. Never called a "model decision"
Source policy	A profile setting saying whether an external source is a contributing vote or the sole screener
Legacy-gap labels	Labels for history that legacy SyRF never recorded, one per legacy-gap state of BC §3.2 (wording illustrative): "Not recorded in legacy", "Current snapshot only", "Unknown legacy author", "Unknown legacy time", "Wording at the time unknown", "Value or default unknown", "Legacy completion not validated"
Baseline conversion / redesign	Moving a legacy project into the new structures with the same behaviour, and later rearranging it inside the new engine
Classic workflow / Versioned workflow (PROPOSAL names)	A project before and after conversion
My work	Everything a user can act on, by role, in one project and across projects
Monitor capability	The permission to see who is offered what and who is active, including names
Later release (badge)	In scope for this programme but shipped in a later release or lane than the first one. The badge tells users it is planned, not missing
Not in MVP (badge or help note)	Outside the MVP and deferred, with no delivery commitment until its own brief is approved. Shown only as a short note where a user would otherwise look for it

3.3 Roles and capabilities

Capability names below are working names until the permission catalogue is fixed (DH-T07). A capability is always granted explicitly; a role label never implies one. Holding a capability is different from being allowed to grant it. Ownership transfer is owner-only and never appears as a grantable capability.

Role	What they do	Typical capabilities
Reviewer (candidate)	Screens and annotates	Review on a stage
Trainee	Practises in a training step	Review on the training stage
Reconciler	Turns candidate reviews into accepted answers	Reconcile on a stage that binds the form
Adjudicator	Resolves screening ties and Unsure outcomes	Adjudication for a profile (Reconcile through a binding stage until named)
Assessor	Marks training attempts	Assess training
Project designer	Edits questions, forms, profiles, stages	Design
Publisher	Publishes form, profile and stage-settings versions; declares compatibility	Publish review definitions
Project admin	Manages members, settings, merges, exclusions, assignments	Edit memberships, Manage studies, Exclude contributions, Assign reconciliation work, Request an additional review
Project owner	Everything an admin can, plus owner-only actions (delete project, transfer ownership, delegate permission administration)	Owner
Monitor holder	Sees who is offered what and active reviewers' names	Monitor
Agreement viewer	Sees agreement statistics without admin control	View agreement statistics
External-screening importer and accepter	Uploads AI or external screening runs; accepts them	Import external screening decisions; Accept external screening decisions
Catalogue administrator	Publishes catalogue items; decides publication requests	System role (application)
Application administrator	Sees all deleted projects; admits projects to conversion pilots	System role
CAMARADES operator	Runs conversion operations and recovery under approval	Operator (outside project UI)

3.4 Permission boundaries the prototype must show

1. Every list, badge, panel and button is filtered by the user's permissions. Hidden controls are never the only protection, so the prototype should show the refusal state as well.
2. Assignment never grants a permission. A group assignment never hides who resolved the work.
3. Browsing "Your studies" never grants a right to start or submit work. Starting re-checks eligibility.
4. Training admission adds only the named group membership; that group's existing grants apply.
5. An AI screening model has no login, membership or permission. Attributing a decision to it grants nothing.
6. A preview shows counts to everyone and names only to Monitor holders.
7. Contribution exclusion, project deletion, merges and conversions record the real actor, reason and time.

3.5 Blinding boundaries the prototype must show

1. Candidate reviewers never see other candidates' decisions, answers, identities or submission times, in any screen, list, notice or email. The only exception is an enabled profile discussion after submitted decisions conflict.
2. Reconcilers and adjudicators see candidates as Reviewer A, Reviewer B and so on by default. The labels and their order are random for each Study and stay fixed while the reconciler works on that Study. The same person is a different letter on another Study. No submission times, stage names, avatars or "submitted first" wording appear.
3. Names appear in reconciliation only when the form (for annotation) or profile (for screening) sets "Names visible". The order stays random.
4. Monitor holders see active reviewers' names in Monitor views, but never across reconciliation blinding for a Study whose blinded reconciliation they hold or are assigned (PROPOSAL, SP-AMB-07).
5. Accepted-answer hints show the authority and version; the reconciler's name appears only to members with history access, and candidate identities never.
6. Warnings shown to a candidate before they commit never reveal that their decision will complete an outcome, trigger adjudication or move a Study out of a pool.
7. Presence shows counts and the user's own place only.
8. Emails follow the recipient's permissions and the relevant form or profile blinding at the moment of sending.

4. Screen and workspace inventory and navigation

4.1 Navigation model

The project rail follows the agreed information architecture (C17, with Q-13's labels and D3-07's My work). "Library" is reserved for Study Management and must not label the design area.

App bar: SyRF · project switcher · My work badge (count across projects) · inbox · help · account
Project index: Projects · Pending projects · My work (cross-project tab)

Project rail (Versioned workflow)
  Overview                      readiness checklist stays in the rail footer
  My work
  Review                        one entry per stage the user can review
  Reconcile                     tasks per Study × form; adjudication queue
  Design                        Questions and entity types · Concepts & rules (lane C1) ·
                                Outcome schemas (lane O1) · Annotation forms · Screening profiles ·
                                Catalogue
  Stages                        per stage: Overview · Steps and settings · Monitor
                                (Who is offered what · Review history · Eligibility explanation)
  Members & groups              Members · Groups · Permissions
  Study Management              Library (studies, duplicate queue, merges) · Searches · Processing
  Data                          Export · Agreement · PRISMA
  Project settings              General · Workflow version · Notifications · Inference (beta) ·
                                AI screening models · Delete project

Application
  Deleted projects (restricted) · Catalogue administration (catalogue administrators) ·
  Account (notification preferences, account deletion)

Coexistence. A project not yet converted ("Classic workflow") keeps today's Studies and Screening sections and today's stage settings, with the refreshed look, the My work badge and other compatible features (section 7.7). A workflow version badge in the Overview header and rail footer names the project's mode, with text and a shape, never colour alone.

4.2 Inventory versus v10

Disposition: Keep, Change, Add or Remove. "Later release" marks surfaces that are in scope for this programme but ship in a later release or lane; they are lower priority for this iteration. Deferred items outside the MVP are marked "Not in MVP" and have no screen.

Area	Screen	v10 source	Disposition	Key decisions	Changes
Chrome	App bar with global My work badge	none	Add	D3-07	DH-C12
Chrome	Project rail	navigation modes "steps" and "library"	Change	Q-13, C17, D3-07	DH-C11
Chrome	Workflow version badge and panel	none	Add	R4 direction	DH-C13
Overview	Project overview, readiness checklist, admin banner	"Overview · setup checklist"	Change	D3-07, Q-02	DH-C14
My work	Project My work and cross-project tab	none	Add	D3-07	DH-C79
Review	Reviewer workspace (step selector and one form area)	p1, r4	Change	Q-12, D3-03, D3-05, SF3, SF5; required by default (6 October 2026)	DH-C45 to DH-C67, DH-C108, DH-C112, DH-C122, DH-C127
Review	Your studies (browse) and Saved work	none	Add	D4-19, OS-A27, OS-A05	DH-C80
Review	Training attempt, with guidance before it	none	Add	OS-A18; TI-R37	DH-C89, DH-C125
Review	Cohort and record pages, compact cohort selection and the record deletion dialog (lane C1, Later release)	c4 to c6, c9, c10	Change	TC1, Q-19, populations direction (CPR)	DH-C18, DH-C65, DH-C128
Reconcile	Reconcile pool (tasks per Study × form)	r2 Reconcile page	Change	RE4, RA1 to RA5, Q-11, D2-02	DH-C41, DH-C42, DH-C111
Reconcile	Reconciliation workspace	Exploration 4a and 4b; r2 workspace	Change	RE2, RE5, OS-A02, OS-A03, SF4, Q-04	DH-C68 to DH-C71, DH-C76 to DH-C78, DH-C123, DH-C129
Reconcile	Matching	Exploration 3a	Change	MG1, SF4	DH-C73
Reconcile	Outcome reconciliation	r2 step 3 matrix	Change	RD15, SF4	DH-C74
Reconcile	Accepted-result history	RECONCILIATION §4.4	Change	GS1, OS-A28	DH-C75
Reconcile	Adjudication queue, workspace and discussion	RECONCILIATION §4.1 (screening part)	Change and Add	OS-A13, D4-01, D4-02, Q-32	DH-C72, DH-C81
Reconcile	Bulk acceptance	r2 bulk approve	Change	Q-11	DH-C41
Reconcile	Queries on accepted answers (Later release)	none	Add	QY1 to QY9	DH-C98
Design	Questions and entity types (the question tree and editor)	c2	Change	TC1, OS-A01, Q-13, D2-03, QD1; required by default and answer metadata (6 October 2026)	DH-C16, DH-C31, DH-C100 to DH-C103, DH-C117, DH-C119, DH-C120, DH-C126
Design	Concepts & rules	c1	Change	Q-18, Q-19, OS-A19	DH-C15
Design	Outcome schemas	o1	Change	OC1, ODIR1	DH-C51
Design	Annotation forms	r6	Change	OS-A12, OS-A04, Q-04, D4-17	DH-C26 to DH-C30
Design	Form composition	r6, c3	Change	SF1; required by default (6 October 2026)	DH-C104, DH-C121
Design	Screening profiles	r1	Change	DP4, D4-01, OS-A13, OS-A20	DH-C20 to DH-C25, DH-C118
Design	Publication flow (forms, profiles, stage settings)	r6 "Publish v3?" prompt	Change	FV1 to FV4, D2-01, Q-34, Q-26	DH-C24, DH-C32, DH-C106, DH-C107, DH-C110
Design	Presence and collaborative drafts	none	Add	OS-A01, D2-11	DH-C31
Design	Unpublished drafts list	none	Add	D2-11, OS-A01	DH-C105
Design	Question and form history with a diff	none	Add	AC-R2c-27	DH-C109
Design	Question import	none (an existing import dialog is described in section 5.23)	Add	R1a; DS-20	DH-C113
Design	Catalogue	none	Add	D2-15	DH-C88, DH-C114
Design	Question selection per stage	c3	Remove	SF1	DH-C17
Design	What's different from released SyRF	r8	Change	all	DH-C33
Stages	Stage list and lifecycle	r2	Change	Q-02, LC1	DH-C39
Stages	Steps and settings (filter, steps)	r2 Setup tab	Change	Q-15, Q-01, Q-24, Q-28	DH-C34 to DH-C38
Stages	Stage overview	r2 Overview tab; Stage progress	Change	OS-A09, D3-20	DH-C40
Stages	Monitor: Who is offered what	r3	Change	OD5; SP §3.14	DH-C43
Stages	Monitor: Review history	r5	Change	SL3, DP2, D2-01	DH-C50
Stages	Eligibility explanation	none	Add	OS-A07, OS-A08, OS-A10	DH-C44
Stages	Training step set-up, guidance and assessment queue	none	Add	OS-A18; TI-R37	DH-C89, DH-C125
Stages	Completed-stage change approval	none	Add	LC1, Q-02	DH-C96
Members & groups	Members, groups, permissions; disable membership	none (RD8)	Add	PM1, PM2, Q-03, D4-20	DH-C82
Members & groups	Contribution exclusion	none	Add	OS-A24	DH-C83
Study Management	Duplicate queue, merge wizard, unmerge, merged-into history	none	Add	OS-A29	DH-C86
Study Management	AI screening runs (lane XS1)	none	Add	OS-A20	DH-C93
Data	Export, Agreement, PRISMA (Later release)	Data export navigation only; r2 Agreement tab	Change and Add	EX1, EX2, AG1 to AG3, Q-06b, OS-A20	DH-C95
Project settings	Workflow version and conversion wizard	none	Add	OS-A14, OS-A15; BC-R49	DH-C13, DH-C87, DH-C115, DH-C124
Project settings	Inference (beta) opt-in	none	Add	OS-A19	DH-C90
Project settings	AI screening model configurations	none	Add	OS-A20	DH-C93
Project settings	Notification content policy	none	Add	OS-A26	DH-C91
Project settings	Delete project	none	Add	OS-A25	DH-C92
Application	Deleted projects	none	Add	OS-A25	DH-C92
Application	Catalogue administration queue	none	Add	D2-15	DH-C88
Application	Account: notification preferences and account deletion	none	Add	D3-24, D2-14	DH-C91, DH-C94
Overlays	Active-work impact preview, target override, additional-review request	none	Add	consolidation §6; OS-A12	DH-C84, DH-C85

4.3 The reviewer workspace: step selector and one form area

Owner decision Q-12 (4 October 2026). "Use a step selector/strip with one form area in the existing annotation workspace, rather than several competing cards. Validate it with users before committing to the layout." Chris added: "Go with the recommended answer and the existing prototype presentation." The v10 stepper presentation is therefore the starting point; the card-per-step alternative is retired.

Regions, top to bottom (desktop):

1. App bar and project rail. The rail is in-flow at 1,240 CSS px and wider; below that a menu button opens it as a drawer.
2. Study header. Title (never truncated while space remains), "Stage · study N of M", status chips (Your decision, In progress, Completed, Needs updating, Outdated answers), a presence count chip (counts only), the stage progress meter and the My studies navigator when the project enables it.
3. Step selector. A horizontal strip of the steps this reviewer can see. Each item shows the step name and its state by icon shape and text: Available, Locked (with the reason on focus or tap, for example "Finish step 1 first"), Done, Skipped, Held, Not applicable. The selected step is highlighted with a container colour. The adjudication step appears only to eligible adjudicators; training steps appear only where configured. Keyboard [ and ] move between steps; Enter opens. Below 600 CSS px the strip collapses to a labelled menu: "Step 2 of 3 · Risk of bias · Available". The selected step is part of the URL (PROPOSAL), so links and the back button work.
4. Main area. The study source card (title, authors, abstract, PDF viewer link) sits in a left column when at least 980 CSS px of content width remains; otherwise it becomes a collapsed disclosure above the form. The one form area shows the selected step's work: the screening card on top when the step has screening, the annotation form below when it has annotation, both when the step combines them.
5. Action bar. Revert changes (only when the draft has changes) · "N required missing · Jump to next" · Save progress · Complete. On narrow screens the bar is sticky and must stay above the on-screen keyboard.
6. Status line. One quiet line in the action bar, announced politely to screen readers (section 5.1).
7. History panel. A drawer listing versions, draft changes, kept copies and provenance.

Tablet (768 to 1,239 CSS px): drawer rail; source card as a collapsible panel or side panel where width allows; the same step selector. Phone (below 600 CSS px): one column; step menu; source collapsed by default; outcome data as a per-cell list that keeps every function; 44 px touch targets; no feature removed.

Retained from Review Prototype v4 (with D3-04 changes): equal-weight Include and Exclude buttons (never a filled Include, so the interface does not nudge); criteria beside the decision; wrapping category tabs with status dots and the opt-in left rail; branch tabs with dots and a rename hint; numbered gutters; one comment per answer and quote-into-comment; Unanswered only; live completeness with Jump; keyboard shortcuts; Review preferences dialog; the anchored "What's new" tour; the unsaved guard on navigation. Changed under D3-04: sentence case on every button and header control; Material 3 type scale and component shapes; the "Unsaved changes" chip and "All changes saved" footer are replaced by the status line; "Remove all annotations…" is replaced by "Discard draft changes" and a versioned withdrawal.

4.4 The reconciliation workspace

1. Header. Back to pool · Study title and citation · chips for how the task was reached ("Assigned at random", "Opened by you · audit logged", "Assigned to you by an admin") and for blinding ("Reviewers blinded" or "Names visible") · "Accepted-result history" toggle · Release.
2. Form part. The same controls as the reviewer form, with candidate pills between each label and control, an agreement icon (agree, differ, only one answered), the autofill marker on agreeing answers, "N to resolve · Jump to next", Unresolved only, Save progress and Complete. A question shared with another form that already has an accepted answer also shows that answer as a hint, with an optional reason field and Raise a query (section 5.5).
3. Side by side (desktop only). A grid: Question, one column per candidate, Reconciled answer. On narrow screens a candidate selector replaces it; the selector never hides a disagreeing candidate. On phones the whole workspace stays usable with no feature removed, without a formal phone acceptance gate (DH-U12, decided 6 October 2026; section 7.1).
4. Matching (Review matches). Groups that can contain entries from every candidate.
5. Outcome data. The outcome × cohort matrix with one preview per candidate in each cell, and a dialog comparing every candidate's series.

4.5 Shared patterns (each specified once, reused everywhere)

Step selector · save-status line · conflict panel (both values kept) · status chips · version badge · history timeline · candidate pills and agreement icon · autofill marker · accepted-answer hint with "Use accepted answer" · impact preview with Apply anyway · publication flow stepper · queue list (My work rows, pools) · workflow version badge and panel · "What changed" panel · anchored tour · presence count chip · progress vocabulary strip ("Your work", "Available to you", "Waiting on others", "Locked by a step", "Enough reviewers") · keyboard hint (kbd, shown only when the shortcut is live and hidden when touch is the primary pointer) · page states (loading, empty, failure) · long-running operation row (with a real numerator, never invented progress) · version chip and lifecycle state (section 5.22) · child-validity warning · option-mapping table · per-field diff · import preview and receipt.

5. Flows and states

Each flow lists entry points, steps, the nine states and the rules the prototype must show. Copy is illustrative; the meanings are fixed. "Draft", "checkpoint" and "complete" always follow section 5.1.

5.1 The save-state contract (Draft auto-saved, Version checkpoint saved, Complete)

Owner decision (U1 amendment to D3-03, with wording flexibility). "Draft auto-saved" means autosaved edits not yet captured by an explicit Save or Complete. "Version checkpoint saved" (or equivalent clear wording) means an explicit Save progress created an immutable session version. Complete stays visibly distinct from an incomplete checkpoint. Never call an autosaved draft a submitted version, and never imply that a checkpoint completes the session. When a checkpoint exists and newer edits are autosaved, keep showing the earlier checkpoint. The words may change through design review; the three meanings may not.

What each action does:

Action	Creates	Counts towards targets	Becomes current
Autosave (debounced, sends only changed answers with base checks)	A draft change; never a version	Never	The completed or checkpoint version stays current
Save progress	An immutable incomplete version (a checkpoint)	Never as completed	Yes. A Save after Complete stops the review counting as complete
Complete	An immutable completed version after whole-form validation	Yes, once per reviewer per Study and form, whichever stage was used	Yes

Status line states (reviewer and reconciler forms):

Situation	Illustrative status
Not started	"Not started"
Draft only	"Draft auto-saved · no checkpoint yet"
Checkpoint, nothing newer	"Version checkpoint saved 14:02"
Checkpoint plus newer draft	"Draft auto-saved · last checkpoint 14:02"
Complete, nothing newer	"Complete · 14:10"
Complete plus newer draft	"Draft auto-saved · your completed version (14:10) still counts"
Saving	"Saving draft…" (no toast)
Retrying	"Trouble saving draft. Retrying…" (input continues)
Offline	"Offline. Your latest edits are held until you reconnect." (how edits are held is DH-U11)
Failed	"Draft not saved to the server" with Retry; focus moves here on an explicit Save or Complete

Save progress after Complete. Before an incomplete Save replaces a completed version, a confirmation says: "Saving progress now replaces your completed version. This review will stop counting as complete until you complete it again." If reconciliation or accepted answers depend on the completed version, the confirmation adds that, at the reviewer's level of access, without naming a reconciler or another candidate.

Other kinds of unfinished work keep their own words so they never blur with the three meanings above: a reconciler's autosave uses the same status line; a design change not yet published is Unpublished; a resumable guided set-up is Setup in progress; a correction being edited is Correction in progress; a value kept after a same-answer conflict is Copy from another tab; a merge-conflict resolution is Resolution in progress; a conversion mapping is Draft mapping (the last two labels are PROPOSAL wording added by this document).

Banned strings (the copy deck rejects them): "Save draft" as the explicit save label, "All changes saved", "Changes kept, not yet saved", "Autosaved—not yet submitted", "Submit", "Gold standard" as a bare label, "Outcome" for a screening result, "Unavailable" for progress, "model decision", "canonical", "question library", "Mark compatible", and "Locked question" in a Versioned project (versions replace the lock; a Classic project names its answered-question lock "Answered: locked (Classic)", section 5.22). The word "legacy" is banned as a general label for old data, old projects or old screens (say "Classic workflow" for a project that has not been converted). Allowed: the defined legacy-gap labels (glossary, section 3.2; BC §3.2) and the conversion wording that the BC and SP specifications give (sections 5.10 and 5.13). 6 October 2026 (DQ-46, decided): also banned on screen are "no-value answer" (the retired working term), "blank" for an unanswered question, "response mode", "response option", "missing-data code" and "answer exception". Use Answer status, Unanswered, reason no value is provided and Other, please specify as section 3.2 defines them.

5.2 Screening

Entry points. Review › stage › Next study (random from Your studies by default); My work "To review"; Your studies (browse, when enabled); a direct link; My studies navigator.

Steps.

1. The reviewer opens a Study. The step selector shows the screening step.
2. The screening card shows the profile's criteria and, when the profile has eligibility questions, those questions. As the reviewer answers, a proposed decision appears with its reasoning ("Proposed: Exclude. Population is not cattle (your answer to Q2)"). Answering or autosave never records a decision (DP3).
3. The reviewer chooses Include, Exclude or, when the profile enables it, Unsure. All buttons have equal weight. With eligibility questions, the submit button records the displayed derived decision and its answers together. Exclusion reasons follow the profile: required, optional or off; several reason questions may exist; the template may nominate a primary reason.
4. After deciding, the card shows "Included" (or Excluded, Unsure) with Correct decision, and the next-study preference applies.
5. Correcting an earlier Exclude happens from the reviewer's history when review is still possible (DP2). It writes a new version; the old one stays in history.

Keyboard (PROPOSAL where the profile allows): I Include, E Exclude, U Unsure (Unanswered only then moves to Shift+U), N Skip (records nothing), J jump to next required, [ and ] steps. Keys are ignored in dialogs, menus and text fields. With derived decisions the I and E keys are inert and the hint reads "Answer the questions; Enter records your decision". A plain profile needs one action per decision; reasons add one.

Progression after screening (within the stage, Q-01). By default the reviewer may move to a dependent step after their own Include while the team result is pending (own Unsure is DH-U02). A stage setting can make everyone wait for the team's Include. A later collective Exclude still stops new work where exclusion-stop applies.

State	What the reviewer sees (illustrative)
Loading	Skeleton card, then the criteria
Empty	"No more studies available in this stage" with the reason category, for example "Waiting on others"
Pending	Own decision recorded; team result pending, which the candidate does not see unless the project shows screening results
Incomplete	Eligibility questions partly answered: "Draft auto-saved · decision not recorded"
Completed	"Included · 10:41" with Correct decision
Unavailable	"This study is no longer available in this stage" (reason given only where disclosure rules allow)
Historical	History shows each decision version with its time and route
Conflict	Correction submitted from a stale base: "A newer decision was recorded in another tab. Yours is kept as a copy"
Failure	"Your decision was not recorded. Try again" with the decision still selected

5.3 Annotation

Entry points. As screening, plus Saved work, Needs updating and Outdated answers rows in My work.

Steps.

1. Opening a Study creates nothing. The first autosave creates the reviewer's one session for that Study and form. The same session opens from every stage, tab and device that uses the form.
2. Edits autosave as a draft (section 5.1). Hints appear where enabled (section 5.4).
3. Save progress creates a checkpoint. Complete validates the whole form, including questions that are not rendered because of virtual scrolling. A failed Complete shows "3 required answers missing · Jump to next", focuses the summary and opens the right step, category, branch and entity when the reviewer jumps. 6 October 2026: an answer is a value or a reason no value is provided, and Complete also checks the metadata each chosen answer needs; Save progress never needs an answer (section 5.24).
4. Needs updating marks an answer a publication invalidated; the old answer stays visible with "Why it changed" and "What to do differently". Complete is blocked until valid.
5. Outdated answers marks a session that pins an older version of a shared answer. The form's setting decides (the two modes are decided, D4-17; keeping the setting in the form version is a PROPOSAL, RS-R41): warn and allow "Complete anyway" (default) or block until addressed. Fix deliberately creates a new incomplete version and opens that session's form.
6. Two tabs or devices may edit the same session. A change to the same answer from a stale base shows a conflict panel with both values; the reviewer keeps either; nothing is discarded silently.
7. The place stays held while any connection is active. When every connection has been idle beyond the form's timeout, the place is released and the draft kept: "Your place was released while you were away. Your draft is kept." If capacity has filled, the reviewer may keep or discard the draft.

Combined steps (v10 behaviour, kept): Complete submits the screening Include under the profile together with the form; Exclude skips the rest of the form without deleting answers; Save progress never records a decision.

State	What the reviewer sees (illustrative)
Loading	Skeleton, then the first page of units
Empty	"No answers yet" (no session exists until the first edit)
Pending	Step locked: "Locked: finish step 1 first", or "Waiting for the team's screening result"
Incomplete	"Draft auto-saved · last checkpoint 14:02"; "3 required answers missing"
Completed	"Complete · 14:10"; answers read-only until the reviewer edits again
Unavailable	"An admin has restricted finishing work on Studies that left this stage. Your draft is kept." or "This project has been deleted. Your draft is kept."
Historical	History panel lists versions with kind, route and provenance, including versions generated by a publication or merge
Conflict	Conflict panel with both values; or "A newer version of this review was saved, perhaps in another tab. Your changes here are kept as a copy."
Failure	"Draft not saved to the server" with Retry; Save progress available when the server returns

5.4 Accepted-answer hints and click-to-fill

Owner decision (Q-28 hints amendment, Q-30; OS-A04). Accepted answers are shown as labelled hints by default. The annotation form sets the baseline (Shown or Hidden). A stage step may hide hints the form allows; it can never reveal hints the form hides. SyRF never fills an answer automatically. The reviewer clicks to copy. Showing and copying are recorded, so a copied answer never counts as independent evidence. Hiding hints at a step never removes answers already entered or copied and never undoes exposure through another route.

Entry points. Any annotation form opened through a step whose effective hint setting is Shown, on a Study with an applicable accepted answer.

What a hint looks like. Under the question: "Accepted answer: Rat · accepted answers v3 · Reconciled" and a Use accepted answer button. A form-level Use all available accepted answers action fills every applicable hint at once. Replacing a value the reviewer already entered needs an explicit choice ("Replace your answer 'Mouse' with the accepted answer 'Rat'?"). No fill action appears where no applicable hint exists. Provenance opens the exact source version; the reconciler's name appears only for members with history access; candidate identities never appear.

Applicability. A hint appears only where an accepted answer exists for the same Study and answer context under the question-version compatibility rules. The first release shows hints for Study-level questions and option branches; hints for repeatable entity instances wait for a correspondence rule (deferred; PROPOSAL, RS-R37).

How "informed" is communicated is DH-U07.

State	What the reviewer sees (illustrative)
Loading	Hint area reserved; no layout jump when it arrives
Empty	No hint and no fill action where no applicable accepted answer exists
Pending	"Accepted answer being updated" when a newer accepted version is being published
Incomplete	Hint shown; control still empty until the reviewer clicks
Completed	Copied answer shows "From accepted answers v3" beside the value
Unavailable	The step hides hints, or the form baseline is Hidden: no hint, no fill action
Historical	History shows exposure and adoption entries with the source version
Conflict	"The accepted answer changed after you copied it. Your copy used v3; v4 is now current" with "Use v4"
Failure	"Accepted answers could not be loaded" while the form stays usable

5.5 Reconciliation (annotation forms)

Entry points. Reconcile › pool › Start reconciling (assigned tasks first, then random among eligible tasks; PROPOSAL); My work "Reconciliation assigned to you"; an admin's Open a specific study (audit-logged, reserves it); a notice.

Who may reconcile. A member with Reconcile on a stage that binds the form, who is not a candidate on that Study and form. An explicit, audited override grant can allow a candidate to reconcile, and every use is shown in provenance (Q-36). A refused member sees "You reviewed this study". Show the override with a "To be decided" chip: whether the grant allows self-reconciliation, or only overriding an existing outcome, is still open (DQ-20 in the open questions before the design handoff).

Target one (R1 final, OS-A28). Each form version sets what happens when the effective target is one:

• Accept automatically. The single completed review becomes the accepted result at once, labelled Single annotator (accepted automatically). It is never labelled reconciled, verified or checked.
• Require human reconciliation. A second person reconciles one candidate in the ordinary workspace ("one extracts, one checks"). The result reads Reconciled (one candidate). There is no separate verification screen or session type.

A surplus candidate arriving after a Single annotator result puts the task into "Inputs changed · 2 candidates"; the existing result stays effective until a reconciler completes.

Two or more candidates. A human reconciler always produces the accepted result. Agreement alone never creates one. Every qualifying candidate takes part (the target is a minimum).

Steps.

1. The workspace opens with a random, Study-local alias mapping, fixed for the life of this reconciliation session. A candidate who arrives later gets a new alias and is appended without reshuffling ("1 new candidate since you started").
2. Agreeing answers are filled in with the autofill marker (a dashed outline is the v10 treatment) and a note naming their source ("Filled from matching answers: Reviewers A, B, C"). Free text fills only when the texts match exactly. A candidate question with no answer shows Not compared (unanswered) (it was "Not assessed"; the label is carried from the recommendation into the terms decided on 6 October 2026, DH-U42): it is neither agreement nor disagreement and never blocks. "Unknown" and "Not reported" are real answers that compare like any other option, and so is every reason no value is provided: the same reason agrees, while a value or a different reason disagrees. Other, please specify compares as a value: the Other option together with its text (section 5.24).
3. The reconciler resolves differing answers by clicking a candidate pill or entering an answer. Explanations are optional; a non-blocking reminder appears when the reconciler chooses an answer different from every candidate.
4. Complete. If relevant questions were never brought into view, a warning lists them with links and offers Complete anyway. Normal validity and child-question requirements still apply. A successful Complete creates a new accepted-result version and shows "Accepted · Reconciled by you · v3" with Next task and Back to pool.
5. If inputs changed while the reconciler worked, Complete returns "Inputs changed since you opened this study. Your draft is kept."

Questions shared with another form (owner decision D2-09, decided by Chris on 5 October 2026; DH-U27). Two forms may share a question, such as "Species" in "Study design" and "Outcome data". When the other form's reconciler has already accepted an answer for this Study:

• The existing accepted answer is a hint, never prefilled. Under the question the reconciler sees the section 5.4 hint pattern: "Accepted answer: Rat · accepted answers v3 · from Study design" and a Use accepted answer button. The hint never fills the reconciled answer by itself (OS-A04); the autofill rules in step 2 still apply to this form's own candidates. The other reconciler's name appears only for members with history access.
• Keep or revise. The reconciler may keep the accepted answer (Use accepted answer) or choose or enter a different one. A different answer is a revision of the one shared accepted answer, not a second, competing answer.
• Optional reason. As soon as the reconciler's answer differs from the accepted answer, a field appears under the question: "Why are you changing the accepted answer? (optional)". It is prompted, never required: Save progress and Complete work with it empty, and an empty field shows no error or warning.
• Raise a query. A Raise a query action sits beside the hint, carrying the accepted-answer version the reconciler saw. Queries arrive in a later release, so show it with the "Later release" badge (DH-C98).
• After Complete. The accepted-result history shows "Revised for Outcome data · v4 · supersedes v3 (Study design)", with the reason when one was given. The earlier version stays in history, and both forms show the new accepted answer.

State	What the reconciler sees (illustrative)
Pending	"Accepted answer being updated" while a newer accepted version is being published
Conflict	"The accepted answer for Species changed since you opened this study (you saw v3; v4 is now current). Your draft is kept." with "Use v4"
Historical	The revision with its reason, or "No reason given", beside the version it superseded

Bulk acceptance (optional per form, off by default, Q-11). "Accept agreeing studies" lists Studies where every candidate agrees on every compared answer, with per-Study warnings. Excluded with reasons: a held question, inputs changed since the preview, a required question left unanswered, a compared free-text difference, the reconciler as a candidate, or any disagreement. The reconciler confirms the exact list; each result names them and "bulk-confirmed".

Assignment and release. The shared pool is the default. An admin may assign a task to an eligible member or group. Expiry of an assigned, unstarted task is optional and off by default; when enabled, an admin sets the duration (no default is approved). Started work never expires; an admin may release it to the pool, keeping saved work, and the original reconciler must reacquire it.

Request an additional review (capability needed). Raises the effective target for the chosen Studies, may name people or groups, and counts each reviewer once. The extra reviewer sees no other candidate's answers.

Permission-aware provenance. Each accepted-result version shows its authority, the form version and any Study-specific target it used, the number of candidates, the time and, for members with history access, the reconciler or the system rule that created it. Candidates appear under the aliases of that reconciliation session. Real candidate identities appear only through an audited "Show identities" action for holders of the history capability, and the action is recorded. Accepted answers that a reviewer copied from a hint, and merge-carried results, say so in their provenance.

State	Pool or workspace shows (illustrative)
Loading	Skeleton rows: "Loading studies"
Empty	"No studies are ready" with counts of waiting, held and accepted Studies
Pending	"Waiting for 1 more qualifying review (1 of 2)"; "Accepting" while an automatic acceptance lands
Incomplete	"Version checkpoint saved · not completed" on the reconciler's own work
Completed	"Accepted · Reconciled by you · v3"
Unavailable	"You reviewed this study"; "Assigned to Chloe Martin"; "You no longer have Reconcile on a stage using this form"; "Held: versions differ"
Historical	Accepted-result timeline with authority labels and superseded versions
Conflict	"Inputs changed since you opened this study. Your draft is kept."; "Someone else is reconciling this study right now"
Failure	"We could not save your reconciliation. Your draft is kept." with Retry

5.6 Screening tie adjudication, Unsure and discussion

Owner decisions. D4-01 (Unsure per profile, on in the title and abstract template, not excluded for availability), the S1 Unsure amendment (OS-A16), the tie adjudication amendment and adjudicator assignment (OS-A13), D4-02 (optional discussion) and Q-32 (optional required rationale).

Configuration (profile version). Unsure on or off; tie policy chosen explicitly, either Extra review with a bound or Adjudication, with no platform default (templates preselect visibly); separately configured handling for each trigger (decision tie, unresolved Unsure, reason disagreement, AI sole-screener Unsure); discussion on or off with an optional admin-set time limit; adjudication rationale required (off by default). The adjudicator assignment (a member or an eligible group) is a separate audited setting and needs no profile publication.

Owner's example configuration (two agreeing definite decisions, extra review bound one, then adjudication). Evaluation ignores order.

Decisions so far	Result
Include, Include	Included; no third requested
Exclude, Exclude	Excluded; no third requested
Include, Exclude	Waiting for one more decision
Include, Unsure	Waiting for one more decision
Include, Unsure, Include	Included
Exclude, Unsure, Exclude	Excluded
Include, Unsure, Exclude	Awaiting adjudication
Include, Unsure, Unsure	Awaiting adjudication
Unsure, Unsure, Unsure	To be decided (DH-U03)

Rows the owner did not state (in-flight decisions, four or more decisions, other thresholds, larger bounds) are "to be decided" in the prototype (DH-T11).

Adjudication flow.

1. A Study awaiting adjudication appears in the adjudication step and in My work for the assigned member or for eligible members of the assigned group. A member who decided on that Study is not offered it.
2. One eligible member claims it. They see the exact tied decision versions under the profile's blinding (aliases by default), including any AI-model-generated decision with its label, confidence and threshold (whether the source type is shown when blinded is DH-U08).
3. They record Include or Exclude, with reasons where the profile needs them and a rationale when required. The result reads "Excluded · adjudicated by Ben Carter". The original decisions stay.
4. A later correction leaves the adjudicated result current, flagged "Inputs changed", until an adjudicator explicitly reconsiders it.

Discussion flow. After submitted decisions conflict, both candidates are invited. Each sees "Reviewer A: Include" and "Reviewer B: Exclude · Wrong population". A participant may correct their decision (a new version) or mark "Cannot agree". Ending unresolved applies the tie policy. Independent agreement statistics keep using the initial decisions.

Pending stays pending. While a result is Waiting, In discussion or Awaiting adjudication, exclusion-stop does not trigger and steps that need the team's Include keep waiting.

State	Adjudication queue or workspace shows (illustrative)
Loading	"Loading adjudication tasks"
Empty	"Nothing awaits adjudication"
Pending	"Awaiting adjudication · assigned to Senior screeners"
Incomplete	"Version checkpoint saved · rationale required before recording"
Completed	"Excluded · adjudicated by you · rationale recorded"
Unavailable	"You decided on this study, so you cannot adjudicate it"; "Claimed by Ben Carter"
Historical	Adjudication versions with inputs, triggers and actors
Conflict	"The decisions changed since you claimed this task. Your draft is kept."
Failure	"The adjudication was not recorded. Your draft is kept."

5.7 Merge and unmerge

Owner decisions (consolidation §2; D2-12 replaced; OS-A29). A merge creates one consolidated current Study. The input Studies are kept unchanged as history and are no longer listed, offered or counted. The commit is all or nothing. Unmerge is a new action that restores the inputs and never erases the merge. Duplicates only: distinct reports (for example a conference abstract and its later article) are never merged.

Entry points. Study Management › Library › Duplicate queue (Confirm duplicate, Not a duplicate, Distinct report, Defer); a reviewer's "Flag as possible duplicate of…"; an admin's selection.

Merge steps.

1. Preview. Inputs with exact versions; the evidence inventory per form and profile; conflicts; differing reviewer targets; suggested bibliography field by field; active work (reviewers, reconcilers, drafts, places).
2. Resolve conflicts in a reconciliation-like view. Same-reviewer screening decisions or form reviews on two inputs; differing accepted results; differing adjudicated results. Agreeing answers fill the controls; conflicts sit side by side. Answers and complete or incomplete status are resolved together, and Complete still validates. The admin chooses among the inputs' values and never types a new value into a reviewer's review (PROPOSAL).
3. Delegate a reviewer's conflict to that reviewer, who gets a My work item: "Duplicate merge needs your input: Lee 2021 was imported twice and you reviewed both copies." The actual resolver is recorded.
4. Confirm the consolidated effective target and the bibliography (each field keeps its source record, who decided and when).
5. Commit. If anything changed since the preview, the commit refuses ("S-204 changed since the preview") and the preview refreshes. On success the inputs show "Merged into S-512 on 5 October by Priya Shah" and offer "Continue in S-512" to anyone with a draft there.

Unmerge steps. The preview lists every item created on the consolidated Study after the merge, with a suggestion where lineage gives one. Each needs an explicit choice: "Move to S-204", "Move to S-377" or "Leave in the merged history". "Both" is never offered. A warning appears for accepted results whose inputs came from both originals.

Blinding. Detecting that one reviewer reviewed both inputs needs identities. A merging user who is blinded for the form sees "Reviewer 1 (same person on both)" and can delegate without learning who it is.

State	Merge or unmerge shows (illustrative)
Loading	"Preparing the merge preview"
Empty	"No conflicts. 6 items will be carried to the consolidated Study"
Pending	"1 reviewer to respond: Alice Martin, delegated 5 October 10:12" (name only where allowed)
Incomplete	"Resolution in progress · 2 of 3 conflicts resolved"; commit disabled
Completed	"S-512 is current. Consolidated from S-204 and S-377 (merge M-17)"
Unavailable	"This study is already in another merge"; "Reverse the later merge first"
Historical	Tombstoned inputs readable with "Merged into S-512"; Library filter "Show merged records"
Conflict	"S-204 changed since the preview"; "New active work appeared. Review it again."
Failure	"The merge did not commit. Both studies are unchanged."

5.8 Active-work impact previews and Apply anyway

Owner decision (consolidation §6). Every admin action that affects reviewers shows its impact before commit, rechecks at commit and informs affected people afterwards. Apply anyway may release temporary places made incompatible by a change (for example after lowering a capacity cap) while keeping drafts. It never bypasses permissions, valid configuration, allocation constraints, validation or mandatory re-review.

Entry points. The Confirm, Publish, Save or Apply button of any admin action listed under "Producers" below; the preview opens before anything is committed.

Preview sections. What changes · who is affected now (counts; names only for Monitor holders, never across reconciliation blinding) · what is kept (drafts, submitted work) · what will be released (temporary places only) · dependent results whose inputs change · which notices will be sent.

Actions. Cancel · Confirm · Apply anyway (only when the change conflicts with temporary places; its label names exactly what it releases, for example "Apply anyway and release 4 places").

Recheck. If the impact changed after the admin reviewed it: "The impact changed since you reviewed it" with the difference, then ask again.

Producers. Form, profile and stage-settings publication (for form publication, Apply anyway appears only for a target-only publication that lowers the target and conflicts with temporary places; a publication that changes questions never offers it, because drafts are always kept; RD §7); target and override changes; merge and unmerge; capacity, timeout, in-progress limit, filter, continuation and lifecycle changes; adjudicator assignment changes; external run acceptance; search withdrawal; contribution exclusion; project deletion and restoration; conversion waves (which never use Apply anyway).

State	Preview shows (illustrative)
Loading	"Checking who is affected"
Empty	"Nobody is working on affected studies now. Nothing will be released."
Pending	Preview shown; nothing committed
Incomplete	Required choice missing (for example an override treatment); Confirm disabled with the reason
Completed	"Applied. 3 places released; drafts kept; 3 notices sent"
Unavailable	"You need Publish on this form to make this change"
Historical	The operation record shows the confirmed impact summary and whether Apply anyway was used
Conflict	"The impact changed since you reviewed it"
Failure	"Nothing was changed. Try again."

5.9 Form and profile publication (target changes and compatibility)

Owner decisions. FV1 to FV4; VU1 to VU3; PS1 to PS3; D2-01 amended (publication may create attributable generated session versions); D2-02 amended and Q-34 (the publisher declares compatibility and mapping explicitly; immutable from commit); target-versions-form (OS-A12); Q-26 (profile versions with mismatch detection); D2-11 and collaborative drafts (OS-A01); D4-05 (eligibility-changing profile publication needs a protocol amendment entry).

Entry points. Design › form or profile › Publish (from one of several Unpublished drafts); a change to the standard target or reconciliation policy; Stages › Steps and settings › Publish.

Form publication steps (one stepper):

1. Review changes. Changed questions grouped by category. For each, SyRF's suggestion ("Options were only added: compatible") and the publisher's explicit Compatible or Not compatible declaration, with a rationale field and, where allowed, an option mapping (old option → new option). Meaning changes must be declared not compatible. Optional "Why it changed" and "What reviewers need to do differently" per question; a missing reason shows a non-blocking warning.
2. Impact summary. Per earlier form version and per stage using the form: counts of completed, saved-incomplete and draft-only reviews, active reviewers, reconciliations in progress, accepted results and dependent steps. Usage evidence shows its freshness; stale evidence blocks with "Updating usage figures…".
3. Choices. Per changed question: Require re-answer, Update automatically (compatible only) or Keep as is; per review category where they differ. A "What reviewers will see" preview renders a sample review in each category with Needs updating markers.
4. Confirm. A summary of reviews affected per choice, notices to be sent once per recipient and the generated versions to be written. The inputs are rechecked at commit.
5. After. A long-running operation row with real progress. Reviewers see an in-form alert when they next open the review. Drafts are kept and rebased; overlapping draft edits show both values. Generated versions read "Version 4 · generated by publication of Risk of bias v3 · Priya Shah".

Target-only publication. Changing the standard target publishes a new form version with no question changes. The preview lists Studies whose sufficiency changes, accepted results that fall below the new target, Studies that newly meet the Single annotator condition, and every Study-specific override with a required treatment (keep its effective value, rebase it or remove it; the suggested default keeps each Study's effective target). Show this override treatment with a "To be decided" chip; it is still open (DQ-11 in the open questions before the design handoff). Treatments: for a raised target, keep accepted results, labelled "below current target (1 of 2)" (default), or suspend them (DH-U26); for a lowered target with Accept automatically, create Single annotator results now or at the next qualifying completion. No review, vote or reviewer is ever created.

Profile publication. The preview finds decisions, results and adjudications under earlier profile versions and their consequences. Treatments: keep decisions pinned, request new decisions or carry compatible decisions forward. If eligibility changed (SyRF suggests it, a PROPOSAL detection; the publisher confirms or overrides with a reason), a protocol amendment entry is required in the same flow (decided, D4-05). A source-policy change counts as an eligibility change (PROPOSAL).

One publication at a time. Other drafts stay editable: "Publishing by Priya since 14:05. You can keep editing drafts." The next publication rebases and recomputes its impact.

Corrections. A wrong declaration or mapping is corrected by a guided rollback that publishes a new version and generates corrective versions; the original stays in history marked "corrected by K-2". An unnecessary re-answer requirement can be revised (FV4), recorded as a new policy generation.

State	Publication flow shows (illustrative)
Loading	"Calculating impact"
Empty	"No existing reviews use earlier versions. Publishing creates v2."
Pending	"Waiting for current usage figures" or "Publishing… 1,240 of 3,100 studies updated"
Incomplete	"2 changed questions need a compatibility declaration"; Publish disabled
Completed	"Risk of bias v3 is published" with the impact manifest link
Unavailable	"Another publication of this form is running"; "You need Publish on this form"
Historical	Version list with target, policy, declarations, reasons and generated versions
Conflict	"The impact changed since you reviewed it"; a draft conflict "keep mine" or "discard mine"
Failure	"Publication stalled at 1,240 of 3,100. It will resume."

5.10 Migration: the conversion wizard and later redesign

Owner decisions. R4 owner direction (OS-A15): one eventual writable engine; staging trials, production pilots, then conversion of every remaining project, including completed and inactive ones, to a faithful baseline; later optional redesign inside the new engine. R4 amendment (OS-A14): the wizard shows how each legacy stage's annotation and screening work maps to steps, forms and profiles, what is created and reused, and when to convert or wait. Q-05, Q-21, D4-16. No migration is authorised now.

Entry points. Project settings › Workflow version (project owner and admins); My work "Conversion findings needing action"; a wave notice.

Conversion wizard steps.

1. Summary. The latest read-only inventory: stages, forms, sessions, decisions, records with counts; findings with remedies.
2. Mapping. Each legacy stage on the left; its proposed steps, forms, profile, filter, targets and settings on the right, labelled Created or Reused. How existing sessions, answers and decisions map, with counts. Where the default step setting differs from legacy behaviour, the wizard says so ("New steps default to Stop; this baseline keeps Allow to match the old stage"). 6 October 2026: each converted question keeps its legacy Required or Optional setting, shown "Optional (kept from legacy)", and conversion adds no reasons no value is provided (DH-C124).
3. Screening meaning. The admin confirms what the legacy-compatible profile means ("title and abstract screening"). Unconfirmed profiles carry no PRISMA phase (DH-U23).
4. Converging stages. If the admin maps two stages onto one shared form, every reviewer with work in both is listed; each conflict group is resolved (or delegated) before approval.
5. Findings and guidance. "Convert now" when every check is green; otherwise a specific finding and remedy, for example "Stage 3 uses proportional allocation; that is not available yet" or "Phone form load above budget". Waiting is a supported choice during trials and pilots.
6. Approve. The owner (or a delegate) approves the mapping; if legacy data changes before cutover, the approval becomes invalid and the wizard says why. Show this step with a "To be decided" chip: what Chris's approval of a conversion wave covers, and so when an owner must approve in a wave, is still open (DQ-44 in the open questions before the design handoff).
7. After conversion. The project shows "Converted on [date]. Review history before that date is current snapshot only; stage pool history before it was not recorded." Legacy-gap labels appear on affected values and in exports.

Containment. If a problem is found after the first new-engine write, the project becomes read-only with "This project is read-only while it is checked. Your changes are kept. Nothing you saved is lost." Before any new write, the project can return to the classic path with nothing lost.

Later redesign wizard. Rearranges a converted project (for example splitting one stage into screening then annotation). It is an ordinary publication with an impact preview. It reads no legacy data. 6 October 2026: it lists converted optional questions and offers "Make required, with reasons no value is provided such as Not reported and Unable to assess", one question at a time; the publication preview then asks whether earlier completed reviews still count (DH-C124).

State	Wizard shows (illustrative)
Loading	"Reading the latest inventory"
Empty	"No review data to convert. Your stages and questions will be set up in the new structures."
Pending	"Approved. Waiting for the conversion window"
Incomplete	"Draft mapping · 1 conflict group unresolved"; approval disabled
Completed	"Converted. Parity report passed"
Unavailable	"Conversion unavailable: 3 legacy reconciled sessions found. Their treatment needs an owner decision."
Historical	Conversion record with manifest, parity report and dates
Conflict	"Project changed since approval. Review the mapping again."
Failure	"Conversion paused: large-form phone load above budget. Remedy: performance work. The project keeps working as before."

5.11 Reviewer-pool browsing and saved work

Owner decisions (O4 browsing addition and clarifications; D4-19; OS-A27; OS-A05). Random serving stays the default. Optional, explicitly enabled browsing lists Your studies in a stage: the current stage pool restricted to the reviewer's allocation or assignment and current availability. The list is dynamic. It shows no other reviewer's candidate decisions, answers, tallies, identities or times. Browsing grants nothing; starting re-checks eligibility. Removal from the list never revokes permitted continuation.

Entry points. Review › stage › "Your studies" (only when the stage enables browsing); My work "Saved work you may still finish"; the reviewer workspace's Saved work link.

Browse row content. Bibliographic details (hidden where the profile's bibliographic blinding is on); the reviewer's own status per step (Not started, Draft auto-saved, Version checkpoint saved, Completed; wording illustrative); their step availability ("Available", "Waiting for the team's screening result", "Enough reviewers", "Stopped by exclusion"); accepted results under their visibility rules; the active reviewer count. Order is a stable per-reviewer shuffle or a bibliographic sort, never an order derived from other reviewers' activity (PROPOSAL).

Saved work. A separate list of started work the reviewer may still finish after a Study stopped being offered: "Okafor 2021: no longer in the Full text stage. You can finish your saved work." Two triggers exist: a screening exclusion with exclusion-stop (saved work may be completed by default; a step can set Preserve only) and any filter-driven pool departure (started work may continue by default; an admin can restrict it). Drafts are kept either way. Continuation never returns the Study to either pool and never admits a new review.

State	Browse or Saved work shows (illustrative)
Loading	Skeleton rows
Empty	"No studies are available to you in this stage now. Waiting on others: 12"
Pending	Row "Waiting for the team's screening result"
Incomplete	Row "Draft auto-saved" or "Version checkpoint saved"
Completed	Row "Completed"
Unavailable	Opening a stale row: "No longer available in this stage" (no reason where candidates may not see the result)
Historical	Saved work completed after departure shows "Completed as saved work (continuation allowed)"
Conflict	"This study left the stage while you were browsing. Refresh the list."
Failure	"Your studies could not be loaded. Try again."

5.12 My work

Owner decision D3-07 (approved without amendment). A project My work view lists actionable items by role, a cross-project tab sits on the project index, and a global badge counts work across projects even when notifications are muted. Admins see pending approvals. A full global landing page is deferred.

Entry points. The app-bar badge; the project rail's My work item; the My work tab on the project index; the overview banner for admins; deep links from notices.

Role	Rows
Reviewer	To review (by stage and step, Start or Continue); Saved work you may still finish; Needs your attention (Needs updating, Outdated answers with Fix, drafts whose place was released); Merge conflicts delegated to you; Training to complete or retry; Requested reviews
Reconciler or adjudicator	Reconciliation assigned to you, available or held; Adjudication assigned to you or your group
Admin	Changes awaiting your approval; Publications in progress or stalled; Merge conflicts awaiting resolution; External screening runs awaiting acceptance; Training attempts awaiting manual assessment; Conversion findings needing action

Rows deep-link to the exact task. Counts are computed when the page loads. An item someone else resolves leaves the counts and stays in history ("Decided by Omar"). The overview banner reads "2 changes are waiting for your approval". Reconciliation rows use Study-local aliases.

State	My work shows (illustrative)
Loading	Skeleton groups
Empty	"Nothing to do here now. This stage is waiting on other reviewers."
Pending	"Awaiting assessment"; "Waiting for 1 more review"
Incomplete	"Continue: Draft auto-saved 2 days ago"
Completed	Completed items move to History
Unavailable	"Related item unavailable" when access was removed
Historical	History tab with resolved items and who resolved them (aliases where blinded)
Conflict	"Already decided by Omar" when the reviewer opens a resolved approval
Failure	A row shows "Couldn't load" with Retry; counts never show a false 0

5.13 Admin eligibility explanation timeline

Owner goal and requirements (OS-A07, OS-A08, OS-A10, OS-A11). An admin must be able to explain why a Study was available, reviewed, not reviewed or no longer available, without assuming the platform failed. Explanations use the versions in force at the time.

Entry points. A Study's History tab › "Why?"; a Monitor row; a reviewer's "Why isn't this available to me?" (own reasons only).

Timeline entries. Pool entries and departures with the filter version, the satisfied or failed clauses and the cause; review starts with the route and the eligibility recorded at the time; submissions; configuration changes that explain availability; continuation of started work after a departure; the current reason category (Outside the pool, Already sufficiently reviewed, Stopped by exclusion, Awaiting an earlier step, Awaiting the team's Include, Stage not active, Stage completed, Publication in progress, Not allocated to you, Batch not open, No permission, Enough reviewers, In-progress limit reached, Continuation restricted, Saved work only).

Example. "1 Oct 09:14 · entered Full text. TA team result Included; FT not Excluded. Filter version 3." · "2 Oct 11:40 · Chandra started Outcomes through Full text, step 2.2. Allowed because the Study was in the pool and her own FT Include satisfied the dependency." · "4 Oct 16:05 · left Full text. FT team result became Excluded. Clause 'FT not Excluded' failed." · "6 Oct 10:22 · Chandra completed Outcomes as work started before the Study left the pool (continuation allowed)."

Honesty rules on screen. "No review is recorded" when a Study was eligible and unreviewed, with no invented cause. "Pool history before 20 September 2026 is not recorded (converted from legacy)" for coverage gaps. A past "no place free" cannot be shown, and the gap is stated.

State	Timeline shows (illustrative)
Loading	"Building the timeline"
Empty	"No pool events yet for this stage"
Pending	"Pool history is catching up after a filter change"
Incomplete	"History before tracking began is not recorded" banner
Completed	Full ordered timeline with details per entry
Unavailable	Reviewer view: only their own reasons; no other reviewer's decision, identity or timing
Historical	Each entry shows the versions in force then
Conflict	Not applicable (read-only); a stale timeline shows "Newer events exist. Refresh."
Failure	"The timeline could not be loaded."

5.14 Catalogue

Owner decision D2-15 amended. One application-wide CAMARADES catalogue, administered by users with a system permission. Direct entry and project sharing create versioned catalogue copies with source, version and sharer provenance. Copying into a project creates project-owned definitions with "copied from" provenance. Edits never overwrite copies in either direction. Others may request publication.

Entry points. Design › Catalogue; "Copy from the catalogue" in the form, profile and question editors and in guided set-up; "Request catalogue publication" on a published definition version; Application › Catalogue administration for catalogue administrators.

Flows. Browse and preview an item · Copy into project (creates an Unpublished draft to review and publish) · "A newer catalogue version exists" note on the project copy · Request publication of a project definition version · Catalogue administrators' queue (approve or decline with reason). Scientific template content waits for methodologist review (DH-T05).

State	Catalogue shows (illustrative)
Loading	Skeleton cards
Empty	"No catalogue items match"
Pending	"Your request is waiting for a catalogue administrator"
Incomplete	Copied item: "Unpublished copy · review and publish"
Completed	"Published to the catalogue as v2"
Unavailable	"Only catalogue administrators can publish. You can request publication."
Historical	Item versions with provenance; project copy shows its source version
Conflict	"The source changed after your request; the request keeps v4"
Failure	"The copy was not created. Nothing changed."

5.15 Training

Owner decisions (S4 expansion, manual assessment and retries; OS-A18). Training steps for forms and screening; admin-defined reference answers in immutable versions; scoring by versioned rubrics or manual assessment; recorded pass or fail, feedback and attempts; a policy decides retries; a pass can admit the reviewer to a named project group whose existing permissions allow live reviewing. Training never counts as live votes, targets, accepted results or PRISMA counts. Promotion to live evidence is a separate explicit action.

Entry points. Stages › Steps and settings › Add training step (designers); the training step in the step selector and My work "Training to complete or retry" (trainees); My work "Training attempts awaiting manual assessment" (assessors); My work "Retry requests" and "Admission requests" (admins).

Release (decided 6 October 2026). Training does not hold up the first general release (Chris: "No, training does not gate GA"). It is designed as before.

Designer flow. Add a training step to a stage · choose the form or profile version · create a reference version (optionally seeded from existing accepted answers) · publish a policy version (scoring per answer type, pass criteria as example values, assessment mode, feedback disclosure, retries, admission group and mode) · proposed (DH-U43): bind a guidance version (rich text, links and files), and choose whether trainees confirm "I have read this" and whether the guidance stays visible during an attempt (DH-C125).

Feedback (decided 6 October 2026, DH-U19). Trainees see right or wrong per item after assessment; the expected answers appear only after a pass or when no retry remains. Other disclosure options stay available per policy.

Trainee flow. Proposed (DH-U43): read the guidance, and confirm "I have read this" if asked · "Training · attempt 1 of 2" · answer practice items with the same save-state contract · submit · automatic score and feedback per the policy (references never before submission) · "Awaiting assessment" when manual items remain · Passed (admission) or Not passed (retry rules).

Assessor flow. Assessment queue in My work · per-item judgement and comment · Pass or Fail · an assessor never assesses their own attempt.

Admission. "Passed · admitted to Screeners". If the group's permissions grew beyond what the policy publisher could grant, admission converts to a manual approval request with the reason.

State	Training shows (illustrative)
Loading	"Loading training"
Empty	"No training is set up for this stage" (designers see a set-up link)
Pending	"Awaiting assessment"; "Scoring"; "Confirm you have read the guidance to start" (proposed)
Incomplete	"Attempt 1 · 12 of 20 answered · Version checkpoint saved"
Completed	"Passed · admitted to Screeners" or "Not passed · retry available after approval"
Unavailable	"No retries remain under policy v1"; "You no longer have access to this stage"
Historical	Every attempt with scores, assessments and policy versions
Conflict	"Another assessor recorded an assessment. Your draft is kept."
Failure	"Passed · admission pending. We will retry."

5.16 Notifications and email settings

Owner decisions (O2; OS-A26; D3-22 amended, D3-24, D3-25; D3-21 and D3-23 brief items). Emails may include project and study context, including study titles. Aliases and content respect the recipient's permissions and the relevant blinding. Answers and free text are configurable per project. Access and blinding are checked when each email is sent. Per-project mute keeps in-app notices. Reconciliation conversations are permissioned audit records, outside answer exports and agreement statistics. My work and the badge never depend on notifications.

Entry points. The app-bar inbox; Account › Notification preferences; Project settings › Notifications (admins with the notification-settings capability); the "Mute email for this project" link in each email footer.

Screens.

• Inbox (owned by the notification programme): rows with a context line, filters by project and kind, mark all read, "hide unavailable", resolved rows marked "Decided by Omar" and excluded from the unread count.
• Account › Notification preferences: categories, digest frequency and per-project mute ("Mute email for Sepsis models; in-app notices continue").
• Project settings › Notifications (content policy, versioned): project name (on), study title (on), actor reference (role or Study-local alias; names only where allowed), answer values (off by default, DH-U18), free text (off by default), link (always). A recipient may choose minimal emails and can never widen the project's policy.
• Email preview for admins showing exactly what a blinded candidate, a reconciler and an admin would receive.

State	Notification screens show (illustrative)
Loading	Skeleton inbox
Empty	"No notifications"
Pending	"Email sending is paused by an operator; notices are kept"
Incomplete	Policy edit not yet saved: "Unpublished change to the email content policy"
Completed	"Policy v3 applies to emails sent from now"
Unavailable	"Related item unavailable"
Historical	Policy versions with actor and time; resolved notices in history
Conflict	"Someone else changed the policy. Review their version."
Failure	"Preferences not saved. Try again."

5.17 Project deletion and restoration

Owner decision (O1 final; OS-A25). Ordinary deletion is reversible: the project leaves normal lists; review and editing are blocked; allocations and notifications stop; active places are released; drafts, data and history are kept. An authorised admin restores it from a restricted Deleted projects view. Restoration re-checks availability and capacity and never revives stale places. Nothing is erased, and no screen or message may suggest that it is. Permanent erasure is a separate unapproved policy and must not appear (T-POL-01). A deleted project is kept until such a policy is approved (ACD §3.3), so the prototype shows no deletion date, countdown or restore deadline.

Delete flow. Project settings › Delete project · reason · impact preview (active reviewers, places, drafts, scheduled and running jobs; a running bulk update blocks deletion) · confirm · the project leaves normal lists (its data is kept) · reviewers mid-form get "This project has been deleted. Your draft is kept."

Restore flow. Deleted projects · select · reason · preview ("Released places will not come back") · restore · members are told · drafts reappear · capacity is checked when reviewers resume.

State	Deletion screens show (illustrative)
Loading	"Checking active work"
Empty	Deleted projects: "No deleted projects"
Pending	"Moving to Deleted projects… 1,200 of 4,000 studies. Nothing is erased." (admin view; the project is already hidden from lists)
Incomplete	Reason missing: Delete disabled
Completed	"Pilot 2024 was deleted and moved to Deleted projects. Its data is kept. An authorised admin can restore it."
Unavailable	"Wait for the bulk update to finish"; "Only the owner or a Delete holder can delete this project"
Historical	Audit timeline with both actions, actors, times and reasons
Conflict	"The impact changed since you reviewed it"
Failure	"The move to Deleted projects did not finish. The project stays hidden and the move will complete. Nothing is erased."

5.18 Contribution exclusion, membership disable and account deletion

Owner decisions (O1 amendment; OS-A24; D4-20; D2-14 amended). Reviewers cannot withdraw submitted work by leaving. Disabling a membership keeps contributions counting. An admin may explicitly exclude a member's contributions from current use for one form, one profile, one stage or the whole project, with a preview, a reason, the actor and the time. History and named attribution stay. Dependent accepted results stay as they are, flagged, and their authors are told. Ordinary account deletion disables access and keeps named attribution.

Exclusion flow. Member page or the disable-membership dialog ("Also exclude this member's contributions", off by default) · scope and reason · preview (contributions that stop counting, Studies whose sufficiency changes, screening results that change, pool entries and departures, dependent results and their authors, reconciliations whose candidates change, whether the member can still review) · for stage scope, groups with mixed route provenance need an explicit choice (DH-U32) · confirm · authors of dependent results are told · excluded work shows "Excluded from current use" in history.

Account deletion. Confirmation: "Your submitted reviews will stay in the projects you contributed to, with your name." Joining screens explain retention (legal wording to be decided, DH-T12). Names show as "Dana Reid (account deleted)" where the viewer may see identities.

State	Exclusion screens show (illustrative)
Loading	"Calculating effects"
Empty	"Sam has no contributions in this scope"
Pending	Preview shown, nothing committed
Incomplete	"1 mixed-provenance group needs a choice"; reason missing
Completed	"Excluded from current use. 3 accepted results flagged; Kim, Lee and Priya told"
Unavailable	"Exclusion is available after this project is converted" (classic projects, DH-U31)
Historical	Exclusion and any lift with reason, actor and time
Conflict	"The impact changed since you reviewed it"
Failure	"Nothing was excluded. Try again."

5.19 AI-model-generated screening decisions and model metadata

Owner decisions (E3 expansion with metadata ownership, source identity and terminology; OS-A20). This is a later opt-in lane (working name XS1), shown in the prototype with a "Later release" badge.

Entry points. Project settings › AI screening models; Design › Screening profiles › Source policy; Study Management › AI screening runs (upload and accept); the provenance link on any AI-model-generated screening decision; My work "External screening runs awaiting acceptance".

Model configuration (Project settings › AI screening models). Versioned description: name, provider, model version or artifact reference, intended use, label vocabulary and its mapping to Include, Exclude and Unsure, thresholds the project supplies (SyRF proposes none), training-set and evaluation-set context, documentation links, and an explicit list of items "Not supplied". Every change creates a new version; earlier decisions keep their version ("Version 2 is current; profile v3 still uses version 1").

Profile source policy. Per profile version: the source, its exact configuration version, its role (Contributing vote or Sole screener), its scope, the label mapping and Unsure routing to the adjudication step. Publishing it follows section 5.9. Whether it needs a protocol amendment entry (a source-policy change counting as an eligibility change) is a PROPOSAL (RI-R22).

Run import. Upload → validate → preview (matched, unmatched, unmapped labels, out of scope, Studies whose result would change, outputs on training inputs that will not count, active-work impact) → accept (a separate capability; PROPOSAL). Unmatched rows never create Studies. A rerun creates new versions of the AI-model-generated screening decisions, never extra voters.

Labels everywhere. "AI-model-generated screening decision", "AI screening model", "Machine-only result" (sole screener), "Machine-assisted result" (contributing vote). Non-AI external sources keep their real type. Importer and accepter are shown separately from the AI screening model. An AI screening model's Unsure under a sole-screener policy waits for human adjudication; it is never an Include.

State	AI screening screens show (illustrative)
Loading	"Validating 4,000 rows"
Empty	"No AI screening models described for this project"
Pending	"Validated · awaiting acceptance"; "Accepting 1,200 of 3,990"
Incomplete	"6 unmatched rows, 2 unmapped labels: fix the mapping or accept only valid rows"
Completed	"Accepted. 3,990 AI-model-generated screening decisions recorded"
Unavailable	"You can upload runs but not accept them"
Historical	Runs, superseded runs and decision versions with configuration versions
Conflict	"The profile version changed since validation. Validate again."
Failure	"This file could not be read (line 1,203)"

5.20 Stage set-up: study filter, steps and lifecycle

Owner decisions (Q-15 replaced by the stage filter model; Q-01; Q-02; Q-24; Q-28; OS-A06).

Entry points. Stages › stage › Steps and settings (designers); Stages › New stage; the conversion wizard's proposed mapping (read-only preview); My work "Changes awaiting your approval" for a Completed stage.

Filter editor. AND and OR groups of clauses. Clause kinds: a profile's screening result (in or not in Included, Excluded, Unresolved and its sub-states) and an accepted answer to a named question (any of, all of, has an accepted answer). A read-only base condition always applies (current Study, active lifecycle, not hidden by search withdrawal). A clause that cannot be evaluated is shown as "Unknown" and fails closed. When a clause reads a profile or form bound in the same stage, the editor explains the feedback effect: "Results recorded in this stage can remove Studies from its pool. Reviewers keep their evidence, and by default they can finish work they have started." Editing the filter previews entering and departing Studies, affected started work and completion effects. Accepted-answer clauses carry a "Later release" badge (they need accepted results; they stay in scope, and the badge wording is DH-U34).

Steps editor. Activities (screening profile, form or both); display order separate from Depends on (AND and OR of steps; cycles refused); progression basis at stage level (Own Include sufficient, default, or Team Include required) with a step tighten-only option (PROPOSAL); exclusion-stop per screening step (personal, collective, scope; proposed defaults on, on, dependent steps); extra screening after sufficiency (Stop default for new combined steps, or Allow); saved work after exclusion (stage default Allow completion, step override Preserve only); started work after leaving the pool (default Allow, restriction placement DH-U04); hints (step may only hide); target shown read-only from the form; adjudication step added automatically beside screening steps; optional training steps; route capacity cap stricter than the form's only; browsing (off by default, placement DH-U05).

Lifecycle. Automatic or manual completion. An automatic Completed stage recalculates as soon as remaining work appears and tells its admins. A manual Completed stage stays Completed until an explicit authorised Reopen. A protected change to a Completed stage needs that change approved.

State	Stage set-up shows (illustrative)
Loading	"Loading stage settings"
Empty	New stage: "Add a step to start"
Pending	"Pool history is catching up after your filter change"
Incomplete	"Unpublished changes · 2 errors: a dependency cycle; an empty group"
Completed	"Settings v4 published"
Unavailable	"This stage is completed. Request approval for this change."
Historical	Settings versions with filter versions and who published them
Conflict	"Another admin published settings v4. Your draft is rebased; 1 item conflicts."
Failure	"Publication did not finish. Settings v3 still apply."

5.21 Inference beta (classification)

Owner decisions (S5 approved behaviour and beta opt-in; Q-18; Q-19; OS-A19; the scope of the beta, DH-U21, decided by Chris on 6 October 2026). Off by default for every project, including templates, copies and converted projects. An authorised project designer enables it after reading what it does. The first reasoner supports conjunction, containment, disjointness and exhaustiveness only. Candidate inference uses only the reviewer's own answers and is visible only to them; collective inference uses a pinned accepted result. Reported answers never change and no animal count is invented. Changes recompute and mark old results superseded; disabling withdraws current results and keeps history.

Entry points. Project settings › Inference (beta) for designers; the inference panel beside cohort questions in the reviewer workspace (only when the project opted in); Design › Concepts & rules.

What the beta covers (decided 6 October 2026, DH-U21, option (a)). Rule authoring and publication, rule evaluation and inferred results need the project's explicit beta opt-in. So the rule pages of Design › Concepts & rules, the per-paper rule-applicability answers and the inference panels appear only after a project designer opts in; before that, Concepts & rules shows shared concepts and an "Inference (beta): off" note with a link to the opt-in. Ordinary annotation and explicit group or classification recording (lane C1: shared concepts, per-paper mapping answers, populations, cohorts and set annotations) follow their own availability and never need the beta (section 5.26). This adds no separate review workflow and does not bring classification delivery forward. The classification specification's alternative, rule authoring in lane C1 outside the beta, was not adopted. No chip.

State	Inference panel shows (illustrative)
Loading	"Checking relationships"
Empty	"No cohorts or rules to evaluate"
Pending	"Provisional: based on your unsaved changes"
Incomplete	"Not evaluated: too complex for the beta"
Completed	Propositions with proof state and rule provenance
Unavailable	Nothing (beta off)
Historical	Superseded and withdrawn results with reasons
Conflict	"Conflicting evidence: dependent conclusions withheld"
Failure	"Not evaluated. Your answers are unaffected."

5.22 Question authoring: questions, forms, drafts, history and import

Owner decisions. SF1 (questions are chosen per form; stages bind forms); QD1 (a published question is retired, never deleted); D2-02 amended and Q-34 (compatibility is the publisher's immutable declaration); D2-11 and OS-A01 (many drafts, collaborative drafting, presence and audit stamps); D3-04 (sentence case); D3-05 (devices); Q-13 (naming); and, decided by Chris on 6 October 2026, one editor for both project modes (DH-U41), where the editor opens (DH-U35), saving design edits automatically into the draft (DH-U37) and phone layouts without a formal phone gate (DH-U12). D2-03 (a data-type or multiplicity change is an incompatible version of the same question) and D2-06 (system questions as versioned data) are engineering contracts with no owner question. Everything else here is a PROPOSAL from RD §3.4, §3.5, §3.7 and §4.7, UX §3.13, ACD §3.11 and §3.12 and BC §3.4. Nothing is approved for building.

Entry points. Design › Questions and entity types; Design › Annotation forms › a form › Questions; "Import question template" on the Questions and entity types toolbar; "Copy from the catalogue"; a question's History.

Two kinds of project (decided 6 October 2026, DH-U41). Every project uses the same refreshed question editor, with the saving and assignment behaviour of its own mode. In a Classic workflow project the editor saves each question directly, as today: no versions, drafts or presence, Required set per question, and Assign keeps per-stage selection until the project converts. It never adds versioned publication, draft or assignment behaviour to a project that has not converted. An answered question keeps today's lock: it shows "Answered: locked (Classic)" with its answer count and offers no Edit or Delete, including while counts load, fail or are switched off, and the server refuses an edit or delete the lock forbids (RD-R39, PROPOSAL). When today's older "Question design" page and its switch retire is not decided, and the prototype does not show that page. In a Versioned workflow project every edit goes into an Unpublished draft and reaches reviewers only through publication (section 5.9).

The question list and tree (DH-C100, DH-C102).

1. One tree per entity type, numbered exactly as on the reviewer page, with search and filters (Used by form, Unpublished, Retired, System). Each card shows its version number as a chip, its lifecycle state by icon shape and text (Unpublished, Published, Published · unpublished changes, Retired) and "Used by: Study design v3, Risk of bias v2".
2. A virtualised tree that stays responsive with the 2,023-question replica; expand and collapse all.
3. Reordering within the same parent uses pointer drag, with "Move up", "Move down" and keyboard alternatives (arrow keys move focus; Shift+Up and Shift+Down reorder). Never native HTML5 drag.
4. Child validity. A child whose condition names a retired or missing parent option shows a warning naming the parent, the child and the option. When a parent gains an option, each conditional child asks "Show for new option 'Subcutaneous'?".

The question editor (DH-C101).

1. Fields: wording, help text, answer label, control type, data type, answer shape (Single answer · Several answers in one list · Repeated answers for each …) and options.
2. Options keep their identity. A rename reads "Renamed · answers keep their meaning". Removing an option offers Retire (struck through, with its answer count) or "Replace with a new option" for a change of meaning.
3. Requiredness is set per form in a Versioned project, during composition (DH-C104, DH-C121). Decided 6 October 2026 (DH-U38): a newly added question is Required by default, and Optional sits under Advanced settings with the warning "Reviewers can skip this without saying why" (section 5.24). Classic projects keep today's per-question Required.
4. Repeated answers are fixed at creation: "Fixed when the question was created. Create a new question instead." Changing the data type, or between single and several answers, warns "This will be published as Not compatible".
5. System questions are read-only, show "System-controlled" and their system version, and change only when a form version that adopts a newer system version is published.
6. Published questions are never deleted. The editor offers "Remove from this form" or Retire; Delete appears only for a question that was never published.
7. Where the editor opens (decided 6 October 2026, DH-U35). On wide screens the editor sits beside a compact question list or tree; on narrow screens it is a separate drill-in page (list, then editor, then back). It never expands inline inside a tree node. The width where the layout switches is a design detail to validate with users: no numeric breakpoint is approved, so label any width the prototype uses "Example, not approved". How edits are kept (decided 6 October 2026, DH-U37). In a Versioned project accepted field changes save automatically into the Unpublished draft, with a clear save status, safe conflict handling and "Discard changes" per question; there is no per-question Save or "Keep changes" button, and saving a draft never publishes to reviewers. A Classic project saves directly, as above.
8. Reasons no value is provided and answer metadata per question (section 5.24; DH-C119, DH-C120).
9. Reference questions (section 5.25; DH-C126), with the "Later release" badge.

Conditional display and filtered options (DH-C103). "Always with parent" or "Only when the parent answer is …" (Yes or No, or parent options picked from the list, never typed). Filtered options are a grid of the parent's options against this question's options, saying which are offered after each parent answer. Renaming a parent option keeps conditions and filters. The designer preview explains "Shown because Species is Rat". A question hidden by its condition is never required. A Classic project that cannot store filtered options shows the reason in place of the grid.

Forms, drafts and presence (DH-C104, DH-C105, DH-C31). Forms are composed with two trees. Several Unpublished drafts may exist for one form. Accepted field changes save automatically into the draft as the designer works (DH-U37, decided): one quiet status per draft, such as "Unpublished · saved 14:03", and "Discard changes" per question. Presence shows avatars of viewers and editors and a per-question "editing" marker; live updates never overwrite local typing; a same-item conflict shows as soon as another designer's change lands ("Priya changed this option while you were typing") and offers "Keep mine" or "Discard mine"; every accepted change shows its author and time. Saving a draft never publishes: only publication reaches reviewers. Presence ships with publication in a later release than the editor, but the prototype shows it.

History with a diff (DH-C109). Per question and per form: versions, declarations, reasons, and a per-field comparison of any two versions. "Start a draft from this version" never rewrites history.

Import with a preview and receipt (DH-C113). The preview is exactly what will be created; any refused row is named and nothing is created; one confirmation adds everything or nothing; a receipt and recent attempts follow.

Converted questions (DH-C115). After conversion each question shows "v1 · Converted on [date]" and "Earlier wording not recorded in legacy"; answers whose wording at the time cannot be proven show "Wording at the time unknown"; conditions and filtered options are kept.

Devices and Material 3 (DH-C116, DH-C117). Desktop and tablet with touch for everything; a one-column phone layout with nothing hidden and no formal phone acceptance gate (DH-U12, decided 6 October 2026); light and dark themes with every state shown by icon shape and text.

State	What the designer sees (illustrative)
Loading	Skeleton tree rows: "Loading questions"
Empty	"No questions yet. Add a question, import a template or copy one from the catalogue."
Pending	"Saving changes…" in the draft's status; "Publishing by Priya since 14:05. You can keep editing drafts."; "Checking 40 rows" during an import preview
Incomplete	"Unpublished · 3 changes · saved 14:03" on a draft; "2 questions need attention" for child-validity warnings
Completed	"Risk of bias v3 is published"; "40 questions added" on an import receipt
Unavailable	"System-controlled"; "You need Design to edit questions"; in a Classic project, "Filtered options can be saved once this project is converted" and "Answered: locked (Classic)" on an answered question (DH-U41, decided)
Historical	Version history with the per-field diff, declarations and "corrected by" links
Conflict	"Priya changed this option while you were typing" with Keep mine or Discard mine, shown as soon as her change lands; "Based on v4 · v5 is now current"
Failure	"Your change was not saved to the draft. It is kept here." with Retry, while typing continues; "Row 14: parent 'Route' is not in this file or project"

5.23 Question management: what to start from and what to avoid

The design session cannot read the SyRF repository, so this section describes each source as a pattern, and section 13 repeats it in the prompt. Every source is a design reference only; none approves building anything.

Start from.

Source	What to reuse	What changes
SyRF's shipped question editor, with tabs Design, Assign and Preview	Category tabs with counts and guidance; a nested tree whose nodes open to Preview beside Settings; Add child and Copy; the conditional-display controls; the system lock	It becomes the one editor for every project, Classic and Versioned (DH-U41, decided). Category tabs become entity types; the tree and editor follow DH-C100 to DH-C103; the editor opens beside a compact tree on wide screens and as a drill-in page on narrow screens, not inline inside a tree node (DH-U35, decided); in Versioned projects the per-node Save gives way to automatic saving into the draft (DH-U37, decided); remove the "Focused question" debug line, literal colours and title case; replace native drag; in Versioned projects, locks driven by answer counts become version states (Classic projects keep the answered-question lock, section 5.22)
Its Assign tab	Two trees (all questions; chosen questions) with ancestor and descendant selection	Reused to compose forms, not stages (DH-C104); Classic projects keep per-stage Assign
Its Preview tab	The real reviewer form rendering the questions	Render the pinned form version; drop the placeholder study card; add "Shown because …" and published versus unpublished markers
v10 pages c2, r6 and r1	Entity-type trees with reviewer numbering and the system lock; the forms page that pins one version of each question and owns the target; the profile editor with its own question tree	Rename "question library"; c3 is removed (DH-C17); remove "Mark compatible" (DH-C111)
An existing question import dialog	Download a blank template; choose a file; validate and preview the hierarchy (parents, conditions, options, help text, Required or Optional, answer shape); issues by row and column; "I reviewed the hierarchy and conditions"; "Add N questions"; a receipt; recent attempts; "Retry same import"	Restyle to Material 3; show its file limits as "Example, not approved"; in a Versioned project Confirm creates a draft (DH-C113)
An earlier child-validity warning	A warning when a child's condition names an option its parent no longer has; new options left untouched on children	Name the parent, child and option in sentence case; work on option identity; ask "Show for new option?" (DH-C102)
An earlier, unmerged designer prototype (reference only)	A version history timeline with a per-field diff; a tree keyboard model (arrows, Shift+Up and Shift+Down to reorder, Home, End, F2 to edit); a compact tree beside a side panel, now the decided wide-screen layout (DH-U35); a reviewer's alert after a publication	Show version numbers on cards; "Restore" starts a new draft; check shortcuts that clash with browser keys; the alert names the publication and the publisher and uses the copy deck

Avoid. That prototype's state store and properties panel (its undo did nothing and its autosave wiped options); per-stage assign trees and per-stage question selection in Versioned projects; native HTML5 drag; stage-scoped publishing ("publish to a stage"); "Mark compatible"; locks driven by answer counts in Versioned projects (a Classic project keeps today's answered-question lock, section 5.22); typed option values in conditions; emoji status icons; any numeric limit shown as decided.

For human readers: the shipped editor is main's question-management route (M-09 to M-11 in the question-management plan); the import dialog is #3934 (H-IMP-05); the child-validity warning is #2387 (H-TREE-01, H-TREE-02); the unmerged prototype is QM v2 PR-D,

2575 (H-WEB-03, H-WEB-04, H-WEB-11, H-WEB-18; its store and panel are H-WEB-01 and H-WEB-05, its

assign trees H-WEB-09).

5.24 Answers: required by default, reasons no value is provided and metadata

Owner decisions (Chris, 6 October 2026). Required by default (decided-amended), configurable answer metadata (Chris's direction) and, later that day, the answer terminology (DH-U42, approved with revised terminology). New questions are required by default; requiredness is still set per form; Optional sits under Advanced settings with a warning, is discouraged and exists mainly for older questions. Each question offers its own reasons no value is provided: the defaults Not reported, Not applicable and Unable to assess, the designer's own, and sets copied from catalogue templates such as SYRCLE. Each question declares answer metadata fields, each Hidden, Allowed or Required for each answer state. Complete needs an answer for every applicable required question; Save progress never does. Converted projects keep each legacy question's Required or Optional setting, and the redesign wizard offers to upgrade optional ones. The field shapes, the stored payload and how clearing is recorded are PROPOSALs (RD §3.16). Nothing here approves building anything.

Terminology (decided 6 October 2026, DH-U42). Use these terms exactly, on screen and in this document (section 3.2):

• Answer status is the overall state of a question in a session version: Unanswered; answered with a value (a listed option, Other, please specify with its text, a number, text, a date or a reference); or answered with a configured reason no value is provided.
• Reason no value is provided names the designer-configured set of explicit reasons: the defaults, the designer's own reasons and catalogue sets such as SYRCLE, each with a stable identity and its own metadata requirements. The short form "no-value reason" may appear only in dense tables. It replaces the working term "no-value answer", which is retired.
• No value to enter is the proposed reviewer action that opens a question's reasons. It is illustrative wording, not a fixed label.
• Other, please specify is a value-bearing answer: the listed "Other" option plus its configured free text, recorded together as the answer's value. It is never a reason no value is provided.
• Carried from the recommendation, not separately discussed: Unanswered means nothing recorded; option means only a predefined choice; Not compared (unanswered) is the comparison label for a missing answer.
• The distinctions, each reason's stable identity, and the Other option's identity with its text are kept in versions and exports.
• Never use "no-value answer", "blank" (for an unanswered question), "response mode", "response option", "missing-data code" or "answer exception" on screen.

Designer: requiredness (DH-C121). In form composition each newly added question shows Required. "Advanced settings" holds Optional, with the warning "Reviewers can skip this without saying why" and a suggestion to keep the question required and offer Unable to assess instead. The form summary counts optional questions ("2 optional questions").

Designer: reasons no value is provided (DH-C119). The question editor has a "Reasons no value is provided" block: Not reported, Not applicable and Unable to assess are offered (which of them a new question starts with is DH-T21); "Add your own" takes a label and a description; "Add from a catalogue template" copies a set (for example "SYRCLE risk of bias", shown with "Content pending methodologist review"), which records "copied from" and does not change when the catalogue does. Each reason has a stable identity, kept in versions and exports. A risk-of-bias "Unclear" stays an ordinary option, and the editor explains "Unclear is a judgement, so it is an option, not a reason no value is provided". Retiring a reason of a published question warns "This will be published as Not compatible" unless it is mapped to another of the same meaning.

Designer: Other, please specify (DQ-46). An "Other, please specify" option carries its configured free-text field as part of the option, so the text belongs to the answer's value. It is set up with the options, not in the metadata grid, and it is never offered as a reason no value is provided. The exact field settings are a PROPOSAL (RD §3.16).

Designer: the metadata grid (DH-C120). Rows are the metadata fields the designer adds: Comment, Unit, Evidence quote with its source location and Reason (several of one kind are allowed). Columns are the answer states: "Any value", a column for each option that needs its own rule (for example "Other"), one per reason no value is provided, and "Unanswered" (shown only for an optional question). Each cell is Hidden, Allowed or Required. Example: Comment Required for Unable to assess; Evidence quote Allowed for any value. Requiring a field for Unanswered warns "This makes the question 'answer or explain'. Consider making it required with a reason no value is provided instead."

Reviewer form (DH-C122).

1. Beside each question's control, an action opens that question's reasons no value is provided. Its wording, "No value to enter", is illustrative, not a fixed label. Choosing a reason replaces any value; choosing a value replaces the reason.
2. Choosing Other, please specify records the Other option and its text together as the value. The text field appears inside the answer, never among the metadata fields, and the answer status reads answered with a value.
3. Each question shows its answer status by icon shape and text: Unanswered, answered with a value, or answered with a reason no value is provided.
4. Metadata fields appear only for the chosen answer state. A field that state requires shows "Needed to complete"; Save progress works without it.
5. Complete checks every applicable required question, including questions never scrolled into view: "3 questions need an answer · 1 needs a comment · Jump to next". A required repeated question (such as cohorts) needs its minimum count or the group-level reason None reported (PROPOSAL).
6. Clear answer returns a question to unanswered, and history shows "answered, then cleared" (PROPOSAL). A required question then needs an answer again before Complete.
7. A question hidden by its condition needs nothing. The reviewer's Not applicable reason never looks like a question hidden by a condition.

Recording unanswered (PROPOSAL; an open owner item, not a design question). A question never touched stays unanswered and nothing is written for it, at Save or at Complete. Clearing writes an explicit "Unanswered" entry so that history shows it. Text that is empty or only spaces counts as unanswered. On screen only the history line "answered, then cleared" depends on this.

Reconciliation and agreement (DH-C123). An unanswered candidate question shows "Not compared (unanswered)" (it was "Not assessed"; carried from the recommendation into the decided terms). The same reason no value is provided agrees; a reason against a value, or against a different reason, disagrees. Other, please specify compares as a value: the Other option together with its text. How agreement statistics count reasons no value is provided waits for the statistical review (DH-T20).

Conversion (DH-C124). Converted questions keep their legacy Required or Optional setting, shown "Optional (kept from legacy)". Legacy options worded "Not reported" or "Unclear" stay ordinary options. The redesign wizard lists optional questions and offers "Make required, with reasons no value is provided such as Not reported and Unable to assess", one question at a time; the publication preview then asks whether earlier completed reviews still count. Turning an existing option into a reason no value is provided is not offered (DH-T23).

State	What the designer or reviewer sees (illustrative)
Loading	"Loading answer settings"
Empty	"This question offers no reasons no value is provided. Reviewers must give a value." (designer)
Pending	"Draft auto-saved" beside a newly chosen reason
Incomplete	"Needs a comment for Unable to assess"; "2 questions need an answer"
Completed	"Unable to assess · Comment: Methods section missing from the PDF", read-only after Complete
Unavailable	"This reason was retired in v4. Choose another answer."
Historical	"Answered Rat, then cleared · 14:02" in history
Conflict	"Another tab chose Not reported for this question. Keep yours or theirs."
Failure	"Your answer was not saved. It is kept here." with Retry

5.25 Custom reference questions (Later release)

What is specified (all PROPOSAL; CPR §3.4). A designer can create a question whose answer points at records of declared types in the same paper, for example "Housing location" on a cohort, pointing at Location records. Today five such questions exist and SyRF fixes all of them (a cohort's disease models, treatments and outcomes; an experiment's cohorts; an outcome's PDF graphs); they keep working unchanged. Designer-made reference questions arrive with lane C1, so show them with the Later release badge. Whether they are needed at the first general release, and which target types they offer, is open (DH-U44).

Designer (DH-C126). The question editor offers the answer type "Reference to records", with: target types (entity types such as Location or Cohort, and configuration records such as a shared concept version; the recommended set is in DH-U44); scope (always the same population, optionally "under the same parent record"); single or several, with an optional minimum and maximum; and the empty-state text ("Add a Location first"). It can offer reasons no value is provided and metadata like any question. Removing a target type, narrowing scope, lowering a maximum, switching between single and several, or changing the kind warns "This will be published as Not compatible". The five fixed lookups appear as read-only system questions.

Reviewer picker (DH-C127). A searchable picker lists the reviewer's own records of the target types in this paper and population; selected records appear as chips with their label and population. An empty selection is unanswered, never "none"; "none" is said with a reason no value is provided. History shows each record's label as it was when the version was saved.

Deleting a referenced record (DH-C128). The deletion dialog first lists every answer that references the record ("Referenced by: Pregnant · Housing location; Farm A animals · criteria"). After deletion, the referencing answers keep the record and show "Refers to a deleted record"; Complete names the question until the reviewer chooses another record or a reason no value is provided. Nothing is removed silently.

Reconciliation (DH-C129). Before comparing answers that depend on records, the reconciler confirms which candidates' records correspond. SyRF suggests matches ("Farm A ↔ Farm 1: sizes match; labels differ"); the reconciler confirms a match, splits it or marks a record distinct. Reference answers are then compared through the match, and an unmatched record shows "Not matched yet". Under blinding, candidates stay Reviewer 1 and Reviewer 2 while record labels from the paper are shown. The accepted answer's picker offers only reconciled records. Reference answers get no click-to-fill hints in the MVP.

State	What the reviewer sees in the picker or on record pages (illustrative; CPR §9.8)
Loading	"Loading records"
Empty	The question's empty-state text, for example "Add a Location first", with an add action
Pending	"Draft auto-saved" beside an unsaved selection
Incomplete	"2 of 5 cohorts answered"
Completed	Selected records as chips with label and population
Unavailable	"No records of this type can be referenced here" (another population, or no access)
Historical	The label each record had when the version was saved
Conflict	"This record was deleted in another tab. Choose again."
Failure	"Refers to a deleted record" on the answer; Complete names it

5.26 Populations, entity types and classification records (lane C1, Later release)

What is specified (CPR). The populations direction was recorded on 2 and 3 October 2026; TC1, MG1 and Q-19 are decided; everything else is PROPOSAL. Lane C1 lets reviewers record the groups of animals a paper reports and how they relate, as explicit answers. SyRF records, reconciles and exports this evidence; it never analyses or adds up groups. C1 infers nothing: suggestions come only from the opt-in inference beta (section 5.21). Explicit recording follows lane C1's own availability and never needs the beta; only project rules and inference do (DH-U21, decided 6 October 2026). Show these pages with the Later release badge.

Entity types (DH-C16). Today's fixed category tabs become entity types. A designer can add project types ("Location", "Diet") and switch on "Describes which animals belong to a group" and "Can be nested". Each type has exactly one label question. Templates show the legacy types by default; cohort, outcome-measure and experiment types appear only when a form uses extraction.

Populations and the whole-population cohort (DH-C18). Every Study starts with one population of all the animals it studies (the name is copy). "Add population" is for a paper that reports two unrelated sets of animals. Each population has a system group for all its animals, which shows "Size not reported" until a reviewer records the paper's number. A record belongs to one population, chosen when it is created.

Cohorts and coverage (DH-C18). Each cohort shows its criteria ("Female and Farm A"), its scope (a population and any enclosing cohort), its coverage (Complete, Partial or Unknown; Unknown by default) and its size. A "Total" label never sets coverage. A missing classification shows "Unknown", never "No".

Set annotations (DH-C18). On a population or a parent record, "These groups share no animals" and "These groups together cover the population" are separate statements, each with its evidence kind (Reported or Reviewer interpreted), a quote and a page. A contradiction, such as a subset recorded larger than its superset, is saved with a warning and never blocks Complete. A cycle, or a record in another population, is refused at Save.

Compact cohort selection (DH-C18, DH-C65). Per-cohort questions are answered for the cohort chosen in a compact selector (chips or a searchable menu) showing population, label, size and coverage; it never pushes the form down. Where the population chip sits is DH-U10.

Concepts & rules (DH-C15). Shared concepts ("Pregnant", "Female") and reviewers' mapping answers ("Pregnant here means the shared concept Pregnant v1") are ordinary records and answers, shown without the beta. Rule versions ("Pregnant is contained in Female, v2") and whether a rule applies to a paper (answered Applies, Does not apply or Not evaluated; values to be confirmed in the brief) sit behind the beta (DH-U21, decided 6 October 2026): project rules are authored and published only when the project has opted in, so show the rule pages and rule-applicability answers only then, with no chip. The inference panels need the beta too.

Exports (DH-C95). The Data export (Later release) carries population, cohort and record IDs beside labels, the explicit relationships, and flags for shared controls and overlapping groups; it never adds groups together.

The record pages use the states of section 5.25.

6. Configuration ownership, defaults, overrides and confirmations

6.1 Ownership rules

• Inside a version (form version, profile version, stage-settings version): settings that change what counts as valid evidence, how evidence is produced or how an accepted result is formed. Changing them publishes a new version through the impact flow (section 5.9).
• Audited operational setting: settings that change only who is offered work and when. Changing them is recorded with actor and time, shown through the impact preview where people are working, and takes effect at once.
• Stages and steps own no evidence, target, timeout, in-progress limit, blinding or hint availability. A step may only narrow what its form allows (hints) or tighten progression.

6.2 Settings table

Setting	Owner and record	Default	Permitted override	Change path	Source
Standard reviewer target	Form version	Set per form	Study-specific target (versioned, per Study × form); additional-review request; no stage or step target	Form publication (target-only allowed)	OS-A12; RD-R12, RD-R14
Target-one handling	Form version	To be decided (DH-U01); converted forms "single annotator, not accepted" (DH-U22)	None	Form publication	Q-29, D4-03; RS-R04
Requiredness of a question in a form	Form version	Required for a newly added question; converted forms keep the legacy setting	Optional only under Advanced settings, with a warning	Form publication; raising requiredness asks the counting choice	Required by default (Chris, 6 October 2026); RD-R49; BC-R49
Reasons no value is provided and answer metadata	Question version	Not reported, Not applicable and Unable to assess offered (which start selected is DH-T21); no metadata fields	Designer-added reasons; catalogue sets; each field Hidden, Allowed or Required per answer state; the text of "Other, please specify" belongs to the option's value, not the metadata	Question version, published through a form	Required by default; configurable answer metadata; answer terminology (Chris, 6 October 2026; DH-U42); RD-R50, RD-R52
Accepted-answer completeness	Form version	Follow requiredness	Form may require named optional questions or all applicable questions; no stage or step override	Form publication	Q-04; RS-R13
Reconciliation identity blinding (forms)	Form version	Blinded	None	Form publication	Q-28, Q-30, OS-A02
Accepted-answer hints baseline	Form version	Shown	Step may hide only	Form publication; step via stage settings	OS-A04; RS-R31
Outdated-answer completion	Form version (PROPOSAL placement)	Warn and allow Complete anyway	None	Form publication	D4-17; RS-R39; placement RS-R41
Inactivity timeout	Form operational	Today's value (not approved as a default)	None	Audited, with impact preview	D2-07, Q-28
Per-reviewer in-progress limit	Form operational	Unlimited (proposed)	None	Audited, preview, optional Apply anyway	D2-07, Q-28
Capacity cap	Form operational	Off; when enabled, equal to the effective target (proposed)	Stage route cap, stricter only	Audited, preview, Apply anyway	Q-28, D3-17
Bulk acceptance	Form operational	Off	None	Audited	Q-11
Unstarted assignment expiry	Form operational (tasks); profile operational (adjudication)	Off	Per-assignment override, audited	Audited	Q-30, RA3
Unsure	Profile version	Off; on in the title and abstract template	None	Profile publication	D4-01
Sufficiency rule	Profile version	Per profile	None	Profile publication	Existing
Tie policy and bound	Profile version	None; an explicit choice is required; templates preselect	None	Profile publication	OS-A13; RS-R50
Handling per trigger	Profile version	Per profile	None	Profile publication	OS-A13
Discussion	Profile version	Off; optional time limit with no default	None	Profile publication	D4-02
Adjudication rationale required	Profile version	Off	None	Profile publication	Q-32
Reason handling (reason reconciliation toggle, primary reason, must-agree answers)	Profile version	Template guidance	None	Profile publication	DP5, RX1, Q-22, D4-13
Reconciliation identity blinding (screening)	Profile version	Blinded	None	Profile publication	OS-A02
External or AI source policy	Profile version	None	None	Profile publication; amendment entry (PROPOSAL)	OS-A20; RI-R22
Adjudicator assignment	Profile operational (versioned, audited)	None (any eligible adjudicator)	None	Audited, preview, Apply anyway for claims	OS-A13
Stage study filter	Stage settings version	Base condition only	None	Stage-settings publication with preview	Q-15
Progression basis	Stage settings version	Own Include sufficient	Step tighten-only (PROPOSAL)	Stage-settings publication	Q-01
Exclusion-stop (personal, collective, scope)	Step	On, on, dependent steps (proposed)	None	Stage-settings publication	Q-15; SP-R20
Extra screening after sufficiency	Step	Stop for new combined steps; legacy value preserved	None	Stage-settings publication	Q-24
Saved work after exclusion	Stage default, step override	Allow completion	Step may set Preserve only	Stage-settings publication with preview	Q-28, EW1
Started work after leaving the pool	Placement to be decided (DH-U04)	Allow	Admin restriction	Publication with preview	OS-A05
Route capacity cap	Stage, per bound form	None	Stricter than the form only	Stage-settings publication with preview	Q-28
Reviewer-pool browsing	Stage (PROPOSAL, DH-U05)	Off	None	Stage-settings publication	OS-A27
Inference beta (covers rule authoring and publication, rule evaluation and inferred results)	Project operational	Off (never enabled by templates, copies or conversion)	None	Design holder opt-in with explanation	OS-A19; scope decided 6 October 2026 (DH-U21)
Email content policy	Project (versioned)	Project name and titles on; answers and free text off (proposed)	Recipient may choose minimal; never widen	Audited	OS-A26
Email mute	Recipient, per project	Not muted	None	Self-service	D3-24
Pilot timing telemetry	Project enablement plus user consent	Off	User may decline	Pilot admission	D3-08
Self-reconciliation override	Project capability grant	Not granted; what the grant allows is To be decided (DQ-20)	None	Audited grant	Q-36
Training reference and policy	Project versions bound by a training step	Per policy	None	Publish versions	OS-A18
Training guidance and acknowledgement (PROPOSAL, DH-U43)	Guidance version bound by the training step; acknowledgement and visibility in the policy version	None	None	Publish versions	TI-R37
Classification recording (lane C1)	Project operational (PROPOSAL)	Off	None	Design holder; audited; separate from the inference beta, which it never needs (DH-U21)	CPR-R39
AI screening model configuration	Project (versioned)	None	None	New version per change	OS-A20

6.3 Worked examples for the prototype

1. Hints. Form "Study design" v3 has hints Shown. Stage "Full text" step 2.2 hides them. Alice opening her shared session through Full text sees no hint; through "Extraction" she sees "Accepted answer: Rat" and her earlier copied value stays. Form "Risk of bias" has hints Hidden; no step can show them.
2. Target change. Priya changes "Study design" from target 1 to 2 with no question changes. The flow publishes v4 as a target-only version. The preview: "312 Studies have Single annotator results. They stay accepted and will show 'below current target (1 of 2)'. No reviews will be created." One Study had a Study-specific target of 3; the preview suggests keeping it.
3. Capacity and Apply anyway. Priya lowers the "Outcome extraction" cap from target plus one to the target. The preview: "4 Studies have 3 active reviewers; 4 places would exceed the new cap; drafts kept; 4 notices." She chooses "Apply anyway and release 4 places". At commit one reviewer has just completed, so the screen says "The impact changed since you reviewed it: 3 places" and she confirms again.
4. Two blinding owners in one combined step. Step 2.1 combines profile FT-v1 (Blinded) and form "Study design" (Names visible). The adjudication of FT decisions shows aliases; the form reconciliation shows names. Neither setting lives on the stage.
5. Continuation. Dev restricts finishing started work after pool departure. The preview: "1 reviewer has started work that would no longer be completable; their drafts are kept." Chandra's form becomes read-only with the reason.
6. Unsure and ties. The title and abstract template preselects Unsure on, Extra review with bound 1, then Adjudication. Creating a profile without a template requires a tie-policy choice before publication.
7. Bulk acceptance. "Risk of bias" has bulk acceptance on. Erin's "Accept agreeing studies" finds 47; 3 are left out with reasons; she confirms 44; one changed after the preview and is refused; 43 read "Reconciled · Erin · bulk-confirmed".

7. Devices, large forms, accessibility and Material 3

7.1 Device support (launch requirement)

Owner decision D3-05 (U2 device scope). "Support the full annotation experience at launch on phones, tablets and desktops, as well as screening. Do not limit annotation to tablets or desktops or remove controls or features solely on phones. Responsive presentation may differ while preserving functionality, draft, save and complete behaviour, validation and access rules." Phone annotation is a launch acceptance requirement, including large and structured forms, touch controls and accessibility.

Device class	Typical width	Input	Required
Phone	360 to 430 CSS px (check at 390)	Touch, on-screen keyboard	Screening and full annotation, including large forms, outcome data, comments, history, Fix and Needs updating
Tablet	768 to 1,024 CSS px	Touch, optional keyboard	The same, with side panels where width allows
Desktop	1,240 CSS px and wider	Pointer and keyboard	The same, with multi-panel layouts and the detached source window

Reconciliation and design screens on phones (decided 6 October 2026, DH-U12). Reconciliation, question-design and other admin screens get usable, responsive phone layouts with no feature removed, without a formal phone acceptance gate (DH-C77 for reconciliation; DH-C116 for question authoring on each device class). The launch acceptance requirement in the table above stays for screening and full annotation only, unchanged.

7.2 Large forms

• The largest project is an acceptance case (D2-16 replaced). A real project has about 2,023 questions (figure from earlier research, not re-verified). The prototype uses a synthetic replica: 2,023 generated questions across categories, repeatable entities and branches, with no real content.
• Bounded rendering and virtual scrolling on every device.
• Whole-form validation that does not depend on what is mounted; "N required missing · Jump to next" opens the right step, category, unit and branch, waits for the control and focuses it.
• Diff autosave sends only changed answers.
• Phone risks to solve, never by removing features. The outcome grid needs a phone presentation (for example a per-cell list with the same validation and spreadsheet paste where supported); drag reordering needs menu and keyboard alternatives; the on-screen keyboard must not hide the action bar; the source opens embedded.

7.3 Touch

Touch targets at least 44 px below 600 CSS px and at least 24 px everywhere. Pointer-based drag with a menu or keyboard alternative ("Pair with…", "Move up"); never HTML5 native drag. kbd hints hidden when touch is the primary pointer.

7.4 Accessibility

• Standard. The independent audit at general availability is WCAG 2.1 AA. WCAG 2.2 AA is the working standard (PROPOSAL): focus not obscured, dragging alternatives, minimum target size and consistent help.
• Keyboard. Every action reachable by keyboard with visible focus. Step selector: roving tabindex, [ and ], Enter. Candidate pills: arrow keys between pills, Enter copies. Focus moves to the validation summary after a failed Complete, into and back out of dialogs, and to the banner after a conflict.
• Screen readers. Step selector items announce name, position and state ("Step 2 of 3, Risk of bias, locked: finish step 1 first"). Candidate pills announce alias and value; the agreement icon has a text equivalent ("Candidates differ"); the autofill marker is described in the field's accessible description ("Filled from matching answers of Reviewers A and B"). The status line is a polite live region announced once per state change, never per keystroke.
• Contrast and colour. WCAG AA text contrast and 3:1 for meaningful boundaries in both light and dark themes. Status is never shown by colour alone: every state has an icon shape and text. The autofill outline must meet contrast in both themes.
• Forced colours, reduced motion, zoom. Visible in forced-colours mode; every transition honours reduced motion; 200% zoom and 400% reflow at 320 CSS px with no page-level horizontal scrolling; a 1,280 × 600 short-height layout keeps the action bar reachable.
• Screen-reader matrix for evidence. NVDA with Firefox and Chrome; VoiceOver with Safari on macOS; VoiceOver with iOS Safari for phone screening and phone annotation.

7.5 Width matrix (check every new or changed screen)

320 · 390 · 599 and 600 · 768 · 904 and 905 · 925 · 1,239 and 1,240 · 1,439 and 1,440 CSS px · 1,280 at 200% and 400% zoom · 1,280 × 600. Check the reviewer and reconciliation workspaces also with the rail collapsed and with the source panel open.

7.6 Material 3 and SyRF tokens

• Every new and updated screen uses Material 3 (Chris, 3 October 2026): Material 3 system roles (--mat-sys-*) and documented SyRF brand or domain roles (--syrf-*). No literal colours in the handoff; give a token-mapping table from the prototype's own variables (--surf-0/1/2, --on-surf, --accent, --divider) to Material 3 and SyRF roles.
• Button and type language (D3-04, decided): Material 3 sentence case for every label; the Material 3 type scale; component shapes as the Material 3 theme emits them; no ALL-CAPS letter-spaced buttons.
• The SyRF palette stays the brand reference: brand ink #1c3053, accent #4b5e84, canvas #e9ebef, in-progress #6a3069, success #4caf50, error #f44336. Map these to tokens; never rely on them alone to carry meaning.
• Layout geometry from Review Prototype v4 stays the reference (28 px numbered gutter, 44 px nested, 2 px rail, 480 px controls shrinking to 406 px nested) unless the Material 3 re-audit changes it.
• Light and dark themes are both required. Use shared components and page states (loading, empty, failure) consistently.

7.7 Existing projects before conversion

Owner decision D3-06 (U2 final clarification). Apply the refreshed design and as many compatible new features as possible to existing project screens, without changing review-workflow behaviour. In the prototype, a "Classic workflow" project shows the new navigation, dark mode, the My work badge, phone layouts and keyboard shortcuts. It shows no step selector, no Unsure, no hints, no browsing and no versioned save labels (a legacy save overwrites the session, so legacy screens keep truthful legacy wording). The eligibility explanation shows current state only, with "History before tracking began is not recorded". 6 October 2026 (DH-U41, decided): it also uses the same refreshed question editor as a Versioned project, saving directly with per-question Required and per-stage Assign, and with no versions, drafts or publication (section 5.22).

7.8 PWA (beyond the MVP)

Owner decision (U2 exploration and scope clarification; OS-A22). Making SyRF a Progressive Web App is an exploration beyond the MVP, including possible caching of allocated studies. Today's manifest and mobile tags are not a working PWA. No offline writes are authorised and protected data must never be cached by accident. The prototype must not show an install prompt, an offline review mode or "available offline" labels. Short connection drops use the status line of section 5.1.

8. Scope

Class	Includes	Notes
Baseline (MVP)	Versioned forms with target and reconciliation policy inside the version; shared sessions across stages, tabs and devices; the save-state contract; step selector and one form area; phone, tablet and desktop screening and annotation including the largest form; stage study filters, steps, exclusion-stop, progression, saved work and continuation; pool history and the eligibility explanation; Single annotator and one-candidate reconciliation; N-candidate blinded reconciliation; hints and click-to-fill; outdated-answer modes; Unsure, tie policies and adjudication with group assignment; publication with impact, compatibility declaration, mapping and generated versions; Study-specific targets and additional-review requests; capacity cap separate from target; My work, cross-project tab and badge; duplicate merge and unmerge; contribution exclusion; reversible project deletion; the catalogue; informative, permission-aware email with per-project mute; active-work previews with Apply anyway; universal baseline conversion with its wizard; training (its own lane, after its dependencies); the question editor with stable options, conditions and filtered options; question import (Classic: live questions; Versioned: a draft); question and form history with a diff; form composition and drafts; overlapping forms, guided correction and requirement revision; revising shared accepted answers (D2-09)	Baseline means planned for delivery; it does not mean approved for building
Optional after the core	Bulk acceptance; screening discussion	Both off by default per form or profile
Opt-in beta	Inference (classification reasoning)	Off by default; explicit project-designer opt-in; promotion to general availability is a separate decision
Later lanes	External and AI-model screening imports (XS1); annotation-answer imports (XA1); Data views for PRISMA and agreement	Each needs its own brief and gate. Shown with the "Later release" badge
Deferred	PWA exploration beyond the MVP (including caching allocated studies; no offline writes); answer-based branching between steps (D4-15; reconciled-answer clauses in stage filters stay in scope); grouping distinct reports or investigations (D4-08); graph digitisation (D4-10); the full updated-review workflow (D4-11; supplied previous-review counts stay); a full global landing page (D3-07); hints for repeatable entity instances (PROPOSAL, RS-R37); inference bounds reasoning and operators beyond four; match-based training scoring; further catalogues with their own permissions	Show nothing for these, except a "Not in MVP" note where a user would otherwise look for them
Not approved	Permanent physical erasure; an identity-erasure process; automatic acceptance of multiple agreeing candidates; every numeric threshold	Never shown as options

9. Prototype changes needed

Each change has an ID, the v10 page or scene it touches, the action (Add, Modify, Remove), what to do, and its traces (decision IDs and specification sections).

9.1 Global chrome and cross-cutting

ID	Page or scene	Action	Change	Traces
DH-C01	Whole pack	Add	Produce new files (for example SyRF Prototype v11.dc.html, Review Page v11.dc.html) and leave the v10 files unchanged so their checksums stay verifiable	§1.6
DH-C02	Chrome: Open decisions	Modify	Replace the 44-item list with two lists: "Open now" (section 11 DH-U items still open) and "Resolved since v10" (section 2.7 crosswalk, each linking to its new rule; DH-U27 also goes here as "Decided (D2-09, 5 October)", linking to section 5.5; since 6 October 2026 so do DH-U19 (DQ-31, section 5.15) and DH-U38 (DQ-05, section 5.24), and, later that day, DH-U41 (DQ-01, section 5.22), DH-U35 (DQ-02, section 5.22), DH-U37 (DQ-03, section 5.22), DH-U12 (DQ-04, section 7.1), DH-U42 (DQ-46, sections 3.2 and 5.24) and DH-U21 (DQ-09, sections 5.21 and 5.26))	§2.7, §11
DH-C03	Chrome: Guide	Modify	Replace the 19 walkthroughs with the DH-S scenarios of section 10, grouped as Configure, Review, Reconcile, Administer, Devices and accessibility	§10
DH-C04	Chrome: Tweaks	Modify	Remove "Answers both reviewers agree on" (prefillConfirm) and the review-step card layout. Add: device width (390, 768, 925, 1,440), theme (light, dark), candidate count (1 to 4 and more), blinding (Blinded, Names visible), project mode (Classic, Versioned), large-form replica, hints baseline (Shown, Hidden)	RE2; Q-12; §7
DH-C05	Chrome: Scenario picker and scenes	Modify and Add	Update s0 to s8 per section 2.8 (targets from forms; s7 saved work and a pool-departure variant; s8 SL3 labels). Add scenes: self-departure through a result; filter edit; Unsure and tie; adjudication by group; N-candidate reconciliation; Single annotator and one-candidate check; target-only publication; merge and unmerge; conversion; training; AI contributing vote; AI sole screener; deleted project; classic project	§2.8; §10
DH-C06	Chrome: Simulate menu	Modify	Add: another reviewer completes; team result changes; admin publishes a form version; filter edit applied; merge committed; AI run accepted; connection lost; second tab edits the same answer; place timed out; contribution excluded; project deleted	§5
DH-C07	Chrome: Inspector	Modify	Show logical records (session versions, draft changes, accepted-result versions with authority, history events, pool episodes) with the note "Record names are proposals"	§3.2
DH-C08	All pages	Modify	Sentence case on every button and header control; Material 3 type scale and shapes; remove ALL-CAPS tracking	D3-04; §7.6
DH-C09	All pages	Modify	Map colours to Material 3 and SyRF roles; full dark-theme parity; every status has shape and text	UI1; §7.4, §7.6
DH-C10	All pages	Modify	Apply the copy deck: remove the banned strings of section 5.1; use "Accepted answers", "Screening result", "Save progress", "Complete", "Needs updating", "Outdated answers", "Fix". 6 October 2026: use the decided answer terms of section 3.2 ("Answer status", "reason no value is provided", "Other, please specify", "Unanswered", "Not compared (unanswered)"); "No value to enter" is illustrative wording	D3-03; §5.1; DH-U42
DH-C11	Navigation	Modify	Replace numbered "Setup 1 · … 6 · Stages" and the "Library" mode with the section 4.1 rail: Overview, My work, Review, Reconcile, Design, Stages, Members & groups, Study Management, Data, Project settings	Q-13; D3-07; §4.1
DH-C12	App bar	Add	Global My work badge (count across projects, independent of notifications) and the cross-project My work tab on the project index	D3-07; UX §3.5
DH-C13	Overview, rail, Project settings	Add	Workflow version badge (text and shape) and panel; a Classic-mode project shows legacy navigation with compatible features only	R4; D3-06; §7.7
DH-C14	Overview (model view)	Modify	Show Study, form and profile populations separately; stop repeating criteria per stage; admin banner "N changes are waiting for your approval"; readiness-based checklist in the rail footer	D3-07; Q-02

9.2 Classification and cohorts (c1 to c10)

ID	Page or scene	Action	Change	Traces
DH-C15	c1 Concepts & rules	Modify	Rules are versioned; only conjunction, containment, disjointness and exhaustiveness; other expressions show "Unsupported"; Design holders publish; show "Inference (beta): off" with a link to the opt-in. 6 October 2026: shared concepts and mapping answers are C1 records shown without the beta; rule versions and rule-applicability answers sit behind the beta and appear only after the opt-in, with no chip (DH-U21, decided: rule authoring and publication need the beta); the inference panel stays behind the beta (sections 5.21 and 5.26)	Q-18, Q-19, OS-A19; DH-U21; TI §5.6; CPR §3.6, §3.7
DH-C16	c2 Entity types	Modify	Templates default to existing legacy types (show legacy names marked "name to verify"); cohorts, outcome measures and experiments appear only when a form uses extraction. 6 October 2026: each type shows its capabilities ("Describes which animals belong to a group", "Can be nested"); designers add project-defined types; each type has exactly one label question (section 5.26)	TC1; CPR §3.1, CPR-R01 to CPR-R05
DH-C17	c3 Question selection	Remove	Per-stage question selection is retired; questions are chosen per form and stages bind forms	SF1; OD14
DH-C18	c4 to c6, c9, c10	Modify	Keep as lane C1 content; inference panels appear only when the project opted in; count statements only where proven; save labels per section 5.1. 6 October 2026: the default population, "Add population", the whole-population cohort with "Size not reported", coverage on every cohort, set annotations with evidence, and compact cohort selection (section 5.26); these pages never need the beta (DH-U21, decided)	OS-A19; TI-R33; CPR §3.2, §3.3, §3.5, §3.8; CPR-R08, CPR-R11 to CPR-R13, CPR-R23 to CPR-R25
DH-C19	c7, c8	Modify	Add the beta-off state; candidate inference private to the reviewer; collective inference from a pinned accepted result; disabling withdraws results into history	OS-A19; TI-R27, TI-R31

9.3 Screening profiles (r1)

ID	Page or scene	Action	Change	Traces
DH-C20	r1	Modify	Profile owns its eligibility question tree; templates copy and never stay linked; version history and "used by"	DP4; SET1
DH-C21	r1 Agreement & resolution	Modify	Replace rows 1 to 6 with: sufficiency rule; Unsure on or off; tie policy (Extra review with bound, or Adjudication; required choice); handling per trigger; discussion with optional time limit; adjudication rationale required; reason handling (reason reconciliation toggle, primary reason, several reason questions, must-agree answers); identity blinding	D4-01, OS-A13, OS-A16, OS-A17, D4-02, Q-32, DP5, RX1, OS-A02; RS §3.7
DH-C22	r1	Add	Adjudicator assignment (member or group) as an audited setting outside the profile version, with impact preview	OS-A13; RS §3.9
DH-C23	r1	Add	Source policy section (Contributing vote or Sole screener, scope, label mapping, Unsure routing) with a "Later release" badge	OS-A20; RI §3.12
DH-C24	r1	Modify	Publish through the section 5.9 flow with mismatch detection and the protocol amendment entry when eligibility changes	Q-26, D4-05; RD §4.12
DH-C25	r1 preview	Modify	Preview shows the derived decision with its reasoning	DP3

9.4 Annotation forms (r6)

ID	Page or scene	Action	Change	Traces
DH-C26	r6	Modify	The standard target is shown per version; changing it starts a target-only publication	OS-A12; RD §4.9
DH-C27	r6 Reconciliation block	Modify	Reconciliation policy inside the version: target-one handling; accepted-answer completeness; identity blinding; hints baseline; outdated-answer completion mode (its place in the version is a PROPOSAL, RS-R41)	Q-29, Q-04, OS-A02, OS-A04, D4-17; RS §3.4
DH-C28	r6	Add	Operational settings block (audited, not versioned): inactivity timeout; in-progress limit; capacity cap; bulk acceptance; unstarted assignment expiry; example values marked "not approved"	D2-07, Q-28, D3-17, Q-11, Q-30; RD §3.5
DH-C29	r6	Remove	Remove "Studies where every answer agrees: Reconciler confirms each"; remove "Admin may bulk approve" (replaced by bulk acceptance in DH-C28)	RE2, Q-11
DH-C30	r6	Modify	Matching weights shown read-only, labelled "Example, not approved"	MG1
DH-C31	r6, c2	Add	Design presence: avatars of viewers and editors, per-question "editing" markers, live updates that never overwrite local typing, "keep mine" or "discard mine" on a same-item conflict, actor and time stamps, "Publishing by Priya since 14:05". 6 October 2026: accepted field changes save automatically into the draft (DH-U37, decided), so a same-item conflict shows as soon as the other change lands	OS-A01, D2-11; DH-U37; UX §3.8
DH-C32	r6 "Publish v3?"	Modify	Replace the prompt with the four-step publication flow (declarations and mapping, impact by category and route, choices with a "what reviewers will see" preview, confirm with recheck); missing reason warns; guided correction; FV4 policy revision	FV1 to FV4, VU3, D2-01, D2-02, Q-34; §5.9

9.5 What's different (r8)

ID	Page or scene	Action	Change	Traces
DH-C33	r8	Modify	Rewrite every change note to match the new rules (reconciliation pool, workspace, matching, targets, blinding, steps, filters); remove notes for retired behaviour	All

9.6 Stages (r2)

ID	Page or scene	Action	Change	Traces
DH-C34	r2 Setup	Add	Stage study filter editor with AND and OR groups, base condition, Unknown explanation, feedback notice and an edit preview	Q-15; SP §3.3
DH-C35	r2 Setup	Remove	Remove any cross-stage incoming policy or route control; dependencies exist only between steps of one stage	Q-15; DP6, DP7 superseded
DH-C36	r2 steps editor	Modify	Step kinds; Depends on separate from order; progression basis at stage level with step tighten-only; exclusion-stop per screening step; extra screening Stop or Allow; saved work after exclusion; started work after leaving the pool; hints hide-only; target read-only from the form; remove per-step targets	Q-01, Q-24, Q-28, OS-A05, OS-A04, SF2; SP §3.4
DH-C37	r2 step Reconciliation section	Remove	Remove step-level "Who reconciles", "Assignment" and "Earlier gold standard"; Reconcile authority comes from grants; assignment and expiry are form or profile settings	PM1, RA1 to RA4, Q-30, OS-A04
DH-C38	r2 Setup	Add	Route capacity cap (stricter only) per bound form; browsing setting off by default	Q-28; OS-A27
DH-C39	r2 lifecycle	Modify	Automatic completion recalculates and reopens with an admin notice; manual completion stays until Reopen; settings publish as versions through the impact flow	Q-02, LC1, PV2
DH-C40	r2 Overview, Stage progress	Modify	Show in pool, work released, reviewed through this stage, satisfied elsewhere and departed (with reasons) as separate measures; presence counts only; names for Monitor holders	OS-A09, D3-20; RI §3.3
DH-C41	r2 Reconcile page	Modify	One entry per Study × form task (stages as a filter); KPI cards including Accepting, Below current target, Inputs changed; Start reconciling; Open a specific study and Assign (eligible members only; optional expiry); release and reacquire; Held banner kept, without "Mark compatible" or its Undo (DH-C111); Corrections banner becomes "Inputs changed"; bulk acceptance screen; Request an additional review; the Agreement tab moves to Data	RE4, RA1 to RA5, Q-11, AG1, OS-A28
DH-C42	r2 Reconcile navigation	Modify	Rail badge counts ready tasks across forms; adjudication queue alongside	RE4, OS-A13

9.7 Monitor (r3, r5)

ID	Page or scene	Action	Change	Traces
DH-C43	r3 Who is offered what	Modify	Behind the Monitor capability; reasons from the section 5.13 closed set; pool-level counts until per-reviewer rows exist; never shown to reviewers	OD5; SP §3.14
DH-C44	r3, Study History	Add	Eligibility explanation timeline ("Why?") and the reviewer's "Why isn't this available to me?"	OS-A07, OS-A08, OS-A10; §5.13
DH-C50	r5 History & correction	Modify	Version kinds (Save, Complete, Fix, Upgrade, Withdraw, generated by publication, merge-resolved, carried); draft change history; kept copies; exposure and adoption markers; correct own Exclude from history; surplus as an assessment; scene s8 per SL3	SL3, DP2, D2-01, OS-A04; RD §3.9

9.8 Reviewer session (r4) and outcome data (o1, o2)

ID	Page or scene	Action	Change	Traces
DH-C45	r4	Modify	Step selector as section 4.3 (states by shape and text; narrow menu; keyboard; adjudication and training steps only when eligible)	Q-12; UX §3.1
DH-C46	r4, c10	Modify	Status line per section 5.1; remove "Save draft"; Save progress and Complete	D3-03, SL1 to SL3
DH-C47	r4	Add	Confirmation before Save progress replaces a completed version, with dependent-work wording at the reviewer's access level	Q-27; RD §4.5
DH-C48	r4	Add	One shared session across stages, tabs and devices; conflict panel with both values; place held and released copy	SF1, D2-07, D2-08, Q-28
DH-C49	r4	Modify	Combined-step semantics kept (Complete submits Include with the form; Exclude skips without deleting; Save progress never records a decision) with new labels	v10 r4; DP3
DH-C51	o1 Schema catalogue	Modify	Legacy-compatible schema, event-count schema ("Fields to be decided"), project custom schemas; direction on the outcome measure; no schema-upgrade flow	OC1, ODIR1, Q-17; OD10
DH-C52	o2, Review Page outcome data	Modify	Keep the matrix, dialog and spreadsheet; add a phone presentation keeping every function; "Estimated from graph" flag on linked graph values	RD16, D3-05, D4-10

9.9 Reviewer page (p1, Review Page v10)

ID	Page or scene	Action	Change	Traces
DH-C53	p1	Remove	Retire the card-per-step layout; the stepper becomes the only layout	Q-12
DH-C54	p1 header	Modify	Chips: Your decision, In progress (checkpoint saved), Completed, Needs updating, Outdated answers; remove "Unsaved changes"	D3-03
DH-C55	p1 screening card	Modify	Equal-weight Include, Exclude and (when enabled) Unsure; derived decision with reasoning; profile-owned reasons; Correct decision via history	D4-01, DP3, DP5, DP2
DH-C56	p1 annotation form	Add	Accepted-answer hints with "Use accepted answer", "Use all available accepted answers", replace confirmation, hide-at-step behaviour	OS-A04; §5.4
DH-C57	p1	Add	Needs updating with "Why it changed" and "What to do differently"; Outdated answers with Fix; warn-and-allow or block modes	VU1 to VU3, SF5, SF6, D4-17
DH-C58	p1 action bar	Modify	Whole-form validation summary with Jump to unmounted questions	Consolidation §6; RD-R07
DH-C59	p1	Add	Phone (390), tablet (768) and desktop (1,440) layouts for screening and full annotation, as section 4.3	D3-05
DH-C60	p1	Add	Large-form replica (2,023 synthetic questions) with virtual scrolling and Unanswered only	D2-16; §7.2
DH-C61	p1 panel menu	Remove	Remove "Remove all annotations…"; add "Discard draft changes" and a versioned withdrawal	AC-R2a-09; SL2
DH-C62	p1	Add	Saved work entry; read-only states for restricted continuation, a deleted project and read-only containment	OS-A05, OS-A25; BC §8.2
DH-C63	p1 step messages	Modify	Locked and waiting messages never reveal votes ("Waiting for the team's screening result"; "Enough reviewers are already working on this")	OD5, D3-19; SP §6
DH-C64	p1 Skip	Modify	Study-level Skip records nothing; per-step Skip as a tweakable variant for testing	RC6; DH-U09
DH-C65	p1 population chip	Modify	Keep the header chip, marked "placement to be validated"	RC8; DH-U10
DH-C66	p1 keyboard	Modify	Shortcuts per section 5.2, including U for Unsure and Shift+U for Unanswered only; inert I and E under derived decisions	D4-01, DP3
DH-C67	p1 presence	Modify	Presence chip shows counts and own place only	D3-20

9.10 Reconciliation (Reconciliation Exploration and the Reconcile workspace)

ID	Page or scene	Action	Change	Traces
DH-C68	4a form	Modify	Support 1 to 4 and more candidates (pill overflow and a selector that never hides a disagreeing candidate); random Study-local aliases; no dates or stage names; notes under the alias	SF4/RE3, OS-A02, OS-A03; RS §5.6
DH-C69	4a prefill	Modify	Keep the dashed outline as an autofill marker with a source note; remove CONFIRM; exact-match free text only; an unanswered candidate question as Not assessed (6 October 2026: "Not compared (unanswered)", DH-C123); Unknown and Not reported as answers; unseen-control warning with Complete anyway; one-sided Keep and Leave out with DH-U06 for filling	RE2, RE5, Q-04, RD2
DH-C70	4a	Add	Optional explanation with a non-blocking reminder when the answer differs from every candidate	RE1
DH-C71	4a	Add	One-candidate layout ("Reconciled (one candidate)"); Single annotator results shown as accepted automatically	Q-29, D4-03, OS-A28
DH-C72	RECONCILIATION §4.1 screening part	Modify	Move screening reconciliation into the adjudication step and queue: separate triggers, must-agree answers, reason reconciliation, required rationale per profile	OS-A13, RX1, DP5, Q-32
DH-C73	3a matching	Modify	Groups span every candidate; keyboard "Pair with…"; "Suggest again" keeps earlier pairings in history; weights read-only and not approved	MG1, SF4
DH-C74	Outcome reconciliation	Modify	Each cell shows every candidate's preview; the dialog compares N series	RD15, SF4
DH-C75	4.4 history	Modify	Accepted-result timeline with authority labels and standing (Inputs changed, Below current target, Suspended); "Edit reconciliation" becomes "Start a new reconciliation" when inputs changed, or a query	GS1, OS-A28, Q-27; RS §3.2
DH-C76	Completion	Modify	Next task and Back to pool; the section 5.1 status line for the reconciler's draft	RE2; D3-03
DH-C77	Narrow layouts	Add	Candidate selector and single column below 905 CSS px; side by side on desktop only. 6 October 2026: the workspace is usable on phones with no feature removed and no formal phone acceptance gate (DH-U12, decided)	D3-05; DH-U12
DH-C78	Exploration file	Modify	Mark Turns 1 and 2 as history and 1a to 1c superseded; update the 4b deviations table (remove the CONFIRM row; add N candidates and the unseen-control warning)	RD17, RE2
DH-C99	4a form	Add	Questions shared with another form (section 5.5): the existing accepted answer as a labelled hint with Use accepted answer, never prefilled; an optional "Why are you changing the accepted answer?" field when the answer differs, never required; Raise a query with the "Later release" badge; history shows the revision, its reason and the superseded version. Added 5 October 2026 (evening)	D2-09 (decided), OS-A04, QY1; RD §4.14, RD-R37; RS-R32, RS-R33

9.11 New surfaces

ID	Page or scene	Action	Change	Traces
DH-C79	My work	Add	Project My work with role groups and states (section 5.12); cross-project tab	D3-07, D3-23
DH-C80	Review › Your studies, Saved work	Add	Browse list and Saved work list (section 5.11)	D4-19, OS-A27, OS-A05
DH-C81	Reconcile › Adjudication	Add	Adjudication queue, claim, workspace with rationale, discussion panel and fallback	OS-A13, D4-01, D4-02, OS-A16, Q-32
DH-C82	Members & groups	Add	Members, Groups, Permissions (scoped grants, delegation of permission administration, "why can or can't I" explanations); disable membership with optional exclusion; ownership transfer never grantable	PM1, PM2, Q-03, D4-20
DH-C83	Contribution exclusion	Add	Dialog, scope, reason, preview, mixed-provenance choice, lift (DH-U15)	OS-A24
DH-C84	Shared overlay	Add	Active-work impact preview with Apply anyway and recheck (section 5.8)	Consolidation §6; Q-24
DH-C85	Shared overlays	Add	Study-specific target dialog and bulk additional-review request flow	Consolidation §1; RD §4.10, §4.11
DH-C86	Study Management	Add	Duplicate queue outcomes, merge wizard, delegated conflict task, commit refusals, tombstoned input view, unmerge with per-item choices, bibliographic field provenance editor	OS-A29, Q-37; DM §4
DH-C87	Project settings › Workflow version	Add	Conversion wizard (section 5.10), findings, adoption guidance, quarantine, containment banner; later redesign wizard	OS-A14, OS-A15, Q-05, Q-21, D4-16
DH-C88	Design › Catalogue; catalogue administration	Add	Browse, copy into project, newer-version note, publication request, administrators' queue	D2-15
DH-C89	Training	Add	Training step set-up, reference and policy versions, trainee attempt, assessment queue, retry approval, admission states, training report. 6 October 2026: the policy's feedback default is decided (right or wrong per item after assessment; expected answers only after a pass or when no retry remains), with no chip; guidance before the attempt is DH-C125	OS-A18; TI-R10 (DQ-31)
DH-C90	Project settings › Inference (beta)	Add	Opt-in page explaining the four statements, that results are suggestions and that answers never change. 6 October 2026: it also says that opting in enables writing and publishing project rules, and that explicit group recording never needs the beta (DH-U21, decided)	OS-A19; DH-U21
DH-C91	Notifications	Add	Per-project mute, project content policy with an email preview per recipient type, resolved notices	OS-A26, D3-24, D3-23
DH-C92	Project settings › Delete project; Deleted projects	Add	Delete with preview and reason; restricted Deleted projects view; restore. Copy says the project is moved out of use and can be restored; no wording implies erasure, and no restore deadline or countdown is shown	OS-A25, D3-12
DH-C93	AI screening	Add	Model configuration page, profile source policy, run upload, validation preview, acceptance, decision provenance, machine labels	OS-A20, D4-14
DH-C94	Account; join screens	Add	Account deletion confirmation; joining terms explaining contribution retention (legal text to be decided)	D2-14
DH-C95	Data (Later release)	Add	Export (Current, Previous versions, As of; machine columns; disclosure), Agreement (own capability; human independent, informed, external human and machine classes; percent agreement with denominators; kappa "method pending"), PRISMA (units labelled; mapping to be decided). 6 October 2026: exports that carry groups add population, cohort and record IDs, explicit relationships and overlap flags, and never add groups together (section 5.26)	EX1, EX2, AG1 to AG3, Q-06b, OS-A09, OS-A20; RI-R59 to RI-R63
DH-C96	Stages	Add	Completed-stage change request and approval dialog; "Changes awaiting approval" in My work	LC1, Q-02
DH-C97	All new surfaces	Add	Every new surface shows the nine states (loading, empty, pending, incomplete, completed, unavailable, historical, conflict, failure) using the shared page states	§5
DH-C98	Reconcile (Later release)	Add	Queries on accepted answers: raise from any accepted answer the user can see; one work item per accepted version with per-concern outcomes; pending flag; resolution notices	QY1 to QY9

9.12 Question management

Added on 5 October 2026 (evening) from the question-management integration (sections 5.22 and 5.23). Where a change restates a PROPOSAL, show it as a proposal. D2-09's reconciliation behaviour is DH-C99 and is not repeated here.

ID	Page or scene	Action	Change	Traces
DH-C100	c2 → Design › Questions and entity types	Modify	Rename v10's "question library" and "Entity types & question library" to Questions and entity types (reusable items are "question templates" in the Catalogue). Browse questions by entity type, with search and filters (Used by form, Unpublished, Retired, System). Each card shows its current version number as a chip, a lifecycle state by icon shape and text (Unpublished, Published, Published · unpublished changes, Retired), and "Used by: Study design v3, Risk of bias v2". System questions show a lock and "System-controlled"	Q-13, UI-11; AC-R2c-27; H-WEB-04; UX-R50
DH-C101	Question editor	Add	Fields: wording, help text, answer label, control type, data type, answer shape (Single answer · Several answers in one list · Repeated answers for each …) and options. Options: each keeps its identity, so renaming shows "Renamed · answers keep their meaning". Removing one offers Retire (shown struck through with its answer count) or "Replace with a new option" for a meaning change. Shape: repeated answers are chosen when the question is created and then locked ("Fixed when the question was created. Create a new question instead."). A data-type or single/multiple change warns "This will be published as Not compatible". Requiredness is set per form (DH-C104), Required by default since 6 October 2026 (DH-C121); Classic projects keep today's per-question Required. System questions are read-only, show their system version, and change only when a form version adopting a new system version is published. A published question is never deleted: offer "Remove from this form" or Retire; Delete appears only for a question never published. In a Classic project the same editor saves directly, with no versions or drafts (DH-U41, decided 6 October 2026). 6 October 2026: the editor opens beside a compact tree on wide screens and as a drill-in page on narrow screens, never inline in a tree node, with no numeric breakpoint approved (DH-U35, decided); in a Versioned project accepted field changes save automatically into the draft, with "Discard changes" per question and no per-question Save (DH-U37, decided)	VM §3.1, §3.3, §3.5, §3.8; D2-03; RD-R30, RD-R32, RD-R42, RD-R48; QD1; AC-R2a-10, 23, 32; AC-R2c-22, 26
DH-C102	Question tree	Modify	Numbering identical to the reviewer page. A virtualised tree that stays responsive with the 2,023-question replica. Expand and collapse all. Reorder within the same parent by pointer drag with "Move up", "Move down" and keyboard (arrows; Shift+Up and Shift+Down) alternatives; never HTML5 native drag. A child whose condition names a retired or missing parent option shows a warning naming the parent, child and option ("'Dose route' is shown when 'Route' is 'Intraperitoneal', which was retired"). When a parent gains an option, each conditional child asks "Show for new option 'Subcutaneous'?". 6 October 2026: the tree stays compact, with the editor beside it on wide screens and a drill-in editor page on narrow screens (DH-U35, decided)	AC-R1a-12, AC-R2a-24; H-TREE-01, H-TREE-02; H-WEB-18; RD-R40; §7.2, §7.3
DH-C103	Question editor: conditions	Add	Conditional display: "Always with parent" or "Only when the parent answer is …" (Yes or No, or one or more parent options picked from the list, never typed). Filtered options: a grid of parent options against this question's options, saying which are offered after each parent answer. Renaming a parent option keeps conditions and filters. The designer preview explains "Shown because Species is Rat". A hidden question is never required. A Classic project, which uses the same editor (DH-U41, decided), shows why it cannot store filtered options instead of the grid (PROPOSAL)	AC-R1a-06r, AC-R2a-04, AC-R2c-22; VM §3.3 rule 4; RD-R38; BC-R42; harvest A-N1
DH-C104	r6 Annotation forms › Questions	Modify	Compose the form with two trees (project questions; this form's questions), reusing today's Assign interaction for forms, not stages. Selecting a child adds its ancestors ("Included as ancestor"). Removing an ancestor while a descendant stays is refused, naming both. Each question is Required or Optional for this form, with an optional minimum count for repeated answers (6 October 2026: Required by default, Optional under Advanced settings, DH-C121). Order follows the tree. "Required by data extraction" marks types added by extraction. Each row shows the pinned question version; "Risk of bias uses v3 of this question" appears where another form pins a newer version. A Classic project keeps today's per-stage Assign in the same editor until it converts (DH-U41, decided)	SF1; RD §3.5; VM §4.1; AC-R2a-24; UX-R47; ui-coverage (U14)
DH-C105	Design drafts	Add	A drafts list per form or profile: name ("Wording fixes"), base version, author, last change, status Unpublished; open, rename and discard (audited). Each item's change history reads like "Renamed by Priya Shah, 14:03". When another draft publishes first, the draft shows "Based on v4 · v5 is now current" and rebases item by item, listing conflicts with "Keep mine" or "Take current"; the impact is recalculated at Publish. Design wording never uses "Draft auto-saved", which belongs to reviewers. 6 October 2026 (DH-U37, decided): accepted field changes save automatically into the draft; the draft shows one quiet status such as "Unpublished · saved 14:03", with "Discard changes" per question and no per-question Save or "Keep changes"; saving a draft never publishes to reviewers	D2-11, OS-A01; DH-U37; RD §3.7, §4.7, §9.6, RD-R25, RD-R26; UX §3.8; AC-R2c-14, 34
DH-C106	Publication step 1	Modify	Each changed question shows its change kind (Added, Removed, Changed · compatible, Changed · not compatible, Mapped) and SyRF's suggestion. The option mapping is a per-option table (retired or replaced option → an option of the new version, or "No mapping"), offered only after the publisher declares Compatible. A declared meaning change cannot be mapped. A many-to-one mapping or a changed free-text meaning forces Require re-answer. Renamed options need no mapping. Publishers see answer counts per retired option. An added required question offers "Count earlier completed reviews" or "Require an answer before counting"; a removed question says "Answers stay in history". Update automatically is offered only within a compatibility class. No Apply anyway action appears	Q-34, D2-02; RD §4.8, §7; VM §3.5; AC-R2c-18, 22, 23, 28; H-SVC-03, H-WEB-06
DH-C107	Publication step 5 and reviewer alerts	Modify	Show the outcome per review category. Completed under v2: a generated incomplete version with a mapped answer shown as "mapped on publication" beside the original, and the review stops counting. Saved incomplete: a generated version. Draft only: no version; the draft rebases at its next autosave. A session left on v2 under Keep as is still renders v2 wording and options. The in-form alert names the publication and the publishing admin, says the draft is kept, and offers "Use previous answer" only when it is valid under the pinned version. One notice per reviewer per publication; nobody is notified under Keep as is	D2-01, Q-20; RD §3.15, §9.3, RD-R23, RD-R24, RD-R28; AC-R2c-07, 16, 20r; H-WEB-11
DH-C108	Reviewer form: per-answer states	Add	Render the eight per-answer states with icon shape and text: current (no mark) · "Outdated answers" · "Needs updating" (new version) · "Needs updating" (value no longer valid) · "Needs an answer" · "Answered under an earlier version" · not applicable (hidden, kept) · "Conflicting earlier answers"	VM per-answer states (VA-27, U13); C5; AC-R2d-13
DH-C109	Design › Questions and entity types, and forms › History	Add	History per question and per form: version number, date, publisher, "Why it changed", "What reviewers need to do differently", and the compatibility declaration with its rationale (read-only, "Declared by Priya Shah, 5 Oct"). A structured per-field diff between any two versions ("Options: Oral, IV, IP → Oral, IV, IP, SC"). "Start a draft from this version" creates an Unpublished draft and never rewrites history. A corrected declaration shows "corrected by K-2"	AC-R2c-12, 21r, 27; RD-R20; H-WEB-18
DH-C110	Guided correction and requirement revision	Add	"Correct this publication" opens a guided flow: what was declared, the mapped answers and generated versions it produced (counts), the corrected declaration and treatment, then the section 5.8 preview and recheck. The original stays in history, marked "corrected by K-2". "Revise update requirement" (FV4) drops an unnecessary re-answer requirement; its preview lists the reviews whose completed status returns. No declaration is edited in place and no version or work is deleted	D2-02 amended, FV4; RD §4.13, §9.8; AC-R2c-21r, AC-R2d-06
DH-C111	r2 Reconcile held banner	Modify	Remove "Mark compatible" and its Undo. Keep "Ask v1 reviewers to update", which sends a Needs-updating request and changes no standing. A held question is released when candidates upgrade. Only the held question waits; the rest reconciles. An admin who thinks the declaration was wrong uses "Correct this publication" (DH-C110). Amends DH-C41	RD12; D2-02 amended; RD-R20; VM §9.2
DH-C112	Overlapping forms	Add	Designer: a question's page lists every form and version that uses it. Adding a question that another form uses shows "Shared with Risk of bias: reviewers' answers are shared; each form keeps its own completion". Reviewer: two forms under one entity type share its label answer, with lineage shown. The same question under another entity or branch stays separate. Before a reviewer changes a shared answer, the form says a new version will be created and which of their other forms will show "Outdated answers". Their own earlier answers from other forms show read-only in context. Forms on incompatible versions never flag each other	SF3, SF5, SF6; AC-R2d-01, 02, 07, 09, 11
DH-C113	Design › Questions and entity types › Import question template	Add	Import dialog from the toolbar: download a blank template; choose an XLSX or CSV file; show file limits as "Example, not approved". Validate and preview: a hierarchy identical to what will be created (parents, conditions, options, help text, Required or Optional, answer shape), with existing questions shown as context. Refusals: listed by row and column, each naming the unresolved reference ("Row 14: parent 'Route' is not in this file or project"; "Row 3: refers to a question in another project"). Unsupported columns are refused with the reason; lookup questions show "To be decided" (DH-T19). Nothing is created while any row is refused, and import never edits or deletes existing questions. Confirm and receipt: a confirmation ("I reviewed the hierarchy and conditions"), "Add N questions", a receipt, recent attempts, and "Retry same import" after an uncertain outcome with no duplicates. Classic projects get unassigned live questions, through the same editor's toolbar (DH-U41, decided); Versioned projects get an Unpublished draft with import provenance	AC-R1a-01 to 04, 08; ACD §3.11, ACD-R37 to R42; H-IMP-01 to 06; DS-20; UX §3.12
DH-C114	Catalogue: question templates	Modify	Catalogue item kinds: question set, annotation form, screening profile, entity type, outcome schema. Copying a question set brings its ancestors and children, creates new project questions and options with "copied from v2" provenance, and lands in an Unpublished draft (live questions in a Classic project). "A newer catalogue version exists" offers to copy the newer version into a draft that publishes normally (PROPOSAL). Copying from another project you administer carries "To be decided" (DH-U17)	D2-15; ACD §3.4, §4.7, ACD-R20 to R23, ACD-R45; B5; AC-R1a-05, 10r; H-DOM-24
DH-C115	Conversion wizard: questions	Modify	The mapping lists questions per legacy stage. Each becomes v1, "Converted on [date]", with earlier wording "Not recorded in legacy"; answers whose wording at the time cannot be proven show "Wording at the time unknown". Conditional display and filtered options are kept and counted ("12 conditional questions kept"). Stored option values that match no option are a finding with a remedy ("Q17 has 4 option values with no option: map or set aside"). System questions show their pinned system version. One form per stage question set by default, with a shared form only by admin choice; overlapping sets show the R2d finding	OS-A14, OS-A15; BC §3.2, §3.4, BC-R07, BC-R08, BC-R15, BC-R42, BC-R45, §10.3; harvest A-N1
DH-C116	Design pages on devices	Add	Desktop (1,440) and tablet (768, touch): Questions and entity types, forms, drafts, history and publication; drag with menu alternatives on touch. Wide screens show the editor beside the compact tree, and narrow screens use the drill-in page; where the switch falls is a design detail to validate, with no numeric breakpoint approved (DH-U35, decided 6 October 2026). Phone (390): the same functions in one column (list → editor → back) with no feature hidden and no formal phone acceptance gate (DH-U12, decided 6 October 2026). Presence avatars collapse to a "+2" chip on narrow widths	D3-05 (reviewer scope); UX §3.13, UX-R49; UX A2; DH-U12, DH-U35; AC-R1a-12; §7.3, §7.5
DH-C117	Question-management pages: Material 3 and copy	Modify	Sentence case ("Questions and entity types", "Add question"); no literal colours (today's summary uses one); the "Focused question" text never appears. Lifecycle, version, editing-by-someone-else, invalid-child and retired-option states each have an icon shape and text, with light and dark parity. 6 October 2026: so does the draft's save status (saving, saved with its time, not saved with Retry), which never uses the reviewer words "Draft auto-saved" (DH-U37, decided)	D3-04; UI-1, UI-4, UI-10, UI-11; AC-R1a-07
DH-C118	r1 profile questions	Modify	The profile editor embeds the same question editor and tree, owned by the profile. Questions are never shared across profiles (copies only) and publish through profile publication	DP4; VM §3.1 (definition owner); DH-C20

9.13 Answers, training guidance, reference questions and lane C1

Added on 6 October 2026 for Chris's answers of that day and the classification, populations and references specification (sections 5.15, 5.24, 5.25 and 5.26). The answer terms were decided later that day (DH-U42; sections 3.2 and 5.24) and are applied below; "No value to enter" is illustrative wording. Show every PROPOSAL as a proposal.

ID	Page or scene	Action	Change	Traces
DH-C119	Question editor: reasons no value is provided	Add	A "Reasons no value is provided" block per question: Not reported, Not applicable and Unable to assess offered (which start selected is DH-T21); "Add your own" with a label and a description; "Add from a catalogue template" (for example "SYRCLE risk of bias", "Content pending methodologist review"), recording "copied from" and unchanged when the catalogue changes. Each reason has a stable identity, kept in versions and exports. A risk-of-bias "Unclear" stays an option, with the explanation "Unclear is a judgement, so it is an option, not a reason no value is provided". Retiring one on a published question warns "This will be published as Not compatible" unless it is mapped to another of the same meaning. No naming chip: the term is decided (DH-U42)	Required by default; answer terminology (Chris, 6 October 2026; DH-U42); RD §3.16, RD-R50, RD-R54; RD-AE44, RD-AE45; D2-15
DH-C120	Question editor: answer metadata grid	Add	Metadata fields the designer adds (Comment, Unit, Evidence quote with its source location, Reason; several of one kind allowed) against the answer states (any value; an option that needs its own rule, such as Other; each reason no value is provided; Unanswered, shown only for an optional question). Each cell is Hidden, Allowed or Required. Requiring a field for Unanswered warns "This makes the question 'answer or explain'" and suggests a required question with a reason no value is provided. The text of "Other, please specify" is part of the Other option's value, set with the options, never a metadata field (DH-U42). The source-location format is DH-T22	Configurable answer metadata; answer terminology (Chris, 6 October 2026; DH-U42); RD-R52; RD-AE42; FX-VM-60
DH-C121	r6 form composition: requiredness	Modify	Amends DH-C104: a newly added question shows Required; Optional sits under "Advanced settings" with the warning "Reviewers can skip this without saying why" and a suggestion to offer Unable to assess instead; the form summary counts optional questions ("2 optional questions"). Raising a question to Required in a later version offers DH-C106's counting choice	Required by default (Chris, 6 October 2026); RD-R49; RD-AE39; VM §4.1
DH-C122	p1 reviewer form: answers	Add	An action beside each question that opens its reasons no value is provided (illustrative wording "No value to enter", not a fixed label); each question's answer status (Unanswered, answered with a value, answered with a reason) by icon shape and text; "Other, please specify" records the Other option and its text together as the value, with the text inside the answer; metadata fields shown only for the chosen answer state, with "Needed to complete" on required ones; Complete names each applicable required question with neither a value nor a reason, and each missing required field ("Add a comment for Unable to assess"), including questions never scrolled into view; Save progress is never blocked; a required repeated question needs its minimum count or the group-level "None reported" (PROPOSAL); "Clear answer" returns a question to unanswered and history shows "answered, then cleared" (PROPOSAL); the reviewer's Not applicable never looks like a question hidden by its condition	Required by default; configurable answer metadata; answer terminology (Chris, 6 October 2026; DH-U42); RD-R51 to RD-R53; RD-AE40 to RD-AE43; DH-C58
DH-C123	4a reconciliation form: unanswered questions and reasons no value is provided	Modify	Amends DH-C69: an unanswered candidate question shows "Not compared (unanswered)" (carried from the recommendation into the terms decided on 6 October 2026, DH-U42; it was "Not assessed") and is still neither agreement nor disagreement; the same reason no value is provided agrees; a reason against a value, or against a different reason, disagrees; "Other, please specify" compares as a value (the option with its text); agreement figures for reasons no value is provided show "Method pending statistical review" (DH-T20)	Q-04; DH-U42; RS-R14, RS-R15; RS-AE08; T-SI-02
DH-C124	Conversion and redesign wizards: requiredness	Modify	Amends DH-C87 and DH-C115: converted questions keep the legacy Required or Optional setting, shown "Optional (kept from legacy)"; legacy options worded "Not reported" or "Unclear" stay options; conversion adds no reasons no value is provided. The redesign wizard lists optional questions and offers "Make required, with reasons no value is provided", one question at a time, through the publication preview's counting choice. Turning an option into a reason no value is provided is absent (DH-T23)	Required by default, item 5 (Chris, 6 October 2026); BC-R49; BC-AE37
DH-C125	Training: guidance before the attempt	Add	Designer: bind a guidance version to the training step (rich text, links and files), and choose whether trainees confirm "I have read this" before starting and whether the guidance stays visible during the attempt; editing publishes a new version and attempts in progress keep theirs. Trainee: the guidance opens before "Start attempt"; with the confirmation on, Start stays disabled until it is given; the attempt records which version was read. Shown with a "To be decided" chip (DH-U43)	Chris's question, 6 October 2026; TI §3.10, TI-R37 (PROPOSAL); TI-AE26
DH-C126	Question editor: reference questions	Add	The answer type "Reference to records", with a "Later release" badge: target types (the recommended set is in DH-U44), scope (always the same population; an optional same-parent rule), single or several with an optional minimum and maximum, and empty-state text ("Add a Location first"); reasons no value is provided and metadata as for any question. Removing a type, narrowing scope, lowering a maximum, switching between single and several, or changing the kind warns "This will be published as Not compatible". The five fixed lookups appear as read-only system questions	CPR §3.4, CPR-R15, CPR-R16, CPR-R21, CPR-R22; CPR-AE10, CPR-AE11, CPR-AE16
DH-C127	p1 reviewer form: record picker	Add	A searchable picker of the reviewer's own records of the target types in this paper and population ("Later release" badge); selected records as chips with label and population; the states of section 5.25; an empty selection is unanswered, and "none" is a reason no value is provided; history shows each record's label at the time	CPR-R15, CPR-R17 to CPR-R19; CPR-AE10, CPR-AE12, CPR-AE30
DH-C128	Record deletion dialog	Add	Before a reviewer deletes a record, list every answer that references it ("Referenced by: Pregnant · Housing location"); after deletion the referencing answers show "Refers to a deleted record" and Complete names the question until it changes; nothing is removed silently ("Later release" badge)	CPR-R20; CPR-AE13
DH-C129	Reconciliation: match records first	Add	A step before reference comparison: SyRF suggests matches between candidates' records ("Farm A ↔ Farm 1: sizes match; labels differ"); the reconciler confirms, splits or marks a record distinct; reference answers then compare through the match; an unmatched record shows "Not matched yet"; blinded candidates stay Reviewer 1 and Reviewer 2 while record labels from the paper show; the accepted answer's picker offers reconciled records only ("Later release" badge)	MG1; CPR-R32 to CPR-R34; CPR-AE19, CPR-AE20

Totals. 129 changes (DH-C01 to DH-C129): 64 Modify, 58 Add, 6 Remove and 1 Modify and Add. DH-C99 was added on 5 October 2026 (evening) for D2-09's decision, and DH-C100 to DH-C118 later that evening for question management. The question-management gap report's draft numbered these DH-C99 to DH-C118; they were renumbered from DH-C100 because DH-C99 was taken, and its draft D2-09 change was dropped because DH-C99 already covers it. DH-C119 to DH-C129 were added on 6 October 2026 (section 9.13), and DH-C02, DH-C15, DH-C16, DH-C18, DH-C69, DH-C89, DH-C95, DH-C101 and DH-C104 were amended in place the same day. Later on 6 October 2026, for Chris's design-handoff answers (DH-U12, DH-U21, DH-U35, DH-U37, DH-U41 and DH-U42), DH-C02, DH-C10, DH-C15, DH-C18, DH-C31, DH-C69, DH-C77, DH-C90, DH-C101 to DH-C105, DH-C113, DH-C116, DH-C117, DH-C119, DH-C120, DH-C122 to DH-C124, DH-C126 and DH-C127 were amended in place; no change was added or removed.

10. Acceptance scenarios for the prototype

Fixture world. The v10 project "Livestock TB evidence review" with stages "Title/abstract screening", "Full-text review" and "Outcomes extraction"; profiles TA-v1 and FT-v1; forms "Study design" v3 and "Outcome data" v2. Reviewers Alice, Bob, Carol and Dan (from v10); reconciler Erin; admin and publisher Priya; designer Sam; group "Senior screeners" (Ben, Chloe); assessor Ewan; trainee Tom; Ravi, who runs an AI screening model outside SyRF. A synthetic "largest-project replica" with 2,023 questions. A second, Classic-workflow project for coexistence. All content synthetic. For question management (DH-S52 to DH-S67) the Livestock TB project uses the Versioned workflow and adds a "Risk of bias" form whose versions advance as each scenario needs; questions "Route" (Oral, IV, IP), "Dose route", "Treatment", "Species" and "Strain"; and, in the Classic-workflow project, 12 conditional questions. For DH-S68 to DH-S77 (added 6 October 2026) "Risk of bias" v6 has Q13 "Was allocation concealed?" (Yes, No, Unclear) and an older optional Q14; the Classic-workflow project has 6 optional questions; and Study 12 is a synthetic farm paper reporting 120 cattle on Farm A (70) and Farm B (50).

Each scenario lists its traces: decision IDs; specification sections; changes.

DH-S01 Step selector and one form area. Given Alice opens Study 1 in Full-text review on a desktop, when she selects step 3 in the step selector, then one form area shows only step 3, steps 1 and 2 show Done by icon and text, and a locked step announces its reason. Traces: Q-12; UX §3.1, UX-R01 to R03; DH-C45, DH-C53.

DH-S02 Draft, checkpoint and complete stay distinct. Given Alice has no session for Study 1 "Outcome data", when she types an answer, presses Save progress, edits again and then completes, then the status line moves through "Draft auto-saved · no checkpoint yet", "Version checkpoint saved 14:02", "Draft auto-saved · last checkpoint 14:02" and "Complete · 14:10", and the history shows two versions and no version for the autosaves. Traces: D3-03 (U1, OS-A21), SL1 to SL3; UX §3.2, RD §3.10; DH-C46, DH-C50.

DH-S03 Save progress after Complete. Given Alice completed Study 1 and Erin has started reconciling it, when Alice edits and presses Save progress, then a confirmation explains that her review will stop counting as complete and that a reconciliation in progress will need re-checking, without naming Erin; cancelling keeps her completed version current. On Study 3, where review is still possible, Alice opens her history, chooses Correct decision and changes her own Exclude to Include; the earlier Exclude stays in history and nobody is re-invited automatically. Traces: Q-27, SL3, DP2; RD §4.5, UX-R13; DH-C47, DH-C50, DH-C55.

DH-S04 Largest form on a phone. Given Bob opens the largest-project replica (2,023 questions) on a 390 CSS px phone with touch, when he answers questions in three categories, loses connection for a minute, presses Save progress, presses Complete with 3 required answers missing in units that are not rendered, follows "Jump to next" to each, and completes, then the form never shows a horizontal page scroll, every target is at least 44 px, the action bar stays above the on-screen keyboard, the status line shows the offline and checkpoint states, Jump opens and focuses each missing control, the final status reads "Complete", and every action available on desktop is available on the phone. Traces: D3-05, D2-16, consolidation §6, OS-A21; UX §3.3, UX-R04 to R08, UX-AE03 to AE05, RD-R33; DH-C58, DH-C59, DH-C60.

DH-S05 One session across stages, tabs and devices. Given Alice has Study 1 "Study design" open through Full-text review in one tab and through Outcomes extraction in another, when she edits different answers in each and then the same answer in both, then both edits to different answers apply to the one session, the same-answer edit shows a conflict panel with both values, and only one place is held. Traces: SF1, D2-08, Q-28; RD §4.2, SP §3.11; DH-C48.

DH-S06 Place timeout keeps the draft. Given Bob leaves both tabs idle past the form's timeout, when he returns, then the status explains that his place was released and his draft kept; with an enabled cap and no free place he may keep or discard the draft. Traces: D2-07, Q-28; RD §4.6; DH-C48.

DH-S07 Hints and click-to-fill. Given "Study design" has hints Shown and Study 1 has an accepted answer "Species: Cattle", when Carol opens the form through a step that does not hide hints, then the control stays empty with the labelled hint; clicking "Use accepted answer" fills it and marks it "From accepted answers v3"; opening the same session through a step that hides hints shows no hint and keeps her copied value; a form with hints Hidden shows no hint in any step. Traces: OS-A04, Q-28, Q-30, VS2; RS-R31 to R38; DH-C56.

DH-S08 Outdated answers. Given Dan's change made a dependent answer outdated, when he presses Complete under the default form setting, then a warning offers "Complete anyway"; after Priya publishes a version that sets "block until addressed", his next Complete is refused with a jump link and his draft is kept; a re-answer requirement blocks in both modes. Traces: D4-17, VU1; RS-R39 to R42 (placement in the form version is a PROPOSAL, RS-R41); DH-C57.

DH-S09 Own Include progression and the stage setting. Given Bob included Study 1 at full text and the team result is pending, when he opens the dependent outcomes step, then it is available; after Priya sets the stage to "Team Include required", the same step shows "Waiting for the team's screening result"; on Study 3 the annotation steps wait for his own decision. Traces: Q-01; SP §3.4, SP-R15 to R18; DH-C36, DH-C63.

DH-S10 Exclusion-stop and independent steps. Given step 1 has collective exclusion-stop with scope "dependent steps" and Study 7 is collectively Excluded, when Carol opens Study 7, then the dependent step is never offered and shows "Stopped by exclusion", the independent step stays available, and collective satisfaction admits an unvoted reviewer elsewhere without inventing a vote. Traces: Q-15, Q-24; SP-R19 to R22, SP-R29; DH-C36.

DH-S11 A result recorded through a stage moves its own Study out; saved work continues. Given Alice has started outcomes for Study 2 and the filter is "FT not Excluded", when Bob's Exclude makes the team result Excluded, then Bob's decision is recorded without a predictive warning, Study 2 leaves the pool, Alice sees it under Saved work with "You can finish your saved work", and her later Complete records that it was completed as continuation. Traces: OS-A05, OS-A06, Q-28; SP §4.2, §3.9; DH-C80, DH-C62.

DH-S12 Continuation restricted. Given Priya restricts finishing work after pool departure, when she confirms, then the preview first says one reviewer's started work would no longer be completable with drafts kept, and Alice's form becomes read-only with the reason. Traces: OS-A05; SP-R33, SP-R38; DH-C62, DH-C84.

DH-S13 Messages never reveal votes. Given Carol is a candidate and the project hides screening results from candidates, when any step becomes locked or a Study leaves her list, then no message, chip, order or count reveals another reviewer's decision, and "Who is offered what" is visible only to Monitor holders. Traces: OD5, D3-20, Q-30; SP §6, UX-R28; DH-C43, DH-C63, DH-C67.

DH-S14 Browsing is blinded and dynamic. Given Priya enables browsing for Full-text review, when Bob opens "Your studies", then each row shows only his own statuses, availability and visible accepted results; when a Study leaves the pool while he browses, opening it says "No longer available in this stage" without the reason. Traces: OS-A27, D4-19; SP §3.6, SP-R53 to R59; DH-C80.

DH-S15 Eligibility explanation with a coverage gap. Given a Study converted on 20 September with no review, when Priya opens "Why?", then the timeline reads "Pool history before 20 September 2026 is not recorded", shows the baseline entry and says "No review is recorded" without inventing a cause; for Study 2 it explains Alice's continuation after departure. Traces: OS-A07, OS-A08, OS-A10; SP §3.14, UX §3.7; DH-C44.

DH-S16 Filter edit finds newly matching Studies. Given Outcomes extraction is automatic and Completed, when Priya widens its filter, then the preview lists 14 entering Studies with remaining work and says the stage will reopen; after confirming, the stage reopens and new work appears in My work. Traces: Q-02, Q-15, OS-A11; SP §4.1, SP-R76; DH-C34, DH-C39.

DH-S17 Single annotator accepted automatically. Given "Study design" v3 has target one and "Accept automatically", when Alice completes Study 4, then the Study shows "Accepted automatically · Single annotator" and nothing calls it reconciled or verified; when Dan also completes, the task shows "Inputs changed · 2 candidates" and the result stays effective until Erin completes. Traces: Q-29, OS-A28; RS-R01, RS-R02, RS-R08; DH-C71, DH-C75.

DH-S18 One extracts, one checks. Given "Outcome data" has target one and "Require human reconciliation", when Bob completes Study 5, then the pool shows "Ready · 1 candidate", Erin reconciles one candidate in the ordinary workspace and the result reads "Reconciled (one candidate) · Erin"; Bob opening the task sees "You reviewed this study". Traces: D4-03, OS-A28, Q-36; RS-R03, RS-R17; DH-C71.

DH-S19 Blinded reconciliation with three and four candidates. Given Alice, Bob and Carol completed "Study design" on Studies 6 and 8, when Erin reconciles both, then she sees Reviewers A, B and C in a random order on each, with different mappings between the two Studies, no dates or stage names, and the mapping unchanged after Save progress and reload; a fourth candidate arriving appears as Reviewer D at the end with "1 new candidate since you started", and no candidate is hidden on a narrow screen. Traces: OS-A02, OS-A03, SF4/RE3, Q-30; RS-R24 to R30; DH-C68, DH-C77.

DH-S20 Autofill without per-field confirmation. Given two candidates agree on 18 answers and differ on 3, when Erin opens the task, then the 18 are filled with the autofill marker and a source note and no CONFIRM; free text fills only on an exact match; on Complete with 2 questions never brought into view, a warning lists them with links and "Complete anyway" records the result. Traces: RE2, RE5; RS §4.4; DH-C69.

DH-S21 An unanswered question is not compared. Given one candidate left an optional question unanswered and two answered "Not reported", when Erin reviews, then the unanswered question shows "Not compared (unanswered)" (it was "Not assessed"; carried from the recommendation into the terms decided on 6 October 2026) and does not count as disagreement, the two "Not reported" answers agree, and a required applicable question left unanswered in her own answer blocks Complete. Traces: Q-04, DH-U42; RS-R13 to R16; DH-C69, DH-C123.

DH-S22 Bulk acceptance needs explicit confirmation. Given "Risk of bias" has bulk acceptance on, when Erin opens "Accept agreeing studies", then the list excludes held, changed and disagreeing Studies with reasons, nothing is accepted until she confirms the exact list, and each result reads "bulk-confirmed" with her name. Traces: Q-11; RS-R21 to R23; DH-C41, DH-C28.

DH-S23 Self-reconciliation override. Given Erin was a candidate on Study 9, when she tries to reconcile it, then she is refused; after Priya grants the override, the result shows "Eligibility override: reconciler was a candidate". The override shows a "To be decided" chip (DQ-20). Traces: Q-36; RS-R17, RS-R18; DH-C82.

DH-S24 Unsure and ties. Given TA-v1 has Unsure on, extra review bound one, then adjudication, when Alice includes and Bob answers Unsure on Study 10, then the result reads "Waiting for one more decision"; Carol's Include makes it Included; on Study 11 Include, Unsure and Exclude give "Awaiting adjudication"; all-Unsure shows "To be decided". Traces: D4-01, OS-A16; RS §5.10, RS-R46 to R49; DH-C21, DH-C81.

DH-S25 Adjudication by group with rationale. Given FT-v1 routes ties to adjudication with a required rationale and assigns "Senior screeners", when Study 12 is tied and Chloe screened it, then only Ben sees the task, he must enter a rationale, and the result reads "Excluded · adjudicated by Ben Carter" with both original decisions in history. Traces: OS-A13, Q-32; RS-R50 to R56; DH-C22, DH-C81.

DH-S26 Discussion, then fallback. Given FT-v1 enables discussion, when Alice includes and Bob excludes Study 13, then both see each other's decisions under aliases, Bob marks "Cannot agree", the discussion ends unresolved and an adjudication task appears; agreement statistics keep the initial decisions. Traces: D4-02; RS-R60 to R64; DH-C81.

DH-S27 Target change versions the form. Given "Study design" v3 has target 1, when Priya changes it to 2, then a publication flow starts, the preview says results stay accepted as "below current target (1 of 2)" and no reviews will be created, every Study-specific target needs a treatment (shown with a "To be decided" chip, DQ-11), and v4 appears in the version list. Traces: OS-A12, Q-29; RD §4.9, RS §4.6; DH-C26, DH-C32, DH-C85.

DH-S28 Publication with compatibility, mapping and generated versions. Given "Risk of bias" v3 replaces option "Unclear" with "Some concerns" and adds a required question, when Priya publishes, then she must declare compatibility (SyRF suggests not compatible), may map the option, chooses a treatment per category, sees "what reviewers will see", and after publication Alice's history shows "Version 4 · generated by publication of Risk of bias v3 · Priya", while Carol's active draft is kept and rebased. Traces: D2-01, D2-02, Q-34, FV1 to FV3, VU3; RD §3.15, §4.8; DH-C32, DH-C50.

DH-S29 Profile publication needs an amendment entry. Given Priya changes TA-v1 to exclude in vitro studies, when she publishes, then SyRF marks "eligibility changed" and requires a protocol amendment entry in the same flow, and required new screening stays pending. Traces: Q-26, D4-05; RD §4.12, RI-R21 (requirement decided; the suggestion is a PROPOSAL); DH-C24.

DH-S30 Collaborative design drafts. Given Priya and Sam open the same form draft, when Sam types an option label while Priya renames another question, then both changes save automatically into the draft and Sam sees Priya's change appear without losing his typing; when both edit the same label, Sam sees Priya's text beside his own as soon as her change lands, with "keep mine" or "discard mine"; while Priya publishes, Sam sees "Publishing by Priya since 14:05". Traces: OS-A01, D2-11, DH-U37; RD §4.7, UX §3.8; DH-C31, DH-C105.

DH-S31 Capacity reduction with Apply anyway. Given 4 Studies have 3 places each, when Priya lowers the cap to the target, then the preview lists the 4 places, Apply anyway names them, and a changed impact at commit asks her again; drafts are kept and the released reviewer sees "Enough reviewers are working on this Study. Your draft is kept." Traces: Q-24, consolidation §6, D3-17; ACD-R33 to R35, UX §3.9; DH-C84, DH-C28.

DH-S32 Additional-review request raises the target. Given Erin selects 40 Studies with a disagreement, when she requests one more review each from "Senior extractors", then the preview flags members who already reviewed some of them, 40 Study-specific targets are raised, and the project still reports the standard target with "40 studies have a study-specific target" listed separately. Traces: consolidation §1, RA5; RD §4.11, RD-R17, RD-R19; DH-C85.

DH-S33 Merge with delegation and a stale input. Given Studies 204 and 377 are duplicates and Alice reviewed both, when Priya delegates Alice's conflict and Alice resolves it, then the resolution names Alice; when Bob saves a correction on 204 before commit, the commit refuses with "S-204 changed since the preview"; after refreshing, the commit creates S-512 and the inputs read "Merged into S-512". Traces: OS-A29, D2-12, Q-37; DM-R04 to R11; DH-C86.

DH-S34 Unmerge with per-item choices. Given S-512 has post-merge work, when Priya unmerges, then every item needs "Move to S-204", "Move to S-377" or "Leave in the merged history", "both" is never offered, a warning flags an accepted result built from both originals, and S-204 and S-377 return with their pre-merge evidence plus the moved items. Traces: OS-A29; DM-R14 to R16; DH-C86.

DH-S35 Conversion wizard with converging stages. Given a Classic project with two stages using the same question set, when Priya maps both onto one shared form, then the wizard lists 6 reviewers with work in both, approval stays disabled until each conflict group is resolved or delegated, and every created or reused structure is labelled. Traces: OS-A14, OS-A15, Q-05, Q-21; BC §4.3, BC-AE06, BC-AE07; DH-C87.

DH-S36 The largest project is never excluded. Given the largest-project replica's trial conversion fails the phone load check, when Priya opens the wizard, then it shows "Conversion paused: large-form phone load above budget" with a remedy, the project keeps working as before, and nothing says it is excluded because of its size. Traces: D2-16, OS-A15; BC §9 E4; DH-C87.

DH-S37 Catalogue copy and request. Given the catalogue has "SYRCLE risk of bias" v1 (content pending review), when Sam copies it, then his project gets an Unpublished copy with "copied from" provenance; when the catalogue publishes v2, his copy is unchanged with a "newer version exists" note; his publication request waits in the administrators' queue. Traces: D2-15; ACD-R20 to R23; DH-C88.

DH-S38 Training, retry, manual assessment and admission. Given a training step with pass mark "Example 80%", one retry after approval and admission to "Screeners", when Tom scores 72%, Priya approves a retry, Tom scores 90% with one free-text item and Ewan marks it correct, then Tom sees "Passed · admitted to Screeners", both attempts stay in history, and live counts for the practice Studies are unchanged. Traces: OS-A18, D4-04; TI-R04, TI-R08, TI-R12, TI-R15 to R17; DH-C89.

DH-S39 Inference beta. Given a new project, when Alice opens a cohort form, then no inference appears, and Sam's Concepts & rules shows shared concepts but no rule pages; after Sam opts in and reads the explanation, he publishes rule v2, and Alice sees "Pregnant is contained in Female (proven by rule v2)" based only on her own answers, and Bob cannot see her panel. Traces: OS-A19, Q-18, DH-U21; TI-R24 to R32; DH-C15, DH-C19, DH-C90.

DH-S40 My work with notifications muted. Given Carol muted email for every project, when she opens the project index, then the badge shows 4 and the cross-project tab lists work in a project she has not opened; after Ben resolves an adjudication assigned to her group, the badge drops to 3 and the item appears in history as "Decided by Ben". Traces: D3-07, D3-23, D3-24; UX §3.5, ACD-R28, ACD-R32; DH-C12, DH-C79.

DH-S41 Informative, blinded email. Given the default content policy and blinded reconciliation, when Priya opens the email preview, then a candidate's email names the project and study title without the question text, the reconciler's email uses the same Study-local alias she sees, and a recipient who lost access receives nothing. Traces: OS-A26, D3-22; ACD-R24 to R27; DH-C91.

DH-S42 Project deletion and restoration. Given three reviewers are active in "Pilot 2024", when the owner deletes it with a reason, then the preview lists active work, a reviewer mid-form sees "This project has been deleted. Your draft is kept.", and the project leaves normal lists with its data and drafts kept; restoring from Deleted projects (restricted view) says released places will not come back, and her draft reappears. No screen offers permanent erasure or implies that anything was erased. Traces: OS-A25, D3-12; ACD-R14 to R18; DH-C92.

DH-S43 Contribution exclusion with mixed provenance. Given Sam's session on Study 42 has versions submitted through two stages, when Priya excludes Sam's contributions for one stage, then the preview lists a mixed-provenance group needing a choice, dependent accepted results stay current with "inputs changed: contribution excluded", and Sam's sessions remain in history with his name. Traces: OS-A24, D4-20; ACD-R06 to R12; DH-C83.

DH-S44 AI sole screener with Unsure. Given a profile uses an AI screening model as sole screener, when Priya accepts Ravi's run, then the AI screening model's Include and Exclude decisions read "Machine-only result", its Unsure decisions wait in the adjudication queue, every label says "AI-model-generated screening decision", and the importer and accepter appear separately from the AI screening model. Traces: OS-A20; RI-R32 to R40; DH-C93, DH-C81.

DH-S45 An AI rerun creates new versions and adds no voter. Given the AI screening model's run was accepted, when Ravi's rerun under configuration version 2 is accepted, then each Study still has one current AI-model-generated screening decision, the earlier one is in history, and a resolved adjudication stays current with "inputs changed". Traces: OS-A20; RI-R37, RS-R58; DH-C93.

DH-S46 Account deletion keeps named attribution. Given Dana reviewed 120 Studies, when she deletes her account, then the confirmation says her submitted reviews keep her name, she can no longer sign in, and her decisions show "Dana Reid (account deleted)" to people who may see identities. Traces: D2-14; ACD-R01 to R05; DH-C94.

DH-S47 Classic project after the refresh. Given a Classic-workflow project, when Bob screens there, then he sees the new navigation, dark mode and phone layout, but no step selector, Unsure, hints, browsing or versioned save labels, and studies are served as before. Traces: D3-06, OS-A23; UX §3.4, §7.7; DH-C13.

DH-S48 Accessibility on the key surfaces. Given the reviewer workspace, reconciliation workspace, publication flow, stage designer and Members & groups, when each is used by keyboard alone, with a screen reader, in forced colours, in dark mode and at 400% zoom, then every task completes, the step selector, candidate pills, agreement icons and status line are announced meaningfully, and no status depends on colour alone. Traces: UI1, D3-15, D4-18 reading; UX §8, acceptance criteria UI-4, UI-6; DH-C09, DH-C97.

DH-S49 No PWA or offline claims. Given any screen on a phone, when the connection drops, then the status line uses the agreed offline wording and nothing offers installation, offline review or "available offline". Traces: OS-A22; UX-R38 to R40; DH-C46.

DH-S50 Deferred features stay absent. Given the stage designer and the Study page, when Priya looks for answer-based branching between steps or "link reports to one study", then neither exists, while accepted-answer clauses in the stage filter are available with a "Later release" badge. Traces: D4-15, D4-08; SP-R25, RI-R03; DH-C34.

DH-S51 Revising a shared accepted answer. Given "Study design" and "Outcome data" both include "Species", and Erin accepted "Rat" for Study 7 through "Study design", when Chloe reconciles "Outcome data" on Study 7, then "Species" shows "Accepted answer: Rat · accepted answers v3" with Use accepted answer and an empty reconciled control; when she chooses "Mouse", an optional "Why are you changing the accepted answer?" field appears and Complete succeeds with it empty; history then shows "Revised for Outcome data · v4 · supersedes v3" and "No reason given", and "Study design" shows "Mouse" too; Raise a query is offered on the accepted answer with the "Later release" badge. Traces: D2-09, OS-A04, QY1; RD §4.14, RD-R37, RS-R32, RS-R33; DH-C99, DH-C98.

DH-S52 Questions page and terminology. Given Sam opens Design › Questions and entity types in the Livestock TB project, when he filters to "Used by: Study design" and "Unpublished", then the page is titled "Questions and entity types" (never "library"), each card shows its version chip and lifecycle state by icon and text, and the species system question shows a lock and "System-controlled" with no edit or delete action. On a wide screen, opening a question shows its editor beside the compact tree. Traces: Q-13, UI-11, DH-U35; AC-R2c-27; UX-R50; DH-C100, DH-C101, DH-C102.

DH-S53 Options keep their identity. Given "Route" v2 (Oral, IV, IP) has answers, when Sam renames IP to "Intraperitoneal", retires IV and adds "Subcutaneous", then the rename reads "Renamed · answers keep their meaning", IV shows Retired with its answer count, and the next publication suggests Not compatible for Route. When he tries to switch "Repeated answers for each cohort" off, he sees "Fixed when the question was created. Create a new question instead." Traces: VM §3.3, §3.5; D2-03; AC-R2c-22, 26; DH-C101.

DH-S54 Child validity and a new parent option. Given "Dose route" shows only when Route is Intraperitoneal, when Sam retires that option, then the tree warns, naming the parent, child and option, and publishing the form is refused with the same message. When he then adds "Subcutaneous", each conditional child asks "Show for new option 'Subcutaneous'?". Traces: AC-R2a-24; RD-R40; H-TREE-01, H-TREE-02; DH-C102.

DH-S55 Conditions and filtered options. Given "Strain" offers only Wistar and Sprague-Dawley when Species is Rat, when Carol answers Rat in the preview, then only those two strains appear with "Shown because Species is Rat", and Complete never requires a question hidden by its condition. Traces: AC-R1a-06r, AC-R2a-04; RD-R38; DH-C103.

DH-S56 Composing a form. Given Priya adds "Dose route" to the "Study design" draft, then Route and Treatment are added as "Included as ancestor"; removing Route while Dose route stays is refused, naming both; she marks Dose route Optional for this form only; each row shows its pinned version. In the Classic-workflow project the same editor opens, and its Assign still selects questions per stage, with no draft or publication. Traces: SF1, DH-U41; AC-R2a-24; UX-R46, UX-R47; DH-C104.

DH-S57 Several drafts and a rebase. Given Sam edits the "Risk of bias" draft "Wording fixes", based on v4, and his edits save automatically with "Unpublished · saved 14:03", when Priya publishes her draft "Guidance update" as v5, then Sam's draft shows "Based on v4 · v5 is now current", rebases item by item with one conflict offered as "Keep mine" or "Take current", and its impact is recalculated when he publishes; reviewers saw none of his draft changes before then. Traces: D2-11, OS-A01, DH-U37; RD §9.6; DH-C105.

DH-S58 Mapping only where meaning is unchanged. Given "Risk of bias" v3 replaces "Unclear" with "Some concerns" and merges "Low" and "Very low", when Priya publishes, then she can map Unclear → Some concerns only after declaring Compatible. The merge forces Require re-answer. Declaring Not compatible disables mapping. Retired options show answer counts. The added required Q12 offers both counting choices. No Apply anyway action appears. Traces: Q-34; AC-R2c-18, 23, 28; DH-C106.

DH-S59 After publication. Given Alice completed "Risk of bias" under v2, Bob saved incomplete, Carol has a draft only and Dan's category was set to Keep as is, when v3 publishes, then:

• Alice's history shows "Version 4 · generated by publication of Risk of bias v3 · Priya Shah"; her review stops counting and she gets one notice;
• Bob gets a generated version;
• Carol's draft shows "mapped on publication" beside her original value;
• Dan still sees v2 wording marked "Answered under an earlier version" and gets no notice.

Traces: D2-01; RD §9.3; AC-R2c-07, 16; DH-C107, DH-C108.

DH-S60 History and diff. Given Route has versions 1 to 3, when Sam compares v1 with v3, then a per-field diff lists only the changed fields with each version's declaration (read-only); "Start a draft from v1" creates an Unpublished draft and v3 stays current. Traces: AC-R2c-27; DH-C109.

DH-S61 Guided correction. Given Priya mapped Unclear → Some concerns a week ago, when she starts "Correct this publication", then the preview lists 47 mapped answers, the commit publishes a new version with Q7 declared Not compatible and Require re-answer, and the original publication reads "corrected by K-2"; nothing was edited in place. Traces: D2-02 amended; RD §9.8; DH-C110.

DH-S62 A held question without relabelling. Given candidates answered Q6 under v1 and v2, which were declared Not compatible, when Erin opens the task, then only Q6 waits under the held banner, "Mark compatible" does not exist, "Ask v1 reviewers to update" sends requests without changing any standing, and Q6 is released when the v1 candidate upgrades. Traces: RD12; VM §9.2; DH-C111, DH-C41.

DH-S63 Overlapping forms. Given "Study design" and "Outcome data" both use "Species", when Alice changes her Species answer through Study design, then the form first says a new version will be created and Outcome data will show "Outdated answers". Her Outcome data session then shows that flag with Fix; Fix creates an incomplete version; a warning alone keeps her completed review counting. Traces: SF5, SF6; AC-R2d-03 to 05, 09; DH-C112.

DH-S64 Import preview equals apply. Given Sam uploads a 40-row template to the Livestock TB project, when row 14 names a parent that does not exist, then the preview names the row and the missing parent, "Add 40 questions" is disabled and nothing is created. After he fixes the file, the preview matches exactly the draft that apply creates, the receipt names that draft, and existing questions are unchanged. The same file, imported from the same editor's toolbar in the Classic-workflow project, adds 40 unassigned questions. A retry after a lost connection returns the same receipt without duplicates. Traces: AC-R1a-01 to 04; ACD-R37 to R40; H-IMP-02, H-IMP-03, H-IMP-05; DH-U41; DH-C113.

DH-S65 Copying question templates. Given the catalogue has "SYRCLE risk of bias" v1 ("Content pending methodologist review"), when Sam copies its question set, then new project questions with "copied from SYRCLE risk of bias v1" land in an Unpublished draft, and later edits on either side leave the other unchanged. Traces: D2-15; ACD §4.7; DH-C114, DH-T05.

DH-S66 Conversion keeps conditions. Given the Classic-workflow project has 12 conditional questions, one of which has 4 stored values with no matching option, when Priya opens the conversion wizard, then the mapping shows "12 conditional questions kept" and a finding for that question with a remedy, and approval waits for its disposition. After conversion, questions show v1 with "Earlier wording not recorded in legacy" and affected answers show "Wording at the time unknown". Traces: OS-A15; BC-R07, BC-R42, BC §3.2; harvest A-N1; DH-C115.

DH-S67 Designing on a tablet and a phone. Given Sam uses a 768 px tablet with touch, when he reorders by drag and by "Move down", composes a form and publishes it, then every step works without native drag. On a 1,440 px desktop the editor opens beside the compact tree. On a 390 px phone the same functions are reachable in one column (list, then editor, then back) with no horizontal page scroll, and no formal phone acceptance gate applies. Traces: DH-U12, DH-U35; AC-R1a-12; UX A2, UX-R49; DH-C116.

DH-S68 Required by default. Given Sam adds "Allocation concealment" and "Housing notes" to the "Risk of bias" draft, when he opens form composition, then both show Required; he opens Advanced settings for "Housing notes", sees "Reviewers can skip this without saying why", makes it Optional, and the form summary reads "1 optional question". Traces: required by default (Chris, 6 October 2026); RD-R49; RD-AE39; DH-C121.

DH-S69 Reasons no value is provided and the metadata grid. Given Sam edits Q13 "Was allocation concealed?" (Yes, No, Unclear), when he opens "Reasons no value is provided", then Not reported, Not applicable and Unable to assess are offered; he adds the "SYRCLE risk of bias" set from the catalogue ("Content pending methodologist review"), which shows "copied from SYRCLE risk of bias v1", while Unclear stays an option with its explanation; in the metadata grid he sets Comment Required for Unable to assess and Evidence quote Allowed for any value; no Unanswered column appears, because Q13 is Required. Traces: required by default, configurable answer metadata and the answer terminology (Chris, 6 October 2026; DH-U42); RD-R50, RD-R52; RD-AE42, RD-AE45; DH-C119, DH-C120.

DH-S70 A reviewer cannot assess a question. Given Q13 is Required with Not reported and Unable to assess, and a Comment required for Unable to assess, and Q14 is Optional with an "Other, please specify" option, when Alice opens Q13's reasons (illustrative wording "No value to enter"), chooses Unable to assess and presses Save progress, then the checkpoint saves with "Needed to complete" on the comment; at Complete SyRF names Q13 ("Add a comment for Unable to assess"); she writes "Methods section missing from the PDF" and completes. Bob answers Q14, then uses Clear answer; his history shows "answered, then cleared", and he completes with Q14 unanswered. Carol chooses Q14's "Other, please specify" and types "Sealed envelopes": the text sits inside her answer, not among the metadata fields, her answer status reads answered with a value, and history keeps the Other option with its text. Traces: DH-U42; RD §9.11; RD-R51 to RD-R53; RD-AE40, RD-AE42, RD-AE43; DH-C122.

DH-S71 Comparing reasons no value is provided. Given Alice answered Q13 Unable to assess and Bob answered Not reported, and Bob left Q14 unanswered, when Erin reconciles, then Q13 shows the two different reasons as disagreeing, and Q14 shows "Not compared (unanswered)" for Bob, which is not a disagreement. Traces: Q-04, DH-U42; RS-R14, RS-R15; RS-AE08; DH-C123.

DH-S72 Converted optional questions and the upgrade offer. Given the Classic-workflow project has 6 optional questions, 120 answers holding only empty text and an option "Not reported" on Q9, when Priya converts it, then the 6 questions show "Optional (kept from legacy)", the 120 answers show as unanswered, and Q9's "Not reported" is still an option; later the redesign wizard offers "6 optional questions could be made required, with reasons no value is provided such as Not reported and Unable to assess"; she upgrades 4, and the publication preview asks whether earlier completed reviews still count. Traces: required by default, item 5 (Chris, 6 October 2026); BC-R49, BC E12; BC-AE37; DH-C124.

DH-S73 Training guidance before the attempt. Given Priya binds guidance version 1 (a two-page screening guide and a link to the protocol) to the training step, asks trainees to confirm "I have read this" and keeps it visible during attempts, when Tom opens the training step, then he sees the guide first and "Start attempt" stays disabled until he confirms; during the attempt the guide opens from a side link; when Priya publishes guidance version 2, Tom's attempt keeps version 1. The guidance carries a "To be decided" chip. Traces: TI §3.10, TI-R37 (PROPOSAL); TI-AE26; DH-C125, DH-U43.

DH-S74 A reference question round trip (Later release). Given Sam adds "Housing location" to the cohort type, targeting Location records, several allowed, same population, with Not reported, when Alice records the Location records Farm A and Farm B on Study 12 and selects both for the cohort "Female", then the chips show "Farm A" and "Farm B" with their population; renaming Farm A to "Farm A (north)" changes the chip only, and history shows "Farm A" at the earlier version. Traces: CPR §3.4, CPR-R15 to CPR-R19; CPR-AE10; DH-C126, DH-C127.

DH-S75 Deleting a referenced record (Later release). Given Alice's cohort "Pregnant" references Farm A in "Housing location", when she starts to delete Farm A, then the dialog lists "Referenced by: Pregnant · Housing location; Farm A animals · criteria", and she cancels; on another Study, Bob deletes a Location that a cohort references, the cohort's answer shows "Refers to a deleted record", and Complete names the question until he picks another location or Not reported. Traces: CPR §9.3, CPR-R20; CPR-AE13; DH-C128.

DH-S76 Matching records before comparing references (Later release). Given on Study 12 Alice recorded Farm A and Farm B and Bob recorded "Farm 1", "Farm 2" and "Pasture", when Erin reconciles under blinding, then SyRF suggests Farm A with Farm 1 and Farm B with Farm 2 (sizes match, labels differ); she confirms both and marks Pasture distinct; the two "Housing location" answers then agree; her accepted answer picks the reconciled "Farm A"; neither reviewer's name appears. Traces: MG1; CPR §9.4, CPR-R32 to CPR-R34; CPR-AE19, CPR-AE20; DH-C129.

DH-S77 Populations, coverage and set annotations without inference (Later release). Given the inference beta is off, when Alice records on Study 12 the whole population's size, 120, quoting page 3; the cohorts "Farm A animals" (complete, 70) and "Farm B animals" (complete, 50), with "share no animals" and "together cover the population" as two reported statements; and an age set, Young and Adult, then each statement shows its evidence, nothing is inferred, a cohort with no recorded size shows "Size not reported", and no screen or export shows 240. Traces: populations direction (CPR §3.3); CPR-R10 to CPR-R14, CPR-R23 to CPR-R26; CPR-AE01, CPR-AE03, CPR-AE04; RI-R62; DH-C16, DH-C18.

Totals. 77 scenarios. The largest-form phone scenario is DH-S04. DH-S51 was added on 5 October 2026 (evening) for D2-09's decision, and DH-S52 to DH-S67 later that evening for question management (renumbered from the gap report's DH-S51 to DH-S67, whose D2-09 scenario DH-S51 already covers). DH-S68 to DH-S77 were added on 6 October 2026, and DH-S21 was amended the same day. Later on 6 October 2026, for Chris's design-handoff answers, DH-S21, DH-S30, DH-S39, DH-S52, DH-S56, DH-S57, DH-S64, DH-S67 and DH-S69 to DH-S72 were amended in place; no scenario was added or removed.

11. Explicitly unresolved design inputs

Before the pack is sent, these inputs and items are settled through open questions before the Claude Design handoff, which sorts them into questions to answer first (class A), questions the pack can carry as options (class B) and items that are not design questions (class C). An answered input is then marked "Decided (DQ-nn, date)" here, as DH-U27 is.

11.1 Genuine open inputs (options and a recommendation)

Show each as a visible "To be decided" chip where it appears, using the recommended option as the default only where the prototype must show something. Exceptions: DH-U27 is "Decided (D2-09, 5 October)"; build it as section 5.5 describes, with no chip. DH-U19 and DH-U38 were decided on 6 October 2026 (DQ-31 and DQ-05); build them as sections 5.15 and 5.24 describe, with no chip. DH-U12, DH-U21, DH-U35, DH-U37, DH-U41 and DH-U42 were decided later the same day (DQ-04, DQ-09, DQ-02, DQ-03, DQ-01 and DQ-46). Build them with no chip: DH-U12 as section 7.1 describes, DH-U21 as sections 5.21 and 5.26 describe, DH-U35, DH-U37 and DH-U41 as section 5.22 describes, and DH-U42 as sections 3.2 and 5.24 describe.

ID	Question	Options	Recommendation	Source
DH-U01	Default target-one handling for new forms	(a) Accept automatically; (b) Require human reconciliation; © no default, choose at creation	(a), visibly chosen in templates	RS §12
DH-U02	Does a reviewer's own Unsure let them progress like an own Include?	(a) Yes for own progression, never for team Include; (b) treated as no decision; © per-profile setting	(a)	RS-R47, RS §12
DH-U03	Result when every decision is Unsure	(a) Adjudication; (b) a collective "Unsure (not excluded)" result; © further review beyond the bound (ruled out by the owner)	(a), with (b) only as an explicit per-profile option if Chris approves it	RS §5.10
DH-U04	Where the "started work after leaving the pool" restriction lives	(a) One stage setting; (b) a step setting; © stage default with step restrict-only override	©, shown together with saved work as "Finishing work already started"	SP-AMB-01
DH-U05	Where reviewer-pool browsing is configured	(a) Stage setting; (b) step; © form; (d) project	(a), off by default	SP §3.6
DH-U06	Are answers filled from a single candidate (one-candidate tasks; kept one-sided items)?	(a) Fill with the autofill marker and the unseen-control warning; (b) leave empty with click-to-copy pills; © per-form setting	(a) for one-candidate checking tasks and kept one-sided items, owner-visible	RD2 (decision register)
DH-U07	How the interface tells a reviewer that copying a hint makes the answer informed	(a) Inline label on each hint plus a session note; (b) a one-time interstitial before the first hint; © both	(a), because hints are shown by default and exposure is recorded automatically; validate with users	VS2; UX strategy §7.3
DH-U08	Does a blinded adjudicator see that a decision came from an AI screening model?	(a) Always; (b) hidden when blinded; © profile setting	©, defaulting to showing the source type	RI A2
DH-U09	Per-step Skip in addition to study-level Skip	(a) Study-level only; (b) per-step Skip or handoff; © both	Keep (a) as default and prototype (b) as a variant for testing	RC6; validation U2
DH-U10	Population context placement	(a) Header chip; (b) first category tab; © source card	(a), tested against normal tabs and numbering	RC8; validation U3
DH-U11	Holding edits on the device during a connection loss	(a) Bounded in-session holding, cleared at logout, completion and access loss, replayed only if the base still matches; (b) memory only; © none until the PWA design	(a), described as connectivity resilience	UX A1
DH-U12	Reconciliation and admin screens on phones	(a) Phone acceptance for reconciliation; (b) usable narrow layout with no feature removed, no phone acceptance gate; © desktop only	Decided (DQ-04, 6 October 2026): (b): usable, responsive phone layouts for reconciliation, question-design and admin screens with no feature removed, without a formal phone acceptance gate; the screening and annotation device acceptance requirements stay as they are (section 7.1)	UX A2
DH-U13	May a merge commit while some conflicts are still pending?	(a) Never; (b) by explicit choice, holding the conflicting contribution out of current counts until resolved	(a) for the MVP, because the owner said resolution precedes commit; revisit after pilots	DM §12 ambiguity 1
DH-U14	Identity of the consolidated Study	(a) New identity (inputs tombstoned); (b) one input survives	(a)	DM §3.10
DH-U15	Can a contribution exclusion be lifted?	(a) Yes, as a separate recorded action with preview; (b) no	(a)	ACD B2
DH-U16	Who sees and restores deleted projects	(a) Owner and Delete holders for their projects, plus application administrators; (b) application administrators only; © owner only	(a)	ACD B4
DH-U17	Copying a definition from another project outside the catalogue	(a) Keep, with the same provenance; (b) catalogue only	(a)	ACD B5
DH-U18	Default email content for answers and free text	(a) Off; (b) on	(a), because sent email cannot be recalled	ACD B6
DH-U19	Training feedback default	(a) Per-item correctness after assessment, reference answers after a pass or when no retry remains; (b) score only; © full references after submission	Decided (DQ-31, 6 October): (a), as recommended (section 5.15)	TI-R10
DH-U20	Can a live step depend on passing a training step?	(a) Group admission only; (b) also an explicit step dependency	(a) for now; show (b) as "To be decided"	TI-R23
DH-U21	Scope of the inference beta (the S5 amendment: the "advanced classification/rule/inference capability" starts in beta)	(a) The beta covers rule authoring, rule evaluation and inference results; explicit cohort recording (lane C1) follows its own enablement; (b) the beta also gates cohort recording; © the classification specification's proposal: rule authoring and publication in C1, outside the beta, and only rule evaluation and inference in it	Decided (DQ-09, 6 October 2026): (a): rule authoring and publication, rule evaluation and inferred results need the project's explicit beta opt-in; ordinary annotation and explicit group or classification recording (lane C1) follow their own availability and never need it; © is not adopted (sections 5.21 and 5.26)	TI §12; CPR §12 item 4; DQ-09
DH-U22	How converted single-reviewer forms behave	(a) "Single annotator, not accepted": no accepted results, no reconciliation work; (b) accept automatically at conversion; © admin chooses per form	(a)	RS-R04a, BC A1
DH-U23	Legacy screening meaning when no admin confirms	(a) Convert labelled "meaning not confirmed" with no PRISMA phase; (b) block; © operator confirms	(a)	BC A2
DH-U24	Can a project admin defer a scheduled conversion wave?	(a) One bounded deferral with a reason; (b) none	(a); never permanent	BC A4
DH-U25	When the sole candidate completes again after a correction under Accept automatically	(a) The rule writes the next Single annotator version; (b) the earlier version stays, flagged, until someone re-accepts	(a)	RS §12
DH-U26	Offer "suspend" for results below a raised target?	(a) Offer keep (default) and suspend; (b) keep only	(a)	RS-R10, RD §4.9
DH-U27	Accepted answers to a question shared by two forms (owner decision D2-09)	(a) The second form's reconciler may revise with a new snapshot; (b) the first publisher wins and others use queries	Decided (D2-09, 5 October): (a), with an optional reason prompt and a Raise a query action, and the existing answer shown as a hint, never prefilled (section 5.5)	RD §4.14; T-OI-01
DH-U28	Do accepted-answer filter clauses count Single annotator results?	(a) Any authority; (b) human-reconciled only; © any by default with an optional restriction	©	SP-AMB-02
DH-U29	Owner of timeout, limit and capacity for screening-only work	(a) Profile; (b) stage; © project	(a)	SP-AMB-03
DH-U30	Names for project modes	(a) "Classic workflow" and "Versioned workflow"; (b) other wording after card-sort testing	(a) as working labels	UX strategy §3.3
DH-U31	Exclusion on classic projects	(a) Converted projects only; (b) also classic projects	(a)	ACD B7
DH-U32	Mixed route provenance under stage-scoped exclusion	(a) Admin chooses per group; (b) decide by the current version's route; © per answer	(a), with (b) as the suggested choice	ACD B3
DH-U33	Notices for a deleted project	(a) Leave unread counts and show "Project deleted", returning on restore; (b) unchanged	(a)	ACD B8
DH-U34	What the "Later release" badge on accepted-answer clauses in stage filters says about timing (they stay in scope; whether they ship inside GA is open)	(a) "Later release" alone, naming no release; (b) "Later release · inside GA scope" (an increment shipped after the first reconciliation release); © "Later release · after GA"	(a) until Chris confirms the timing	Rollout plan R-AMB-02; SP §3.3
DH-U35	Where the question editor opens	(a) Inline inside the tree node (today's editor); (b) a side panel beside a compact tree (the earlier prototype's layout, v10 c2); © a side panel at 1,240 CSS px and wider, and a drill-in page below that	Decided (DQ-02, 6 October 2026): ©: a compact question list or tree with the editor beside it on wide screens, and a separate drill-in editor page on narrow screens. No numeric breakpoint is approved: the 1,240 CSS px in option © is a design detail to validate with users (section 5.22)	H-WEB-03, H-WEB-05; section 5.22; UX §3.13
DH-U36	What the first form shows after another form's reconciler revises a shared accepted answer (D2-09). The value is the revised one (DH-S51); this input is about the label, the notice and the first form's task state	(a) The new value labelled "Revised through Outcome data by Chloe" (the name only for members with history access), plus an in-app notice to the first form's reconcilers; (b) the label only, with no notice; © the first form's task moves to "Inputs changed" and needs a reconciler	(a): affected authors are informed without their work being rewritten (Q-27); © creates work the owner did not ask for	D2-09; RD §4.14, RD-R10; AC-R2d-08
DH-U37	How design edits are kept in a draft	(a) Each field change is kept in the draft as the designer types, with an "Unpublished · saved 14:03" status; (b) an explicit per-question "Keep changes" into the draft (like today's per-node Save)	Decided (DQ-03, 6 October 2026): (a): accepted field changes save automatically into the unpublished design draft, with a clear save status, safe conflict handling and "Discard changes" per question; saving a design draft never publishes to reviewers (section 5.22)	RD §3.7, §4.7; UX §3.8
DH-U38	Where requiredness is set in Versioned projects	(a) Per form only; (b) a question-level default copied when the question is added to a form, with the form's setting authoritative	Decided (DQ-05, 6 October), by Chris's required-by-default answer: form-level Required default: per form, with Required as the default for every newly added question and Optional only under Advanced settings, with a warning (section 5.24). The reading that a separate question-level default (option (b)) is not needed is to be confirmed in the Codex session (DQ-05). Whether an import row's requiredness sets the pin is a brief detail	VM §4.1; ACD §3.11; RD-R49
DH-U39	Changing a question's parent or entity type (an identity change)	(a) Always refused, offering "Copy to …" (a new question that records it was copied) and optional retirement of the original; (b) free moves for a never-published question, and copies only for a published one	(b): a never-published question has no answers or versions to lose	VM §3.1, §3.5, §3.8; C4 identity
DH-U40	Where question import starts	(a) The Questions and entity types toolbar; (b) inside the Catalogue; © both	(a): an import copies into one project, while the Catalogue is application-wide and administered	H-IMP-05; ACD §3.4, §3.11
DH-U41	What a Classic-workflow project's question editor is (owner question QMI-04)	(a) The same editor as Versioned projects, saving directly as today: no versions, drafts or presence, Required per question, per-stage Assign, the answered-question lock ("Answered: locked (Classic)", section 5.22); the older "Question design" page retires after one staging soak; (b) today's older "Question design" page, restyled, until the project converts or legacy writers retire	Decided (DQ-01, 6 October 2026): (a): one refreshed editor for Classic and Versioned projects, with the saving and assignment behaviour of each mode; it never adds versioned publication, draft or assignment behaviour to an unconverted project. When the older page and its switch retire (T-RD-17) is not decided (section 5.22)	UX §3.13, UX-R46; C17; QMI-04
DH-U42	How answers and the explicit "no value" answers (working term "no-value answer", now retired) are named (Chris asked for the naming to be thought again, 6 October 2026: "Should reduce ambiguity and be intuitive!")	(A) An answer is anything recorded, a value or an explicit "no value" answer with its reason; "option" means only a choice's predefined option; unanswered means nothing recorded; an unanswered comparison reads "Not compared (unanswered)"; "blank" and "response mode" never appear on screen; (B) "missing-data codes"; (C) "answer exceptions" (options as asked)	Decided (DQ-46, 6 October 2026), with revised terminology: Answer status for the overall state; reason no value is provided for the configured reasons; Other, please specify is a value-bearing answer; "No value to enter" is illustrative wording for the reviewer's action; Unanswered, Option and "Not compared (unanswered)" are carried from (A) (sections 3.2 and 5.24)	RD §12; DQ-46
DH-U43	Guidance for trainees before an attempt (Chris's question, 6 October 2026)	(a) Versioned guidance on the training step, shown before the attempt, with an optional "I have read this" confirmation and a policy choice on visibility during the attempt; (b) guidance always visible, with no confirmation; © no guidance on the step	(a)	TI-R37; DQ-47
DH-U44	Custom reference questions: needed at the first general release or with lane C1, and which target types	Timing: (a) with C1, not a GA prerequisite; (b) before GA as its own slice. Targets: (a) named records only; (b) named records plus configuration records (shared-concept and rule versions); © (b) plus records in other Studies and source regions	Timing (a), unless a GA form needs one; targets (b); show the answer type with the "Later release" badge and a chip	CPR §10.2, §12 items 1 and 2; DQ-48

Totals. 44 inputs (DH-U01 to DH-U44): 35 open and nine decided. They are DH-U27 (Decided (D2-09, 5 October)), DH-U19 (Decided (DQ-31, 6 October)) and DH-U38 (Decided (DQ-05, 6 October)), and, from Chris's design-handoff answers, DH-U41 (Decided (DQ-01, 6 October 2026)), DH-U35 (Decided (DQ-02, 6 October 2026)), DH-U37 (Decided (DQ-03, 6 October 2026)), DH-U12 (Decided (DQ-04, 6 October 2026)), DH-U42 (Decided (DQ-46, 6 October 2026)) and DH-U21 (Decided (DQ-09, 6 October 2026)). DH-U35 to DH-U41 were added on 5 October 2026 (evening) for question management, and DH-U42 to DH-U44 on 6 October 2026.

Open items with a chip but no DH-U entry (added 5 October 2026). Three behaviours this document describes are still open owner confirmations. Show each as described, with a "To be decided" chip: the self-reconciliation override (section 5.5 "Who may reconcile", the §6.2 row and DH-S23; DQ-20), the treatment of Study-specific target overrides at a target-only publication (section 5.9 and DH-S27; DQ-11) and the scope of conversion-wave approvals (section 5.10 step 6; DQ-44). The DQ IDs are in the open questions before the design handoff.

11.2 Items the prototype must show as "To be decided" and never invent

ID	Item	How to show it
DH-T01	Every numeric threshold (timeouts, limits, caps, bounds beyond the owner's example, pass marks, weights, parity figures)	Example values labelled "Example, not approved", or empty fields
DH-T02	PRISMA box mapping (T-SI-05)	Measures with their own labels; "Mapping to be decided"
DH-T03	Agreement methods beyond percent agreement (T-SI-02)	Kappa and multi-rater figures marked "Method pending statistical review"
DH-T04	Event-count schema fields and "variation" (T-SI-01)	"Fields to be decided"
DH-T05	SYRCLE, CAMARADES and ARRIVE template content (T-SI-03)	Names only, "Content pending methodologist review"
DH-T06	ASySD parity method and figures (T-SI-04)	No figures
DH-T07	Exact capability names and the default grant matrix	Working names, marked "name to be confirmed"
DH-T08	Final status wording	Illustrative labels; the three meanings fixed
DH-T09	Publication pause and queued-retry messages for reviewers	A neutral "This form is being updated. Your changes are kept." with "To be decided" on retry behaviour
DH-T10	Outcome-schema upgrade flow	"To be decided"
DH-T11	Unsure rows the owner did not state (in-flight decisions, four or more, other thresholds, larger bounds)	"To be decided" in the transition table
DH-T12	Legal text for joining terms and account deletion	Placeholder text marked "Legal review required"
DH-T13	Which admin transitions need an extra explicit confirmation beyond the impact preview	Use the impact preview only
DH-T14	Hints for repeatable entity instances (deferral is a PROPOSAL, RS-R37)	Absent, with a "Not in MVP" note in help
DH-T15	A full global landing page	Absent
DH-T16	Permanent erasure, identity erasure, automatic multi-candidate acceptance	Absent; never offered
DH-T17	Bulk reassignment of reconciliation assignments	Absent
DH-T18	Match-based training scoring for repeatable entities	Manual assessment only
DH-T19	Lookup questions in a question import (remapped, or refused until a remap exists; an R1a brief item, ACD-R41). 6 October 2026: the classification specification proposes that lookup rows stay refused until lane C1 (CPR-R22)	A refused-row example reading "Lookup questions: to be decided"
DH-T20	How agreement statistics count reasons no value is provided (T-SI-02)	"Method pending statistical review" on agreement figures for reasons no value is provided
DH-T21	Which default reasons no value is provided a new question starts with, and where the count of optional questions appears beyond the form summary (RD §12 brief details)	All three defaults offered, with none shown as a decided preselection; the count on the form summary only
DH-T22	The source-location format of an evidence quote (E37, with the PDF viewer's anchors)	"Page and quote", with "Location format to be decided"
DH-T23	Turning an existing option, such as a legacy "Not reported", into a reason no value is provided (not offered in the MVP, RD-R54)	Absent, with a "Not in MVP" note in the redesign wizard

Totals. 23 items (DH-T01 to DH-T23). DH-T19 was added on 5 October 2026 (evening), and DH-T20 to DH-T23 on 6 October 2026.

12. Traceability

Decision ID → specification sections → prototype changes → acceptance scenarios. OS-A IDs are listed in section 1.8 and defined in the owner-session integration.

Decision	Specification sections	Prototype changes	Scenarios
Q-12 step selector with one form area	UX §3.1, UX-R01 to R03	DH-C45, DH-C53	DH-S01
D3-03 with U1 amendment (OS-A21)	UX §3.2, UX-R11 to R15; RD §3.10, §4.2 to §4.4	DH-C10, DH-C46, DH-C54, DH-C76	DH-S02, DH-S04
D3-04 sentence case	UX-R14; UX strategy §4.2	DH-C08, DH-C117	DH-S48
D3-05 phones, tablets, desktops	UX §3.3, UX-R04 to R10; UX §3.13, UX-R49	DH-C52, DH-C59, DH-C77, DH-C116	DH-S04, DH-S67
DQ-04 reconciliation and design screens on phones, no formal phone gate (decided 6 October 2026)	UX §12 A2, UX-R49; UX §3.13	DH-C77, DH-C116; DH-U12 (decided)	DH-S67
D2-16 largest project as acceptance case	RD-R33; UX-R07; BC-AE16	DH-C60, DH-C87	DH-S04, DH-S36
D3-06 legacy refresh (OS-A23)	UX §3.4, UX-R16, UX-R17	DH-C13	DH-S47
U2 PWA beyond MVP (OS-A22)	UX §3.11, UX-R38 to R40	DH-C46	DH-S49
D3-07 My work, tab, badge	UX §3.5, UX-R18 to R23	DH-C12, DH-C14, DH-C79	DH-S40
D3-08 tester panel, consent telemetry	UX §3.6	None in this iteration (a consent card is optional)	None
D3-20 presence disclosure	SP §6, SP-R73; UX-R37	DH-C40, DH-C67	DH-S13
D3-22, D3-24, D3-25 email (OS-A26)	ACD §3.5 to §3.8, ACD-R24 to R29	DH-C91	DH-S40, DH-S41
D3-23 notice resolution	ACD §3.7, ACD-R32	DH-C79, DH-C91	DH-S40
Q-15 stage study filter (replaced)	SP §3.3, SP-R01 to R12	DH-C34, DH-C35	DH-S10, DH-S16, DH-S50
Q-01 progression basis	SP §3.4, SP-R15 to R18	DH-C36	DH-S09
Q-02 completed stages	SP §3.10, SP-R76 to R80	DH-C39, DH-C96	DH-S16
Q-24 independence, legacy mapping, Apply anyway	SP §3.4, §7, SP-R21, SP-R24, SP-R74	DH-C36, DH-C84	DH-S10, DH-S31
Q-28 shared-form rules	SP §3.11, RS §5.7	DH-C28, DH-C36, DH-C38, DH-C48	DH-S05, DH-S06, DH-S07
Q-30 defaults, aliases, expiry	RS §5.6, §5.14	DH-C27, DH-C41, DH-C68	DH-S07, DH-S19
OS-A02, OS-A03 blinding and ordering	RS §3.5, RS-R24 to R30	DH-C21, DH-C27, DH-C68	DH-S19
OS-A04 hints and click-to-fill	RS §3.6, §4.7, RS-R31 to R38	DH-C36, DH-C56	DH-S07
OS-A05, OS-A06 continuation and self-departure	SP §3.9, §4.2, SP-R32 to R38	DH-C36, DH-C62, DH-C80	DH-S11, DH-S12
OS-A07, OS-A08, OS-A10 history and explanation	SP §3.5, §3.14; UX §3.7	DH-C44	DH-S15
OS-A09 pool coverage and reporting priority	SP §3.13; RI §3.3	DH-C40, DH-C95	DH-S15
OS-A11 structured events	SP §3.12, §3.13	DH-C07, DH-C44	DH-S16
OS-A27 and D4-19 browsing	SP §3.6, SP-R53 to R59	DH-C38, DH-C80	DH-S14
Q-29, D4-03 target one (OS-A28)	RS §3.2, §5.1, RS-R01 to R08	DH-C27, DH-C71, DH-C75	DH-S17, DH-S18
Q-36 self-reconciliation	RS §5.4, RS-R17, RS-R18	DH-C82	DH-S18, DH-S23
Q-11 bulk acceptance	RS §5.5, RS-R21 to R23	DH-C28, DH-C29, DH-C41	DH-S22
Q-04 completeness, unanswered questions (comparison wording amended 6 October 2026, terms decided by DQ-46)	RS §5.3, RS-R13 to R16	DH-C27, DH-C69, DH-C123	DH-S21, DH-S71
D4-17 outdated answers	RS §5.8, RS-R39 to R42	DH-C27, DH-C57	DH-S08
D4-01, OS-A16 Unsure	RS §5.10, RS-R46 to R49	DH-C21, DH-C55, DH-C66	DH-S24
OS-A13 tie adjudication and assignment	RS §3.9, §5.11, RS-R50 to R59; SP-R91, SP-R92	DH-C21, DH-C22, DH-C72, DH-C81	DH-S25
Q-32 adjudication rationale	RS-R56	DH-C21, DH-C81	DH-S25
D4-02 discussion	RS §5.12, RS-R60 to R64	DH-C21, DH-C81	DH-S26
Q-22, D4-13 primary reason (OS-A17)	RS §5.13, RS-R65 to R67	DH-C21, DH-C55	DH-S24
OS-A12 target versions the form	RD §3.5, §4.9, RD-R12 to R17	DH-C26, DH-C32, DH-C85	DH-S27, DH-S32
D2-01 generated session versions	RD §3.15, RD-R23	DH-C32, DH-C50	DH-S28
D2-02, Q-34 compatibility and mapping	RD §3.4, §4.13, RD-R20, RD-R21	DH-C32, DH-C106, DH-C110, DH-C111	DH-S28, DH-S58, DH-S61, DH-S62
D2-05 setting classification	RD §3.5	DH-C27, DH-C28	DH-S27
D2-07, D2-08 shared session and place	RD §3.10, §3.11, RD-R11	DH-C48	DH-S05, DH-S06
D2-11, OS-A01 collaborative drafts	RD §3.7, §4.7, RD-R25, RD-R26, RD-R45; UX §3.8	DH-C31, DH-C105	DH-S30, DH-S57
DQ-03 design edits saved automatically into the draft (decided 6 October 2026)	RD §3.7, §4.7; UX §3.8	DH-C31, DH-C105, DH-C117; DH-U37 (decided)	DH-S30, DH-S57
Q-26 profile publication	RD §4.12, RD-R27	DH-C24	DH-S29
Q-27, Q-20 dependent work and alerts	RD §4.5, RD-R10, RD-R28	DH-C47, DH-C75	DH-S03
D2-09 shared-question accepted answers (decided 5 October 2026)	RD §4.14, RD-R37; RS-R32, RS-R33	DH-C99, DH-C98; DH-C02 (listed as resolved, DH-U27)	DH-S51
D2-12 replaced, OS-A29 merge and unmerge	DM §3, §4, DM-R01 to R24	DH-C86	DH-S33, DH-S34
Q-37 deduplication	DM-R21; RI-R48	DH-C86	DH-S33
R4 direction, OS-A14, OS-A15; Q-05, Q-21, D4-16	BC §3.4, §4.3, §10.3; BC-R42	DH-C13, DH-C87, DH-C115	DH-S35, DH-S36, DH-S66
D4-04, OS-A18 training	TI §3.1 to §3.6, TI-R01 to R23	DH-C89	DH-S38
Training does not gate GA; DQ-31 feedback default (both decided 6 October 2026)	TI §10; TI-R10	DH-C89	DH-S38
Training guidance before the attempt (PROPOSAL; open, DQ-47)	TI §3.10, TI-R37	DH-C125; DH-U43	DH-S73
Q-18, Q-19, OS-A19 inference beta; DQ-09 its scope, rule authoring inside it (decided 6 October 2026)	TI §3.7 to §3.9, TI-R24 to R36; TI §12; CPR §3.7	DH-C15, DH-C18, DH-C19, DH-C90; DH-U21 (decided)	DH-S39, DH-S77
D4-15 step branching (deferred)	SP-R25	DH-C34 (no branching)	DH-S50
D4-08, Q-23 report grouping (deferred)	RI-R01 to R03	DH-C95 (no grouping action)	DH-S50
E3 AI expansion, D4-14, OS-A20	RI §3.11 to §3.14, RI-R32 to R47	DH-C23, DH-C93	DH-S44, DH-S45
D4-05 methods and amendments	RI §3.6, §3.7, RI-R19 to R22	DH-C24	DH-S29
D4-10 estimated from graph	RI-R28	DH-C52	none
Q-06b, Q-33 reporting units and withdrawal	RI §3.1, §3.5	DH-C95	none (Later release)
D2-14 account deletion	ACD §3.1, ACD-R01 to R05	DH-C94	DH-S46
D4-20, OS-A24 contribution exclusion	ACD §3.2, §4.3, ACD-R04 to R13	DH-C82, DH-C83	DH-S43
D3-12, OS-A25 reversible deletion	ACD §3.3, §4.5, §4.6, ACD-R14 to R19	DH-C62, DH-C92	DH-S42
D2-15 catalogue	ACD §3.4, ACD-R20 to R23	DH-C88, DH-C114	DH-S37, DH-S65
Consolidation §6 active-work previews	ACD §3.10, §7, ACD-R33 to R36; UX §3.9	DH-C84	DH-S31
RE2, RE5 reconciliation acceptance and free text	RS §4.4	DH-C69	DH-S20
RE4 shared reconciliation task	RS §3.1	DH-C41, DH-C42	DH-S17
SF4/RE3 all qualifying candidates	RS §3.5	DH-C68, DH-C73, DH-C74	DH-S19
MG1 match suggestions	RS (unchanged); ledger MG1	DH-C30, DH-C73	DH-S19
RA1 to RA5 assignment and additional review	RS §5.14; RD §4.11	DH-C41, DH-C85	DH-S32
DP2, DP3, DP4, DP5 screening ownership	RS §3.7; ledger	DH-C20, DH-C25, DH-C55	DH-S24
VU1 to VU3, SF5, SF6 Needs updating and Fix	RD §3.15; RS §5.8	DH-C57	DH-S08
PM1, PM2, Q-03 groups and grants	ACD §6; ledger	DH-C82	DH-S23
AG1 to AG3 agreement	RI §3.16	DH-C95	none (Later release)
QY1 to QY9 queries	Ledger; contracts	DH-C98	none (Later release)
Q-13 naming ("Design", "question templates"; "Library" only for Study Management)	UX §3.13, UX-R50	DH-C11, DH-C100, DH-C117	DH-S52
QD1, D2-03, D2-06 question identity, options and system questions	VM §3.1, §3.3, §3.5; RD §3.4, RD-R30, RD-R32, RD-R42, RD-R43	DH-C101	DH-S52, DH-S53
Child validity and the question tree	RD-R40, RD-R41; AC-R1a-12, AC-R2a-24	DH-C102	DH-S54
Conditional display and filtered options	RD-R38; BC-R42	DH-C103	DH-S55
SF1 form composition	RD §3.5; UX §3.13, UX-R47	DH-C104	DH-S56
D2-01 outcomes per category and per-answer states	RD §3.15; C5	DH-C107, DH-C108	DH-S59
History with a diff (AC-R2c-27)	RD §3.4; RD-R20	DH-C109	DH-S60
SF3, SF5, SF6 overlapping forms	RD §4.14 (R2d)	DH-C112	DH-S63
Question import (R1a)	ACD §3.11, ACD-R37 to R43	DH-C113	DH-S64
DP4 profile-owned questions	RD §3.6	DH-C118	none
One question editor for Classic and Versioned projects (DQ-01, decided 6 October 2026; it answers owner question QMI-04 in part, and the retirement timing T-RD-17 is not decided)	UX §3.13, UX-R46; C17; RD §4.7	DH-C101, DH-C103, DH-C104, DH-C113; DH-U41 (decided)	DH-S56, DH-S64
DQ-02 where the question editor opens (decided 6 October 2026; no numeric breakpoint approved)	UX §3.13	DH-C101, DH-C102, DH-C116; DH-U35 (decided)	DH-S52, DH-S67
Required by default with reasons no value is provided (Chris, 6 October 2026; decided-amended)	RD §3.16, RD-R49 to RD-R51, RD-R54; VM §3.4, §4.1; BC-R49	DH-C119, DH-C121, DH-C122, DH-C124; DH-C101, DH-C104 (amended); DH-U38 (decided)	DH-S68, DH-S69, DH-S70, DH-S72
Configurable answer metadata (Chris's direction, 6 October 2026)	RD §3.16, RD-R52	DH-C120, DH-C122	DH-S69, DH-S70
Recording unanswered and cleared answers (PROPOSAL; open owner item)	RD §3.16, RD-R53	DH-C122	DH-S70
DQ-46 answer terminology: Answer status, reason no value is provided, Other, please specify (decided 6 October 2026, with revised terminology)	RD §3.16, RD §12	DH-C10, DH-C119, DH-C120, DH-C122, DH-C123; DH-U42 (decided)	DH-S21, DH-S69, DH-S70, DH-S71
Custom reference questions (PROPOSAL; timing and target types open)	CPR §3.4, CPR-R15 to CPR-R22, CPR-R32 to CPR-R34	DH-C126 to DH-C129; DH-U44	DH-S74, DH-S75, DH-S76
Populations and explicit classification (lane C1; populations direction, TC1, MG1, Q-19; never behind the beta, DQ-09)	CPR §3.1 to §3.3, §3.5 to §3.8	DH-C15, DH-C16, DH-C18, DH-C65	DH-S77
OS-A30 this deliverable	This document	DH-C01 to DH-C129	DH-S01 to DH-S77

13. Copy-ready design-session handoff prompt

Chris can paste the block below into the Claude Design session that produced SyRF Prototype v10, attaching or pasting this file with it. Sending it is Chris's decision; nothing has been sent.

Hello. You produced the Claude Design handoff pack "SyRF v10: review steps, versioned forms and
reconciliation" (folder design_handoff_syrf_v10), supplied on 2 October 2026. I would like you to
iterate that prototype so it reflects every product decision made since then.

I am attaching (or pasting after this message) a specification titled "Specification:
design-prototype handoff for SyRF Prototype v10" (file design-prototype-handoff.md). Please read all
of it before changing anything. It is self-contained. You do not need, and should not assume, access
to the SyRF code repository; any repository links in it are optional extras.

SOURCE FILES. Work from the v10 pack you produced. Please confirm your copy matches these SHA-256
values; if any differs, stop and tell me before making changes:
- prototype/SyRF Prototype v10.dc.html
  1f940684e0bbd32e4b04b0e48f50ecf2d371c20ade94f51eb1e9c1e188ecdbe6
- prototype/Review Page v10.dc.html (byte-identical to Review Form v10.dc.html)
  29adb6b5cf383e5b273aaac7f8817a0c446c2dd22474b504d5231306c240bdbc
- prototype/Reconciliation Exploration.dc.html
  8daf4e3a860407691c09cf3de0602f35cd6c6429323c0cb0b9b3c7ffe261e31c
- Supporting documents: README.md, AGENTS.md, FEATURES.md, DECISIONS.md, RECONCILIATION.md,
  IMPLEMENTATION_PLAN.md, reference/stage-review-page-handoff.md, plus prototype/_ds/, support.js and
  assets/ (runtime only).
Keep the v10 files unchanged. Save your work as new files (for example "SyRF Prototype v11.dc.html"
and "Review Page v11.dc.html").

ITERATION GOALS.
1. Apply every change in section 9 (DH-C01 to DH-C129) of the specification.
2. Make every acceptance scenario in section 10 (DH-S01 to DH-S77) walkable in the prototype, and
   replace the Guide with them.
3. Keep the distinction between "Draft auto-saved", "Version checkpoint saved" and "Complete"
   visible everywhere (section 5.1). The words are illustrative; the meanings are fixed.
4. Show full screening and annotation on phone (390 px), tablet (768 px) and desktop (1,440 px),
   including a synthetic 2,023-question form with virtual scrolling and whole-form validation.
   Reconciliation, question-design and admin screens also get usable, responsive phone layouts with
   no feature removed; they have no formal phone acceptance gate (decided, DH-U12; section 7.1).
5. Show every open item in section 11 as a visible "To be decided" chip, never as a decided behaviour.
   DH-U27 is no longer open: it was decided on 5 October 2026 (D2-09), so build it as section 5.5
   describes, without a chip. DH-U19 and DH-U38 were decided on 6 October 2026: build them as
   sections 5.15 and 5.24 describe, without a chip. DH-U12, DH-U21, DH-U35, DH-U37, DH-U41 and
   DH-U42 were also decided on 6 October 2026: build them as sections 7.1, 5.21, 5.22, 5.24 and 5.26
   describe, without a chip. Three open items have a chip but no DH-U entry (section 11.1): the
   self-reconciliation override (sections 5.5 and 6.2, DH-S23), the treatment of Study-specific
   target overrides at a target-only publication (section 5.9, DH-S27) and the scope of
   conversion-wave approvals (section 5.10 step 6).

QUESTION MANAGEMENT (new in this revision of the specification; sections 5.22, 5.23 and 9.12).
6. Apply section 9.12 (DH-C100 to DH-C118) and make DH-S52 to DH-S67 walkable. Question management
   is the admin's work of authoring questions, composing annotation forms from them, and publishing
   new versions without corrupting earlier reviews. Design these surfaces:
   - Design > Questions and entity types: the project's questions, one tree per entity type with
     numbering identical to the reviewer page, version chips and lifecycle states, "Used by",
     search and filters. Reusable items are "question templates" in the Catalogue. "Library"
     belongs only to Study Management, so replace v10's "question library" wording.
   - The question editor: options keep their identity (rename keeps meaning; retire; replace for a
     meaning change); requiredness is set per form, Required by default (section 5.24); repeated
     answers are fixed at creation; system questions are read-only; published questions are
     retired, never deleted. It opens beside a compact question list or tree on wide screens and
     as a separate drill-in page on narrow screens, never inline inside a tree node (decided,
     DH-U35). No width threshold is decided: label any width you use "Example, not approved".
   - Conditional display chosen by parent option, and filtered options per parent option.
   - Child-validity warnings that name parent, child and option, and a "Show for new option?"
     choice.
   - Form composition with two trees (ancestors added automatically; Required by default and
     Optional only under Advanced settings, per form) and a list of Unpublished drafts with rebase.
   - Collaborative drafting: presence avatars, "editing" markers, live updates that never
     overwrite local typing, same-item conflicts with "Keep mine", and author and time on every
     change. Accepted field changes save automatically into the Unpublished draft, with one quiet
     save status (for example "Unpublished · saved 14:03"), "Discard changes" per question and no
     per-question Save or "Keep changes" button; a same-item conflict shows as soon as the other
     change lands; saving a draft never publishes to reviewers (decided, DH-U37).
   - Question and form history with a per-field diff.
   - Option-mapping limits; the eight per-answer states; guided correction and requirement
     revision; the held banner without "Mark compatible".
   - Overlapping forms; import with a preview that equals the result, and a receipt.
   - Catalogue copies; question rows and legacy-gap labels in the conversion wizard.
   - Desktop and tablet layouts for all of this, a one-column phone layout (list, then editor,
     then back) with nothing hidden and no formal phone acceptance gate (decided, DH-U12), and
     light and dark themes.
   - A Classic-workflow project using the same editor (decided, DH-U41), saving directly as today,
     with per-question Required, per-stage Assign and today's answered-question lock ("Answered:
     locked (Classic)", section 5.22). It never shows versions, drafts, publication or presence.
     No chip.

ANSWERS, TRAINING GUIDANCE, REFERENCE QUESTIONS AND LANE C1 (new on 6 October 2026; sections 5.15,
5.24, 5.25, 5.26 and 9.13).
7. Apply section 9.13 (DH-C119 to DH-C129) and make DH-S68 to DH-S77 walkable. Design these:
   - Question editor: new questions are Required by default, and Optional sits only under
     Advanced settings with the warning "Reviewers can skip this without saying why"; a
     "Reasons no value is provided" block per question (the defaults Not reported, Not applicable
     and Unable to assess; the designer's own; sets added from catalogue templates such as SYRCLE;
     each reason with a stable identity; a risk-of-bias "Unclear" stays an ordinary option); an
     "Other, please specify" option whose free text is part of the answer's value; and a metadata
     grid of fields (comment, unit, evidence quote with its source location, reason) against answer
     states (any value, a specific option, each reason no value is provided, unanswered for
     optional questions), each cell Hidden, Allowed or Required.
   - Reviewer form: per question, an action that opens its reasons no value is provided (show it
     as "No value to enter", which is illustrative wording, not a fixed label); each question's
     answer status (Unanswered, answered with a value, answered with a reason) by icon shape and
     text; "Other, please specify" records the Other option and its text together as the value,
     with the text inside the answer; metadata fields for the chosen answer state, with "Needed to
     complete" on required ones; Complete blocked until every applicable required question has an
     answer (a value or a reason no value is provided) and every needed field; Save progress never
     blocked; "Clear answer" back to unanswered, with "answered, then cleared" in history.
   - Reconciliation: "Not compared (unanswered)" for an unanswered candidate question; reasons no
     value is provided compare as answers (the same reason agrees; a different reason or a value
     disagrees); "Other, please specify" compares as a value, the option with its text.
   - Conversion: converted questions keep their legacy Required or Optional setting; the redesign
     wizard offers to make optional questions required, with reasons no value is provided.
   - Training guidance: the designer binds guidance (rich text, links, files) to a training step and
     chooses whether trainees confirm "I have read this" and whether the guidance stays visible
     during the attempt; the trainee reads it before starting. Show it with a "To be decided" chip
     (DH-U43).
   - Reference questions, with the "Later release" badge: the "Reference to records" answer type in
     the editor; the reviewer's record picker and its states; the deletion dialog that lists
     references; and the reconciliation step that matches records before comparing references.
     Their timing and target types are open (DH-U44).
   - Lane C1 screens, with the "Later release" badge (v10's c1, c2, c4 to c6, c9 and c10): entity
     types with capabilities and one label question each; populations with "Add population" and the
     whole-population group ("Size not reported"); coverage on every cohort; set annotations with
     evidence; compact cohort selection. These pages never need the inference beta. Nothing is
     inferred unless the beta is on, and no screen ever adds groups together.
   - Concepts & rules: shared concepts and per-paper mapping answers show without the beta. Rule
     pages (writing and publishing project rules), per-paper rule-applicability answers and the
     inference panels appear only after the project opts in to the beta (decided, DH-U21; sections
     5.21 and 5.26). No chip.
   ANSWER TERMS (decided 6 October 2026, DH-U42; sections 3.2 and 5.24). Use these exactly:
   - "Answer status" is the overall state of a question: Unanswered; answered with a value (a
     listed option, "Other, please specify" with its text, a number, text, a date or a reference);
     or answered with a reason no value is provided.
   - "Reason no value is provided" names the designer-configured reasons (the defaults Not
     reported, Not applicable and Unable to assess, the designer's own, and catalogue sets such as
     SYRCLE), each with a stable identity. Use the short form "no-value reason" only in dense
     tables.
   - "No value to enter" is illustrative wording for the reviewer's action that opens the reasons.
     It is not a fixed label.
   - "Other, please specify" is a value-bearing answer: the Other option plus its text. It is never
     a reason no value is provided and never a metadata field.
   - "Unanswered" means nothing recorded; "option" means only a predefined choice; "Not compared
     (unanswered)" labels a missing answer in reconciliation (these three are carried from the
     recommendation).
   - Never show "no-value answer", "blank" (for an unanswered question), "response mode", "response
     option", "missing-data code" or "answer exception" on screen.

START FROM (all of these are in your v10 pack or described in the specification).
- The shipped SyRF question editor (section 5.23): tabs Design, Assign and Preview; category tabs
  with counts; a nested tree whose nodes open to Preview beside Settings; Add child and Copy; a
  two-tree "assign" interaction (reuse it to compose forms, not stages); and a preview that renders
  the real reviewer form. Keep these patterns. It becomes the one editor for every project
  (DH-U41). Open the editor beside a compact tree on wide screens and as a drill-in page on narrow
  screens, not inside the tree node (DH-U35). Replace native drag with pointer drag plus
  "Move up", "Move down" and keyboard alternatives.
- v10 c2 (entity-type question trees with reviewer numbering and the system lock), r6 (the forms
  page) and r1 (the profile editor with its own question tree). Keep their structure.
- An existing import dialog: download template, choose file, validate and preview the hierarchy,
  confirm, receipt, recent attempts, retry. Restyle it to Material 3 and show its file limits as
  "Example, not approved".
- An existing child-validity warning, rewritten to name the parent, child and option.
- For reference only, an earlier unmerged designer prototype: a version history timeline with a
  per-field diff, a tree keyboard model (arrows, Shift+Up and Shift+Down, Home, End, F2), a
  compact tree beside a side panel (the decided wide-screen layout, DH-U35) and a reviewer's alert
  after a publication.

AVOID.
- That prototype's state store and properties panel.
- In Versioned projects: per-stage question selection or assign trees, and stage-scoped
  publishing ("publish to a stage"). A Classic project keeps per-stage Assign (DH-U41, decided).
- In Versioned projects, a per-question Save or "Keep changes" button on design pages (changes
  save automatically into the draft, DH-U37). A Classic project saves directly, as today. Never
  use the reviewer words "Draft auto-saved" on design pages.
- An editor that expands inline inside a tree node (DH-U35), or any width shown as the decided
  breakpoint.
- Native HTML5 drag.
- "Mark compatible" anywhere: a compatibility declaration is immutable; a mistake is corrected by
  "Correct this publication".
- Apply anyway on a publication that changes questions (drafts are always kept).
- In Versioned projects, locks driven by answer counts (versions replace them). A Classic
  project keeps today's answered-question lock (section 5.22).
- Typed option values in conditions.
- Any numeric limit shown as decided.

DECIDED SINCE THE LAST SPECIFICATION (question management).
- D2-09 is decided (Chris, 5 October 2026), as DH-C99 and DH-S51 describe: the existing accepted
  answer appears as a labelled hint with "Use accepted answer", never prefilled; the second form's
  reconciler may revise it, creating a new accepted-answer version; a reason is prompted for but
  never required; "Raise a query" is offered with the "Later release" badge. DH-U36 (what the
  first form shows afterwards) stays open.
- One question editor for every project (DH-U41, decided 6 October 2026): Classic-workflow
  projects use the same refreshed editor with their own saving and assignment behaviour (direct
  saves, per-question Required, per-stage Assign); it never adds versions, drafts, publication or
  presence to them.
- Where the editor opens (DH-U35, decided 6 October 2026): beside a compact question list or tree
  on wide screens, and as a separate drill-in page on narrow screens. No width threshold is
  decided.
- How design edits are kept (DH-U37, decided 6 October 2026): accepted field changes save
  automatically into the Unpublished draft, with a clear save status, safe conflict handling and
  "Discard changes" per question. Saving a draft never publishes to reviewers.
- Phones (DH-U12, decided 6 October 2026): reconciliation, question-design and admin screens get
  usable, responsive phone layouts with no feature removed, without a formal phone acceptance
  gate. Screening and full annotation keep their phone, tablet and desktop acceptance at launch.

DECIDED ON 6 OCTOBER 2026 (Chris).
- Training does not hold up the first general release. Design the training screens as before.
- Trainees see right or wrong per item after assessment; the expected answers appear only after a
  pass or when no retry remains (DH-U19).
- New questions are required by default; Optional sits under Advanced settings with a warning and
  is discouraged; each question offers its own reasons no value is provided, and designers can add
  their own or copy sets from catalogue templates such as SYRCLE (DH-U38).
- Answer metadata is configurable per question and per answer state: Hidden, Allowed or Required.
- The answer terms in ANSWER TERMS above: Answer status, reason no value is provided, and Other,
  please specify as a value-bearing answer; "No value to enter" stays illustrative wording
  (DH-U42).
- The inference beta covers writing and publishing project rules, evaluating them and inferred
  results. Ordinary annotation and explicit group or classification recording (lane C1) never need
  it (DH-U21).
Still open: training guidance (DH-U43), reference question timing and target types (DH-U44), and
whether a live step can depend on passed training (DH-U20). How clearing is recorded is a proposal;
show only "answered, then cleared" in history.

BOUNDARIES (question management).
- Prototype only. Nothing in it approves building question management, import, conversion or any
  migration; implementation is on hold. Use synthetic questions only. Show every open item,
  including DH-U36, DH-U39, DH-U40, DH-U43, DH-U44, DH-T19 and DH-T20 to DH-T23, as "To be
  decided". DH-U35, DH-U37, DH-U38, DH-U41 and DH-U42 are decided: build them without a chip.

ORDER OF WORK.
1. Verify the source files. Draft the change log skeleton from section 9 and the "Resolved since v10"
   list from section 2.7.
2. Cross-cutting chrome: navigation (section 4.1), sentence case, Material 3 roles and dark theme,
   copy deck, Tweaks, Scenario picker, Simulate menu, Inspector, Open decisions panel.
3. The reviewer workspace: step selector with one form area, status line, Save progress and
   Complete, hints and click-to-fill, Needs updating and Fix, shared sessions and conflicts, then the
   phone, tablet and large-form passes.
4. Reconciliation: N candidates with random Study-local aliases, the autofill marker without
   per-field confirmation, the unseen-control warning, one-candidate checking and Single annotator
   results, matching, outcome reconciliation, accepted-result history, questions shared with another
   form (the accepted-answer hint, the optional reason and Raise a query, section 5.5), then the
   adjudication queue, Unsure, ties and discussion.
5. Configuration: annotation forms (target and reconciliation policy in the version, operational
   settings), screening profiles, the stage filter and steps editor, and the publication flow with
   impact previews and Apply anyway.
5a. Question management: Questions and entity types and the question editor, conditions and
    filtered options, the tree and child validity, form composition and drafts, history and diff,
    publication details (mapping limits, per-answer states, guided correction, the held banner),
    overlapping forms, import, catalogue copies and conversion rows, then the tablet and phone pass.
5b. Answers: Required by default in form composition, the editor's reasons no value is provided,
    "Other, please specify" and the metadata grid, the reviewer's "No value to enter" action
    (illustrative wording) and answer status, Complete's checks, "Clear answer", "Not compared
    (unanswered)" in reconciliation, and the conversion and redesign rows.
6. Work discovery: My work, the global badge, Your studies, Saved work and the eligibility
   explanation timeline.
7. Merge and unmerge; contribution exclusion; Members & groups; project deletion and restoration;
   notifications and email settings; the catalogue.
8. Training, with guidance before the attempt; the inference beta, with the rule pages behind its
   opt-in; AI-model-generated screening decisions (marked "Later release").
8a. Lane C1 and reference questions (marked "Later release"): entity types, populations, cohorts
    and coverage, set annotations, the record picker, the deletion dialog and the matching step.
9. The conversion wizard and the Classic-workflow project view.
10. Accessibility and theme pass: keyboard-only, screen-reader labels, forced colours, dark theme,
    400% zoom and the width matrix in section 7.5.
11. Data views (Export, Agreement, PRISMA), marked "Later release", only if time allows.

OUTPUTS I EXPECT.
- Updated prototype file(s) as new .dc.html files, keeping the v10 runtime and design-system bundle.
- A change log: one entry per DH-C ID with what changed, where to find it, and any deviation from the
  specification with its reason.
- An open-question list: anything ambiguous you found, anything the specification is silent on where
  you kept v10 behaviour, and your view on each DH-U item if testing the prototype suggested one.
- A token-mapping table from the prototype's own variables to Material 3 and SyRF roles.
- A short note listing which scenarios (DH-S IDs) you could and could not make walkable.

CONSTRAINTS.
- Prototype only. Do not write production code or Angular components.
- Use Material 3 roles and the SyRF design system (--syrf-* tokens); Material 3 sentence case for
  every label; light and dark themes; status never shown by colour alone.
- Phone, tablet and desktop layouts for screening and annotation, with 44 px touch targets below
  600 px.
- Use synthetic fixtures only. No real project content, participant data or live service calls.
- Never show permanent erasure, an identity-erasure process, automatic acceptance of several
  agreeing candidates, or any numeric threshold as decided. Use example values labelled "Example,
  not approved". Project deletion is reversible: its copy says the project is moved out of use and
  can be restored, never that data is erased or destroyed.
- Show anything the specification marks `PROPOSAL` as a proposal, never as a decided behaviour.
- Use two distinct badges: "Later release" for items that are in scope but ship in a later release
  or lane, and "Not in MVP" for deferred items outside the MVP. Never use a bare "Later".
- Keep implementation-only detail (storage, record names, transactions) out of product screens; the
  Inspector may show logical records with "Record names are proposals".
- Use "AI-model-generated screening decision" and "AI screening model"; never "model decision".

BOUNDARIES.
- This is a prototype iteration only. Nothing in the specification, and nothing you produce, approves
  implementation, migration, production activation or notification delivery. SyRF feature
  implementation is on hold.
- Where the specification and the v10 pack disagree, follow the specification. Where it is silent,
  keep the v10 behaviour and list it in the open-question list.
- Do not resolve the open items in section 11 yourself; show them as "To be decided".

Validation of this document. It restates decisions from the 5 October consolidation and the nine companion specifications (ten since 6 October 2026, with the classification specification). It changes no other file. Updated 5 October 2026 (evening) for Chris's D2-09 answer: §1.6, §4.4, §5.5 ("Questions shared with another form"), DH-C02, DH-C99, DH-S51, DH-U27, §12 and the §13 prompt. Updated again that evening for the question-management integration (question-management plan): §2.6 to §2.8, the §3.2 glossary, §4.2, §4.5, the §5.1 banned strings, §5.8's Apply anyway scope, the new §5.22 and §5.23, §7.1, §8, DH-C41, §9.12 (DH-C100 to DH-C118), DH-S52 to DH-S67, DH-U35 to DH-U41, DH-T19, §12 and the §13 prompt. Updated again that evening for verification fixes: the §5.1 banned strings and §5.22's Classic answered-question lock; §5.23 and the §13 AVOID list scoped to Versioned projects; DH-U41; "To be decided" chips for DQ-11, DQ-20 and DQ-44 in §5.5, §5.9, §5.10, §6.2, DH-S23, DH-S27, §11.1 and the §13 prompt. Updated 6 October 2026 for Chris's answers of that day and the classification, populations and references specification: §1.6, the §3.2 glossary, §4.2, §5.3, §5.5, §5.10, §5.15, §5.21, §5.22, the new §5.24 to §5.26, §6.2, DH-C02, DH-C15, DH-C16, DH-C18, DH-C69, DH-C89, DH-C95, DH-C101, DH-C104, §9.13 (DH-C119 to DH-C129), DH-S21, DH-S68 to DH-S77, DH-U19 and DH-U38 (decided), DH-U42 to DH-U44, DH-T19 to DH-T23, §12 and the §13 prompt. Updated again 6 October 2026 for Chris's design-handoff answers (DQ-01 to DQ-04, DQ-46 and DQ-09; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18): the "Open questions before sending" note, §1.6, the §3.2 glossary (Answer status, reason no value is provided, No value to enter, Other, please specify, Unanswered, Not compared (unanswered)), §4.4, the §5.1 banned strings, §5.3, §5.5, §5.10, §5.21, §5.22, §5.23, §5.24, §5.25, §5.26, §6.2, §7.1, §7.7, DH-C02, DH-C10, DH-C15, DH-C18, DH-C31, DH-C69, DH-C77, DH-C90, DH-C101 to DH-C105, DH-C113, DH-C116, DH-C117, DH-C119, DH-C120, DH-C122 to DH-C124, DH-C126, DH-C127, DH-S21, DH-S30, DH-S39, DH-S52, DH-S56, DH-S57, DH-S64, DH-S67, DH-S69 to DH-S72, DH-U12, DH-U21, DH-U35, DH-U37, DH-U41 and DH-U42 (decided), DH-T20, DH-T21, DH-T23, §12 and the §13 prompt (its "NAMING IS OPEN" line is replaced by the decided terms). The totals stay 129 changes, 77 scenarios, 44 inputs (now 9 decided and 35 open) and 23 "To be decided" items. Nothing has been sent to the design session: the pack is ready for Chris to send (T-DH-01) only after this integration is checked and merged, and implementation stays on hold. Figures about the prototype files (sizes, line counts, checksums) were measured on 5 October 2026 from the read-only copy named in section 2.1.