Open questions before the Claude Design handoff¶

Status on 5 October 2026. This is a temporary planning document. Feature implementation is on hold (Chris, 5 October 2026) and G0 is not approved. Nothing has been sent to the Claude Design session, and this document sends nothing. It prepares a discussion; it decides nothing. Every recommendation below is only a recommendation, and no answer is recorded until Chris gives it.

Updated 6 October 2026. In a planning session Chris answered DQ-31 as recommended and rollout ambiguity R-AMB-01 ("No, training does not gate GA"), and his required-by-default answer decides DQ-05 (decision register §1.17). DQ-32 is rewritten with a gating analysis; Chris is unsure, so it stays open. Five entries are new: DQ-46 (naming, class A), DQ-47 and DQ-48 (class B), and DQ-49 and DQ-50 (class C, with answer fields). They come from that session and from the new classification, populations and references specification (CPR). Implementation remains on hold, and nothing here authorises sending the pack.

Updated again 6 October 2026 (design-handoff answers). In a Codex discussion Chris answered all five class A questions (DQ-01 to DQ-04 and DQ-46) and the class B question DQ-09. His words are in each Answer field below, quoted from the record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt, and they are registered in decision register §1.18. They are rolled into the design-prototype handoff as §6 steps 1, 2, 4 and 5 describe. No class A question is open now; 40 class B questions stay open and travel in the pack 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 sends nothing: sending is Chris's own step (T-DH-01). Feature implementation stays on hold (T-HOLD), and no answer authorises it.

Why it exists. On 5 October 2026 Chris asked for "the open questions … that need answering before handing the updated pack to claude design", so that he can "discuss and find answers to them all in a codex session before handing an updated pack (with resolved question answers rolled into the pack)". The pack is the design-prototype handoff with its §13 copy-ready prompt, plus the package documents it cites. It asks the design session to iterate SyRF Prototype v10.

Sources gathered. Every item cites its source ID and file:

the handoff's open design inputs DH-U01 to DH-U41 and its "To be decided" items DH-T01 to DH-T19 (handoff §11), leaving out DH-U27, which is decided (D2-09); since 6 October 2026 the handoff also lists DH-U42 to DH-U44 (DQ-46 to DQ-48) and DH-T20 to DH-T23, and DH-U19 and DH-U38 are decided, as are, later that day, DH-U12, DH-U21, DH-U35, DH-U37, DH-U41 and DH-U42;
the owner-visible confirm items in each specification's §12, listed in owner-session integration §7.3;
the question-management questions QMI-01 to QMI-05 and their brief-level confirmations (question-management plan §9);
the rollout ambiguities R-AMB-01 to R-AMB-06 (rollout plan §7.6);
the specialist inputs T-SI-01 to T-SI-05 (owner-session integration §7.4);
G0-D1 and the G0 and hold items, only to say that they are not design questions;
added 6 October 2026: Chris's answers and questions in that day's planning session (decision register §1.17), RD §12's owner items and brief details of that date, and CPR §12;
PROPOSAL and "To be decided" items elsewhere in the handoff that the designer would otherwise have to guess.

Abbreviations. The specifications are 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 CPR classification, populations and references. "Handoff" is the design-prototype handoff, "QM plan" the question-management plan, VM the versioning model and "register" the decision register. DH-C, DH-S, DH-U and DH-T IDs are the handoff's changes (§9), scenarios (§10), open inputs (§11.1) and "To be decided" items (§11.2). T- IDs are rows of the implementation tracker. CI-02 to CI-18 are the labels the programme status page gives the 17 brief confirm items; the page is outside the repository, and the repository source for each is owner-session integration §7.3 and the specification §12 cited.

1. How to use this document¶

Who it is for. Chris, in a Codex session, working through the questions with an assistant that has the package open. Each question is written to make sense on its own.
Order. Work through class A first, by screen area (§3). Those answers change layouts, flows, navigation or copy enough that designing without them wastes an iteration. Then class B (§4): Chris wants answers to all of them, but if time runs short the handoff can carry any class B item as labelled options or a placeholder. Class C (§5) is listed only so nothing is lost; none of it needs an answer before the handoff.
Answers. Write each answer in its Answer field, in Chris's words, and fill Decided by / date. "As recommended" is a valid answer. An answer may also pick an option with an amendment, or move an item to another class.
Afterwards. A writer rolls the answers into the pack using §6, and the checks run. Only then may Chris send the pack (T-DH-01). Sending is Chris's own step.
Boundaries. This document decides nothing by itself. Answers are planning approval only: they approve no brief, authorise no implementation, lift no hold and message no design session. Implementation stays on hold (T-HOLD).

2. Summary¶

2.1 Counts¶

Class	Count	Meaning
A. Answer before the handoff	5	DQ-01 to DQ-04 and DQ-46; all five decided on 6 October 2026 (Codex discussion), so 0 open
B. The handoff can carry options	43	DQ-05 to DQ-45, DQ-47 and DQ-48; DQ-05 and DQ-31 decided on 6 October 2026 (planning session) and DQ-09 the same day (Codex discussion), so 40 open
C. Not a design question	40 rows	§5; a row may group several source IDs; DQ-49 and DQ-50 also have entries with answer fields; R-AMB-01's row decided on 6 October 2026, so 39 open

Screen area	Class A	Class B
Question management and designer	4 (DQ-01 to DQ-03, DQ-46; all decided)	6 (DQ-05 to DQ-09, DQ-48; DQ-05 and DQ-09 decided)
Forms and publication	0	4 (DQ-10 to DQ-13)
Reconciliation and screening	0	11 (DQ-14 to DQ-24)
Stages and pools	0	9 (DQ-25 to DQ-32, DQ-47; DQ-31 decided)
Reporting	0	0
People and messages	0	7 (DQ-33 to DQ-39)
Devices	1 (DQ-04; decided)	1 (DQ-40)
Conversion	0	5 (DQ-41 to DQ-45)
Total	5 (0 open)	43 (40 open)

Placement notes. Duplicate-merge items (DQ-23, DQ-24) sit under reconciliation and screening, because merge conflicts are resolved in a reconciliation-like view. Training items (DQ-31, DQ-32) sit under stages and pools, because training is a step kind (SP §3.4). The inference beta (DQ-09) sits under question management and designer, because Concepts & rules is a Design page. Population context (DQ-13) sits under forms, because its options trade a header chip against a form category tab. Reporting has no class A or B item: its open points are specialist inputs (§5), shown as fixed placeholders, and the export overlap markers (DQ-49, class C). Added 6 October 2026: naming (DQ-46) sits under question management and designer, where designers configure the reasons no value is provided, though its copy also reaches the reviewer form, reconciliation and exports; training guidance (DQ-47) sits with the other training items; reference questions (DQ-48) sit under question management.

Class C by kind: question-management engineering and brief-level confirmations 10; specialist inputs 5; legal and policy 2; brief-level details and settled items 11; release sequencing 4 (R-AMB-01 now decided); G0 and the hold 4; answers and classification, added 6 October 2026, 4 (DQ-49, DQ-50, CPR §12 items 5 to 8, and RD §12's brief details).

CI-08 (the full Unsure transition table) is split: its all-Unsure row is DQ-15 in class B, and its other unstated rows are one class C row ("CI-08 (other rows); DH-T11", §5). Each part is counted once, in its own class.

2.2 Class A in one line each¶

All five class A questions were answered by Chris on 6 October 2026 (Codex discussion) and are integrated into the pack the same day; none is open. Each line gives the question, then the answer.

DQ-01: does a Classic-workflow project use the same question editor as a Versioned one, or keep today's older "Question design" page (QMI-04; DH-U41)? Decided, option (a): one refreshed editor, with each project mode's own saving and assignment behaviour. QMI-04 is answered in part; when the older page retires is not decided.
DQ-02: does the question editor open inline in the tree, in a side panel, or in a side panel on wide screens and a drill-in page below (DH-U35)? Decided, option ©: beside a compact list or tree on wide screens, a drill-in page on narrow screens. No numeric breakpoint is approved.
DQ-03: are design edits kept in the draft as the admin types, or by an explicit "Keep changes" per question (DH-U37)? Decided, option (a): automatic saving into the unpublished design draft, with save status, safe conflict handling and discard controls.
DQ-04: must reconciliation and design screens work at phone width, and is that an acceptance gate (DH-U12; UX A2)? Decided, option (b): usable responsive phone layouts with no feature removed, and no formal phone acceptance gate.
DQ-46: what are answers and "no-value answers" called on screen (DH-U42; added 6 October 2026)? Decided with revised terminology: Answer status, Reason no value is provided, and Other, please specify as a value-bearing answer.

2.3 Where the 17 confirm items went¶

The 17 brief confirm items (status page CI-02 to CI-18) map as follows: CI-02 DQ-10; CI-03 DQ-41; CI-04 DQ-20; CI-05 DQ-14; CI-06 DQ-19; CI-07 class C; CI-08 DQ-15 (all-Unsure) and class C (the other unstated rows); CI-09 DQ-25; CI-10 DQ-11; CI-11 DQ-08; CI-12 DQ-44; CI-13 DQ-40; CI-14 DQ-12; CI-15 DQ-31 (decided 6 October 2026); CI-16 DQ-32 (still open); CI-17 DQ-09 (decided 6 October 2026, option (a)); CI-18 class C. CI-01 is G0-D1 (class C). No other mapping changed on 6 October 2026.

So that each label can be checked without the status page, this table gives each one's repository source: the row of owner-session integration §7.3 that holds it and the specification §12 item it comes from.

Label	Confirm item	§7.3 row	Specification source	Here
CI-02	Default target-one handling	"The RS §12 owner-visible confirm items"	RS §12 ("Default for `targetOneHandling`")	DQ-10
CI-03	Converted target-one forms carry `NoAcceptance`	"The RS §12 owner-visible confirm items"	RS §12 ("Converted target-one forms"); BC A1 (BC §12.4)	DQ-41
CI-04	The Q-36 reading of "explicit override grants"	"The RS §12 owner-visible confirm items"	RS §12 ("Q-36 override reading")	DQ-20
CI-05	A reviewer's own Unsure and progression	"The RS §12 owner-visible confirm items"	RS §12 ("Own Unsure and progression")	DQ-14
CI-06	Re-acceptance under `AutoAccept`	"The RS §12 owner-visible confirm items"	RS §12 ("Re-acceptance under `AutoAccept`")	DQ-19
CI-07	The screening-annotation agreement bypass: a profile rule or `T-POL-03`	"The RS §12 owner-visible confirm items"	RS §12	Class C
CI-08	The full Unsure transition table	"The full Unsure transition table"	RS §5.10; RS §12 ("Unsure transition rows")	DQ-15 (all-Unsure); class C (other rows)
CI-09	Where "finish started work after departure" lives	"SP-AMB-01"	SP §12.4 (SP-AMB-01)	DQ-25
CI-10	Study target overrides under a new standard target	"RD-R16"	RD §12 ("Override treatment at publication")	DQ-11
CI-11	Direct project-to-project copying	"ACD B5"	ACD §12.5 (B5)	DQ-08
CI-12	The scope of Chris's wave approvals	"BC A3"	BC §12.4 (A3)	DQ-44
CI-13	Holding edits on the device during a connection loss	"UX A1"	UX §12 (A1)	DQ-40
CI-14	Offering "suspend" for results below a raised target	"RS §12: whether the 'suspend' treatment …"	RS §12 ("Suspension of results below a raised target")	DQ-12
CI-15	The trainee feedback disclosure default	"The TI §12 owner-visible items"	TI §12 ("Feedback disclosure default"); TI-R10	DQ-31 (decided as recommended, 6 October 2026)
CI-16	A live step that depends on passed training	"The TI §12 owner-visible items"	TI §12; TI-R23	DQ-32 (open; rewritten 6 October 2026)
CI-17	The scope of the inference beta	"The TI §12 owner-visible items"	TI §12 ("Scope of the beta")	DQ-09 (decided, option (a), 6 October 2026)
CI-18	Legal review of the joining-terms and account-deletion wording	"Legal review of the joining-terms …"	ACD §12.3; ACD-AE03	Class C

2.4 Notes from gathering¶

Three confirm items appeared in the handoff as settled behaviour, with no chip. The Q-36 override reading (DQ-20: handoff §5.5 "Who may reconcile", the §6.2 "Self-reconciliation override" row and DH-S23), the RD-R16 override treatment (DQ-11: §5.9 "Target-only publication" and DH-S27) and the scope of wave approvals (DQ-44: §5.10 step 6 shows owner approval only). Updated 5 October 2026: the handoff now shows each with a "To be decided" chip that points to its DQ ID here, lists them in §11.1 and names them in the §13 prompt's goal 5. They have no DH-U entry. §6 step 5 removes a chip once its item is answered.
Two DH-T items are design choices with options, so they are class B: bulk reassignment (DQ-22, DH-T17) and extra confirmations beyond the impact preview (DQ-39, DH-T13).
The sweep of the handoff's other PROPOSAL and "To be decided" text added no item beyond the DH-U and DH-T lists and the confirm items. The handoff marks many behaviours as PROPOSAL and tells the designer exactly what to show (for example the selected step in the URL, keyboard shortcuts, the outdated-answer mode's place in the form version). The §13 prompt already says to show them as proposals, so the designer guesses nothing and they need no answer here.
Decided items left out. DH-U27 (D2-09, decided 5 October 2026) and the answered G0-D5, G0-D6 and G0-D12 do not appear as open anywhere below.
6 October 2026. DQ-05 and DQ-31 keep their sections, marked decided, so their answers can be rolled in; they no longer count as open. Configurable answer metadata (Chris's direction) opened no new design question beyond naming (DQ-46): its field types, answer states and the Hidden, Allowed or Required setting are specified in RD §3.16, and its brief details are one class C row.
6 October 2026, later (design-handoff answers). DQ-01 to DQ-04, DQ-46 and DQ-09 also keep their sections, marked decided, so their answers can be traced. DQ-46 is recorded as asked: its options use the working term "no-value answer", which the answer retires. QMI-04 (DQ-01) is answered in part: the retirement timing of the older page and its flag (T-RD-17) stays a recommendation. DQ-11, DQ-20 and DQ-44 stay open, so their chips stay.

3. Class A questions: answer before the handoff¶

Grouped by screen area: question management and designer (DQ-01 to DQ-03), then devices (DQ-04). DQ-46 (naming, question management and designer) was added on 6 October 2026 and follows them. No other screen area has a class A question.

DQ-01 Question editor for Classic projects¶

Screen area: question management and designer.

Source: QMI-04 (QM plan §9.4; tracker T-OI-02; owner-session integration §7.8); DH-U41 (handoff §11.1, §5.22 "Two kinds of project", §12); UX §3.13 and UX-R46; RD §4.7 ("Editor modes"); T-RD-17; AC-R1a-14.

Context: SyRF has two question editors today. Every default entry opens the older "Question design" page; the newer Design, Assign and Preview editor sits behind a flag that only hides its navigation link. Projects that have not converted ("Classic workflow") save each question directly, with no versions or drafts, and choose questions per stage. The plan proposes that the newer editor becomes the default entry for every project, saving directly in Classic projects, and that the older page retires after R1a acceptance and one staging soak; the alternative keeps the older page for Classic projects until legacy writers retire (R7). The handoff currently shows the first option with a "To be decided" chip.

Options:

(a) One editor for both kinds of project. The Classic-workflow project in the prototype shows the same Design › Questions and entity types page and editor as a Versioned project, without versions, drafts or presence, with per-question Required, per-stage Assign, and an explanation where filtered options cannot be saved. The designer designs one editor with two modes.
(b) Classic projects keep today's older "Question design" page, restyled to Material 3, until they convert or R7. The designer must restyle a second editor; the Classic project's Design entry differs from the Versioned one; the Classic halves of DH-C101, DH-C103, DH-C104, DH-S56 and DH-S64 move to the older page, and question import needs an entry there too.

Recommendation: (a), as QMI-04 recommends: one editor to learn and maintain, and the older page already drops filtered options silently (QM plan §10.1 item 4).

What the answer changes in the pack: DH-U41's status; handoff §5.22 ("Two kinds of project"), §7.7 and the §12 row for QMI-04; DH-C101 (its Classic sentence), DH-C103 (the Classic note), DH-C104 (per-stage Assign), DH-C113 (Classic import); DH-S56 and DH-S64 (their Classic halves); the §13 prompt's question-management block (the last bullet, "A Classic-workflow project using the same editor …") and its boundary line naming DH-U41. Outside the pack: T-OI-02, UX-R46 and RD §4.7 lose or keep their PROPOSAL label, and T-RD-17 and AC-R1a-14 follow.

Answer: Chris answered "Yes" to using the same refreshed question editor for older and converted projects, "while retaining the saving and assignment behaviour appropriate to each project mode". The record's status line: "Approved, option (a): one editor with mode-appropriate capabilities. This does not silently introduce versioned publication, draft or assignment semantics into unconverted projects." QMI-04 is therefore answered in part: the same editor serves every project. The retirement timing of the older "Question design" page and the newQuestionManagement flag (T-RD-17: after R1a acceptance and one staging soak) was not addressed; it stays the recommendation and is not recorded as decided. Rolled into the handoff on 6 October 2026 (DH-U41; §5.22 "Two kinds of project", §7.7, DH-C101, DH-C103, DH-C104, DH-C113, DH-S56, DH-S64, §12 and the §13 prompt).

Decided by / date: Chris, 6 October 2026 (Codex discussion; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18); Decided.

DQ-02 Where the question editor opens¶

Screen area: question management and designer.

Source: DH-U35 (handoff §11.1, §5.22 item 7, §5.23); UX §3.13; harvest map H-WEB-03 and H-WEB-05.

Context: Today's newer editor opens a question inline, inside its tree node, with Preview beside Settings, so the siblings below move down the page. An earlier unmerged prototype, and v10's c2, put a compact tree beside a side panel instead. The largest project has about 2,023 questions, so the tree must stay compact and navigable. The handoff tells the designer to start from the shipped editor's patterns and also recommends a side panel on wide screens, so without an answer the designer must choose the frame for every question-management screen; a wrong guess redoes the largest new area of this iteration.

Options:

(a) Inline inside the tree node (today's editor). One column; the editor expands under its node; on large trees the surrounding questions scroll out of view; narrow screens follow naturally.
(b) A side panel beside a compact tree at every width. Two panes everywhere; on phones the panel still has to become a full-screen sheet.
© A side panel at 1,240 CSS px and wider, and a drill-in page below that (list, then editor, then back). Two layouts, and the narrow one is the phone pattern DH-C116 already asks for.

Recommendation: ©, the handoff's recommendation: a 2,023-question tree must stay compact, and inline expansion pushes siblings out of view. Validate with users before the layout freezes; if Chris wants users to compare, the answer can also ask for (a) as a Tweaks variant.

What the answer changes in the pack: DH-U35's status; handoff §5.22 item 7 and the §5.23 "Start from" rows for the shipped editor and the earlier prototype; DH-C101, DH-C102, DH-C116; DH-S52 to DH-S55, DH-S60 and DH-S67; the §13 prompt's "START FROM" bullets (the shipped editor and the reference-only prototype, which names DH-U35) and its boundary line naming DH-U35.

Answer: "Approved by Chris, option ©: compact question list/tree with an editor beside it on wide screens, and a separate drill-in editor page on narrow screens." The record adds: "The proposed breakpoint is a design detail requiring validation, not an approved numerical threshold." So no numeric breakpoint is approved: the 1,240 CSS px in option © is a design detail to validate with users, and the pack shows any width as "Example, not approved". Rolled into the handoff on 6 October 2026 (DH-U35; §5.22 item 7, the §5.23 "Start from" rows, DH-C101, DH-C102, DH-C116, DH-S52, DH-S67, §12 and the §13 prompt).

Decided by / date: Chris, 6 October 2026 (Codex discussion; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18); Decided.

DQ-03 How design edits are kept in a draft¶

Screen area: question management and designer.

Source: DH-U37 (handoff §11.1, §5.22 item 7); RD §3.7, §4.7; UX §3.8; OS-A01; DH-C31, DH-C105.

Context: In a Versioned project every question edit goes into an Unpublished draft that several admins can edit at once, with presence, live updates and conflict handling (OS-A01). Today's newer editor saves each question with a per-node Save button. In the plan's model each edit is stored as a change with its base revision, which suits keeping edits as the admin types. The answer decides whether the editor has a Save button, what its status line says and when a same-item conflict appears, across every question-management screen.

Options:

(a) Each field change is kept in the draft as the admin types, with a status such as "Unpublished · saved 14:03" and "Discard changes" per question. No per-question Save; one quiet status per draft; a same-item conflict shows as soon as another admin's change lands ("Priya changed this option while you were typing"); others see changes almost at once.
(b) An explicit per-question "Keep changes" into the draft, like today's per-node Save. A Keep changes button and an unsaved state per question, with a navigation guard; conflicts appear only when keeping; others see a change only after Keep.

Recommendation: (a): presence and live updates need accepted changes promptly, and each edit already carries its base revision (RD §4.7). Keep "Discard changes" per question.

What the answer changes in the pack: DH-U37's status; handoff §5.22 ("Forms, drafts and presence" and the Incomplete, Conflict and Failure rows of its state table); DH-C31, DH-C105 and DH-C117's copy; DH-S30 and DH-S57; the §13 prompt's "Collaborative drafting" bullet. DH-C105's rule that design wording never uses "Draft auto-saved" stands either way.

Answer: "Approved by Chris: automatic saving into the unpublished design draft, with clear save status, safe conflict handling and discard controls." This is option (a). The recommendation the record restates: "automatically save accepted field changes into the unpublished design draft, with save status, safe conflict handling and per-question discard controls. Saving a design draft does not publish changes to reviewers." So "Discard changes" stays per question, there is no per-question Save or "Keep changes", and DH-C105's rule against "Draft auto-saved" in design wording stands. Rolled into the handoff on 6 October 2026 (DH-U37; §5.22 "Forms, drafts and presence" and its state table, DH-C31, DH-C105, DH-C117, DH-S30, DH-S57, §12 and the §13 prompt).

Decided by / date: Chris, 6 October 2026 (Codex discussion; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18); Decided.

DQ-04 Reconciliation and design screens on phones¶

Screen area: devices.

Source: DH-U12 (handoff §11.1, §7.1); UX A2 (UX §12); UX-R49; DH-C77, DH-C116; DH-S67; D3-05.

Context: Chris decided that screening and full annotation work on phones, tablets and desktops at launch (D3-05). He has not said whether reconciliation, question authoring and other admin screens must work on phones too. The handoff assumes they are usable at phone width with no feature removed, but without a phone acceptance gate. That assumption sets the scope of the device pass for two large areas, N-candidate reconciliation and the 2,023-question designer, and neither a placeholder nor "show both options" can stand in for it.

Options:

(a) Phone acceptance for reconciliation, and for design screens if Chris wants. The same layouts as (b), but every phone layout must meet the launch acceptance bar (touch, keyboard, screen readers, the largest form), and the scenarios add phone walkthroughs for reconciliation.
(b) Usable narrow layouts with no feature removed and no phone acceptance gate. A candidate selector and one column below 905 CSS px (DH-C77); list, then editor, then back for design pages (DH-C116); DH-S67's phone half.
© Desktop and tablet only. No phone layouts for reconciliation or design pages, and a "Use a larger screen" state on phones; DH-C77's narrow layout and DH-C116's phone part are dropped.

Recommendation: (b), with admin screens responsive: it keeps D3-05's "no feature removed" spirit without a gate the owner did not set (UX A2).

What the answer changes in the pack: DH-U12's status; handoff §7.1 (the line naming DH-U12) and §4.4 item 3; DH-C77, DH-C116; DH-S67; the §13 prompt's goal 4 and the question-management bullet on devices. Outside the pack: UX-R49 and UX A2.

Answer: "Approved by Chris, option (b): usable responsive phone layouts with no feature removed, without a formal phone acceptance gate for reconciliation and design. The previously approved screening/annotation device acceptance requirements remain." So reconciliation, question-design and other admin screens get responsive phone layouts with every function, and only screening and full annotation carry the phone acceptance requirement (D3-05, unchanged). Rolled into the handoff on 6 October 2026 (DH-U12; §7.1, §4.4 item 3, DH-C77, DH-C116, DH-S67, §12 and the §13 prompt's goal 4 and question-management devices bullet).

Decided by / date: Chris, 6 October 2026 (Codex discussion; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18); Decided.

DQ-46 Naming answers and no-value answers¶

Screen area: question management and designer; its copy also reaches the reviewer form, reconciliation, history and exports. Added 6 October 2026.

Source: Chris, planning session of 6 October 2026 (decision register §1.17); RD §12 ("Owner items from 6 October 2026"); RD §3.16, RD-R50; RS-R14; VM §3.4; handoff DH-U42 and §5.24.

Context: Chris decided on 6 October 2026 that new questions are required by default, with explicit answers for "no value" such as Unable to assess, and that answer metadata is configurable per answer state. The package had called those explicit answers "response modes", and a later draft suggested "response option". Chris replied: "'Response option' is even more ambiguous as it could easily be confused with a chosen option given as an answer value!? Need to think again about naming. Should reduce ambiguity and be intuitive!" Until he decides, the specifications use the working term "no-value answer". The words appear in the question editor (each question's set), the reviewer form (the "No value…" menu and Complete's messages), reconciliation (the label for an unanswered comparison), history and exports, so designing them twice wastes an iteration.

Options:

(A) An answer is anything recorded: a value, or a no-value answer with its reason. "Option" means only a choice's predefined option. Unanswered means nothing recorded, and the comparison of an unanswered question reads "Not compared (unanswered)". "Blank" and "response mode" are dropped from user-facing language.
(B) "Missing-data codes" for the explicit answers.
(C) "Answer exceptions" for the explicit answers.

Recommendation: (A): one word, "answer", covers everything a reviewer records, "option" stays for choices only, and no new jargon is needed.

What the answer changes in the pack: DH-U42's status; handoff §3.2 glossary, §5.5 step 2, every label in §5.24, DH-C119, DH-C120, DH-C122, DH-C123, DH-S21, DH-S69 to DH-S71, and the §13 prompt's "NAMING IS OPEN" line. Outside the pack: RD §3.16 and RD-R50's working term, RS-R14's label, VM §3.4, contracts C1, C4, C5, C9 and C11, the decision register's UA1 and AG3 notes, open questions Q-04 and the copy deck (T-UX-02).

The context and options above are recorded as asked on 6 October 2026; they use the working term "no-value answer", which this answer retires.

Answer: "Approved with revised terminology: Answer status describes the overall state; Reason no value is provided identifies configured explicit reasons; Other, please specify records an actual non-listed value." The record's final clarification: "Chris agreed the distinction after discussing custom reasons and non-listed values. Use Answer status for the overall state, covering Unanswered, answered with a listed or other specified value, and a configured explicit reason no value is provided. Use Reason no value is provided for that reason set, with No value to enter as the proposed reviewer action. Designers can configure defaults, custom reasons or catalogue sets and reason-specific metadata requirements. Other, please specify is a value-bearing answer with configured free text, not a missing-value reason. Preserve distinctions and configured stable identities in versions and exports. Naming of the action itself should be treated as illustrative unless separately confirmed."

What this decides for the pack:

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 reasons (the defaults Not reported, Not applicable and Unable to assess, custom reasons and catalogue sets such as SYRCLE), each with a stable identity and its own metadata requirements. It replaces the working term "no-value answer" in user-facing copy and in specification prose. The short form "no-value reason" may be used in dense tables; a code identifier, if one is needed, is noValueReasonId (PROPOSAL), replacing noValueAnswerId.
No value to enter is the proposed reviewer action that opens the reasons. It is illustrative wording, not a fixed label, unless separately confirmed.
Other, please specify is a value-bearing answer: the listed "Other" option plus its configured free text, recorded as the answer's value and never a reason no value is provided. Its option identity and the text are kept in versions and exports. Where it was modelled as a metadata field ("Other: specify" text), it becomes part of the Other option's value; metadata stays for comments, units, evidence quotes, reasons and the like.
Carried from the recommendation (option (A)); not separately discussed: Unanswered means nothing recorded; Option means only a predefined choice; Not compared (unanswered) is the comparison label for a missing answer.
Retired from user-facing language: "no-value answer", "blank", "response mode", "response option", "missing-data code" and "answer exception".

Rolled into the handoff on 6 October 2026 (DH-U42; the §3.2 glossary, the §5.1 banned strings, §5.3, §5.5 step 2, §5.24, §5.25, §6.2, DH-C119, DH-C120, DH-C122 to DH-C124, DH-C126, DH-C127, DH-S21, DH-S69 to DH-S72, DH-T20, DH-T21, DH-T23, §12 and the §13 prompt, whose "NAMING IS OPEN" line is replaced by the decided terms).

Decided by / date: Chris, 6 October 2026 (Codex discussion; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18); Decided-amended (the recommendation with revised terminology; the record names no option letter).

4. Class B questions: the handoff can carry options¶

Each item says what the handoff shows if it is still open when the pack is sent. For a DH-U item that is the handoff's own rule: the recommended option where the prototype must show something, with a visible "To be decided" chip (handoff §11.1). The common updates after any answer (the DH-U or DH-T row, the §11 totals and DH-C02's lists) are in §6 and are not repeated here.

DQ-05 Requiredness default on a question¶

Screen area: question management and designer.
Source: DH-U38 (handoff §11.1, §5.22 editor item 3); VM §4.1; ACD §3.11.
Context: In a Versioned project each form decides whether a question is Required or Optional. Import templates carry requiredness per row, so a question could also carry a default that is copied into a form when the question is added.
Options: (a) per form only: the editor has no Required field in Versioned projects; (b) a question-level default copied when the question is added to a form, with the form's setting authoritative: the editor shows a default, and form composition shows the copied value.
Recommendation: (b) (PROPOSAL): import templates carry requiredness per row, and the default never changes an existing form.
If still open at the handoff: (b) with a "To be decided" chip.
What the answer changes in the pack: §5.22 editor item 3; DH-C101 (Requiredness), DH-C104, DH-C113 (the preview's Required or Optional); DH-S56.
Answer: Decided: form-level Required default, by Chris's required-by-default answer of 6 October 2026 (decision register §1.17, item 1): requiredness stays form-owned; the form-level default for a newly pinned question is Required; Optional stays under advanced settings with a warning ("reviewers can skip this without saying why"), discouraged and mainly for backward compatibility. This is option (a), amended by the Required default. The reading that a separate question-level default (option (b)) is not needed is to be confirmed in the Codex session. Whether an import row's requiredness sets the pin is a brief detail (ACD §3.11). Rolled into the handoff on 6 October 2026 (DH-U38, §5.22, §5.24, DH-C101, DH-C104, DH-C121).
Decided by / date: Chris, 6 October 2026 (planning session); Decided-amended.

DQ-06 Moving a question to another parent or entity type¶

Screen area: question management and designer.
Source: DH-U39 (handoff §11.1); VM §3.1, §3.5, §3.8; contracts C4 (question identity).
Context: A question's parent and entity type are part of its identity, so moving a published question would strand its answers and versions.
Options: (a) always refused, offering "Copy to …" (a new question that records it was copied) and optional retirement of the original: the tree only reorders within a parent; (b) free moves for a never-published question and copies only for a published one: "Move to …" or a drag across parents for unpublished questions, "Copy to …" for published ones.
Recommendation: (b): a never-published question has no answers or versions to lose.
If still open at the handoff: (b) with a chip; (a)'s refusal path is part of (b).
What the answer changes in the pack: §5.22 tree item 3; DH-C101, DH-C102; a move or copy step in DH-S52 to DH-S54 if Chris wants one walkable.
Answer: Not yet answered.
Decided by / date:

DQ-07 Where question import starts¶

Screen area: question management and designer.
Source: DH-U40 (handoff §11.1); harvest map H-IMP-05; ACD §3.4, §3.11.
Context: Questions can be imported from a template file into one project, with a preview that equals the result. The Catalogue is application-wide and administered.
Options: (a) the Questions and entity types toolbar; (b) inside the Catalogue; © both.
Recommendation: (a): an import copies into one project, while the Catalogue is application-wide and administered.
If still open at the handoff: (a) with a chip; DH-C113 already places it on the toolbar.
What the answer changes in the pack: §5.22 entry points; DH-C113; DH-C114 under (b) or ©; DH-S64.
Answer: Not yet answered.
Decided by / date:

DQ-08 Copying definitions from another project¶

Screen area: question management and designer.
Source: DH-U17 (handoff §11.1, DH-C114); ACD B5 (ACD §12.5); status page CI-11; owner-session integration §7.3.
Context: The amended D2-15 names catalogue routes for reuse: direct entry, project sharing and publication requests. Earlier plans also let an admin copy straight from another project they administer (AC-R1a-10 (retired; now AC-R1a-10r)).
Options: (a) keep it, with the same provenance shape as a catalogue copy: a "Copy from another project" entry beside "Copy from the catalogue"; (b) catalogue only: that entry disappears.
Recommendation: (a), because guided setup (SET1) and existing plans rely on it.
If still open at the handoff: the entry carries a "To be decided" chip (DH-C114).
What the answer changes in the pack: DH-C114, DH-C88; the §5.14 entry points, where "Copy from another project" would sit beside "Copy from the catalogue".
Answer: Not yet answered.
Decided by / date:

DQ-09 What the inference beta covers¶

Screen area: question management and designer (Design › Concepts & rules and the cohort pages).
Source: DH-U21 (handoff §11.1); TI §12 ("Scope of the beta"); CPR §3.7 and §12 item 4; status page CI-17; owner-session integration §7.3.
Context: Inference starts as an opt-in beta, off by default (OS-A19). The S5 amendment says the "advanced classification/rule/inference capability" starts in beta. Rule authoring and explicit cohort recording (lane C1) could each sit inside or outside that beta.
Options: (a) the beta covers rule authoring, rule evaluation and inference results, while C1's explicit recording follows its own enablement: the cohort pages and shared concepts show without the beta, and the rule pages and inference panels need it; (b) the beta also gates C1's explicit classification: Concepts & rules and the cohort pages appear only after opt-in; © CPR's reading (CPR §3.7 and §12 item 4, PROPOSAL): rule authoring and publication sit in C1, outside the beta, and only rule evaluation and inference sit in the beta: Concepts & rules and the cohort pages show without the beta, and only the inference panels need it.
Recommendation: (a), as closest to S5's wording, while ordinary annotation stays usable without opting in; © is the alternative the classification specification proposes. 6 October 2026: the three options replace the earlier two.
If still open at the handoff: (a) with a chip on the rule pages; DH-C18 and DH-C19 already show inference panels only when the project opted in.
What the answer changes in the pack: §5.21, §5.26; §4.1 rail under (b); DH-C15, DH-C18, DH-C19, DH-C90; DH-S39.
Answer: the record says Chris said the recommendation makes sense: only rule-writing and inference require the beta. The record's status line: "Approved, option (a): rule authoring/publication, rule evaluation and inferred results require explicit project beta opt-in; ordinary annotation and explicit group/classification recording follow their own availability and do not require inference-beta opt-in. This does not accelerate classification delivery or introduce a separate ordinary review workflow. It is a class B clarification, not a prerequisite to sending the design pack. Implementation remains on hold." Option ©, CPR's reading that rule authoring sits outside the beta, is not adopted, so CPR's rules, flows and amendments change to match: lane C1 keeps explicit recording, shared concepts and per-paper mappings, and versioned project rules are authored only with the beta on. Rolled into the handoff on 6 October 2026 (DH-U21; §5.21, §5.26, §6.2, DH-C15, DH-C18, DH-C90, DH-S39, §12 and the §13 prompt; the rule pages lose their "To be decided" chip and appear only after the beta opt-in).
Decided by / date: Chris, 6 October 2026 (Codex discussion; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18); Decided.

DQ-10 Default target-one handling for new forms¶

Screen area: forms and publication.
Source: DH-U01 (handoff §11.1, §6.2); RS §12 ("Default for targetOneHandling"); status page CI-02; owner-session integration §7.3.
Context: When a form's reviewer target is one, the form version chooses Accept automatically (a Single annotator result) or Require human reconciliation (one extracts, one checks). Both are decided; only the default for new forms is open.
Options: (a) Accept automatically; (b) Require human reconciliation; © no default, choose at creation. The design difference is the preselected value in the form's reconciliation block and templates, or a required choice under ©.
Recommendation: (a), visibly chosen in templates (RS §12; it follows Q-29's retained path).
If still open at the handoff: (a) preselected with a chip; the §6.2 row already reads "To be decided (DH-U01)".
What the answer changes in the pack: the §6.2 target-one row; DH-C27. DH-S17 and DH-S18 set the handling explicitly and stay as they are.
Answer: Not yet answered.
Decided by / date:

DQ-11 Existing Study overrides when the standard target changes¶

Screen area: forms and publication.
Source: RD-R16 (RD §12, "Override treatment at publication" and ambiguity 3); status page CI-10; owner-session integration §7.3. No DH-U entry.
Context: A Study can carry its own target, for example after an additional-review request. When the form's standard target changes through publication, each such override needs a defined treatment; the owner asked for an explicit definition, and RD-R16's treatment set is a PROPOSAL.
Options: (a) RD-R16 as drafted: an explicit keep, rebase or remove choice per override, with the suggested default keeping each Study's effective target and flagging redundant or lower overrides; the preview lists every override. The sources give only (a); these alternatives are this document's illustrations: (b) the same choice with a different default, such as rebase; © one treatment for every override in the publication, a single control in the preview.
Recommendation: (a): no effective target changes silently (RD-R16).
If still open at the handoff: the handoff shows (a) with a "To be decided" chip (§5.9 "Target-only publication", DH-S27; chip added 5 October 2026). Nothing more is needed.
What the answer changes in the pack: §5.9 "Target-only publication"; DH-C26, DH-C85; DH-S27.
Answer: Not yet answered.
Decided by / date:

DQ-12 Suspending results below a raised target¶

Screen area: forms and publication.
Source: DH-U26 (handoff §11.1, §5.9); RS §12 ("Suspension of results below a raised target"); RS-R10; RD §4.9; status page CI-14.
Context: When a form's standard target rises, for example from one to two, existing accepted results have fewer reviewers than the new target.
Options: (a) offer keep (the default, labelled "below current target (1 of 2)") and suspend: a choice in the publication preview and a "Suspended" standing in accepted-result history; (b) keep only: no choice and no Suspended standing.
Recommendation: (a), with keep as the default.
If still open at the handoff: (a) with a chip on the suspend choice.
What the answer changes in the pack: §5.9; DH-C75 (the Suspended standing); DH-S27.
Answer: Not yet answered.
Decided by / date:

DQ-13 Population context placement¶

Screen area: forms and publication (the reviewer form's category tabs).
Source: DH-U10 (handoff §11.1, DH-C65); RC8 (handoff §2.7; register §4); validation U3 (open questions §3).
Context: In forms with cohorts, the reviewer needs to see which population they are annotating without the form being pushed down.
Options: (a) a header chip; (b) the first category tab; © the source card.
Recommendation: (a), tested against normal tabs and numbering.
If still open at the handoff: the header chip marked "placement to be validated" (DH-C65); this is a user-validation item, so the prototype carries it either way.
What the answer changes in the pack: DH-C65; §4.3 Study header.
Answer: Not yet answered.
Decided by / date:

DQ-14 Own Unsure and progression¶

Screen area: reconciliation and screening.
Source: DH-U02 (handoff §11.1, §5.2); RS §12 ("Own Unsure and progression"); RS-R47; SP §3.4; status page CI-05.
Context: Under the stage default "Own Include sufficient", a reviewer who includes a Study can move on to the next step before the team result. The question is whether their own Unsure does the same.
Options: (a) yes for their own progression, never for the team's Include: the next step unlocks after own Unsure; (b) treated as no decision: the step stays Locked, "Waiting for the team's screening result"; © a per-profile setting, adding a control to the profile.
Recommendation: (a), because D4-01 treats Unsure like Include for availability and the S1 amendment keeps it out of collective agreement.
If still open at the handoff: (a) with a chip at the step selector.
What the answer changes in the pack: §5.2; DH-C45; DH-C21 under ©; DH-S09.
Answer: Not yet answered.
Decided by / date:

DQ-15 Result when every decision is Unsure¶

Screen area: reconciliation and screening.
Source: DH-U03 (handoff §11.1, §5.6 table); RS §5.10 (item 1 of "Rows and rules still to specify"); RS §12 ("Unsure transition rows"); status page CI-08 (its all-Unsure part).
Context: Unsure handling is bounded and falls back to adjudication (OS-A16), but the owner's example did not say what happens when every decision is Unsure.
Options: (a) adjudication: the Study goes to the adjudication queue; (b) a collective "Unsure (not excluded)" result that keeps the Study available to stages filtering on "not Excluded": a new result state, also a filter value; © further review beyond the bound, which the owner's no-repeated-review rule rules out.
Recommendation: (a), with (b) only as an explicit per-profile option if Chris approves it.
If still open at the handoff: "To be decided" in the transition table (§5.6).
What the answer changes in the pack: the §5.6 table's last row; DH-C21; DH-C34's filter values under (b); DH-S24.
Answer: Not yet answered.
Decided by / date:

DQ-16 Filling answers from a single candidate¶

Screen area: reconciliation and screening.
Source: DH-U06 (handoff §11.1, DH-C69); RD2 (handoff §2.7; register §4).
Context: Agreeing answers from two or more candidates are filled in with the autofill marker. In a one-candidate checking task, or for a one-sided item the reconciler keeps, there is nothing to agree with.
Options: (a) fill with the autofill marker and the unseen-control warning; (b) leave empty with click-to-copy pills; © a per-form setting.
Recommendation: (a) for one-candidate checking tasks and kept one-sided items, owner-visible.
If still open at the handoff: (a) with a chip; both patterns already exist in the workspace, so (b) can be a Tweaks variant.
What the answer changes in the pack: §5.5 steps; DH-C69, DH-C71; DH-S18, DH-S20.
Answer: Not yet answered.
Decided by / date:

DQ-17 Telling a reviewer that a copied hint makes their answer informed¶

Screen area: reconciliation and screening.
Source: DH-U07 (handoff §11.1, §5.4); VS2 (register §1.3); UX strategy §7.3.
Context: Copying an accepted-answer hint makes the answer informed rather than independent for agreement statistics. Exposure is recorded automatically.
Options: (a) an inline label on each hint plus a session note; (b) a one-time interstitial before the first hint; © both.
Recommendation: (a), because hints are shown by default and exposure is recorded automatically; validate with users.
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: §5.4; DH-C56; DH-S07.
Answer: Not yet answered.
Decided by / date:

DQ-18 AI source type under blinded adjudication¶

Screen area: reconciliation and screening.
Source: DH-U08 (handoff §11.1, §5.6 step 2); RI A2 (RI §12); RS §12 ("Source type under blinded adjudication").
Context: An adjudicator may see a tied decision that came from an AI screening model. Human identities stay blinded either way.
Options: (a) always show "AI screening model"; (b) hide the source type when the profile is blinded; © a profile setting.
Recommendation: ©, defaulting to showing the source type, because the terminology decision requires explicit AI attribution and the adjudicator needs the confidence and threshold.
If still open at the handoff: © with a chip, inside the "Later release" AI screening lane.
What the answer changes in the pack: §5.6 step 2; §5.19; DH-C21, DH-C81, DH-C93; DH-S44.
Answer: Not yet answered.
Decided by / date:

DQ-19 Re-acceptance after a correction under Accept automatically¶

Screen area: reconciliation and screening.
Source: DH-U25 (handoff §11.1); RS §12 ("Re-acceptance under AutoAccept"); RS-R09; status page CI-06.
Context: Under Accept automatically a single completed review becomes a Single annotator result. The question is what happens when that reviewer corrects their review and completes again.
Options: (a) the rule writes the next Single annotator version: history shows a new automatic version; (b) the earlier version stays current, flagged, until someone explicitly re-accepts: a flagged result and a re-accept action.
Recommendation: (a): Accept automatically is the admin's explicit, versioned acceptance policy, and the only input author is the candidate, who was warned before commit.
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: §5.5 "Target one"; DH-C71, DH-C75; DH-S17.
Answer: Not yet answered.
Decided by / date:

DQ-20 What the self-reconciliation override grant allows¶

Screen area: reconciliation and screening.
Source: RS §12 ("Q-36 override reading"); RS-R17, RS-R18; status page CI-04; owner-session integration §7.3. No DH-U entry.
Context: A member may not reconcile a Study they reviewed. Q-36's package text pairs "no ordinary self-reconciliation by default" with "explicit override grants", which can be read two ways.
Options: (a) the override grant permits self-reconciliation, with every use recorded in provenance (the adopted reading); (b) "adjudication overrides" means only overriding an existing outcome, with no self-reconciliation path: DH-S23 goes and the grant describes outcome overrides.
Recommendation: (a), because the package pairs the two phrases (RS §12).
If still open at the handoff: the handoff presents (a) with a "To be decided" chip (§5.5, the §6.2 row and DH-S23; chip added 5 October 2026). Nothing more is needed.
What the answer changes in the pack: §5.5 "Who may reconcile"; the §6.2 "Self-reconciliation override" row; DH-C82; DH-S23.
Answer: Not yet answered.
Decided by / date:

DQ-21 What the first form shows after its shared accepted answer is revised¶

Screen area: reconciliation and screening.
Source: DH-U36 (handoff §11.1 and the §13 prompt); D2-09 (register §1.16); RD §4.14, RD-R10; AC-R2d-08.
Context: Under D2-09 the second form's reconciler may revise a shared accepted answer, and both forms then show the new value (DH-S51). Open is how the first form labels it, whether its reconcilers are told, and whether its task changes state.
Options: (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 new task state and work item.
Recommendation: (a): affected authors are informed without their work being rewritten (Q-27); © creates work the owner did not ask for.
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: §5.5 "After Complete"; DH-C99; DH-S51; DH-C41's Inputs changed count under ©; the §13 prompt's "DECIDED SINCE THE LAST SPECIFICATION" block, which says DH-U36 stays open.
Answer: Not yet answered.
Decided by / date:

DQ-22 Bulk reassignment of reconciliation assignments¶

Screen area: reconciliation and screening.
Source: DH-T17 (handoff §11.2); RD9 (handoff §2.7; register §4).
Context: An admin can assign a reconciliation task to a member or group and release started work. Whether many tasks can be reassigned at once is still open.
Options: (a) absent from this iteration; (b) a "Reassign selected" action on the Reconcile pool for admins, with the active-work preview.
Recommendation: (a), as the handoff shows: single assignment and release cover the decided behaviour (RA1 to RA4), and the RS brief can add bulk reassignment for R4a.
If still open at the handoff: absent (DH-T17).
What the answer changes in the pack: §5.5 "Assignment and release"; DH-C41.
Answer: Not yet answered.
Decided by / date:

DQ-23 Merge commit while conflicts are pending¶

Screen area: reconciliation and screening (duplicate merge).
Source: DH-U13 (handoff §11.1); DM §12 ambiguity 1.
Context: A duplicate merge resolves conflicts between the input Studies before it commits.
Options: (a) never: Commit stays disabled until every conflict is resolved; (b) by explicit choice, holding the conflicting contribution out of current counts until resolved: a "Commit with pending conflicts" path and a held state on the consolidated Study.
Recommendation: (a) for the MVP, because the consolidation says resolution precedes commit; revisit after pilots.
If still open at the handoff: (a), as §5.7's Incomplete state shows, with a chip.
What the answer changes in the pack: §5.7; DH-C86; DH-S33.
Answer: Not yet answered.
Decided by / date:

DQ-24 Identity of the consolidated Study¶

Screen area: reconciliation and screening (duplicate merge).
Source: DH-U14 (handoff §11.1); DM §3.10; DM §12 ambiguity 2.
Context: A merge creates one current Study from duplicates. It can be a new record or one of the inputs.
Options: (a) a new identity, with the inputs tombstoned: "S-512 is current. Consolidated from S-204 and S-377"; (b) one input survives: "S-204 is current", and an unmerge writes reversal versions on the survivor.
Recommendation: (a), which matches the owner's wording and keeps both originals' histories untouched (DM §3.10).
If still open at the handoff: (a), as §5.7 shows, with a chip.
What the answer changes in the pack: §5.7's steps and states; DH-C86; DH-S33, DH-S34.
Answer: Not yet answered.
Decided by / date:

DQ-25 Where "finish started work after leaving the pool" lives¶

Screen area: stages and pools.
Source: DH-U04 (handoff §11.1, §5.20, §6.2); SP-AMB-01 (SP §12.4); OS-A05; status page CI-09.
Context: Work already started may be finished after a Study leaves a stage pool (default allow), and an admin may restrict that. The owner did not say where the restriction lives.
Options: (a) one stage setting; (b) a step setting beside the saved-work setting; © a stage default with a step-level restrict-only override.
Recommendation: ©, shown together with saved work as "Finishing work already started".
If still open at the handoff: © with a chip.
What the answer changes in the pack: §5.20 steps editor; the §6.2 row; DH-C36; DH-S11, DH-S12.
Answer: Not yet answered.
Decided by / date:

DQ-26 Where reviewer-pool browsing is configured¶

Screen area: stages and pools.
Source: DH-U05 (handoff §11.1, §5.20, §6.2); SP §3.6; OS-A27.
Context: Reviewers may optionally browse their blinded study pool within a stage.
Options: (a) a stage setting; (b) a step setting; © a form setting; (d) a project setting.
Recommendation: (a), off by default.
If still open at the handoff: (a) with a chip (DH-C38).
What the answer changes in the pack: §5.20; the §6.2 row; DH-C38; DH-S14.
Answer: Not yet answered.
Decided by / date:

DQ-27 Per-step Skip¶

Screen area: stages and pools (the reviewer workspace's steps).
Source: DH-U09 (handoff §11.1, DH-C64); RC6 (handoff §2.7; register §4); validation U2 (open questions §3).
Context: Skip moves the reviewer to another Study and records nothing. With several steps per Study, a reviewer might want to skip or hand off one step only.
Recommendation: keep (a) as the default and prototype (b) as a variant for testing.
If still open at the handoff: (a), with (b) as a Tweaks variant (DH-C64).
What the answer changes in the pack: DH-C64; the Skip shortcut in §5.2.
Answer: Not yet answered.
Decided by / date:

DQ-28 Accepted-answer filter clauses and Single annotator results¶

Screen area: stages and pools.
Source: DH-U28 (handoff §11.1); SP-AMB-02 (SP §12.4).
Context: A stage filter can include Studies by an accepted answer ("Species is Rat"). Some accepted results are Single annotator results that no second person checked.
Options: (a) count any authority; (b) human-reconciled, adjudicated and merge-resolved only; © any authority by default, with an optional per-clause restriction in the filter editor.
What the answer changes in the pack: §5.20 filter editor; DH-C34.
Answer: Not yet answered.
Decided by / date:

DQ-29 Who owns timeout, limit and capacity for screening-only work¶

Screen area: stages and pools.
Source: DH-U29 (handoff §11.1); SP-AMB-03 (SP §12.4).
Context: For annotation, the form owns the inactivity timeout, the in-progress limit and the capacity cap. Screening-only work needs an owner too.
Recommendation: (a); in a combined step each activity follows its own owner.
If still open at the handoff: (a) with a chip: the operational settings appear on the profile page.
What the answer changes in the pack: the §6.2 settings table; the profile page (DH-C20 to DH-C22) or stage settings (DH-C38).
Answer: Not yet answered.
Decided by / date:

DQ-30 What the "Later release" badge on accepted-answer clauses says¶

Screen area: stages and pools.
Source: DH-U34 (handoff §11.1, §5.20); R-AMB-02 (rollout plan §7.6); SP §3.3.
Context: Accepted-answer clauses in stage filters stay in scope but need accepted results, so they carry a "Later release" badge. Whether they ship inside GA is R-AMB-02 (recommended: an R4a increment inside GA scope).
Options: (a) "Later release" alone, naming no release; (b) "Later release · inside GA scope"; © "Later release · after GA".
Recommendation: (a) until Chris answers R-AMB-02; if he confirms R-AMB-02's recommendation, (b) becomes accurate.
If still open at the handoff: (a).
What the answer changes in the pack: §5.20; DH-C34. Outside the pack: rollout plan §7.6 R-AMB-02.
Answer: Not yet answered.
Decided by / date:

DQ-31 What trainees see after an attempt¶

Screen area: stages and pools (training steps).
Source: DH-U19 (handoff §11.1); TI-R10; TI §12 ("Feedback disclosure default"); status page CI-15.
Context: A training policy decides what a trainee sees after submitting an attempt. The default is open.
Options: (a) per-item correctness after assessment, and reference answers after a pass or when no retry remains; (b) score only; © full references after submission.
Recommendation: (a), as TI-R10 proposes.
If still open at the handoff: (a) as the policy default, with a chip.
What the answer changes in the pack: §5.15 trainee and designer flows; DH-C89; DH-S38.
Answer: As recommended: option (a). Trainees see right or wrong per item after assessment; the expected answers appear only after a pass or when no retry remains (TI-R10). Rolled into the handoff on 6 October 2026 (DH-U19, §5.15, DH-C89).
Decided by / date: Chris, 6 October 2026 (planning session; decision register §1.17); Decided.

DQ-32 A live step that depends on passed training¶

Screen area: stages and pools.
Source: DH-U20 (handoff §11.1); TI-R23; TI §12 ("Optional step dependency on passed training (DQ-32)"); SP §3.4; contracts C6; status page CI-16; decision register §1.17. Rewritten on 6 October 2026.
Context: Passing training can admit a reviewer to a named project group, and that group's existing grants let them review live work (S4, decided). The question is whether anything else should gate live work on training. Chris discussed it on 6 October 2026 and is unsure, so it stays open.
Gating analysis. Where a gate could sit:
Group admission (decided, S4). The policy names a group; a pass adds the reviewer to it, automatically or after approval; the group's grants decide which stages and activities they may work on, through the Q-03 permission model. One mechanism, audited and checked against escalation (TI-R17, TI-R18).
A step dependency (TI-R23's optional PROPOSAL). A live step lists "Passed training step" in Depends on. It duplicates the grant: a reviewer could hold the grant and still be locked, or pass and still lack the grant, and "Why can't I review this?" needs two explanations.
A profile or form gate. Each screening profile or annotation form names the training it needs. It ties training to definitions that several stages share and needs its own refusals, explanations and conversion rules.
Re-qualification. An admission that expires, or retraining when a reference version changes. No owner decision asks for it; it can come later as a policy option on top of group admission.
Options: (a) group admission as the only access gate, at stage and activity level through the group's existing grants; no separate step, profile or form gates; re-qualification later as a policy option; TI-R23's step dependency left out of the MVP. (b) (a) plus TI-R23's explicit step dependency: "Passed training" in the steps editor's Depends on, and a Locked reason such as "Pass the training first". © Gates on profiles or forms as well (this document's illustration; no source proposes it).
Recommendation: (a): one access path to build, explain and audit, the decided S4 gate already covers the need, and a later policy option can add re-qualification.
If still open at the handoff: (a), with (b) carrying a chip.
What the answer changes in the pack: §5.15; §5.20 steps editor; DH-C36, DH-C89; DH-S38; DH-U20's status. Outside the pack: TI-R23, TI §12, contracts C6 and T-TI-00.
Answer: Not yet answered. (6 October 2026: Chris is unsure; no answer is recorded.)
Decided by / date:

DQ-33 Lifting a contribution exclusion¶

Screen area: people and messages.
Source: DH-U15 (handoff §11.1, DH-C83); ACD B2 (ACD §12.5).
Context: An admin can exclude a member's contributions from current use, with a preview and a reason (OS-A24). The owner did not say whether that can be reversed.
Options: (a) yes, as a separate recorded action with its own preview and reason; (b) no; a new contribution is needed.
Recommendation: (a).
If still open at the handoff: a "Lift exclusion" action with a chip.
What the answer changes in the pack: §5.18 (the Historical row's "any lift"); DH-C83; DH-S43.
Answer: Not yet answered.
Decided by / date:

DQ-34 Who sees and restores deleted projects¶

Screen area: people and messages.
Source: DH-U16 (handoff §11.1); ACD B4 (ACD §12.5).
Context: Ordinary project deletion is reversible, and "an authorised admin" restores the project from a restricted Deleted projects view (OS-A25).
Options: (a) the project owner and Delete holders for their projects, plus application administrators for any project; (b) application administrators only; © the owner only.
Recommendation: (a).
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: §4.1 (the Application entry); §5.17; DH-C92; DH-S42.
Answer: Not yet answered.
Decided by / date:

DQ-35 Default email content for answers and free text¶

Screen area: people and messages.
Source: DH-U18 (handoff §11.1, §5.16); ACD B6 (ACD §12.5).
Context: Emails may include answer values and free text, configurable per project (OS-A26).
Options: (a) off by default; (b) on by default.
Recommendation: (a), because sent email cannot be recalled.
If still open at the handoff: (a), both switches off, with a chip.
What the answer changes in the pack: §5.16 content policy; DH-C91; DH-S41.
Answer: Not yet answered.
Decided by / date:

DQ-36 Contribution exclusion on Classic projects¶

Screen area: people and messages.
Source: DH-U31 (handoff §11.1, §5.18 Unavailable row); ACD B7 (ACD §12.5).
Context: Exclusion is specified for converted projects. Classic projects still write through the legacy code.
Options: (a) converted projects only; (b) Classic projects as well, through the legacy writers.
Recommendation: (a); Classic projects keep contributions after a membership is disabled until they convert.
If still open at the handoff: (a): "Exclusion is available after this project is converted".
What the answer changes in the pack: §5.18; §7.7; DH-C83.
Answer: Not yet answered.
Decided by / date:

DQ-37 Mixed route provenance under stage-scoped exclusion¶

Screen area: people and messages.
Source: DH-U32 (handoff §11.1, §5.18); ACD B3 (ACD §12.5).
Context: An exclusion scoped to one stage meets shared sessions whose versions came through more than one stage.
Options: (a) the admin chooses per group before commit; (b) decide by the route of the current version only; © decide by the route of each answer.
Recommendation: (a), with (b) as the suggested choice in the interface.
If still open at the handoff: (a) with (b) preselected, with a chip.
What the answer changes in the pack: §5.18; DH-C83; DH-S43.
Answer: Not yet answered.
Decided by / date:

DQ-38 Notices for a deleted project¶

Screen area: people and messages.
Source: DH-U33 (handoff §11.1); ACD B8 (ACD §12.5).
Context: A deleted project may still have unread notices in members' inboxes.
Options: (a) they leave unread counts and show "Project deleted", returning if the project is restored and the item is still open; (b) they stay unchanged.
Recommendation: (a).
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: §5.16 inbox; §5.17; DH-C91, DH-C92; DH-S42.
Answer: Not yet answered.
Decided by / date:

DQ-39 Extra confirmation beyond the impact preview¶

Screen area: people and messages (admin actions).
Source: DH-T13 (handoff §11.2); OD6 (handoff §2.7; register §4).
Context: Every admin action that affects reviewers shows an active-work impact preview (consolidation §6). OD6 left open which transitions, if any, also need an extra explicit confirmation.
Options: (a) the impact preview only; (b) the preview plus an extra explicit confirmation, for example typing the project name, for named transitions such as project deletion, contribution exclusion and a merge commit.
Recommendation: (a) for this iteration, as the handoff instructs. This reason is this document's: the named transitions are reversible (a deleted project can be restored, a merge can be unmerged, and an exclusion can be lifted if DQ-33 is (a)).
If still open at the handoff: the impact preview only (DH-T13).
What the answer changes in the pack: §5.8; DH-C83, DH-C84, DH-C86, DH-C92.
Answer: Not yet answered.
Decided by / date:

DQ-40 Holding edits on the device during a connection loss¶

Screen area: devices.
Source: DH-U11 (handoff §11.1, the §5.1 Offline row); UX A1 (UX §12); status page CI-13; owner-session integration §7.3.
Context: The UX strategy proposed a bounded local copy of unsaved answers, replayed on reconnect. The owner said no offline writes are authorised and protected data must not be cached by accident, so holding answer data on the device needs an explicit answer.
Options: (a) bounded in-session holding, cleared at logout, completion and access loss, and replayed only if the base still matches: "Offline. Your latest edits are held until you reconnect."; (b) memory only: closing the tab loses unacknowledged edits, so the copy must warn; © none until the PWA design: editing pauses while offline.
Recommendation: (a), described as connectivity resilience within one editing session.
If still open at the handoff: (a)'s copy, with a chip on how edits are held.
What the answer changes in the pack: the §5.1 Offline row; DH-C46; §7.8.
Answer: Not yet answered.
Decided by / date:

DQ-41 How converted single-reviewer forms behave¶

Screen area: conversion.
Source: DH-U22 (handoff §11.1, §6.2); BC A1 (BC §12.4); RS-R04a; RS §12 ("Converted target-one forms"); status page CI-03.
Context: Legacy single-reviewer projects export the reviewer's answers and have no accepted results. Converting them to Accept automatically would create accepted results legacy never had; Require human reconciliation would add work legacy never had.
Options: (a) "Single annotator, not accepted": a conversion-only setting with no accepted results and no reconciliation work, and later acceptance only through a publication; (b) accept automatically at conversion; © the admin chooses per form in the wizard.
Recommendation: (a), as the faithful baseline.
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: the §6.2 target-one row; the §5.10 mapping step; DH-C27 (the value a converted form shows), DH-C87; DH-S35.
Answer: Not yet answered.
Decided by / date:

DQ-42 Legacy screening meaning when no admin confirms¶

Screen area: conversion.
Source: DH-U23 (handoff §11.1, §5.10 step 3); BC A2 (BC §12.4).
Context: The conversion wizard asks an admin what the legacy screening meant (for example title and abstract screening). Some projects have no active admin.
Options: (a) convert labelled "Legacy project screening (meaning not confirmed)" with no PRISMA phase until someone confirms; (b) block until an admin confirms; © a CAMARADES operator confirms on the owner's behalf.
Recommendation: (a): faithful, and it does not leave old projects stuck.
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: §5.10 step 3; DH-C87.
Answer: Not yet answered.
Decided by / date:

DQ-43 Deferring a scheduled conversion wave¶

Screen area: conversion.
Source: DH-U24 (handoff §11.1); BC A4 (BC §12.4).
Context: After the pilots, every remaining project converts in scheduled waves, with notice.
Options: (a) one bounded deferral with a reason during the notice period, recorded as a blocker with a review milestone: a "Request deferral" action; (b) no deferral.
Recommendation: (a) (PROPOSAL); it never makes a project permanently legacy.
If still open at the handoff: (a) with a chip.
What the answer changes in the pack: §5.10; DH-C87.
Answer: Not yet answered.
Decided by / date:

DQ-44 Scope of conversion-wave approvals¶

Screen area: conversion.
Source: BC A3 (BC §12.4); BC-R39; status page CI-12; owner-session integration §7.3. No DH-U entry.
Context: Each project's conversion has a manifest, its mapping. In universal waves, the question is what Chris's approval of a wave covers.
Options: (a) every project owner approves their own manifest: the wizard's Approve step as §5.10 step 6 shows it; (b) Chris's wave approval covers every manifest: no owner approval in waves; © the wave approval covers default faithful mappings with no unresolved findings, and project-specific choices need the owner or a delegate: "Covered by the wave approval" for default-only projects and owner approval otherwise.
If still open at the handoff: the handoff shows owner approval (step 6) with a "To be decided" chip and no wave-covered state (chip added 5 October 2026). Nothing more is needed.
What the answer changes in the pack: §5.10 step 6 and its states; DH-C87; DH-S35.
Answer: Not yet answered.
Decided by / date:

DQ-45 Names for project modes¶

Screen area: conversion.
Source: DH-U30 (handoff §11.1, §3.2); UX strategy §3.3.
Context: A project before conversion and after it needs a name on every screen that shows its mode.
Options: (a) "Classic workflow" and "Versioned workflow"; (b) other wording after card-sort testing.
Recommendation: (a) as working labels.
If still open at the handoff: (a) as working labels, with a chip on the workflow version badge.
What the answer changes in the pack: the §3.2 glossary; §4.1; §7.7; DH-C04, DH-C13; every scenario that names a Classic-workflow project; the §13 prompt.
Answer: Not yet answered.
Decided by / date:

DQ-47 Guidance for trainees before an attempt¶

Screen area: stages and pools (training steps). Added 6 October 2026.
Source: Chris's question in the planning session of 6 October 2026 (whether trainees will get guidance to read before being tested); TI §3.10, TI-R37 and TI-AE26 (PROPOSAL); handoff DH-U43, DH-C125 and DH-S73; decision register §1.17.
Context: The training specification had no guidance for trainees to read before an attempt. TI-R37 now proposes it. Guidance never holds expected answers, and it is not the form's operational guidance (A-15), which it may link to.
Options: (a) versioned guidance on the training step (rich text, links or files), shown before the attempt, with an optional "I have read this" acknowledgement and a policy choice on whether it stays visible during the attempt; attempts pin the version they started with. The sources give only (a); these alternatives are this document's illustrations: (b) guidance always visible, with no acknowledgement option; © no guidance on the step, with designers linking material from the form's guidance.
Recommendation: (a), yes: it answers Chris's question with one small versioned record, and the acknowledgement and visibility choices stay per policy.
If still open at the handoff: (a), with a "To be decided" chip (DH-C125).
What the answer changes in the pack: §5.15; the §6.2 training guidance row; DH-C125; DH-S73; DH-U43's status. Outside the pack: TI-R37's PROPOSAL label, TI-AE26, AC-TR1-16 and T-TI-02.
Answer: Not yet answered.
Decided by / date:

DQ-48 Custom reference questions: at GA or with lane C1, and which targets¶

Screen area: question management and designer (the question editor), with the reviewer's record picker. Added 6 October 2026.
Source: CPR §10.2 and §12 items 1 and 2; CPR-R22; the owner discussion of 6 October 2026 (decision register §1.17, still open); handoff DH-U44 and DH-C126 to DH-C129; T-CP-00.
Context: Today five questions point at other records (a cohort's disease models, treatments and outcomes; an experiment's cohorts; an outcome's PDF graphs). All five are fixed in code, and project questions cannot be lookups. The classification specification generalises them into designer-defined reference questions whose answer stores a record's identity, never its name. Whether they are needed at the first general release, and which target types they cover, is not decided.
Options: Timing: (a) with lane C1, not a GA prerequisite; (b) before GA as a separate slice. Target types: (a) named records only (definitions, cohorts, outcome measures, experiments, populations); (b) named records plus configuration records (shared-concept versions, and rule versions for applicability answers); © (b) plus records in other Studies and source regions.
Recommendation: Timing (a), unless a GA pilot form needs one: legacy SyRF has no custom reference questions, so nothing regresses, and the five fixed lookups keep working throughout (CPR-R21). Targets (b): cross-Study references wait for report grouping (D4-08) and cross-Study blinding rules; source regions stay system-only (the PDF-graph lookup); outcome-schema versions keep C14's dedicated system question.
If still open at the handoff: the reference answer type with the "Later release" badge and a chip, offering (b)'s target types (DH-C126).
What the answer changes in the pack: §5.25; DH-C126 to DH-C129 (their badge under timing (b)); DH-S74 to DH-S76; DH-U44's status. Outside the pack: CPR-R22 and CPR §10, the rollout plan's C1 placement, T-CP-03 and the C1 acceptance rows.
Answer: Not yet answered.
Decided by / date:

5. Class C items: not design questions¶

None of these changes a layout, flow, navigation or copy beyond a placeholder the handoff already fixes. They are listed so nothing is lost.

ID	Question	Why it is not a design question	Where it will be decided
QMI-01 (X-03)	How design presence and live draft updates reach users on other API pods	Server transport; UX §12 says it shapes UX §3.8 and UX-R45, not the screens. The prototype shows presence either way	Chris, before F2 (`T-OI-02`; QM plan §9.1)
QMI-02 (X-41)	The P9 class of publication phases 1 and 2, baseline conversion, merge and unmerge staging and stage pool sweeps	Job rollback and completion rules	Chris, before F1a (`T-OI-02`; QM plan §9.2)
QMI-03 (X-24)	Statistics scope for canonical projects	How usage figures are counted at the publication boundary; the preview shows their freshness either way	Chris, before R2c's staging pilot (`T-OI-02`; QM plan §9.3)
QMI-05 (X-12)	v0 and v1 per type in the surface-area plan's D4	Storage-shape cleanup	The architecture-review session with Chris (QM plan §9.5)
X-06; R-AMB-04	Which release carries presence on design pages	Release placement; the prototype shows the target state, with presence (handoff §5.22)	`T-RD-00` and `T-UX-00` briefs (QM plan §9.6; rollout plan §7.6)
X-08	Who migrates the question editor's client state	Engineering ownership	`T-RD-00` with the state-plan owner (QM plan §9.6)
X-16	One durable-intent store	Engineering	With the persistence plan's D3; `T-RD-01` (QM plan §9.7)
X-35	The Material 3 ledger's wait on #2812	Delivery dependency	`T-UX-00`, once G0-D7 is answered (QM plan §9.6)
X-44	Which grant allows Study target overrides	Permission catalogue; capability names are working names in the prototype (DH-T07)	RD brief, `T-RD-00` (RD §6; QM plan §9.6)
X-46	The project-level gold completeness default	Already dropped by Q-04 and recorded in RS §12; nothing to show	`T-RS-00` (QM plan §9.6)
`T-SI-01`; DH-T04	Event-count outcome fields and the meaning of "variation" (Q-17)	Methodology; the schema shows "Fields to be decided"	Chris with CAMARADES methodologists, before F-O (owner-session integration §7.4)
`T-SI-02`; DH-T03	Agreement methods beyond percent agreement (Q-16, D4-12)	Statistics; kappa shows "Method pending statistical review"	A statistical reviewer through Chris, before the R5c ship gate
`T-SI-03`; DH-T05	SYRCLE, CAMARADES checklist and ARRIVE template content (D4-06)	Content; template names only, "Content pending methodologist review"	CAMARADES methodologists with the catalogue administrator
`T-SI-04`; DH-T06	ASySD parity method and thresholds (D4-21)	Method and figures; no figures shown	A deduplication specialist through Chris, before the P2a ship gate
`T-SI-05`; DH-T02	PRISMA box mapping for pool history versus review through the stage	Methodology; measures with their own labels and "Mapping to be decided"	Methodologists with the RI owner, before F6b
CI-18; DH-T12	Legal review of the joining-terms and account-deletion wording	Legal; placeholder text marked "Legal review required"	Chris routes it; recorded before the release that shows the text (ACD §12.3; ACD-AE03)
DH-T16; `T-POL-01` to `T-POL-03`	Permanent erasure, identity erasure, automatic acceptance of several agreeing candidates	Unapproved policies; never offered in the prototype	Chris only, if ever (owner-session integration §7.5)
CI-07 (RS §12)	Is FEAT-009's agreement-derived reason handling a profile rule or automatic acceptance (`T-POL-03`)?	Policy classification; the profile's must-agree answers and the adjudication queue (DH-C21, DH-C72) exist under either reading	RS brief, `T-RS-00` (F5)
CI-08 (other rows); DH-T11	The Unsure rows the owner did not state: in-flight decisions, four or more decisions, other thresholds, bounds above one, mixed sources (RS §5.10 items 2 to 6)	Rule details that produce existing states (Waiting, Included, Excluded, Awaiting adjudication); the transition table shows "To be decided". All-Unsure is DQ-15	RS brief, `T-RS-00` (F5)
DH-T01	Every numeric threshold (timeouts, limits, caps, bounds, pass marks, weights, parity figures)	Measured or set per brief and gate; shown as "Example, not approved" or empty	Each brief and gate (handoff §1.4)
DH-T07	Exact capability names and the default grant matrix	Permission catalogue; working names marked "name to be confirmed"	ACD brief, `T-AC-00` (F1b)
DH-T08	Final status wording	OS-A21 fixes the three meanings and calls the words illustrative; final words come from user validation of the prototype	F1c copy deck (`T-UX-02`), after `T-DH-03`
DH-T09	Publication pause and queued-retry messages for reviewers	Retry behaviour follows D2-10's measured protection; a neutral message is shown	RD brief, F2 part (`T-RD-00`, `T-RD-04`)
DH-T10	The outcome-schema upgrade flow	Engineering detail (OD10); "To be decided"	F-O, with the RI brief (`T-RI-00`)
DH-T14	Hints for repeatable entity instances	Needs a correspondence rule first (RS-R37 `PROPOSAL`); absent, with a "Not in MVP" note	RS brief, `T-RS-00`
DH-T15	A full global landing page	Already decided: deferred (D3-07); nothing to design	None now; only if Chris reopens D3-07
DH-T18	Match-based training scoring for repeatable entities	Scoring algorithm; manual assessment only	TI brief, `T-TI-00`
DH-T19	Lookup questions in a question import	Import capability; a refused-row example	R1a brief (`T-RD-11`; ACD §12.1, ACD-R41)
R-AMB-01	Is training (TR1) a GA prerequisite?	Release scope; the training screens are designed either way	Decided (Chris, 6 October 2026): "No, training does not gate GA", option (a) (rollout plan §7.6; decision register §1.17). No longer open
R-AMB-03	What "after the first engine release" means for XS1	Timing; the "Later release" badge covers it	Chris, through the rollout plan (§7.6)
R-AMB-05	Does `ReviewStartEligibility` start in R2a or R3a?	Engineering sequencing	Chris, through the rollout plan (§7.6)
R-AMB-06	May production conversion pilots precede GA?	Rollout policy	Chris, through the rollout plan (§7.6); each pilot through G-ADOPT
CI-01; G0-D1	Confirm the recorded reading of D4-18 ("independent of funders")	Programme governance	Chris, at G0 (`T-G0`; G0 dossier §2)
`T-G0`	G0 approval of the plan and operating model	Governance	Chris
`T-HOLD`	Lifting the implementation hold	Governance; separate from G0	Chris
G0-D4, G0-D7 to G0-D10	Dormant-PR dispositions and the notification merge train	PR management, not authorised while the hold lasts	Chris, at G0 (G0 dossier §2)
DQ-49 (added 6 October 2026)	Export overlap markers (RI-R59 to RI-R63)	Export file content and its codebook; the Data views are "Later release"	The RI and CPR briefs (`T-RI-00`, `T-CP-00`); entry below
DQ-50 (added 6 October 2026)	Recording unanswered and cleared answers, and empty text	Engineering; on screen only the history line "answered, then cleared"	Chris (an open owner item), then the RD brief (`T-RD-00`, `T-RD-01`); entry below
CPR §12 items 5 to 8 (added 6 October 2026)	Populations as author-scoped records (item 5); a deleted target in a referencing answer (item 6); direct contradiction warnings in C1 (item 7); coverage value names (item 8)	Brief-level choices; the handoff shows the recommended behaviour as `PROPOSAL` (sections 5.25 and 5.26)	`T-CP-01` (item 5); `T-CP-00` (items 6 and 7); the copy deck, `T-UX-00` (item 8)
RD §12 brief details (added 6 October 2026)	Which default reasons no value is provided a new question starts with; where optional-use counts appear; the repeatable "None reported" mechanics; mapping an option to a reason no value is provided; the versioned clear; the evidence quote's location; how agreement counts reasons no value is provided (wording updated for DQ-46, 6 October 2026)	Brief details; the handoff shows placeholders (DH-T20 to DH-T23)	`T-RD-00` and `T-RD-01`; `T-SI-02` for agreement

Class C entries with an answer field (added 6 October 2026). DQ-49 and DQ-50 are not design questions, but they came out of Chris's session or name a choice he may want to confirm, so each has the full entry below.

DQ-49 Export overlap markers¶

Class: C. It changes export files and their codebook, not a screen; the Data views carry the "Later release" badge.
Source: RI-R59 to RI-R63 and RI-AE41 to RI-AE45 (PROPOSAL); CPR §12 item 3 and CPR-R37; the classification research §3.3; T-RI-00 and T-CP-00.
Context: Papers report overlapping groups: two partitions of one population, a subset, or one control used by several comparisons. A consumer that adds such groups together double counts. The specifications propose stable population, cohort and record IDs beside labels, explicit relationships by default, inferred relationships only on request with their proof, flags for overlaps and shared controls, no sums over overlapping groups, and codebook entries for each marker.
Options: (a) RI-R59 to RI-R63 as written, for every export that carries groups; (b) markers only in X1's analysis-ready file.
Recommendation: (a): every export that carries groups needs them, or a consumer can double count.
Where it will be decided: the RI and CPR briefs (T-RI-00, T-CP-00); Chris may confirm it.
What the answer changes: RI-R59 to RI-R63; AC-C1-10, AC-X1-01 and AC-X1-03; contracts C11; in the pack, only DH-C95's export note.
Answer: Not yet answered.
Decided by / date:

DQ-50 Recording unanswered and cleared answers, and empty text¶

Class: C (engineering). On screen, only the history line "answered, then cleared" depends on it.
Source: RD §3.16, RD-R53 and RD §12 ("Recording unanswered and cleared answers"); VM §3.4 rule 4; contracts C1; Chris's question in the planning session of 6 October 2026 (decision register §1.17).
Context: With questions required by default, SyRF must say what it stores when a reviewer clears an answer, when a question is never touched, and when text is empty. Chris asked why the recommendation avoids pre-writing an "unanswered" record for every untouched question at Complete.
Options: (a) clearing writes an explicit Unanswered revision, so history shows "answered, then cleared", and it may carry metadata allowed for that state; a question never touched stays an absent answer; nothing is pre-written at Complete; empty or whitespace-only text is normalised to Unanswered on the server, and empty strings are never stored. (b) Pre-write an Unanswered record for every applicable untouched question at Complete. © Clearing writes a withdrawal revision, the mechanism used to delete entity instances, with no metadata (this document's illustration).
Recommendation: (a) (PROPOSAL). The coordinator's answer to Chris's question: a pre-written record adds no information, because absence already means never answered and each session version stores its resolved question set; applicability is derived per ancestor instance and changes after an ancestor answer or a form version changes, so pre-written records would go stale; they would cost one revision per untouched applicable question on forms of up to 2,023 questions; and every reader would have to ignore them.
Where it will be decided: Chris (an open owner item), then the RD brief confirms the mechanics (T-RD-00, T-RD-01, E37).
What the answer changes: RD-R53, VM §3.4 rule 4, contracts C1 and C5, RD-AE43 and FX-VM-61; in the pack, only DH-C122's history line and DH-S70.
Answer: Not yet answered.
Decided by / date:

6. Rolling the answers into the pack¶

A writer does this after the Codex session, in a docs PR. Nothing here sends anything.

6 October 2026: this roll-in was done for DQ-01 to DQ-04, DQ-46 and DQ-09 in one docs PR. Step 6's checks and a fresh-context verifier follow; the pack is ready for Chris to send only after that PR is checked and merged (step 7).

Record each answer here. Fill the Answer field with Chris's words and the Decided by / date field. Leave unanswered items as they are. Set this document's front matter updated date.
Move items between classes where Chris says so (§1, "Answers"). Move the item's section to its new class (§3, §4, or a §5 row), keep its DQ ID, and record the move and Chris's reason in the item. Update §2.1's counts and screen-area table, §2.2 and §2.3, and any "If still open at the handoff" line the move changes.
Record the answers as owner decisions. Add a new dated section to the decision register (the next §1 number, "Design-handoff answers, ") with one row per answered DQ: its source IDs, the decision in short, its status (Decided or Decided-amended) and where it applies, and the hold statement that §1.16 uses. Append the same answers to the owner ledger in a new dated section, as was done for D2-09. Where the two disagree, the ledger wins.
Update the source records.
Each specification's §12 row or ambiguity (RS, SP, RD, ACD, BC, UX, TI, DM, RI and, since 6 October 2026, CPR, as cited), and any rule whose PROPOSAL label the answer settles (for example UX-R46 after DQ-01, or CPR-R22 after DQ-48).
The question-management plan §9.4 and owner-session integration §7.3 and §7.8 tables.
Open questions and assumptions, for items it lists (for example U2 and U3 after DQ-27 and DQ-13).
The tracker: T-OI-02's PR/status for QMI-04 (DQ-01), and a note in the Evidence or Blockers column of the brief row an answer belongs to (T-RS-00, T-SP-00, T-RD-00, T-AC-00, T-BC-00, T-UX-00, T-TI-00, T-DM-00, T-RI-00 and, since 6 October 2026, T-CP-00 with the CP rows T-CP-01 to T-CP-09), with a change-log line. An answer never changes a row's Brief or Implementation authorisation state.
The acceptance criteria: each row whose status or wording waits on an answered item, for example AC-R1a-14's pending-QMI-04 status after DQ-01, with a dated note and recounted statuses in its Resolution record.
The product-owner guide §20 (for example the §20.3 release table and the §20.5 questions after DQ-01).
The rollout plan §7.6, for ambiguities an answer settles (for example R-AMB-02 after DQ-30).
Update the design handoff.
In §11.1, set each answered DH-U row to "Decided (DQ-nn, date)", as DH-U27 reads, and update the totals line. In §11.2, do the same for DH-T13 or DH-T17 if answered.
Rewrite the affected §5 text, §6.2 settings rows, DH-C changes and DH-S scenarios that each item lists under "What the answer changes in the pack", and the §12 traceability rows.
Move decided items into DH-C02's "Resolved since v10" list.
In the §13 prompt, update goal 5's exception list, the question-management block's "To be decided" lines (DH-U35 to DH-U41), the "DECIDED SINCE THE LAST SPECIFICATION" block and any bullet the answer changes. Since 6 October 2026 also update the "ANSWERS, TRAINING GUIDANCE, REFERENCE QUESTIONS AND LANE C1" block (goal 7, its chips and its "NAMING IS OPEN" line), the "DECIDED ON 6 OCTOBER 2026" block and its "Still open" line, and the "BOUNDARIES (question management)" list, for DH-U42 to DH-U44 and DH-T20 to DH-T23.
DQ-11, DQ-20 and DQ-44 have no DH-U entry. Their "To be decided" chips were added on 5 October 2026 (§5.5, §5.9, §5.10 step 6, §6.2, DH-S23, DH-S27, the §11.1 note and the §13 prompt's goal 5). When one is answered, remove its chip at each of those places; while it stays open, leave the chip as it is.
Add an "Updated" line to the handoff's closing validation note.
Re-run the checks from the repository root. python3 docs/scripts/generate-mkdocs-nav.py; ./docs/scripts/validate-docs.sh --skip-indexes; ./docs/scripts/generate-indexes.sh if the planning index changes; a relative link and anchor check across the package under GitHub slug rules; the handoff totals (129 changes in §9, 77 scenarios in §10, 44 inputs in §11.1 with the decided count, 23 items in §11.2, unless the roll-in adds some); and this document's §2 counts and front matter updated date. Record the results in validation evidence, and have a fresh-context verifier read the diff, as the package does for each integration.
Only then may Chris send the pack (T-DH-01). Sending is Chris's step; no agent messages the design session. The iteration (T-DH-02), its review (T-DH-03) and folding it into F1c (T-DH-04) follow only after that.

7. Notes for the Codex session¶

Read first. The design-prototype handoff (§1, §5.22 to §5.26, §9.12, §9.13, §11 and §13); the question-management plan (§1, §3 and §9); the product-owner guide; and the §12 of each specification cited (overview). Then this document.
Do not invent decisions. Record Chris's words, verbatim where possible. An assistant's recommendation is never an owner answer, and "as recommended" must come from Chris. If Chris amends an option, record the amendment and mark it Decided-amended.
Keep the classes honest. If Chris thinks a class B item must be answered first, or a class C item is a design question after all, record the move with his reason.
Use synthetic examples only. The names in the handoff (Priya, Sam, Chloe, Erin and the rest) and its Studies are synthetic. No real project content, participant data, clinical data or reviewer identities.
Boundaries. Nothing in the Codex session messages the design session, approves a brief, lifts the hold or authorises implementation.

Design-prototype handoff and its §13 copy-ready prompt.
Question-management plan and the harvest map.
Owner-session integration, decision register and the owner ledger.
Rollout plan and the implementation tracker.
Classification, populations and references specification (DQ-48, DQ-49 and the CPR §12 row), added 6 October 2026.

Open questions before the Claude Design handoff¶

1. How to use this document¶

2. Summary¶

2.1 Counts¶

2.2 Class A in one line each¶

2.3 Where the 17 confirm items went¶

2.4 Notes from gathering¶

3. Class A questions: answer before the handoff¶

DQ-01 Question editor for Classic projects¶

DQ-02 Where the question editor opens¶

DQ-03 How design edits are kept in a draft¶

DQ-04 Reconciliation and design screens on phones¶

DQ-46 Naming answers and no-value answers¶

4. Class B questions: the handoff can carry options¶

DQ-05 Requiredness default on a question¶

DQ-06 Moving a question to another parent or entity type¶

DQ-07 Where question import starts¶

DQ-08 Copying definitions from another project¶

DQ-09 What the inference beta covers¶

DQ-10 Default target-one handling for new forms¶

DQ-11 Existing Study overrides when the standard target changes¶

DQ-12 Suspending results below a raised target¶

DQ-13 Population context placement¶

DQ-14 Own Unsure and progression¶

DQ-15 Result when every decision is Unsure¶

DQ-16 Filling answers from a single candidate¶

DQ-17 Telling a reviewer that a copied hint makes their answer informed¶

DQ-18 AI source type under blinded adjudication¶

DQ-19 Re-acceptance after a correction under Accept automatically¶

DQ-20 What the self-reconciliation override grant allows¶

DQ-21 What the first form shows after its shared accepted answer is revised¶

DQ-22 Bulk reassignment of reconciliation assignments¶

DQ-23 Merge commit while conflicts are pending¶

DQ-24 Identity of the consolidated Study¶

DQ-25 Where "finish started work after leaving the pool" lives¶

DQ-26 Where reviewer-pool browsing is configured¶

DQ-27 Per-step Skip¶

DQ-28 Accepted-answer filter clauses and Single annotator results¶

DQ-29 Who owns timeout, limit and capacity for screening-only work¶

DQ-30 What the "Later release" badge on accepted-answer clauses says¶

DQ-31 What trainees see after an attempt¶

DQ-32 A live step that depends on passed training¶

DQ-33 Lifting a contribution exclusion¶

DQ-34 Who sees and restores deleted projects¶

DQ-35 Default email content for answers and free text¶

DQ-36 Contribution exclusion on Classic projects¶

DQ-37 Mixed route provenance under stage-scoped exclusion¶

DQ-38 Notices for a deleted project¶

DQ-39 Extra confirmation beyond the impact preview¶

DQ-40 Holding edits on the device during a connection loss¶

DQ-41 How converted single-reviewer forms behave¶

DQ-42 Legacy screening meaning when no admin confirms¶

DQ-43 Deferring a scheduled conversion wave¶

DQ-44 Scope of conversion-wave approvals¶

DQ-45 Names for project modes¶

DQ-47 Guidance for trainees before an attempt¶

DQ-48 Custom reference questions: at GA or with lane C1, and which targets¶

5. Class C items: not design questions¶

DQ-49 Export overlap markers¶

DQ-50 Recording unanswered and cleared answers, and empty text¶

6. Rolling the answers into the pack¶

7. Notes for the Codex session¶

Related documents¶