Open questions, contracts to settle and provisional assumptions

Temporary planning document; planning only. Settled decisions are in the decision register and are not asked again here. This page lists only what is genuinely undecided, when each answer is needed, the recommended answer, and what the integrated plan does until an answer arrives. Nothing here is built without consent. "Needed by" names the release or gate that cannot pass without an answer. Every recommendation is a proposal. Release and gate names follow the integrated plan §5–§6.

Revised after the round-2 review (3 October 2026): Batch D added; engineering items E36–E93, assumptions A-25–A-40 and UI validations U30–U45 added; several items rewritten. Batch D1 was answered the same evening (decision register §1.13), and the G0 inputs (Q-03, D4-18, D1-06's tester names and D1-03's activation date) late that evening (decision register §1.14).

Owner session (4–5 October 2026). Chris answered most of the open decisions in an owner session on 4–5 October 2026. These answers are planning approval only. Feature implementation remains on hold (Chris, 5 October 2026): brief approval and implementation authorisation stay separate, per gate (D1-04), and none has been given; no work has started, no gate has passed and nothing is enabled in production. The owner-session integration holds the count reconciliation, the superseded-wording register and the coverage matrix. The specification overview indexes the nine specifications that now carry each answer (RD, DM, SP, RS, BC, TI, RI, UX and ACD below). The archive keeps the session outputs byte for byte; its consolidation supersedes older conflicting recommendations. Statuses, tracker rows and the amendments OS-A01 to OS-A30 are in decision register §1.15. Every row of Batches B to D stays below, marked with its new status, with its original question and recommendation kept as history. This page therefore no longer lists only undecided items; the one open owner decision is D2-09.

Batch	Open before the session	Resolved, replaced, removed or deferred	Alignment, brief or validation entries	Open owner decision
B	13	13	0	0
C	15	12	3 (Q-23, Q-16, Q-17)	0
D2	16	10	5 (D2-10, D2-13; engineering contracts D2-03, D2-04, D2-06)	1 (D2-09)
D3	25	12	13 (D3-01, D3-02, D3-09, D3-10, D3-11, D3-13, D3-16, D3-17, D3-18, D3-19, D3-20, D3-21, D3-23)	0
D4	20	16	4 (D4-06, D4-08, D4-12, D4-21)	0
Total	89	63	25	1

The 74-entry session register held 74 of the 89: its 52 resolved, replaced, removed or deferred entries and its 22 alignment or brief entries are inside these totals. The other 15 were outside the session register: 11 decided or replaced there (D2-01, D2-02, D2-05, D2-07, D2-08, D2-12, D2-14, D2-15, D2-16, D3-14, D3-15), three engineering contracts with no owner question (D2-03, D2-04, D2-06) and D2-09. 63 + 25 + 1 = 89. Outside the 89 sit the G0 items (G0-D1 confirming the D4-18 reading; G0-D4 to G0-D10 PR dispositions, with no closure authorised; G0 approval; lifting the hold), the policies not approved (T-POL-01 permanent physical erasure, T-POL-02 an identity-erasure process, T-POL-03 automatic acceptance of several agreeing candidates), every proposed numeric threshold and the amendments OS-A01 to OS-A30. Exact PRISMA box mapping, statistical methods and scientific event definitions need specialist input (T-SI-01 to T-SI-05).

1. Owner and product decisions for Chris

Answered by Chris on 3 October 2026

These are settled and recorded in the decision register §1.11 (D1-01 in §1.12; D1-02 to D1-09 in §1.13; Q-03, D4-18, D1-06's names and D1-03's date in §1.14). The original question texts follow below for traceability; Q-03 and D4-18 stay in their batch tables, marked answered.

ID	Decision	Where it lands
Security	Fix now: owner-only ownership transfer, and no grants of owner-reserved activities (ChangeOwner, AssignPermissions, Delete)	PR #3964, merged 3 October 2026 (85e6facf7); R1b entry criterion (met)
Q-10	Make the #3944 changes, with conversations on their own flag (route a)	PR #3965, stacked on #3947
Q-07	Pilots are new projects and the seeded projects in staging and preview; add seed projects where helpful	Acceptance criteria §6
Q-08	Harvest the QM v2 stack	F1a
Q-09	#2224's author has left; harvest the work into R1c	R1c
Q-13	As recommended	R1a; C17
Q-03a	As recommended	R1c, R1d; C10
Q-25	As recommended	Plan §5.11
Q-31	As recommended	R2c; C8
Q-06a	Approved, plus ASySD deduplication inside SyRF and manual reporting of steps done outside SyRF	PRISMA amendments K and L; P1, P2, R5b
D1-01	Keep #3964 for the ownership fix; port #3969's active-member check and tests; close #3969	PR #3964, merged 3 October 2026 (85e6facf7); #3969 closed
D1-02	As recommended: #3961's Phase 0 fixes continue; #3985 and #3973 are F1a prerequisites (X-ARCH-a); #3986 is decided before R0 guards PM consumers; #3988 is folded into E24 or deferred until after R2a; #3989 runs only as L5 seam slices until R3a ships	Plan §6.1 F1a entry; delivery operating model §15; programme integration §10, §12 (X-ARCH-a to d)
D1-03	As recommended: activate the ProjectStatistics families this plan uses (#3987); freeze is not chosen, so Q-31(b) is not extended to GA. Date given late on 3 October: activation from 5 October 2026, staging first, then production the following week; the production date is a target, and production enablement keeps its own approval and waits for X-STATS-b1 to b7 (register §1.14)	Plan §6.1 F1a entry ("#3987 decided"); X-STATS-b1 to b7 on the GA path; programme integration §7
D1-04	As recommended: implementation is authorised per freeze gate through Chris's approval of each gate's dossier; merges keep his /approve, batched daily; product decisions, production enablement and adoption waves stay with him	Plan §6.1 and §12; delivery operating model §2, §3
D1-05	As recommended: merge the owner ledger, this package and its research inputs to main as a docs-only PR (PR #3617); promote contracts into ADRs and feature specs as they freeze. Merged on 3 October 2026 (PR #3617, f5318074d)	G0 entry (step 0); plan §11, §12
D1-06	As recommended: five CAMARADES reviewers and administrators for T1 releases and three for the rest; sessions batched monthly; at least two external SyRF users where possible. Names given late on 3 October: T1 Gillian Currie, Alexandra Bannach Brown, Francesca Tinsdeall, Chris Sena and Nadia Soleman; other releases Gillian Currie, Alexandra Bannach Brown and Francesca Tinsdeall; no external SyRF users named yet (register §1.14)	Acceptance criteria release tiers and §5; UX strategy §9; G0 exit
D1-07	As recommended: opt-in production pilots for new projects after staging acceptance, R0's production soak and AF2 per-project admission; one production pilot per family (R2, R3, R4a) before GA	Plan §9; acceptance criteria §5.2; A-23
D1-08	As recommended: the FEAT-024 gate (b) shape at 1, 2, 5 and 10 concurrent reviewers; start budgets Save ≤ 150 ms and Complete ≤ 300 ms (p95, 200-question form); tiers of 50, 340 and 2,023 questions; E28 in pins and bytes. F1a confirms the thresholds from M0 evidence	AC-M0-02, AC-ALL-26, AC-R2a-19; M0 go/no-go; F1a
D1-09	As recommended: #3964 (done), then #3932 → #3938 → #3941 → #3942 → #3943 → #3944 → #3965 → #3945 → #3947. Restacking #3965 onto #3944 needs the stack owner's agreement; otherwise it stays on #3947 and lands in the same train before any environment enables conversations	Notifications integration merge order; programme integration §8; X-NOTIF
Q-03	As recommended (late on 3 October): the permission matrix proposal is approved, with one rule: each new capability ships with the feature that uses it. The catalogue subset is settled now; the Publish, stage-lifecycle and Monitor, and reconciliation subsets are approved as proposed and freeze with their features	C10; R1d; F1b (catalogue), F2, F3, F4
D4-18	A different answer (late on 3 October): "independent of funders". Recorded reading, PROPOSAL until Chris confirms it in the G0 dossier: the plan maps the NC3Rs and SSI RSMF deliverables to releases itself and does not wait for the funders to confirm the mapping; the independent WCAG 2.1 AA audit at GA stays	G0 exit (mapping part); GA (audit, AC-GA-08)

Correction to Q-25's tracking line (round 2, 3 October). Q-25 stands as decided. Its recommendation said activeReviewerTrackingEnabled is "not needed for slot-reservation claims"; that premise was false. Claims, capacity guards and typed admission exist only when tracking is on, and tracking is off in every deployed environment (on only in the E2E stack). Enabling it is a FEAT-024 durable reviewer-mode transition with no owner (M15), and it never protects reconciliation. So R2b's claims, R3a's reservation admission and any capacity promise need a production claims route (X-CLAIMS), now put to Chris as D3-16, and R4a needs the reconciliation-task editor claim in every environment (X-RECLAIM). See programme integration §6. Update (owner session, 4–5 October 2026): D3-16 is now a brief item under T-SP-00, piloting shared-form capacity through admitted pilot projects first; it is no longer an owner question.

Original question texts (answered):

ID	Question	Recommendation	Until answered	Needed by
Q-10	What must hold before #3944's reconciliation conversations are enabled, and how should it merge? #3944 adds reconciler questions to selected candidates behind studyAttention; #3945 (study issues) and #3947 (PDF proposals) are stacked on it and share that flag. As inspected: every participant sees every reply (conflicts with VS1 candidate isolation); incomplete sessions can be questioned, and the reviewer's link opens the editable review route (an independence and exposure risk that extends the PV1/VS2 principle; VS2 itself concerns accepted answers); any Reconcile holder can start a thread, including one who reviewed the study; threads are stage-scoped and owned by their creator (gaps against RE4 and RA4); labels are unstable (BL1); threads stay usable after gold exists (overlaps QY).	Required before conversations are enabled, not necessarily before merge: reviewer-private (one-to-one) visibility; an exposure marker on any questioned session plus a read-only context link; a reconciler-eligibility check, so a reconciler who reviewed the study can't start a thread; requested additional reviewers excluded until they return their review. Merge route: (a) give conversations their own flag that depends on notificationInbox, so #3945 and #3947 can be enabled separately; (b) restack #3945/#3947 below #3944; or © merge with the flag off and gate enablement on the changes. Recommend (a). Task identity, handover, stable aliases and open-task-only threads become R4a follow-ups. Explicit reconciliation assignees are notified. Details: notifications integration §2.	Conversations stay disabled; the plan treats #3944 as a clarification channel, never as queries	Before conversations are enabled; F4
Q-07	Which projects pilot each release (R2a/R2b, R3a/R3b, R4a, C1, O1)?	Start every release on synthetic projects in the local e2e stack and on staging (both disposable), then one or two real, low-risk projects that Chris nominates, admitted through R0's admission service. Pilot entry criteria follow plan §5.10: R2 pilots need no reconciliation before R4a, or use target-1 forms (Q-29); R3a pilots using Stop on a profile that feeds a cross-stage route accept waiting for R4p. Production pilots wait for Q-25.	Synthetic and staging acceptance only	R2a pilot
Q-08	What should happen to the dormant QM v2 stack (#2572–#2575, plus #2461)?	Harvest, don't revive wholesale. Audit #2572's AQ/AQV/QSV domain and #2573's impact/transition services against C1/C4; port what fits into small new PRs; close the stack once harvested.	Reference code only	F1a
Q-09	Should #2224 (custom project groups, authored by nurikarakaya, conflicting) become the basis for R1c?	Reuse its API shape and tests, as the authorization plan's D10 already says, rather than merging it as is. Agree the route with its author: they rebase it in slices, or agree a hand-over.	Groups UI designed, not started	R1c
Q-13	The question area's name: v10's alternate navigation calls it "Library", but Study Management already uses "Library" for studies. And what do we call the reusable question collection?	Keep "Library" for studies. Group definition work under "Design". Call the reusable collection "question templates", not a library.	Docs use "Design" and "question templates" provisionally	R1a
Q-03a	Who may create and edit project groups, and under which anti-escalation rule? (The group part of the permission matrix, needed early so the authorization programme can plan WP11.)	Group create/edit under EditMemberships. An editor can't add themselves or anyone else to a group whose grants exceed what the editor may administer. ChangeOwner is never grantable (ownership transfer stays owner-only, PM1); AssignPermissions is grantable only through R1d's delegation envelope (PM2); Delete follows Q-03.	Existing groups only	R1c
Q-25	Production pilots depend on environment-wide flags owned by other programmes. Which route does each owner agree?	Per flag, agreed with its owner: annotationFormV2 (AF2 programme): per-project admission through AF2 eligibility, which already falls back to v1; this is an AF2 contract change because eligibility must read the generated selector. stageReviewRedesign / stageReviewDockview (stage-review programme): per-project admission or production readiness where the new UI extends the shell. reviewEligibilityPolicy (eligibility programme): enable after the reservation migration and the D7 tool, or per-project admission. activeReviewerTrackingEnabled (presence owner): not needed for slot-reservation claims; R4a uses a dedicated reconciliation claim if tracking stays off. Notification flags: never a release dependency (feature queues). FEAT-024 flags: per Q-31.	R2–R4 pilots run on staging only	Any production pilot
Q-31	PS1 in production. PS1 asks for materialized, version-aware usage statistics at publication. FEAT-024 is dark in production and refuses fold enable on the production database until its gate (b). For R2c production publication: (a) wait for the FEAT-024 usage family plus production activation, as an explicit cross-programme dependency; or (b) for named pilot projects, accept authoritative counting and identity enumeration from canonical records under the same protected boundary, switching to the materialized family once it is live?	(a) as the target. Allow (b) only for named pilots, and only if gate (b) isn't reached when R2c is otherwise ready; (b) keeps PS3's protected boundary and never treats missing evidence as zero.	A-08 applies: strict PS1; R2c production waits for gate (b)	F2
Q-06a	Approve the PRISMA amendments that shape writes, through the FEAT-011 change policy: A (within-stage admission and configurable routing separate from collective outcomes; "entering screening" defined as protocol scope or actual release, including shared batches and personal grants), C (one downstream source column from the earliest import), D (admin-reviewed dedup when review evidence exists; no double counting), and the new G (per-project adoption replaces platform-wide MIG-11/MIG-12), H (screening outcome per profile with route provenance instead of one stage ID, authority values including legacy-compatible/unknown, structured reason with coverage status), I (canonical-aware rollback replaces $unset rollbacks) and J (deletion and withdrawn searches keep Citation history, per Q-33)	Approve, so amendment PRs land before the P1 build and the F3 freeze	P1 and R3a don't write PRISMA-shaped data	F3, F-P

Batch B: needed before the F2, F3 and F5 freezes and P1

Thirteen of these fourteen were open before the owner session. Q-03 was answered late on 3 October (decision register §1.14) and stays in the table for traceability. After the owner session (4–5 October 2026) all thirteen are resolved: twelve are decided (Q-34 and Q-37 decided-amended; Q-28's hint part decided-amended) and Q-15 is replaced by the stage study filter and step model.

ID	Question	Recommendation	Until answered	Needed by
Q-03	Answered by Chris on 3 October 2026: as recommended. Approve the rest of the permission matrix: the new capability list, defaults beyond PM1's ordinary-admin rule, a non-recursive owner-managed delegation envelope, and each capability's mapping to its view	Decided as recommended: the matrix proposal is approved, with one rule: each new capability ships with the feature that uses it. The catalogue subset is settled now, so F1b can freeze C10; the Publish (F2), stage-lifecycle approval and Monitor ("Who is offered what", F3), and reconcile, assign, request an additional review and view agreement (F4) subsets are approved as proposed and freeze with their features at those gates.	Existing grants only; no new capability identifiers	Decided (3 October 2026); each subset freezes with its feature at F1b (catalogue), F2, F3 and F4; R1d
Q-20	Answered by Chris on 4–5 October 2026 (owner session): approved with clarified wording. The admin sees affected active work and its consequences before publication. Reviewers whose ongoing session a publication affects are alerted, told the impact, keep their draft and get a safe resume or conflict flow. A reviewer's own edit that makes another answer need attention shows inside the form, with no separate notice. Changes by others give one deduplicated in-app notice per recipient and cause; notices for publication-generated versions follow the impact policy. The old premises (no active-reviewer warning; publication never generates session versions) are superseded (RD §4.8, §7). Original question: Approve or replace the publish-pause UX recommendation (active-reviewer warning, queued exact-version retry). Also: when should "contains outdated annotations" (SF5) send a notice rather than only flag the session in-app?	Original recommendation (history; the answer in the question column supersedes it where they differ): Approve a minimal pause version: an admin impact summary and a non-disruptive reviewer notice only when action is needed. The active-reviewer warning needs a form-scoped "who has form F open now", which needs presence keyed by form with tracking on; the minimal version drops it. Outdated annotations (PROPOSAL, narrowed): no notice when the session owner caused the flag (candidate answers are their own, and the ledger already requires an in-form alert); otherwise one in-app notice per recipient per cause, when the cause is a support on-behalf-of write, an adoption remap or a shared-gold revision. (A publication never causes this flag: under D2-01 its autoUpdate writes no revision, and Q-34's derived mapping revisions are excluded from outdated flags; its effects reach reviewers through the "form version published" notice.)	Publication without a pause; reviewer writes fenced by the protected boundary; outdated annotations flagged in-app only	Decided (4–5 October 2026); brief T-RD-00 before R2c and R2d
Q-27	Answered by Chris on 4–5 October 2026 (owner session): approved with clarifications. Readiness comes from current authoritative evidence at query time, or from a cache proven current for the relevant input versions. An explicit incomplete Save after Complete removes that completed contribution; autosave alone does not. Before commit the actor sees which dependent work is affected and how, rechecked at commit, and affected authors are informed afterwards. Dependent work and accepted results are never rewritten, deleted or regenerated automatically; reconsideration is an explicit action that creates new immutable versions. Automatic stage completion follows remaining-work rules; static completion stays until explicit reopening (RD §4.5, §7). Original question: Approve the ledger's "proposed effects" of an incomplete Save, and the cascade rule for cross-stage corrections	Original recommendation (history; the answer in the question column supersedes it where they differ): Recompute shared sufficiency and dependent applicability; show affected steps as needing reassessment; never silently reopen, delete or change gold or screening decisions as a side effect (ledger "Current state…" section; OD16)	Effects designed but not activated	Decided (4–5 October 2026); brief T-RD-00 before R2a (Save effects) and R3a (cascade)
Q-34	Answered by Chris on 4–5 October 2026 (owner session): decided-amended, with an explicit compatibility declaration. SyRF detects option compatibility and proposes a default. The authorised publisher sees the basis and impact and explicitly declares compatibility and whether mapping applies. Compatible options whose meaning is unchanged may be mapped, writing new immutable revisions with mapping provenance and keeping the originals. The declaration, exact versions, mapping, actor and time are recorded. A committed declaration stays immutable; corrections use guided rollback and republication (D2-02). Differing meanings need a new answer (RD §3.4, §4.8). Original question: QM v2's publication wizard offers "map answers to updated options", which transforms recorded answers. Is that an approved form of autoUpdate under FV3?	Original recommendation (history; the answer in the question column supersedes it where they differ): Allow only as an explicit per-option mapping recorded in the publication policy, applied as new revisions with provenance (old revisions untouched), and only where an option's meaning is unchanged; otherwise use requireReanswer	R2c offers requireReanswer, autoUpdate (carry forward unchanged where compatible) and doNothing only	Decided (4–5 October 2026); F2
Q-15	Replaced by Chris's model clarification on 4–5 October 2026 (owner session). The stage study filter defines the stage's pool, with clauses on screening-profile outcomes and reconciled answers to named questions combined in AND/OR groups. There is no incoming stage gate and no cross-stage progression setting. Partitioning, allocation, permissions, availability and step rules decide which work is offered. Dependencies are between steps inside a stage, and exclusion-stop is a separate step setting. Neither alternative (a) nor (b) below is approved, and no personal or collective filter default or reviewer-dependent pool clause is introduced; A-06 and A-18 are retired (SP §3.3, §3.4, §5.1, §5.2). Original question: Cross-stage routing interpretations: candidate rules for the default and for the advanced option	Superseded recommendation (history; neither part is approved): (a) Default, collective required. Options: Mode B, collective Included admits anyone (even a personal Excluder); Mode C, both personal and collective Include required (unvoted reviewers never admitted); or a hybrid, collective Included admits unless the reviewer personally Excluded. Recommend the hybrid: it matches the within-stage veto on personal Exclude and lets unvoted reviewers proceed without an invented vote. (b) Advanced option. Either a relaxation (own Include or collective Included admits) or a replacement (only own Include admits, as in the access-policy proposal, where "personal policy + no own decision" means the prerequisite is still to do). Recommend the relaxation, so the faster option never blocks someone the default admits; this departs from the access-policy proposal.	Assumptions A-06 and A-18	Replaced (4–5 October 2026); no gate waits on it; the filter and step model freezes at F3 (T-SP-00)
Q-24	Answered by Chris on 4–5 October 2026 (owner session): resolved with clarifications. Independent annotation stays independent unless a step dependency is configured. Legacy stages have no steps, so the opt-in migration wizard shows how actual stage behaviour maps to steps and an authorised admin confirms it; no historical step settings are invented. New combined steps stop further screening at profile sufficiency by default, with Allow available. Newly disallowed actions are refused while drafts and saved work are kept. A settings change that conflicts with temporary reservations shows the exact impact and offers Cancel or Apply anyway, which only releases those reservations. The form's enforcement baseline and Study-specific effective targets stay distinct from a capacity cap (SP §3.4, §3.11, §7, §10.4). Original question: Confirm how the review-eligibility programme's decisions carry into the step model. D3a ("no closure concept") is superseded for the new stage model by the later LC1/RX2 under the precedence rule; this is recorded, not asked. Confirm: (a) D3b (independent contributions; the AnnotationHasNoScreeningPrerequisite test) applies to independent steps and migrated combined stages, while configured dependency edges follow DP6/DP7; (b) D1/D2 Allow/Stop for new screening votes after sufficiency becomes a combined-step "extra-vote admission" setting, with migrated combined stages keeping their resolved values and new combined steps defaulting to Stop; © D4 (refuse newly unavailable activity after a stage is disabled or its mode changes, preserving drafts) applies to step availability changes and coexists with EW1; (d) D6 capacity and "Apply anyway" semantics carry into typed claims (C7). D5 (excluded work) and D7 (keep each stage's mode in migration) carry over unchanged.	Original recommendation (history; the answer in the question column supersedes it where they differ): Confirm all four; amend the eligibility policy document in the R3a PRs	R3a design follows this mapping (A-16)	Decided (4–5 October 2026); F3
Q-26	Answered by Chris on 4–5 October 2026 (owner session): yes. Screening profiles have immutable versions. Before publication the proposed version is compared with the exact versions behind existing decisions and collective or adjudicated outcomes; mismatches and their consequences are previewed; the authorised admin chooses the treatment (keep pinned, request new decisions or compatible carry-forward) with a final recheck. Originals, outcome history and frozen reports are kept, and the policy is recorded at profile scope (RD §3.6, §4.12). Original question: Does the FV1–FV3 publication model apply to screening-profile versions? That is: a publish-time check over decisions cast under prior profile versions, an admin choice of treatment (keep pinned, require a new decision, or compatible carry-forward), collective outcomes recomputed only under that choice, and PRISMA snapshots frozen	Decided as recommended (owner session): Yes, mirroring form publication; profile changes never silently alter cast decisions, collective outcomes or past reports. #2621's screening-profiles prototype shows a per-stage migration policy (keep on old version / re-screen / archive stage) that becomes per profile under DP4.	Profile versions publishable only before any decision exists	Decided (4–5 October 2026); F5
Q-28	Answered by Chris on 4–5 October 2026 (owner session): fully resolved (the hint part decided-amended). Reconciliation identity blinding belongs to the annotation form, or to the screening profile for screening reconciliation, the same through every stage; the most-restrictive-stage proposal is superseded. Reconciled-answer availability is a form baseline, on by default, shown as labelled hints with explicit click-to-fill; a step may only hide them. Already-started saved work may be completed after screening exclusion by default, and a step setting can prevent it; drafts are kept. The form owns the inactivity timeout and per-reviewer in-progress limit across stages; tabs and routes share one session and place, and a timeout keeps the draft. The form's capacity baseline applies through every route and a stage may be stricter (SP §3.9, §3.11; RS §3.5, §3.6, §5.6, §5.7; OS-A02, OS-A04). Original question: Some stage-owned policies apply to evidence reachable through several stages: BL1 blinding for one study × form reconciliation task (RE4), EW1 on one shared session, VS1 on a shared form, and tracking's settings on a shared form (EnforceAnnotationTarget, the idle timeout, MaxInProgress, and the binding-scope tracking setting proposed for #3876). Which policy applies when the stages differ?	Original recommendation (history; the answer in the question column supersedes it where they differ): Task blinding uses the most restrictive setting among the stages that can reach the task. EW1 is evaluated for the route (stage/step) the reviewer is using and never changes the shared target. VS1 is evaluated per route, with exposure recorded per PV1/VS2. Tracking settings (D3-18): the most restrictive bound stage sets the capacity cap and the idle timeout; the stage in use sets the in-progress limit, counting a shared session once; the form is tracked if any bound stage is.	Pilots use one stage per form, or identical settings	Decided (4–5 October 2026); F3 (continuation, hints, tracking), F4 (blinding)
Q-12	Answered by Chris on 4–5 October 2026 (owner session): as recommended and as shown in the prototype. A step selector with one form area in the existing annotation workspace (UX §3.1). The user validation (U7) still runs before the layout is committed. Original question: Reviewer page structure: one form area driven by the selected step (v10 r4), one card per step (v10 p1), or the earlier three-card page?	Decided as recommended (owner session): A step strip plus one form area inside the existing AF2/Dockview workspace; validate in user testing (U7)	Prototype both; ship neither until U7 passes	Decided (4–5 October 2026); validation U7 before R3a
Q-01	Answered by Chris on 4–5 October 2026 (owner session). By default a reviewer progresses after their own Include while the collective result is pending. A stage setting can require collective Include first; it is off by default. Configured exclusion-stop rules still apply after a collective Exclude. This concerns progression between steps, never a stage gate (SP §3.4, §5.2). The tighten-only step override and pilot validation stay recommendations; SP-AMB-11 places the stage setting in R3c. Original question: Should optional strict within-stage collective gating exist, and in what form?	Original recommendation (history; the answer in the question column supersedes it where they differ): Yes, as an advanced stage setting with a tighten-only step override, default off, shipped in R3c once pilot users confirm the need	R3a ships own-Include within-stage only (DP6)	Decided (4–5 October 2026); R3c for the stage setting (SP-AMB-11)
Q-02	Answered by Chris on 4–5 October 2026 (owner session): approved after clarification. Before an admin change, show the additional work and its completion effect, and recheck at commit. Automatic completion is recalculated as soon as remaining work appears, including Studies that newly match the stage filter. A manually or statically completed stage stays Completed until an explicit authorised reopening. Pool membership alone does not imply remaining work, and merges change evidence, never stage status directly. LC1's confirmation hold for automatic stages and new arrivals is superseded; protected changes to a Completed stage still need approval (SP §3.10, §4.11, §5.9). Original question: Approve the exact LC1 flow: a pending change request for a Completed stage, admin approval of that specific change, a recheck at commit, automatic transition in automatic mode, an explicit Reopen in manual mode, and the same gate for new arrivals	Original recommendation (history; the answer in the question column supersedes it where they differ): Approve the lifecycle proposal	Lifecycle work stays at design level	Decided (4–5 October 2026); R3c
Q-30	Answered by Chris on 4–5 October 2026 (owner session). Reconciled-answer hints are shown by default (Q-28). Reconciliation identity blinding is on by default, owned by the form or profile, with context-local anonymous labels assigned independently per Study and an unpredictable candidate order that stays stable while one reconciler works; no persistent pseudonym crosses Studies. Expiry of explicitly assigned, unstarted reconciliation work is optional, admin-configured and off by default; there is no seven-day rule (RS §5.6, §5.7, §5.14; OS-A02, OS-A03). Original question: Default values for confirmed settings with stage defaults: VS1 (show reconciled answers to candidates), BL1 (reconciliation identity blinding), RA3 (expiry for explicitly assigned, unstarted reconciliation work)	Superseded recommendation (history; all three defaults changed): VS1 off (independent workflows by default); BL1 blinded with stable aliases; expiry 7 days, changeable per stage, with audited per-assignment override	Settings ship only with these values visibly marked provisional	Decided (4–5 October 2026); R3a (hints), R4a (blinding, expiry)
Q-33	Answered by Chris on 4–5 October 2026 (owner session): as recommended. Original citations stay and a withdrawal event is appended. Current reports exclude withdrawn searches as appropriate and explain it, counting Studies still identified by another search correctly. Frozen reports never change, and submitted review evidence is never erased (RI §3.5). Original question: Search and project deletion currently fail closed until the reversible-deletion scheduler exists. When a search is withdrawn, what should PRISMA show?	Decided as recommended (owner session): Citations stay immutable identification history; a withdrawal is an appended event; current reports exclude withdrawn searches and say so; frozen reports never change (amendment J)	P1 records nothing for withdrawal; deletion stays disabled	Decided (4–5 October 2026); F-P
Q-37	Answered by Chris on 4–5 October 2026 (owner session): approved as amended (decided-amended). Amendment K (external-step ledger, per-box combination, reported versus computed counts, no double counting, permissions, warnings and withdrawal) and L's deduplication requirements (imports preserved, non-current records excluded from admission, privacy, QC sampling, reviewer duplicate flags and parity validation) are approved. The alias-only merge rule is replaced by one consolidated current Study with immutable history, atomic commit and guided unmerge (D2-12). The parity metric and tolerance stay with D4-21, a specialist input (DM §4.1, §5; RI §3.4, §3.15). Original question: Confirm the detailed rules proposed for the two amendments Chris asked for: K (external step records, how reported counts combine with computed ones, the consistency warning, no double counting, who may enter counts) and L (FEAT-012 implemented as specified, the ASySD parity tolerance, no hard deletes, reviewed merges through the engine, admission exclusion); and the round-2 extensions to K (entry phase per search or import, per-box combination, K.2/K.3 agreement, box 1 per D4-11, withdrawn searches) and L (merge as an alias per D2-12, scenarios by form and profile, privacy, extended pool exclusion, QC sample and reviewer flag, parity metric per D4-21)	Original recommendation (history; its alias rule and its parity tolerance are not approved by this answer): Approve as written in PRISMA amendments K and L, including the parity tolerance in AC-P2-01r, as revised after the round-2 review (3 October)	P1 records no external counts; P2 waits	Decided (4–5 October 2026); F-P (K), P2 (L)

Batch C: needed before F4, F6a, F6b, R5c and the remaining lanes

All fifteen were open before the owner session. After the owner session (4–5 October 2026): twelve are resolved (Q-29, Q-36, Q-04, Q-11, Q-32, Q-05, Q-06b, Q-18, Q-19, Q-22 and Q-21 decided; Q-35 removed); Q-23 is a carry-forward alignment entry; Q-16 and Q-17 are specialist inputs.

ID	Question	Recommendation	Until answered	Needed by
Q-29	Answered by Chris on 4–5 October 2026 (owner session), R1 final clarification: decided-amended. A reconciliation task exists for every form with a qualifying candidate. The form version configures target-one handling: the single qualifying candidate either becomes an automatic immutable accepted result with Single annotator authority, exact candidate lineage and system-rule provenance, or it needs human reconciliation before acceptance. Automatic acceptance is never labelled human reconciliation or verification. A new target or form policy may produce a corresponding new result version; history is kept and raising a target invents no reviewers. Automatic acceptance of several agreeing candidates is not approved (RS §3.2, §5.1; OS-A28). Converted legacy forms create no accepted results (RS-R04a NoAcceptance, PROPOSAL). Original question: How do target-1 forms (one reviewer, common for extraction) reach gold, and how are legacy single-reviewer studies adopted? Under RE2/AG2, gold needs an explicit final reconciliation submission; earlier designs auto-promoted single-annotator studies (QM v2 RECON-03, MIG-08; annotation-versioning migration step 6).	Superseded recommendation (history): Target-1 forms create no reconciliation task. The single qualifying assessment is the effective answer for exports, labelled "single reviewer, unreconciled". An optional "accept as gold" action by a reconciler creates an attributed snapshot when a project wants gold. Never automatic promotion, including at adoption.	Target-1 exports show unreconciled answers, labelled as such	Decided (4–5 October 2026); F4; conversion per the BC spec at R6 (owner-visible confirm items in RS §12)
Q-35	Removed by Chris on 4–5 October 2026 (owner session, R3) as inapplicable. Reconciliation was never fully implemented or used, so no legacy reconciliation records are assumed, and no migration lane or "legacy authority unknown" backfill is designed. Every conversion dry run verifies the no-records premise; unexpected records stop that project's case and surface their provenance treatment explicitly (RS §5.13, RS-R68; BC §4.2, §8). Original question: How are legacy reconciled answers (one overwritten set per question, authority unknown) treated in exports, queries, R4a readiness and adoption?	Superseded recommendation (history): Exportable as "legacy reconciled (authority unknown)"; never a gold snapshot (GS1); not queryable through QY; R4a treats such a study as still needing canonical reconciliation for gold; a canonical task supersedes it with explicit provenance	Legacy projects keep today's exports. An aggregate-only production count of legacy reconciled sessions runs off-peak before F4 (a first read-only attempt on 3 October timed out on an unindexed scan); if the count is near zero, Q-35 shrinks to a fail-closed refusal.	Removed (4–5 October 2026); the premise check runs in every conversion dry run (T-BC-00)
Q-36	Answered by Chris on 4–5 October 2026 (owner session): approved (R2). No ordinary self-reconciliation by default. Adjudication overrides need explicit grants. New admissions that need accepted authority use current applicable authority, with saved work kept and revalidation shown. QY4's audited query-review exception stays separate. A screening profile may also route ties to an explicit adjudication step (OS-A13) (RS §5.4). Original question: Default authority policy (research §8 #3): may any project permit self-reconciliation (today's AllowSelfReconciliation stage setting has no writer), which adjudication overrides need explicit grants, and may a gate use stale authority for new admissions? The ledger already rules out a blanket self-review exception for ordinary reconciliation (QY4's audited self-review applies to query review only).	Decided as recommended (owner session): Explicit grants for overrides; no self-reconciliation by default; authoritative gates require current authority, and a stale result is shown as needing revalidation, never as freshly reconciled; saved work stays	A reconciler is never offered a study they reviewed; stale authority pauses new admissions	Decided (4–5 October 2026); F4, R4p
Q-04	Answered by Chris on 4–5 October 2026 (owner session): approved (R3). Accepted-answer completeness follows question requiredness, with a form override and no stage override. A blank candidate comparison is Not assessed and reported separately; it is neither a disagreement nor a bar to reconciliation. Unknown and Not reported are recorded answers (RS §5.3). Original question: Approve (a) a gold-completeness setting (project default "Follow question requiredness", form override, no stage override) and (b) a missing-state statistics contract (missing = "comparison not assessed", reported separately; Unknown/Not reported is a recorded state)	Decided as recommended (owner session): Approve both as proposed	R4a follows requiredness only (UA1-consistent); statistics show missing counts without an agreement value	Decided (4–5 October 2026); F4 / R5c
Q-11	Answered by Chris on 4–5 October 2026 (owner session): approved (R2). An optional per-form setting after the core reconciliation workflow, off by default. An authorised reconciler explicitly confirms the final acceptance of the exact displayed inputs, with study-level warnings; agreement alone never creates accepted answers. Automatic acceptance of agreeing candidates stays unapproved (T-POL-03) (RS §4.5, §5.5). Original question: Should admins be able to bulk-approve studies where every candidate agrees (v10 §3; QM v2 RECON-09)?	Decided as recommended (owner session): Optional per-form setting after R4a, default off. RE2 still applies: approval is an explicit final acceptance by an authorised reconciler of displayed valid answers, shown per study with the unseen-content warning summarised. Recorded with candidate-agreement provenance; never automatic gold.	Not built	Decided (4–5 October 2026); after R4a
Q-32	Answered by Chris on 4–5 October 2026 (owner session): approved (R2). A profile setting, off by default, can require a rationale for adjudicated screening decisions only; ordinary reconciled-answer explanations stay optional (RE1) (RS §5.11, RS-R56). Original question: v10 lets a profile require a rationale for a reconciled screening decision, with a blocking error. RE1 makes reconciled-answer explanations optional. May a profile require a rationale for an adjudicated screening decision?	Decided as recommended (owner session): Allow as a profile setting, default off, for screening-decision adjudication only (RX1); RE1 stays for ordinary reconciled answers	Rationale optional everywhere	Decided (4–5 October 2026); R4p
Q-05	Answered by Chris on 4–5 October 2026 (owner session) through R4: decided-amended. Existing outcome data converts inside each project's faithful baseline under the universal baseline conversion direction: read-only dry run, reviewed manifest, staged copy, fenced project cutover and an explicit rollback boundary. Untouched legacy defaults stay ValueOrDefaultUnknown unless evidence proves them. Execution is not authorised (BC §3.4, §4, §5; OS-A15). Original question: Approve the outcome-migration plan: read-only dry-run first, approved manifest, staged copy, project-scoped fence, rollback boundary	Original recommendation (history; now applied inside R4's universal baseline conversion): Approve the plan, with the default-value rules (legacy false direction, SD, mean and zero counts treated as "value or default, unknown" unless an explicit answer is proven); execution needs separate authorisation	Read-only design and synthetic dry-run only	Decided (4–5 October 2026); O2 and each project's baseline conversion (T-BC-00); execution needs separate authorisation
Q-06b	Answered by Chris on 4–5 October 2026 (owner session): approved (E1). Amendments B, E and F: imported-reference, source-document and Study counts stay distinct; missing exclusion-reason coverage is disclosed; accepted answers stay separate from reporting status; time, protocol amendments and frozen reports are preserved; labels stay honest where report identity is missing (RI §3.1, §3.2). Original question: Approve the remaining PRISMA amendments: B (report identity and records/report multiplicity), E (reasons coverage and gold separation), F (time, protocol amendments and frozen reports)	Decided as recommended (owner session): Approve, so reporting work can start at F6b	Exports label citation totals as records, not reports; no complete-diagram claim	Decided (4–5 October 2026); F6b
Q-17	Specialist input (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. The field-level event-count specification and the meaning of "variation" come from Chris or a CAMARADES methodologist before the O1 build; a placeholder definition is not enough (T-SI-01; RI §12). Original question: Field-level specification of the event-count schema, and what "variation" means	Original recommendation, now an input to the specialist review: Domain specification by Chris or a CAMARADES methodologist before the O1 build	O1 builds catalogue infrastructure and the legacy-compatible schema first	Specialist input T-SI-01; needed by F-O
Q-18	Answered by Chris on 4–5 October 2026 (owner session): approved (S5). The first reasoner supports conjunction, containment, disjointness and exhaustiveness only. It starts as a beta, off by default, enabled only by an explicit project-designer opt-in and never by baseline conversion (TI §5.5, §5.6; OS-A19). Original question: Scope of the first classification reasoner	Decided as recommended (owner session): Conjunction, containment, disjointness and exhaustiveness only, as the research recommends	C2 design assumes that scope	Decided (4–5 October 2026); C2 (beta)
Q-19	Answered by Chris on 4–5 October 2026 (owner session): approved (S5). Holders of the project Design capability publish rules; reviewers confirm per-paper applicability through mapping answers; normal reconciliation resolves disagreements (TI §5.6, TI-R30). Original question: Who may publish project rules and shared-concept mappings?	Decided as recommended (owner session): Design capability publishes rules; reviewers confirm per-paper applicability through mapping answers; reconciliation applies as normal	Design-only authority	Decided (4–5 October 2026); F-C
Q-16	Specialist input (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. One methods specification with D4-12: denominators and percent agreement first, statistical review before any multi-rater formula, AG2's identical-set rule kept, and accepted answers never counted as an extra independent reviewer (T-SI-02; RI §3.16, §12). Original question: Agreement formula and denominators for more than two reviewers and for entities (AG2's identical-set rule for multi-selects is settled and not reopened)	Original recommendation, now an input to the specialist review: Method review with a statistician; show percent agreement plus explicit denominators first	Percent agreement with counts only	Specialist input T-SI-02; needed by R5c
Q-22	Answered by Chris on 4–5 October 2026 (owner session), S3 as amended: decided-amended. A primary exclusion reason is template and reporting guidance. Profiles may have several screening annotation questions and agreement rules. Distinct excluded-Study totals are counted separately from reason counts, which may overlap and are labelled that way; reason coverage is disclosed (RS §5.13; OS-A17). Original question: PRISMA reason reporting: one primary reason or several counted reasons per excluded study?	Original recommendation (history; the primary reason is now template guidance): Follow the FEAT-011 primary-reason MVP; report coverage when reasons are pending or off (amendment E)	Primary reason plus coverage status	Decided (4–5 October 2026); F6b
Q-23	Brief item, carry-forward alignment (owner session, 4–5 October 2026). No new owner question. Apply the agreed reporting-unit distinction (imported references, source documents and project Studies), keep the full report or investigation grouping deferred and label totals honestly. Amendment B's report identity is approved through Q-06b; immediate full report linking is superseded (D4-08) (RI §3.1, RI-R01 to RI-R03; T-RI-00). Original question: PRISMA report multiplicity: approve report identity as in amendment B, or keep labelled citation totals?	Original recommendation (history; the reduced scope applies): Approve amendment B; until then label totals honestly	Labelled totals	Brief item T-RI-00; F6b
Q-21	Answered by Chris on 4–5 October 2026 (owner session) through R4: decided-amended. Legacy screening maps to a reviewed, legacy-compatible screening profile based on verified old behaviour, and an admin confirms its scientific meaning. No protocol is inferred and no decisions or reasons are invented. Projects with no active admin are an open brief ambiguity (BC A2) (BC §3.4, §5; OS-A14). Original question: For each existing project adopted later, what did its legacy screening represent?	Original recommendation (history; the answer in the question column supersedes it where they differ): Admin-reviewed labelling of a "legacy project screening" compatibility profile, set at adoption	Legacy projects stay on the legacy path	Decided (4–5 October 2026); per project at baseline conversion (R6, T-BC-00)

Batch D: decisions raised by the round-2 reviews

The round-2 reviews (see the round-2 resolution matrix) produced the 71 decisions below, each with a recommendation. Batch D1 is answered: Chris decided D1-01 on 3 October and approved D1-02 to D1-09 as recommended that evening (decision register §1.12 and §1.13). Late that evening he answered D4-18 with a different answer, "independent of funders"; its recorded reading stays PROPOSAL until he confirms it in the G0 dossier (decision register §1.14). Before the owner session the other 61 (D2-01 to D2-16, D3-01 to D3-25, D4-01 to D4-17 and D4-19 to D4-21) were open, and with Batch B's 13 and Batch C's 15, 89 owner decisions were open. After the owner session (4–5 October 2026) the 61 split into 38 resolved, replaced, removed or deferred (D2 10, D3 12, D4 16), 22 alignment, brief or validation entries (D2 5, D3 13, D4 4) and one open owner decision, D2-09. Across all 89, 63 are resolved, replaced, removed or deferred, 25 are alignment, brief or validation entries and 1 is an open owner decision (the table near the top of this page). They are grouped by when the answer was needed. "Source" names the review findings behind each one.

D1: needed before G0 (operating model and delivery)

All nine are answered. D1-03's activation date and D1-06's tester names were given late on 3 October (decision register §1.14), and D1-05's merge (step 0) completed on 3 October 2026 (PR #3617, f5318074d). Parts still open: F1a confirms D1-08's start thresholds from M0 evidence; D1-09's restack of #3965 onto #3944 depends on the stack owner agreeing; no external SyRF tester is named yet (D1-06). G0 itself, Chris's approval of the G0 dossier, has not happened, and nothing is built before it.

ID	Question	Recommendation	Until answered	Needed by	Source
D1-01	Answered by Chris on 3 October 2026: keep #3964. #3964 (this plan) and #3969 (the architecture review) fix the same defect.	Decided as recommended: keep #3964. It compares the caller with the persisted owner, so a stored ChangeOwner grant cannot bypass it (the policy #3969 relies on is satisfiable by such a grant), and it also refuses owner-reserved grants and fixes the UI. Port #3969's active-member check and its tests into #3964, then close #3969. Carried out: #3964 merged on 3 October 2026 (85e6facf7) and #3969 is closed.	Neither merges	Decided (3 October 2026); it was needed by G0 and before #3941 merges, because both edit ProjectController.UpdateProject	DS-19, DS Q7, #3964 verifier
D1-02	Answered by Chris on 3 October 2026: as recommended. Precedence with the architecture-review roadmap (#3961). Both programmes compete for the same approver, agents, CI and files, and #3961 changes foundations F1a freezes.	Decided as recommended: #3961's Phase 0 security fixes continue as they are. #3985 (non-upsert saves, version bump on direct writes) and #3973 (await domain events) become F1a prerequisites (X-ARCH-a). #3986 (MassTransit after v8) is decided before R0 guards PM consumers. #3988 (v0/v1 schema retirement) is folded into E24 or deferred until after R2a. #3989 (web state convergence) runs only as L5 seam slices until R3a ships.	Both proceed independently, with collision risk	Decided (3 October 2026)	DS-02, DS Q1
D1-03	Answered by Chris on 3 October 2026: activate. ProjectStatistics: activate or freeze (#3987), and what counts as current statistics at GA.	Decided as recommended: activate the families this plan uses. Freeze is not chosen, so Q-31(b) (authoritative counting at the protected boundary) stays for named pilots and is not extended to GA; GA depends on X-STATS-b1 to b7. Date (given late on 3 October): activation from 5 October 2026, staging first, then production the following week; the production date is a target, and production enablement keeps its own approval (D1-04) and waits for X-STATS-b1 to b7.	Q-31(b) stays pilot-only; GA depends on X-STATS-b	Decided (3 October 2026), date included (register §1.14)	DS Q2, MS-01
D1-04	Answered by Chris on 3 October 2026: as recommended. Implementation authorisation per freeze gate instead of per PR.	Decided as recommended: yes. Chris approves each gate's dossier, including its slice list and its decisions. Merges keep his /approve, batched daily. He keeps every product decision, every production enablement and every adoption wave. Nothing is built under this plan before G0.	Per-PR authorisation (§12)	Decided (3 October 2026)	DS-01, DS Q3
D1-05	Answered by Chris on 3 October 2026: as recommended. Commit and merge the owner ledger, this package and its research inputs to main now (they are committed only on the PR #3617 branch, not yet on main, so agents starting from main cannot see them).	Decided as recommended: yes, as a docs-only PR (PR #3617). As contracts freeze, promote them into ADRs and feature specs; keep one append-only ledger on main. Merged on 3 October 2026 (PR #3617, f5318074d).	The package stays on the PR #3617 branch only	Decided (3 October 2026); step 0 (G0's entry) merged on 3 October 2026 (f5318074d)	DS-17
D1-06	Answered by Chris on 3 October 2026: as recommended. Tester panel and tiers.	Decided as recommended: five CAMARADES reviewers and administrators for T1 releases and three for the rest; sessions batched monthly; at least two external SyRF users where possible. Names (given late on 3 October): T1 Gillian Currie, Alexandra Bannach Brown, Francesca Tinsdeall, Chris Sena and Nadia Soleman; other releases Gillian Currie, Alexandra Bannach Brown and Francesca Tinsdeall.	User-testing criteria cannot be run	Decided (3 October 2026), names included (register §1.14); no external SyRF users named yet	DS-16, DS Q6, review AC-25, AC Q7
D1-07	Answered by Chris on 3 October 2026: as recommended. Production opt-in pilots before GA (A-23).	Decided as recommended: yes, for new projects whose creators opt in, after the release passes staging acceptance, R0 has completed a production soak and AF2 per-project admission exists. One production pilot per family (R2, R3, R4a) is required before GA.	Pilots stay on staging and preview	Decided (3 October 2026); binding before the first production pilot	DS Q4, AC Q4, review AC-33
D1-08	Answered by Chris on 3 October 2026: as recommended. Write-path gate and scale commitment. A canonical Save writes several documents, so "no more than 1.2 × today's p95" cannot be met by construction.	Decided as recommended: the shape of the FEAT-024 gate (b): zero engine-caused exhausted submissions at 1, 2, 5 and 10 concurrent reviewers, same study and different studies. Absolute p95 budgets are set after M0, starting at Save ≤ 150 ms and Complete ≤ 300 ms on a 200-question form. Three benchmark tiers: typical (50 questions), p99 (340) and max (2,023, the largest real project). The form-size limit (E28) is expressed in pins and bytes per commit. The start thresholds apply now; F1a confirms them from M0 evidence.	M0 records numbers but nothing gates	Decided (3 October 2026) for the start thresholds; F1a confirms them from M0 evidence	DC-16, PH-01, VB-12, MS Q5, review AC-18, AC Q8
D1-09	Answered by Chris on 3 October 2026: as recommended. Notification stack merge order and #3965's place in it.	Decided as recommended: the ownership fix first (done: #3964 merged on 3 October 2026), then #3932 → #3938 → #3941 → #3942 (with tolerant preferences) → #3943 → #3944 → #3965 → #3945 → #3947 last. Restack #3965 onto #3944 if the stack owner agrees; otherwise keep it on #3947 and land it in the same merge train before any environment enables conversations.	#3965 waits on top of #3947	Decided (3 October 2026); the restack of #3965 depends on the stack owner agreeing	NS-05, NS-17, NS §4.3

D2: needed before F1a (engine and versioning contracts)

After the owner session (4–5 October 2026): ten are decided or replaced (D2-01, D2-02, D2-05, D2-07, D2-08, D2-11, D2-12, D2-14, D2-15, D2-16); D2-10 and D2-13 are brief items; D2-03, D2-04 and D2-06 are engineering contracts with no owner question; D2-09 is the one open owner decision (T-OI-01).

ID	Question	Recommendation	Until answered	Needed by	Source
D2-01	Answered by Chris on 4–5 October 2026 (owner session): decided-amended, reversing the recommendation. Publication may create attributable generated session versions; the round-2 "publication writes no evidence" proposal is superseded, and SF6 applies to generated versions literally (RD §3.15, §4.8). Original question: Publication writes no evidence. Publishing a form version records a policy; its effects on sessions (qualifying, needs updating, pinned under an older version) are derived when read, and query-path projections are rewritten afterwards by a resumable operation. No session version is created by the publication itself; SF6's "creates a new incomplete session version" is read as "changes the session's effective status".	Superseded recommendation (history): Yes. It keeps SL3 literally true (only a reviewer's explicit Save or Complete creates a version), scales to large forms, and makes FV4 revisions and late saves simple.	The versioning model stays unfrozen	Decided (4–5 October 2026); F1a (generation table in the RD brief)	VA-03, DD-10, DC-06, VB-06
D2-02	Answered by Chris on 4–5 October 2026 (owner session): decided-amended. Compatibility belongs to immutable question versions. SyRF suggests a default and the authorised publisher explicitly declares it; the declaration is immutable from commit; corrections use guided rollback and republication (Q-34) (RD §3.4, §4.13). Original question: When is compatibility between question versions decided, and can it change?	Original recommendation (history; the declaration is now immutable from commit, not from the first pinned answer): Declared when the version is committed in the designer: SyRF suggests it from the change (removed or changed options, a new data type or multiplicity → incompatible; added options, wording, help → compatible), the admin confirms or tightens it, and it becomes immutable once any answer pins that version. FV4 revises the counting and re-answer policy of a publication, never the compatibility declaration.	Sharing, agreement and reconciliation rules can't be frozen	Decided (4–5 October 2026); F1a	VA-01, VA Q1
D2-03	Engineering contract, no owner question (owner session, 4–5 October 2026). The recommendation stands as a PROPOSAL consistent with the owner model and is settled in the RD brief (RD RD-R30; T-RD-00). Original question: A data-type or single/multi-select change: a new question, or an incompatible version of the same question? Treating it as a new identity (FEAT-001 D38) recreates the whole subtree under the "parent is identity" rule and severs answer history.	Recommendation, kept as the engineering PROPOSAL: An incompatible version of the same identity. Parent and owner scope stay part of identity; data type and multiplicity become version content, always classed incompatible.	D38 stays a proposal	Engineering contract (T-RD-00); F1a	VA-16, VA Q2
D2-04	Engineering contract, no owner question (owner session, 4–5 October 2026). The recommendation stands as a PROPOSAL and is settled in the RD brief; targets never come from stages (RD RD-R31; T-RD-00). Original question: What "stage settings bind form versions" (PV2) means.	Recommendation, kept as the engineering PROPOSAL: A stage binds the form and records the version it bound and when. The live route always presents the session's resolved version; a Completed stage's frozen binding governs only its historical display and readiness. This is the only reading consistent with one session per study and form (SF1) and per-form publication (FV2).	Shared sessions across stages can't be specified	Engineering contract (T-RD-00); F1a	VA-08, VA Q5
D2-05	Answered by Chris on 4–5 October 2026 (owner session): decided-amended in part. The form's standard reviewer target is part of the immutable form version: a target change is a publication with impact, even without question changes (OS-A12). Every other setting is classified in the brief; RD §3.5 proposes blinding, hint availability, completeness and outdated-answer mode inside the form version, and timeout, in-progress limit, capacity cap, assignment expiry and bulk acceptance as audited operational settings (PROPOSAL) (RD §3.5). Original question: Operational settings outside requirement versions. Form target, reconciliation compare settings, gold completeness, guidance, DP5, resolution routes, allocation, batches and expiry would be audited settings that never trigger the publication impact flow; PV1's "stage-settings version" stamp refers to the requirement-bearing part.	Original recommendation (history; superseded for the target): Yes. Otherwise a target change or a DP5 toggle forces a publication and a decision over every session.	Every settings change mints a version	Decided in part (4–5 October 2026); F1a (settings classification)	VA-07, VA-08, VA-19, AP-11
D2-06	Engineering contract, no owner question (owner session, 4–5 October 2026). The recommendation stands as a PROPOSAL and is settled in the RD brief (RD RD-R32; T-RD-00). Original question: System question versions.	Recommendation, kept as the engineering PROPOSAL: Store system questions as versioned data (identity = question ID plus SystemQuestionVersion). A new CAMARADES version reaches a project only when its admin next publishes a form version; deploying code never changes a published form or prompts every project.	System snapshots stay per code revision (E24)	Engineering contract (T-RD-00); F1a	VA-09, VB-11, VA Q6
D2-07	Answered by Chris on 4–5 October 2026 (owner session): decided. The form owns the inactivity timeout and per-reviewer in-progress limit across routes and tabs. One inactive tab never releases the shared place while another connection is active. Expiry releases the place and keeps the draft (RD §3.11, §4.6; SP §3.11). Original question: Does an autosaved draft hold the reviewer's place? One review says never (earlier designs); another says yes until Save, Complete, discard, admin release or 14 days.	Original recommendation (history; the timers are now form-owned): Middle ground: a draft keeps the place while the reviewer is active, under today's idle and disconnect timers counting draft activity, so nobody loses a place mid-work. When the timers lapse, the place is released but the draft is kept; the reviewer can still Complete it as an extra contribution (the target is a minimum, SF4) unless an optional capacity cap applies (D3-17), in which case they are told honestly. An unattended draft never blocks capacity for days.	Capacity rules for canonical sessions can't be frozen	Decided (4–5 October 2026); F1a	PH-03, RT-09, RT Q-RT2
D2-08	Answered by Chris on 4–5 October 2026 (owner session): decided. One shared session and place across tabs and devices; connections are tracked separately; base-version checks prevent stale overwrites. The take-over or read-only presentation is a brief detail (RD §3.10, §3.11). Original question: Two tabs or devices on one session.	Original recommendation (history; read-only with take-over is now only a presentation option): The second tab is read-only with "Take over editing"; the displaced tab's unsaved edits are kept as a recoverable conflict copy.	Two-tab behaviour stays undefined	Decided (4–5 October 2026); F1a	DC-07, VA-12, RT Q-RT7, DC Q-DC4
D2-09	Still an open owner decision after the owner session (4–5 October 2026), and the only one of the 89. Tracked as T-OI-01 (RD §4.14, §12). The recommendation is unchanged. Original question: Shared-question gold across two forms. First publisher wins (others challenge only by query), or the second form's reconciler sees the existing gold prefilled as accepted and may revise it in their own final submission (a new snapshot with provenance)?	The second may revise. It keeps the second form's candidates, often different reviewers, in the gold decision, and keeps queries for later challenges.	First-publisher-wins stays a proposal	Open owner decision T-OI-01; F1a (shape), F4	VA-11, VA Q4
D2-10	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Specify and test the publication active-work protection with generated versions, and engineer and measure the pause and operation limits. The 90-second and 30-minute figures are proposed, not approved, and the recommendation's "no generated versions" premise is superseded (RD §7, §12; T-RD-00). Original question: Short, scoped pauses. Publication phase 1 drains in-flight saves for that form (target under 90 seconds); while a publication's follow-up operation runs, new study admission and reconciliation-readiness changes pause for that form only (reviewers keep saving; the admin sees progress; it stops and reports at a limit, e.g. 30 minutes); stage completion, stage settings changes (in-flight submissions may commit during the drain; the change takes effect after it) and adoption cutover use the same drain.	Original recommendation, now an input to the brief (its no-generated-version premise is superseded): Yes. The alternative is serialising every save in a project through one document, which FEAT-024 measured as failing at ten reviewers.	Publication and completion consistency can't be frozen	Brief item T-RD-00; F1a	DC-06, DC-09, VB-06, VB Q1, DC Q-DC2, DC Q-DC3
D2-11	Answered by Chris on 4–5 October 2026 (owner session): as recommended. Many drafts may exist; one publication operation per form runs at a time; the next publication rechecks its impact against the state the previous one produced. Collaborative question drafts (OS-A01) add presence, live updates, preserved local edits, base checks, recoverable conflicts and attributed changes (RD §3.7, §4.7). Original question: One active publication per form at a time.	Decided as recommended (owner session): Yes. Publications are rare; this removes a class of policy-composition errors.	Overlapping publications stay undefined	Decided (4–5 October 2026); F1a	VB-06, VB Q2
D2-12	Replaced by Chris on 4–5 October 2026 (owner session). A duplicate merge produces one consolidated current Study. The Study parent holds its state and current-version pointer; originals stay as immutable historical inputs; conflicts are resolved before an atomic commit; unmerge is a new immutable action that restores the originals with explicit carry-forward choices. The alias model below is superseded (DM; OS-A29; C21). Original question: Duplicate merge as an alias. Records stay attributed to the study they were made on; the primary study shows them as candidates with lineage; a split is a clean reversal; one reviewer who reviewed both is counted once.	Superseded recommendation (history): Yes. Re-keying would rewrite immutable records.	Merges of reviewed studies stay unspecified	Replaced (4–5 October 2026); F1a (shape), F-P, P2 (T-DM-00)	V2-02, DD-08, DC-19, DD Q-D3
D2-13	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Specify isolated point-in-time recovery with manifest-driven forward recovery and evidence checks, and rehearse it on an authorised copy before the first production pilot; production recovery execution needs its own authorisation. Disaster recovery is separate from merge reversal (BC §8.4, §12.1; T-BC-00). Original question: Restore policy for canonical data.	Original recommendation, now an input to the brief: No selective per-project restore. Whole-database point-in-time restore into an isolated database, then manifest-driven recovery; affected projects get a recorded history discontinuity that exports report.	Restore rehearsals have no target	Brief item T-BC-00; F1a (policy), rehearsal before the first production pilot	DC-17, VB-20, DC Q-DC5
D2-14	Answered by Chris on 4–5 October 2026 (owner session): decided-amended. Ordinary account deletion disables access and keeps named attribution on submitted work; joining terms explain contribution retention. A separate identity-erasure process is not decided (T-POL-02), and no legal sufficiency is claimed without review (ACD §3.1). Original question: Account erasure and immutable answers.	Superseded recommendation (history): A deleted reviewer's answers stay in history under an anonymised identity; as-of exports stay identical except for erased identities, and the manifest records the erasure.	E32 stays open	Decided (4–5 October 2026); F1a	VB-19, DC Q-DC6, VB Q4
D2-15	Answered by Chris on 4–5 October 2026 (owner session): decided-amended. For the MVP, one application-wide CAMARADES catalogue, administered by system-permissioned users. Authorised direct entry or project sharing creates versioned copies with source, version and sharer provenance; edits never silently overwrite copies; other users may request catalogue publication. Whether "copy from a project I administer" stays as an R1a copy is an open brief ambiguity (ACD B5) (ACD §3.4, §4.7). Original question: Who owns question, profile and form templates?	Original recommendation (history; amended): A CAMARADES-curated system catalogue (an application role), plus "copy from a project I administer". Copies only, never links.	Templates stay project-scoped	Decided (4–5 October 2026); F1a (R1a scope)	DD-25, PH-27, DD Q-D1, PH Q11
D2-16	Replaced by Chris on 4–5 October 2026 (owner session). No size-based exclusion: the largest project (Francesca's, 2,023 questions) is an explicit acceptance case, and commit limits (E28) are engineered for it with evidence (RD RD-R33, §11). Original question: Initial size ceiling for canonical forms until benchmarks prove larger forms safe (the 2,023-question project stays on the legacy path even after adoption opens).	Superseded recommendation (history): Yes; revisit after M0.	No ceiling	Replaced (4–5 October 2026); F1a (E28 limits)	VB-12, VB Q3

D3: needed before F1c and F3 (UX, workflow and in-flight programmes)

After the owner session (4–5 October 2026): twelve are decided (D3-03 to D3-08, D3-12, D3-22, D3-24 and D3-25 from the session register; D3-14 and D3-15 from outside it); D3-17 and D3-18 are carry-forward alignment entries; D3-01, D3-02, D3-09, D3-10, D3-11, D3-13, D3-16, D3-19, D3-20, D3-21 and D3-23 are brief items.

ID	Question	Recommendation	Until answered	Needed by	Source
D3-01	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Coordinate Material 3 visual roles and themes, staging dark-mode checks and visual baselines with the established UI programme, and record the cutover sequencing for the reviewer UI (UX §12; T-UX-00). Original question: What UI1 (Material 3) requires before FEAT-023's cutover. The app emits only Material 2 component themes today, with M3 tokens alongside.	Original recommendation, now an input to the brief: Build new screens on M3 roles over the current components (no mixing), register every new route for the cutover baselines, and sequence FEAT-023's light cutover before R2a's reviewer UI if possible. The notification stack's inbox and preferences meet UI1 before testers see them; its conversation, issue and PDF screens before production. Dark-mode evidence comes from token checks and staging, where the theme toggle is on.	UI-3 can't be verified	Brief item T-UX-00; F1c	UX-12, review AC-17, AC Q1, NS-10
D3-02	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Each release brief sets the design-review schedule: one integrated staging review, previews for new shared patterns and high-risk screens, and routine checks per PR (UX §12; T-UX-00). Original question: Design acceptance cadence.	Original recommendation, now an input to the brief: A per-release walkthrough on one staging build, with per-PR preview acceptance only for new shared patterns and five high-risk surfaces (publication dialog, reconciliation workspace, stage designer, Members & groups, guided setup). Agents run tier-1 design QA on every PR.	Per-PR acceptance of every new screen (UI-8)	Brief item T-UX-00; F1c	UX-13, review AC-25, AC Q2
D3-03	Answered by Chris on 4–5 October 2026 (owner session), U1 as amended: decided-amended. Use Save progress, Complete, Needs updating, Outdated answers, Fix, Accepted answers (gold standard in help text) and Screening result; never "Save draft". Status text distinguishes "Draft auto-saved" (recoverable draft edits) from "Version checkpoint saved" (after an explicit Save progress), and Complete stays distinct. The labels are illustrative and may iterate; the distinction is fixed (OS-A21). "Changes kept, not yet saved" is superseded (UX §3.2). Original question: User-facing terms.	Original recommendation (history; the autosave status label is superseded): "Save progress", "Complete", autosave status "Changes kept, not yet saved", "Needs updating", "Outdated answers", "Fix", "Accepted answers (gold standard)" and "Screening result" (so "outcome" means measured outcomes). Never "Save draft".	Copy deck stays provisional	Decided (4–5 October 2026); F1c (copy deck)	UX-05, PH-19, DD Q-D4, DD Q-D5, UX Q4
D3-04	Answered by Chris on 4–5 October 2026 (owner session): as recommended (U1). Material 3 sentence case across reviewer screens; older all-caps specifications are re-audited before they are applied (UX §3.2, UX-R14). Original question: Button and type language.	Decided as recommended (owner session): Material 3 sentence case across the reviewer page; re-audit the v4 stage-review spec (ALL-CAPS 13 px buttons) before further parity work.	Two button languages on one page	Decided (4–5 October 2026); F1c	UX-07, UX Q3
D3-05	Answered by Chris on 4–5 October 2026 (owner session), U2 device scope: decided-amended. Full annotation and screening on phones, tablets and desktops at launch, including large and structured forms, touch and accessibility. No control or feature is removed solely on phones; responsive presentation may differ. PWA exploration is beyond MVP, with no offline writes (OS-A22) (UX §3.3, §3.11). Original question: Phone screening.	Superseded recommendation (history): Supported for title/abstract screening steps; annotation stays tablet and desktop.	No phone criteria	Decided (4–5 October 2026); F3 (phone acceptance at launch)	UX-15, UX Q6
D3-06	Answered by Chris on 4–5 October 2026 (owner session), U2 final clarification: decided-amended. Existing and legacy screens get the refreshed design and as many compatible new features as possible, without changing review-workflow semantics before a confirmed conversion or redesign. The brief assesses compatibility and behaviour parity (OS-A23) (UX §3.4). Original question: Visual refresh of legacy screens. Legacy projects stay legacy for years.	Original recommendation (history; extended): An M3 restyle of shared chrome and shared pages under FEAT-023, with no behaviour change, so the app doesn't look like two generations.	Two visual generations coexist	Decided (4–5 October 2026); F1c; restyle by GA	UX-11, UX Q7
D3-07	Answered by Chris on 4–5 October 2026 (owner session): as recommended (U3). A project My work view by role, a cross-project tab and a global badge whose counts work when notifications are muted; pending admin changes are shown; the full global landing page is deferred (UX §3.5). Original question: "My work".	Decided as recommended (owner session): A project-level "My work" surface (R3c/R4a) listing every actionable item by role, a cross-project tab and a global badge with read-time counts that work with notifications off, and an admin banner for pending stage-change approvals; a global landing page after GA.	Queues stay per project, unsurfaced	Decided (4–5 October 2026); F3	UX-08, NS-07, UX Q8
D3-08	Answered by Chris on 4–5 October 2026 (owner session): decided (U3). The current agreed tester panel, with no additional external recruitment now, and consent-based pilot timing events without answer content (UX §3.6). Original question: Research participants and telemetry.	Original recommendation (history; external recruitment is not required): Recruit external SyRF users for sessions, and collect privacy-safe timing events on pilots (study opened → decision; form opened → Complete), with consent at pilot admission and no content captured.	Moderated sessions only	Decided (4–5 October 2026); F1c	UX-01, UX-21, UX Q5
D3-09	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Reconcile the paused eligibility programme with the stage filter and step model; disabled routes, preserved work and explicit early-reconciliation authority stay distinct (SP §12.1; T-SP-00). Original question: The paused eligibility programme.	Original recommendation, now an input to the brief: R3a absorbs the browser's consumption of the eligibility response (S6b) and, if the programme stays paused, S4-B, S4-C and S6a; map eligibility decision D8 as recommended (a disabled stage blocks only its own route; hiding excluded saved work becomes a display sub-setting of EW1; an authorised admin may start reconciliation before readiness with a warning; removal becomes a versioned withdrawal; claim release carries over).	R3a waits on X-ELIG	Brief item T-SP-00; F3	AP-09, DS Q5, PH-04, PH Q3
D3-10	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Prove source-pinned statistics reads at the publication boundary, profile granularity and protected pilots; production readiness stays provisional (RI §3.17, RI-R52 to RI-R56; T-RI-00). Original question: Statistics integration. (a) A FEAT-024 read at the publication fence (stored row, or its pinned authoritative fallback, with identity recorded) counts as "current" for PS2/PS3. (b) Keep seed project "Ready for Annotation" (the FEAT-024 staging pilot) out of R2a–R3a pilots until the statistics seam fixture passes. © Serve the three screening families live for multi-profile R3b pilots; add profile-grain families at F5. (d) Exempt preview pilots from PS1.	Original recommendation, now an input to the brief: Yes to all four.	PS2/PS3 block on admin backfill; pilots collide with the statistics pilot	Brief item T-RI-00; F2 (a, b, d), F5 ©	MS-04, MS-08, MS-10, MS Q1–Q3, Q6
D3-11	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. A separate rebuildable agreement store with a source watermark and a measured budget, apart from progress statistics (RI §3.16, RI-R51; T-RI-00). Original question: Agreement statistics storage.	Original recommendation, now an input to the brief: Their own rebuildable derived store with a watermark, outside FEAT-024 (whose README excludes kappa), with an absolute performance budget.	R5c design open	Brief item T-RI-00; F4	MS-20, MS Q4
D3-12	Answered by Chris on 4–5 October 2026 (owner session), O1: decided-amended. Search withdrawal hides current items and keeps citations and review history. Ordinary whole-project deletion is reversible: the project is hidden, review and editing are blocked, allocations and notices stop and reservations are released, while drafts, data and history are kept. An authorised admin restores it through a restricted deleted-projects view, with capacity and eligibility rechecked. Permanent physical erasure is a separate, unapproved policy (T-POL-01) (OS-A25) (ACD §3.3, §4.5, §4.6). Original question: Deletion versus history. The reversible-deletion design (ADR-014, product decisions approved 12 August) physically deletes a search's studies after 24 hours; amendment J and QD1 keep identification history.	Superseded recommendation (history; ADR-014's physical removal is not approved): Withdrawing a search hides its studies but keeps Citations and canonical evidence; deleting a whole project keeps ADR-014's physical removal with a tombstone; file and PDF cleanup is unchanged.	X-DEL conflict unresolved	Decided (4–5 October 2026); F3 (withdrawal), F-P (identification)	PH-02, PH Q1
D3-13	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Allocation and batch contracts, denominators and performance gates, with first release (WorkFirstReleased), stage-pool entry, review start and completion kept as distinct events. Part © is superseded: an additional-review request raises the effective Study × form target explicitly and counts reviewers once, with no invisible bypass (SP §3.7, §12.1; T-SP-00). Original question: Allocation and batches. (a) Refuse proportional allocation on canonical stages until AL1. (b) Record #3939's decision that sufficiently excluded studies stay in a batch's denominator and count as finished. © Let an RA5 requested reviewer bypass allocation buckets and the enforced target, once, audited. (d) Ship "Who is offered what" as pool-level counts until the out-of-request authority resolver (#3251) exists. (e) A study "enters screening" at its first release to anyone; record shared openings and personal grants separately. (f) Merge #3939 in slices: completion and progression decisions and durable openings first; selection integration after a performance gate.	Original recommendation, now an input to the brief (part © superseded): Yes to all six.	Allocation and batches stay legacy-only	Brief item T-SP-00; F3, F-A	AP-02..06, AP-12, AP Q1–Q6
D3-14	Answered by Chris on 4–5 October 2026 (owner session): decided (outside the session register). Add missing staging seeds, prefer preserving staging data and allow genuinely justified staging changes; this never extends to production (UX §3.12, UX-R43). Original question: Staging seed data.	Original recommendation (history; amended to allow justified staging changes): An additive, idempotent "seed-if-absent" job on preview and staging that never alters or wipes existing data.	New seeds reach preview only	Decided (4–5 October 2026); F1a (S0), or before S0-4 is enabled if earlier	V2-09, review AC-11, AC Q5
D3-15	Answered by Chris on 4–5 October 2026 (owner session): decided (outside the session register). Firefox, WebKit and touch coverage are agreed (UX §3.12, UX-R44). Original question: Browsers and touch.	Decided as recommended (owner session): Firefox and WebKit smoke journeys and touch-capable drag in acceptance for reviewer and reconciler screens; CDK pointer drag, never native HTML5 drag.	Chromium only	Decided (4–5 October 2026); F1c, or before S0-7's browser projects count as evidence if earlier	PH-13, review AC-19, AC Q6
D3-16	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Pilot shared-form capacity through admitted pilot projects before broader opt-in rollout, never silently fleet-wide, and validate load and statistics integration. Project-scope tracking through the admission record is the PROPOSAL now that capacity is form-owned (SP-AMB-12) (SP §12.1; T-SP-00). Original question: Production claims route. Q-25's answer assumed tracking was not needed for claims; in fact claims, capacity guards and typed admission exist only when active reviewer tracking is on, which is off in every deployed environment. Options: (a) reshape #3876 into a binding-scope setting and enable it per admitted pilot project (and for legacy projects that opt in, addressing #2446); (b) enable fleet-wide once FEAT-024's mode transition (M15) has an owner and load tests pass; © no production claims, with RA1 met only by the reconciliation task claim.	Original recommendation, now an input to the brief (route (a)'s binding-scope shape is obsolete): (a).	Capacity promises do nothing in production	Brief item T-SP-00; F1a (claim contract), F3 (production route), before any R2b/R3a production pilot	RT-02, RT-03, RT Q-RT1
D3-17	Brief item, carry-forward alignment (owner session, 4–5 October 2026). The capacity cap stays separate from the evidence target; the form's baseline applies through every route and a stage may be stricter; no eviction; caps respect Study-specific targets. Cap defaults (off; when enabled, equal to the effective target) are proposed, not approved (SP §3.11, §12.1; T-SP-00). Original question: Capacity cap separate from the minimum target.	Original recommendation (history; the per-stage or per-route cap is superseded by the form-owned baseline): An optional per-stage or per-route cap, off by default; when on it defaults to the form target, never limits requested extra reviews (RA5) and never evicts existing work.	Target doubles as cap	Brief item T-SP-00; F1a (C7)	RT-13, RT Q-RT3
D3-18	Brief item, carry-forward alignment (owner session, 4–5 October 2026). Replace the stage-derived rules with Q-28: the form owns the inactivity timeout and per-reviewer in-progress limit, with one shared place across connections and routes (SP §3.11, §12.1; T-SP-00). Original question: A form bound to stages with different tracking settings (extends Q-28).	Superseded recommendation (history): The most restrictive bound stage sets the cap and idle timeout; the stage in use sets the in-progress limit, counting a shared session once; the form is tracked if any bound stage is.	Q-28 open	Brief item T-SP-00; F3	RT-12, RT Q-RT4, PH-05
D3-19	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Reserve the dependent annotation place at personal Include, never while screening is underway, and keep the screening decision when no place is free (SP §4.6, §12.1; T-SP-00). Original question: Places on dependent forms during screening.	Original recommendation, now an input to the brief: Hold no place on a dependent form while the reviewer is still screening; claim it at Include; if refused, show "enough reviewers" for that step and keep the screening decision.	Claim timing open	Brief item T-SP-00; F3	RT Q-RT5
D3-20	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Reviewers see active counts and their own place; Monitor holders see names; reconciliation blinding is never defeated (SP-AMB-07) (SP §6, §12.1; T-SP-00). Original question: Who may see who is reviewing a study now.	Original recommendation, now an input to the brief: Reviewers see counts and their own place; names only for holders of the Monitor capability; never across reconciliation blinding.	Presence names every claim holder to every member	Brief item T-SP-00; F1b (C10)	RT-14, RT Q-RT6
D3-21	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Per-environment and per-kind-family gates, pilots first, a test email sink and an operator delivery pause; approving the brief enables nothing (ACD §3.9, §12.1; T-AC-00). Original question: Notification enablement.	Original recommendation, now an input to the brief: Pilot projects first through per-project notification admission, platform-wide only after the pilot exit review; staging and preview overrides only with your approval per release, email kept in Mailpit; an operator delivery halt (pause, not cancel) before any production email; a G-NOTIF gate per environment and kind family.	Notifications stay off everywhere	Brief item T-AC-00; before any notification enablement	NS-04, NS Q-N1, Q-N8
D3-22	Answered by Chris on 4–5 October 2026 (owner session), O2 as amended: decided-amended. Emails and digests may include useful project and Study context, including Study titles. Reviewer aliases and other content follow recipient permission and configured blinding; answers and free text are configurable rather than universally omitted; rights are checked at delivery; sent email cannot be recalled (OS-A26) (ACD §3.5, §4.9). Original question: Email content.	Superseded recommendation (history): Notification emails and digests may name the project; never study titles, aliases, answers or free text.	Titles only	Decided (4–5 October 2026); before production email	NS Q-N2
D3-23	Brief item (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. Related notices resolve when the work resolves, leave unread counts and stay in history (ACD §3.7, §4.10, §12.1; T-AC-00). Original question: Auto-resolve. When one person resolves a workflow item, others' related notices show "resolved" and leave the unread count, staying in history.	Original recommendation, now an input to the brief: Yes.	Notices stay unread	Brief item T-AC-00; F3 (R3c)	NS Q-N3
D3-24	Answered by Chris on 4–5 October 2026 (owner session): as recommended (O2). Per-project email mute before production email; in-app notices are still recorded (ACD §3.6). Original question: Per-project email mute (the inbox still records).	Decided as recommended (owner session): Yes, before production email.	No mute	Decided (4–5 October 2026); before production email	NS Q-N4
D3-25	Answered by Chris on 4–5 October 2026 (owner session): as recommended (O2). Reconciliation conversations are permissioned project audit records kept while the project exists. Export needs the audit or export permission and the identity-disclosure policy; their text stays out of candidate-answer exports and agreement statistics, with exposure markers kept (ACD §3.8). Original question: Reconciliation conversations as records.	Decided as recommended (owner session): Part of the project's audit record: kept while the project exists, exportable only behind an audit or export capability with aliases, never in candidate-answer exports or agreement statistics except as exposure markers.	Retention undefined	Decided (4–5 October 2026); F4	NS Q-N6

D4: needed before F4–F6 and the lanes (methodology and scope additions)

After the owner session (4–5 October 2026): sixteen are decided or deferred (D4-01 to D4-05, D4-07, D4-09 to D4-11, D4-13 to D4-17, D4-19 and D4-20; D4-15 is deferred beyond MVP); D4-08 is a carry-forward alignment entry; D4-06, D4-12 and D4-21 are specialist inputs. D4-18 was answered at G0 and sits outside the 89.

ID	Question	Recommendation	Until answered	Needed by	Source
D4-01	Answered by Chris on 4–5 October 2026 (owner session): approved (S1), with the owner's bounded-Unsure refinement. Unsure is a per-profile option, on in the title/abstract template. It counts as not excluded for availability and reporting and never as a definite Include for collective agreement. Under the stated two-agree, three-then-adjudicate configuration, Include + Unsure + Include gives Include, Exclude + Unsure + Exclude gives Exclude, and Include + Unsure + Exclude or Include + Unsure + Unsure go to adjudication. The full transition table, all-Unsure behaviour and thresholds are brief items (RS §5.10; OS-A16). Original question: "Unsure" at title/abstract.	Original recommendation (history; approved, then refined by the bounded-Unsure amendment): A per-profile option, on by default in the title/abstract template: Unsure routes like Include for availability, the collective rule is configurable, PRISMA counts it as not excluded, agreement reports it separately and collapsed.	Binary decisions only	Decided (4–5 October 2026); F5	SR-13, SR Q-1
D4-02	Answered by Chris on 4–5 October 2026 (owner session): approved (S2). A per-profile discussion route, off by default. Invitations follow submitted decisions that reveal a conflict; exposure is recorded; corrections create new versions; independent agreement uses pre-exposure initial observations; disabled or unresolved discussion uses the profile's extra-review or adjudication fallback (RS §5.12). Original question: Discussion as a conflict-resolution route.	Decided as recommended (owner session), with the clarified start timing and fallback: A per-profile route, off by default: after a conflict both candidates may see each other's decision and reasons (exposure recorded), either may correct via DP2, and agreement uses the initial decisions.	Extra vote or adjudication only	Decided (4–5 October 2026); F5	SR-23, SR Q-2
D4-03	Answered by Chris on 4–5 October 2026 (owner session), R1 final clarification: decided-amended, replacing the Verified step. Second-person checking uses the same reconciliation mechanism: a target of one qualifying candidate with required human reconciliation (RequireHumanReconciliation). There is no separate verification engine, session type or Verified authority; labels may distinguish the authority (RS §5.1, RS-R03; OS-A28). Original question: Extract-and-verify.	Superseded recommendation (history): A verification step on target-1 forms: a second reviewer confirms or edits the single extraction (exposure recorded) and the result is gold with Verified authority, labelled distinctly in exports and the methods summary.	Not supported	Decided (4–5 October 2026); F4	SR-12, SR Q-3
D4-04	Answered by Chris on 4–5 October 2026 (owner session), S4 expanded: decided-amended. Training is in delivery scope: a training step with admin-defined training reference versions, scoring rubrics and pass criteria, manual assessment, retries under a versioned training policy, and optional automatic admission to a project group whose permissions allow live reviewing. Training evidence stays outside live votes, targets, accepted results and PRISMA; promotion to live evidence is a separate explicit action. Deferring to the admission hook alone needs a separate owner agreement (TI §3.1 to §3.6, §5.1 to §5.4; OS-A18). Original question: Calibration or training rounds.	Original recommendation (history; expanded, and its hook-only fallback is not accepted): A step kind whose records never vote, qualify or count for PRISMA, with live agreement feedback; promotion to live decisions only by an explicit admin action. Build in R3c, or after GA with the admission hook kept now.	Not supported	Decided (4–5 October 2026); training lane (T-TI-00); F3 for the step kind	SR-11, SR Q-4, PH Q12
D4-05	Answered by Chris on 4–5 October 2026 (owner session): approved (E2). Versioned search strategy, date, platform, limits and round; a protocol and registration record with append-only amendments; publishing a profile version that changes eligibility needs an amendment entry (RI §3.6, §3.7). Original question: Protocol, registration and search documentation.	Decided as recommended (owner session): Search documentation fields (date, platform, strategy, limits, round) in P1; a protocol and registration record with an append-only amendments log in R3d or earlier; publishing a profile version that changes eligibility requires an amendment entry.	Protocol URL only	Decided (4–5 October 2026); F-P (search fields), F5 (amendment rule)	SR-04, SR-24, SR Q-5
D4-06	Specialist input (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. CAMARADES methodologists curate and verify the SYRCLE (with outcome-specific items), CAMARADES checklist and ARRIVE Essential 10 templates and their applicability in the agreed catalogue before publication (T-SI-03; RI §12). Original question: Risk-of-bias and reporting-quality templates.	Original recommendation, now an input to the specialist review: SYRCLE (per-outcome items bound to Outcome Assessment), the CAMARADES checklist and ARRIVE Essential 10 as curated templates owned by CAMARADES methodologists.	Ad-hoc questions	Specialist input T-SI-03; F1a (R1a catalogue part), F-O	SR-05, SR Q-6
D4-07	Answered by Chris on 4–5 October 2026 (owner session): approved (E2). Explicit Sought, Retrieved and Not retrieved actions with actor, time and reasons, by authorised admins and stage-granted reviewers. A PDF suggests Retrieved and never silently confirms it; retrieval stays separate from lifecycle (RI §3.8). Original question: Full-text retrieval.	Decided as recommended (owner session): Explicit actions (Sought, Retrieved, Not retrieved with a reason) by admins and stage-granted reviewers; a PDF attachment only suggests Retrieved; retrieval is fullTextStatus, never a lifecycle state (amendment M).	Boxes 6, 7, 12 and 13 can't be truthful	Decided (4–5 October 2026); F-P	SR-02, SR-15, SR Q-7
D4-08	Brief item, carry-forward alignment (owner session, 4–5 October 2026). Prepare source-document links that can support several references per project Study, keep forms, sessions and targets on the Study, defer the interface and scientific workflow for grouping distinct reports into one investigation, and label reporting units honestly. Immediate full report linking (amendment O) is superseded (RI §3.1, RI-R03; T-RI-00). Original question: Several reports describing one study.	Superseded recommendation (history): A "link reports to one study" action for boxes 10 and 16 (amendment O); linking never merges extraction.	Reports counted as studies	Brief item T-RI-00 (with T-DM-00); F-P	SR-07, SR Q-8
D4-09	Answered by Chris on 4–5 October 2026 (owner session): approved (E3). A comparison-level analysis-ready export, a machine-readable codebook and RIS export for a selected set; no effect sizes inside SyRF (RI §3.9). Original question: Analysis-ready and RIS exports.	Decided as recommended (owner session): A lane X1: a comparison-level export shaped for meta-analysis tools (no effect-size computation inside SyRF), a machine-readable codebook, and RIS export of any study set.	Long and wide exports only	Decided (4–5 October 2026); F6a	SR-08, SR-20, SR Q-9
D4-10	Answered by Chris on 4–5 October 2026 (owner session): approved (E3). Estimated-from-graph provenance in the first outcome-data release; digitisation is decided after pilots (RI §3.9). Original question: Graph digitisation.	Decided as recommended (owner session): Ship an "estimated from graph" provenance flag in O1 now; decide on a digitiser lane after pilots show how often graphs are the only source.	Graph regions link only	Decided (4–5 October 2026); F-O	SR-06, SR Q-10
D4-11	Answered by Chris on 4–5 October 2026 (owner session): approved (E1). The previous-review box uses explicitly supplied counts with the updated-review template; the full updated-review workflow stays deferred (RI §3.4). Original question: Box 1 (previous review version).	Decided as recommended (owner session): Populate it from amendment K's reported counts, switching the diagram to the updated-review template; full updated-review support stays deferred.	Box 1 deferred	Decided (4–5 October 2026); F6b	SR-14, V2-04, SR Q-11
D4-12	Specialist input (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. One methods specification with Q-16: initial independent observations by default, screening agreement per profile, percent agreement and prevalence always shown, and statistical review of pooled pairwise κ or Krippendorff's α before shipping; a reconciled result is never an extra independent observation (T-SI-02; RI §3.16, §12). Original question: Agreement observation basis.	Original recommendation, now an input to the specialist review: Default to initial independent observations; screening agreement per profile; pooled pairwise κ or Krippendorff's α for rotating raters, with percent agreement and prevalence always shown; confirmed by a statistician before κ ships.	Basis undefined	Specialist input T-SI-02; F1a (markers in C3), F4	SR-01, SR Q-12
D4-13	Answered by Chris on 4–5 October 2026 (owner session), S3 as amended: decided-amended. The template's default primary reason is the first failing criterion in the profile's configured order, with a per-profile option for reviewer choice. This is template and reporting guidance and limits no questions or reasons (OS-A17) (RS §5.13, RS-R66). Original question: Primary exclusion reason.	Original recommendation (history; now template guidance): The first failing criterion in the profile's configured order, on by default, with a per-profile override allowing reviewer choice.	Reviewer choice	Decided (4–5 October 2026); F5	SR-10, SR Q-13
D4-14	Answered by Chris on 4–5 October 2026 (owner session), E3 with the AI expansion: decided-amended. Answer imports from other tools come in a later lane with provenance, no automatic accepted answers and no independence credit; annotation imports count toward targets only when mapped to a SyRF reviewer. For configured external and AI-model screening sources that mapping rule is superseded: the profile's ScreeningSourcePolicy (ContributingVote or SoleScreener) decides how they count. AI-model-generated screening decisions keep their source identity apart from the importer and need no human login (OS-A20) (RI §3.10 to §3.14). Original question: Importing answers from other tools (FEAT-004).	Original recommendation (history; superseded for configured screening sources): A lane after R2a: imported answers carry their own provenance, are excluded from independence statistics, count toward the target only when mapped to a SyRF reviewer, and never become gold automatically.	Not in scope	Decided (4–5 October 2026); lanes after the first engine release (XS1, XA1)	PH-10, PH Q6
D4-15	Deferred beyond MVP by Chris on 4–5 October 2026 (owner session, E4). Optional accepted-answer branching between steps is outside MVP, with no delivery commitment until a future brief is approved. Reconciled-answer clauses in stage study filters stay in scope, and no stage-entry gate is introduced (SP §3.4, §10.3; TI-R36). Original question: Routing studies by answer values.	Original recommendation (history): A lane after R4a, expressed as a step-dependency rule on gold values; not required for GA.	Not in scope	Deferred beyond MVP; no gate waits on it	PH-05, PH Q8
D4-16	Answered by Chris on 4–5 October 2026 (owner session) through R4: decided-amended. Early limited adoption is allowed only for complete scopes whose readers and writers are validated and canonical. The first-canonical-write rollback boundary applies to every conversion, and universal baseline waves follow (BC §5, §10.1; OS-A15). Original question: Early screening-profile adoption for existing projects.	Superseded recommendation (history): Allow admin-initiated adoption of screening-only, unreconciled stages after R3b, reversible until the first canonical write.	Adoption waits for R6	Decided (4–5 October 2026); after R3b, within R4's pilots	PH-23, PH Q9
D4-17	Answered by Chris on 4–5 October 2026 (owner session), O3 as amended: decided-amended. An authorised designer or admin configures whether an outdated-answer warning allows Complete anyway (the default) or blocks completion until the flagged answers are addressed. Neither mode bypasses validation, applicability, permissions or mandatory re-review. Drafts and the policy and evidence versions are recorded, and the setting lives in the form version (RS §5.8). Original question: Stale-answer acknowledgement (FEAT-001 D54/D55).	Original recommendation (history; now the default of a configurable setting): Replace with RE2's non-blocking warning and Complete anyway; drop per-project enforcement levels.	E34 open	Decided (4–5 October 2026); F4	PH-17, PH Q10
D4-18	Answered by Chris on 3 October 2026: "independent of funders" (a different answer from the recommendation). Funder deliverables.	Recommended: map each NC3Rs and SSI RSMF deliverable to a release, confirm with the funders, and run an independent WCAG 2.1 AA audit at GA. Recorded reading of the answer (PROPOSAL until Chris confirms it in the G0 dossier): the plan maps the deliverables to releases itself and does not wait for the funders to confirm the mapping; the independent WCAG 2.1 AA audit at GA stays.	Unmapped	Decided (3 October 2026) under the recorded reading, which Chris confirms in the G0 dossier; the audit is still needed by GA	PH-12, PH Q4
D4-19	Answered by Chris on 4–5 October 2026 (owner session), O4 as amended: decided-amended. Random serving stays the default, with audited assignment exceptions. Reconciliation blinding is on by default, owned by the form or profile, with context-local aliases. Optional reviewer-study-pool browsing within a stage is dynamic, blinded and grants no broader rights (OS-A27). "Candidates are always blinded; the stage chooses only the alias scheme" is superseded (SP §3.6, §4.5; RS §5.6). Original question: Blinding and random serving as core behaviours.	Superseded recommendation (history): Candidates are always blinded (the stage chooses only the alias scheme); unmasking only through the audited export disclosure contract; random serving is the default and explicit assignment an audited exception.	BL1 stage setting may disable blinding	Decided (4–5 October 2026); F3	PH-12, PH Q5
D4-20	Answered by Chris on 4–5 October 2026 (owner session), O1 as amended: decided-amended. Disabling sign-in or membership keeps contributions valid. Authorised admins may explicitly exclude a member's contributions from current use by form, screening profile, stage or project, with impact preview, reason, actor and time; stage scope uses recorded provenance; dependent results are kept and their authors informed. Reviewers cannot withdraw their own submitted contributions by leaving (OS-A24) (ACD §3.2, §4.3). Original question: Completed work of disabled members.	Original recommendation (history; extended): Keeps counting and stays in reconciliation; an audited admin action can exclude a reviewer's contributions from a form.	"Eligible" undefined	Decided (4–5 October 2026); F4	PH-22, PH Q7
D4-21	Specialist input (owner session, 4–5 October 2026); one of the 25 alignment, brief and validation entries. A specialist parity and benchmark method for the native ASySD port. F1 ≥ 0.99 and 80,000 citations in under an hour remain proposals, neither approved nor achieved (T-SI-04; RI §3.15, §12). Original question: What ASySD parity means (Q-37).	Original recommendation, now an input to the specialist review: Parity with pinned R package outputs (identical auto-confirmed groups; probable-duplicate pair-set F1 ≥ 0.99) and the published sensitivity and specificity on labelled datasets; 80,000 citations in under an hour on Bramble.	AC-P2-01 not computable (retired; AC-P2-01r)	Specialist input T-SI-04; F-P	SR-22, review AC-21, AC Q9

Answered by the evidence (no question needed): Q-N9 (RA5 in Q-10): #3965's completed-sessions-only eligibility already excludes requested reviewers until they return their review. Q-D2 (two reconciliation tasks for one study and form): RE4 already decides one task per study and form; the plan's "compatibility class" task key was a contradiction and is corrected.

2. Engineering contracts to settle (no owner question needed)

These need written contracts with evidence before the gate shown. Owners are lanes from the integrated plan; contract IDs are from contracts. E76–E81 (delivery tooling, from the delivery operating model), E82–E87 (from the UX strategy) and E94–E99 (acceptance tooling, from the acceptance criteria §10) name an owner or lane and no contract.

ID	Contract	Lane / contract	Gate
E1	Treatment vocabulary and derived effects: per-question change classes (added, removed, changedCompatible, changedIncompatible, mapped) with their treatments and defaults; per-category application and the counting choice for sessions left pinned; autoUpdate only within a class for valid answers; one session effective-state evaluator (per-answer state enum, requirement standing, qualification) used by admission, readiness, AF2 and exports; Upgrade and late-Save pin rules; FV4 as an appended policy generation (versioning model §7.4, §7.5, §8)	L2, L1, L7 / C4, C5	F1a design, F2
E2	Context identity for ancestors, repeated entities and branches; legacy duplicate detection; stale-base writes; atomic Fix transition	L1 / C2, C5	F1a
E3	Version-usage families over canonical sources (E72), protected publish boundary, definition-rewrite fence, digest compatibility, the scoped-rebuild-at-pinned-snapshot service API, fence-read identity recorded in the manifest, draft-only counts from the draft collection, authoritative affected identities; profile-version usage. The reviewer pause is the engine's scoped fence	L7 / C8	F2
E4	Query concurrency, snapshot replacement, task claims/locking, query queues, notice delivery	L6 / C9, C15	R4b
E5	Cross-stage propagation mechanics (policy in Q-26/Q-27), partial combined-step reservations. Owner session (5 October 2026): Q-26 and Q-27 are decided, and cross-stage routing is replaced by the stage study filter (Q-15), so propagation covers filter reevaluation and step dependencies (SP §4).	L4 / C6, C7	F3
E6	Map grants to existing authority; assignment start, release and reacquire races; additional-review idempotency; blinded aliases; the reconciliation task editor claim (CAS plus lease) in every environment, working with tracking off (X-RECLAIM). Owner session (5 October 2026): aliases are context-local and assigned independently per Study (OS-A03); additional-review requests raise the effective target (RD §3.12).	L8, L6 / C10, C9	F4
E7	Match scoring, missing features, ties, groups of more than two, reference remapping on re-pair	L6 / C9	F4
E8	Snapshot identifiers, current-snapshot pointer CAS, historical reconstruction, as-of manifests	L6, L11 / C9, C11	F4/F6a
E9	Statistical method and denominators (depends on Q-04/Q-16). Owner session (5 October 2026): Q-04 is decided; the formulas are specialist input T-SI-02.	L11 / C11	R5c
E10	Evidence-based legacy session mapping: a membership rule ("membership-uncertain" where an answer's stage differs from the session's), an admin choice when merging sessions into a shared form, adoption-time validation ("legacy-completed, unvalidated" with an admin count/don't-count decision), definitionVersionAtAuthoring = unknown on adopted pins; dry-run invariants; recovery. Owner session (5 October 2026): the gap states are named LegacyCompletionUnvalidated and UnknownAuthoredUnderDefinition, and the mapping runs inside universal baseline conversion (BC §3.2, §3.4).	L15	R6
E11	Reason collection Off while reason reconciliation is On	L3 / C4	F5/R4p
E12	Legacy-compatible and event-count schema fields, roles, types, validation, export	L10 / C14	F-O
E13	Stage lifecycle actions mapped to existing authority; readiness events; idempotency	L4 / C6	R3c
E14	Validate the entity-type catalogue, legacy aliases and feature-required system types at F-C/F-O; the identities themselves (EntityTypeId for the seven legacy categories, cohort, outcome measure, experiment) are minted at F1a	L9, L10 / C13, C14	F1a (identities), F-C/F-O (catalogue)
E15	Physical storage of every logical boundary in domain-model §4 (revisions, sessions, drafts and snapshots), recorded as the F1a storage ADR from VB's blueprint: revisions never embedded in sessions, a full pin map per session version in its own document, revisions in their own collection, only the canonical summary in Study. It shows the largest transaction stays within MongoDB's size and duration limits at the three fixture tiers, decides the canonical summary versus legacy-shaped stub sessions on M0 evidence (E48), lists each new pmStudy index with its operator build route, and fixes explicit collection names	L1 / C1, C18	F1a
E16	Compatibility floor: capture (never ignore-only) on every extended embedded type one release ahead; R0's reader floor (getter and claim-pipeline merges, IReviewMembershipFacts, predicate fragments); the writer floor (ServiceVersionFloor); ownership markers and the composite guard (E49); the per-project enrolment service; the minimum rollback image per service and its rehearsal	L0 / C16	F1a, R0
E17	Review-workflow notification events through C15 v2 (E73): kind registration, capture mode per operation, deterministic occurrence identity, write-time recipient expansion, read-time shaping through the disclosure hook	L14 / C15	Per feature
E18	Claim/reservation identity: claim contract v2 (detailed in E68), typed claims per (study, kind, scope, reviewer) keyed by form or profile identity, with route-stage provenance; capacity claims on Study, editor claims on their aggregates; versioned hub methods, additive DTOs, new command contracts; one reservation migration shared with the eligibility programme's S4-B; signed by the presence, eligibility and FEAT-024 owners	L7 / C7	F1a (contract), F3 (routing)
E19	Shared-form compatibility for progressive batches (evidence seam, pool-entry-based membership and durable opening, E67) and proportional allocation (refusal until AL1, then the AL1 adapter, E65), with their owners	L7 / C7	F3 (batches), F-A (allocation)
E20	Study canonical summary (built under E48): Study.CanonicalSummary keyed by form and profile with per-reviewer membership markers (session state, standing, claim activities, admitting regime), per-profile outcomes (screeningOutcomes[]), a per-bound-stage projection, readiness flags and its definition-version vector. Written with a Study version bump in every study-scoped canonical transaction through FEAT-024's seam (isolated read, version-guarded non-upsert replace, opaque fields preserved) and by projection-rewrite operations; Core policies read it only through IReviewMembershipFacts (E64), whose conformance suite is the eligibility truth table; R0's floor makes legacy getters, predicates and the claim pipeline read it; an inventory of every reader of embedded tallies and membership, tracking's writers and readers included, with its cutover; retired at R7	L1, L7 / C1, C7	F1a
E21	Drafts: one draft record per session, stored outside Study, with lease holder (stable client tab ID, RT-10), etag, per-holder write sequence and heartbeat; bounded conflict copies; take-over; Save/Complete consume the draft atomically; stale autosave rejection; deterministic SessionId created on first autosave; patches against the base with the E28 cap; no TTL, audited discard feeding LC1; indexed by base form version; invisible to reconcilers and exports; cross-form stale-base conflict; whether a draft holds a place is D2-07 (versioning model §7.6). Owner session (5 October 2026): D2-07 and D2-08 are decided. One shared session and place across tabs and devices with base-version checks; the form owns the timeout; autosave keeps a reconstructable draft change log; the lease and take-over shape is a brief detail (RD §3.10, §3.11).	L1, L5 / C5	F1a
E22	Publication: O(1) phase 1 (form fence, drain, preview-digest re-check, CAS of the form head, policy record generation 1, operation record); phase 2 as an ADR-020-style operation rewriting projections by predicate until clean, writing Q-34 mapping revisions and capturing notices once per recipient by recorded fan-out; manifest built after commit from authoritative records with draft_only from drafts; one active publication per form; FV4 generation CAS; scoped admission and readiness pause (versioning model §8; consistency model §4, §7). Owner session (5 October 2026): D2-01 is decided-amended, so phase 2 may also write attributable generated session versions (RD §3.15); D2-10's limits are a brief item.	L2, L7 / C4, C8	F2
E23	One applicability specification (conditional parents, filtered options, branch context, ADR-011) with shared fixtures run by the .NET validator and AF2; typed errors	L1, L5 / C4, C5	F1a
E24	System questions stored as data in a global pmSystemQuestionVersion store keyed (guid, SystemQuestionVersion, seq), seeded idempotently from code, identity (guid, SystemQuestionVersion) so v0 and v1 structural variants are distinct, CAMARADES content versions with the ordinary compatibility declaration, adoption only through a project form publication (D2-06); never rebuilt per read on canonical paths; no code-revision key (versioning model §3.7)	L2 / C4	F1a
E25	Ordering and as-of (built under E51): per-aggregate versions, with per-study order given by the Study version, plus an HLC stamp on every canonical record from the first write; no per-project commit sequence in any interactive transaction (the M0 evidence is recorded in the C11 ADR with ADR-019's numbers); as-of(T) only for T older than the watermark (transaction lifetime + sweep + twice the skew bound + margin); dataset classes in manifests	L1, L11 / C1, C11, C18	F1a (stamps), F6a (as-of)
E26	History capture from first enrolment (built under E54): legacy screening writes (R2a), pool-entry events (R3a), retrieval and lifecycle events (P1), captured inside the aggregate in the same document write and moved to pmLegacyWriteLedger by a leased worker; overflow is a coverage gap; every writer named and tested. Owner session (5 October 2026): pool entry splits into WorkFirstReleased and the StagePool* membership events in HistoryEvent (C20; SP §3.5, §3.12).	L1, L12 / C3, C12	F1a
E27	Identifiers: deterministic SHA-256 IDs over a versioned canonical key (as CSUUID) for aggregates with natural keys (FormSession, AnnotationHead from the key hash, ReconciliationTask, StudyGold, default population, CanonicalOwnership) with the natural-key unique index as the real guard; client-proposed, server-validated IDs for revisions and entity instances (well-formed, unused, same project); legacy IDs kept through LegacyIdAlias (versioning model §12.3)	L1 / C1, C2	F1a
E28	Commit limits expressed as maximum pins per session version, maximum changed revisions per commit and maximum BSON bytes per commit (not question count), refused before any write; draft size cap tied to the same limits; three fixture tiers (typical, p99, max) from D1-08; an initial form size ceiling until benchmarks prove larger forms safe (D2-16). Owner session (5 October 2026): D2-16 is replaced. No size-based exclusion; limits are set at or above the max tier with evidence, and the largest project is an acceptance case (RD RD-R33).	L1 / C1, C5	F1a
E29	LC1 stage completion in two steps: the Completing fence, a drain, readiness verified from authoritative records in a pinned snapshot, then Completed or back to Active. Readiness-relevant commands are refused while Completing and become change requests once Completed; approval re-validates at commit and commits the underlying change with the status; claims are withdrawn through the outbox; notices inline, with flags-off queues. Owner session (5 October 2026): Q-02 is decided. An automatic Completed stage is recalculated when remaining work appears; change requests stay for protected changes to a Completed stage (SP §3.10).	L4 / C6, C18	F3 (design), R3c
E30	Post-commit effects (C19, E47): every effect classified as derived on read, durable intent or best-effort hint, with the event catalogue in domain-model §6.2. Outdated flags are derived on read. Durable intents use the claim-revocation outbox pattern or an operation record. Notifications are captured inline (bounded) or by recorded fan-out, with deterministic SourceIds. The existing mechanisms are reconciled: FEAT-024's pending entries and its notification outbox (#3107), the claim-revocation outbox, Identity's recovery-email outbox, the notification stack's inbox rows and change-stream hint, and in-process IDomainEvent (loss-tolerant only, after #3973)	L1, L14 / C1, C15, C19	F1a
E31	Restore (E55): no selective per-project restore of canonical data (D2-13); a whole-database point-in-time restore into an isolated database plus manifest-driven forward recovery; a history-discontinuity record; the integrity checker across collections (pointers, pins, drafts, command-bearing records, the canonical summary, markers and the registry) passes before writes reopen; scheduled state is reconciled from Mongo. Owner session (5 October 2026): D2-13 is a brief item, specified and rehearsed per BC §8.4; production execution needs separate authorisation.	L15 / C16, C18	F1a (policy), R2a (rehearsal)
E32	Erasure and retention: canonical records store only opaque investigator GUIDs (with a schema check); account deletion anonymises the Investigator record, and answers stay attributed to it (D2-14); as-of exports are identical except erased identities, recorded in manifests; retention rules for drafts (audited discard only, no TTL), conflict copies, exposure events, presence and connection records (pmReviewerPresence, kept indefinitely today, and pmReviewSessionConnection), inbox items and the notification stack's stores (preferences, the delivery ledger, digests that hold notification IDs, conversation and issue posts as free text under the annotation erasure rule, and checked PDF bytes); retention never orphans ledger or digest references. Owner session (5 October 2026): D2-14 is decided-amended. Account deletion keeps named attribution; anonymisation and erasure in manifests become conditional on T-POL-02, an identity-erasure process that is not decided (ACD §3.1).	L1, L8, notification programme, presence owner / C1, C10, C11, C15	F1a
E33	Reviewed-record merge and split as an alias (D2-12): Study.mergedInto and a StudyAlias entry on the primary; per-reviewer resolution (AliasResolutionPolicy) counted once; no immutable record re-keyed; ADR-020-style operations writing both Study documents and refusing busy studies; a split removes the alias; FEAT-024 staged fences and a rebuild. Owner session (5 October 2026): rewritten. D2-12 is replaced by consolidation and unmerge: StudyMerge staging plus atomic activation, StudyUnmerge with carry-forward items, MergeConflictTask, and the stored CurrentEvidenceView with its size, write-cost, parity and read-cost proof before its design freezes. The alias design above is kept as history only (DM §3, §4.5, §4.10; C21).	L1, L12 / C1, C2, C18	F1a (design), P2
E34	Cross-form conditional consistency: FEAT-001's D51 (materialised crossStageConsistency via domain events) is replaced by the derived per-answer states NotApplicable and NeedsUpdatingValue bounded to one reviewer's sessions on one study; D53's immediate client-side warning stays as AF2 behaviour using the shared E23 evaluator; D54 and D55 (reconciler acknowledgement and enforcement levels) are replaced by RE2's non-blocking warning per Batch D D4-17. Owner session (5 October 2026): D4-17 is decided-amended; the outdated-answer mode is configurable, warn (default) or block (RS §5.8).	L2, L1, L5 / C4, C2, C5	F1a
E35	Replaced by E50, the canonical command ledger (C18; consistency model §5). FEAT-024 receipts stay statistics-protocol receipts, with the CommandId as their OperationId	—	—
E36	Compatibility and class evaluator: diff classifier producing the system suggestion, class derivation and classSeq stamping, immutability guard (refuse a flip once any revision pins the version; re-validate active publication policies before that), designer pending-edit record with lease and etag (versioning model §3.5, §3.9)	L2 / C4	F1a
E37	Option identity and payload contract: optionId minting, typed payload (value XOR response mode, metadata, option IDs), display value and label resolution, v0/v1 legacy option and condition mapping with a manifest of unmatched values (versioning model §3.3, §11)	L2, L1 / C1, C4	F1a (payload); R6 (mapping)
E38	Composition and renderability validator: applicability graph validated against pinned parent versions by option ID; AF2 structural guards run server-side at publication with shared fixtures; typed refusals naming the question (versioning model §4.2, §4.3)	L2, L5 / C4	F1a
E39	System question store: idempotent seeding, (guid, SystemQuestionVersion) identity, the CAMARADES publication command, no per-read rebuild on canonical paths (versioning model §3.7; replaces the mechanics part of E24)	L2 / C4	F1a
E40	Session effective-state evaluator: per-answer state enum (eight states), requirement standing, qualification, policy composition across publications and FV4 generations; one implementation for admission, readiness, AF2 and exports; projections carry the input-version vector (versioning model §7.4, §7.5, §8.4)	L1, L7 / C5	F1a design; F2
E41	Head key value object, versioned canonical serialisation and hash, partial unique indexes per kind, Conflicted head state, AuthoredUnder typed union, LegacyIdAlias (versioning model §6.1, §6.2, §6.6, §11)	L1, L15 / C2	F1a; R6 for the alias
E42	Entity instance commands (create, rename, withdraw, duplicate), population membership as an instance attribute, outcome cells keyed by instance, per-session presentation record outside versions (versioning model §6.5)	L1 / C2, C13	F1a
E43	Append-only persistence: AppendOnlyRecord base, IAppendOnlyRepository<T>, explicit collection-name map with its test, content digests on every immutable record, the architecture test forbidding updates on immutable collections, no TTL on canonical collections, string enums, the read-only integrity checker for invariants I1 to I6 (versioning model §12.2 to §12.4)	L1 / C1	F1a; checker in R2a
E44	AF2 VersionedAnnotationFormDataSource (pinned versions by ID), the Needs-updating presenter contract (fromVersion, toVersion, treatment, reason, guidance, prior value rendered with fromVersion's labels), immutable-definition cache with Cache-Control: immutable, typed no-fallback error for canonical routes (versioning model §4.3, §12.5)	L5 / C17	F1c (seam), R2a
E45	Reconciliation under versioning: task input-set versions, per-question held derivation, gold re-reconciliation derivation, second-task revision of shared gold (D2-09), query target as the reconciled revision ID (versioning model §9)	L6 / C9	F4
E46	Canonical transaction admission ADR (C18): options and deadlines, re-execution, free retries with MaintenanceSequence, the typed outcome catalogue, the cache rule, non-upsert saves, collection and index creation (pmStudy through the operator route), DuplicateKey handling, CanonicalCommitCommandBudgetTests	L1, L0 / C18	F1a
E47	Durable effects and events ADR (C19): the three classes, a generic durable-intent store on the claim-revocation outbox pattern, the operation record family, change streams as hints, IDomainEvent only after #3973; with the notification programme, the inline and recorded fan-out capture modes, scheduler markers and deterministic notification IDs	L1, L14 / C19, C15	F1a
E48	Study.CanonicalSummary and R0's behavioural floor: shape, write rules, getter and claim-pipeline merges, IReviewMembershipFacts, shared predicate fragments; the M0 evidence that decides against legacy-shaped stub sessions; floor steps before R2b and R3a	L1, L7 (with the presence and FEAT-024 owners) / C1, C7, C16	F1a (design), R0 (floor)
E49	Ownership markers and the composite write guard: the CanonicalScopes vocabulary, aggregate-method checks, the ambient writer scope, the architecture-test extension, project-wide pre-checks, registry reconciliation, the greenfield stamping sweep, and the writer and reader inventory (every pmStudy UpdateMany, tracking writers, notification-stack writers)	L0, L15 / C16	F1a (design), R0 (build)
E50	Canonical command ledger: CommandId and digest rules, the command-bearing record per command class, outcome-unknown resolution, FEAT-024 OperationId correlation, inbox SourceId derivation	L1 / C1, C18	F1a
E51	Ordering and as-of: the HLC stamp format and stamp collector, the per-study clock, maximum-drift refusal, the watermark rule, dataset classes, versioned alias records, erasure in manifests	L1, L11 / C11, C18	F1a (stamps), F6a (as-of)
E52	Fences and operations: ScopeFence, the drain from measured server settings (with an optional host in-flight beacon), lease and operator release; pmCanonicalOperation with lease, generation, stable cursor, chunks, final pass, one-active index and limits; bulk-lock interplay	L1 (primitive); L2, L4, L12, L15 (uses) / C19	F1a (primitive); F2, F3, P2, R6
E53	Derived records: the DefinitionVersionVector on every derived record, fail-closed gates, predicate sweeps, the race fixtures (decision against profile publication, threshold change against decision, binding change against Save)	L1, L3, L4 / C1, C6, C18	F1a (shape); F3, F5
E54	Legacy history capture: the bounded Study log, the PM worker into pmLegacyWriteLedger, overflow as coverage, one test per named writer, pool-entry writer enumeration	L1, L12 / C3, C12	F1a (design), R2a
E55	Integrity checker and restore policy: checker contents and schedule, the post-restore gate, the discontinuity record, scheduled-state reconciliation, the isolated-database rehearsal	L15, L1 / C16	F1a (design); R2a (checker; rehearsal before the first production pilot)
E56	Write-path evidence: a canonical-commit arm in FEAT-024's benchmark harness (1, 2, 5 and 10 reviewers; same and different study; eligibility off and on; capture on; fold, claims and a sweep running), three fixture tiers, a failure-injection harness (crash points, unknown commit, failover)	L1, L17 / C18	M0 (evidence for F1a); every release gate
E57	Claim consistency: the claim contract v2 rules (capacity claims on Study, editor claims on their aggregates, uniqueness, last-page release, draft-aware release, lease expiry and a backstop sweep), the canonical claim pipeline, the M15 dependency for X-CLAIMS, budget test updates	L7 (with the presence and FEAT-024 owners), L6 (editor claims) / C7, C9, C18	F1a (contract); F4 (editor claim); X-CLAIMS
E58	Context map as the first contract ADR: one namespace per bounded context under Core/Model/<Context>/ and Core/Services/<Context>/, internal by default with Core/Contracts/<Context>/ as the public surface, and architecture fitness tests (a source-scanning test extending StudyWriteLockArchitectureTests for ownership filters and append-only writes; a reflection-based dependency test for the allowed context dependencies and the hosting rule)	L0 / all	F1a
E59	Command catalogue and hosting rule: every canonical command has one handler in ProjectManagement.Application; API and PM are hosts; PM receives notification-capture capability (flags or the admission-record pattern) as an R0 item; platform-architecture.md §2 corrected in the F1a docs PR	L0, L1, L14 / C18, C19	F1a (catalogue), R0 (PM capture)
E60	Policy catalogue (domain-model §7.1): each policy a pure Core domain service with a fixture suite; IReviewMembershipFacts extracted now with the embedded-Study provider, so the eligibility truth table becomes the conformance suite	L1, L4, L7 / C5, C6, C7	F1a
E61	Shared-kernel value objects frozen with equality rules (domain-model §7.2): AnswerContextKey and hash, typed EntityPath, DefinitionOwner versus owningParent, Provenance, ExposureState, AuthorityValue, DefinitionVersionVector, ClaimKey, EntityTypeId; a joint conformance suite per shared type	L1, L2, L9 / C1, C2, C13	F1a
E62	One Stage aggregate for canonical projects (settings versions, lifecycle, change requests, status history; Active derived); the settings placement table for every existing per-stage setting; settings versions reference the allocation regime and batch plan by ID with embedded Stage.WorkloadShares and ProgressiveBatches legacy-only; two-step completion. Owner session (5 October 2026): the placement table moves the inactivity timeout, in-progress limit and capacity baseline to the form, blinding to the form or profile and VS1 to a form baseline (Q-28; SP §3.2, §3.11).	L4, L7 / C6, C7	F3
E63	Reconciliation task identity (study × form) with versions recorded as state; ReconciliationSession as a task entity with a task-keyed draft; the editor claim; PublicationImpactPolicy for drift; the compatibility-class decision removed from F4. Owner session (5 October 2026): a task exists for every form with a qualifying candidate, including target-one forms (Q-29; RS §3.1).	L6 / C9	F4 (shape at F1a)
E64	Membership-facts seam: IReviewMembershipFacts, behind which the pool predicates, StageWorkloadShareEligibility, AllocationClaimSlot, ActivityReservationAdmission, the own-place checks and the capacity pipelines read per-reviewer facts (own session state per form, claim kinds held, own decision per profile, other reviewers holding a place); embedded-Study provider first with truth-table parity and no behaviour change; CanonicalSummary provider at R0/R2a	Eligibility owner, L1, L7 / C6, C7	F1a (seam), R0
E65	Allocation on canonical stages: refusal guard until AL1 (no shares on canonical stages; R0 refuses a stage with an enabled regime); AL1 adapter with regime schema v2 (form binding, target source), a floor one release ahead, the compatibility check, read APIs and editor on the membership projection, the D8 slot rule on form-keyed claims, and refusal of a form publication that changes the target under an active regime	L7, allocation owner / C7	R0 (guard); F-A, AL1 (adapter)
E66	Requested-review admission and capacity cap: the requestedReview claim written by the AdditionalReviewRequest command (single use, expiring, audited), honoured by pool filters, allocation, typed admission and capacity guards for that reviewer only; target unchanged; counted outside allocation progress; the optional capacity cap (D3-17); the set of sessions that hold a place. Owner session (5 October 2026): an additional-review request raises the effective Study × form target through StudyTargetOverride and counts reviewers once; "target unchanged" is superseded; the cap stays brief item D3-17 (RD §3.12; SP §3.11).	L6, L7 / C7, C9	F4 (design), R4a (build)
E67	Progressive batches for canonical stages: IStudyObligationEvidence with legacy and canonical providers; pool-entry-based membership with late cohorts; compare-and-swap opening and personal grant writing pool-entry events and durable intents; read-only status; performance gate (Next p95 at 100,000 studies and 2,500 batches; AC-R3a-26, AC-R3c-17). Owner session (5 October 2026): batch membership runs over stage pool episodes, and release is recorded as WorkFirstReleased (SP §3.7).	L7, batch owner, L12 / C7, C12	F3 (contract), X-BATCH
E68	Claim contract v2 and one reservation-key migration: typed claims unique per (study, kind, scope, reviewer), released when the last page ends; capacity claims on Study, editor claims on their aggregates; keyed by form identity; versioned hub methods, additive DTOs, new commands with old handlers kept at least the suspension grace plus the idle timeout; presence index create–read-both–drop; S4-B targets the final key with stage provenance; consumer inventory (pool predicates, D8 slot rule, typed admission, Study.GetSlotReservation, FEAT-024 reservation fold kinds, presence index, hub join, idle/suspension/liveness consumers and their scheduled commands, claim-revocation intents)	L7 with presence, eligibility and FEAT-024 owners / C7	F1a (contract), R2b (ship), X-ELIG (migration)
E69	Production claims route (X-CLAIMS): per D3-16, the binding-scope tracking setting enabled per admitted pilot, or the M15 transition with an admin route rehearsed on staging; API and PM switched together statically; orphan-claim backstop (absolute lease expiry, or a bounded sweep behind its own flag); load and failover on Bramble; E2E in both tracking modes. Owner session (5 October 2026): D3-16 is a brief item; project-scope tracking through the admission record is the PROPOSAL (SP-AMB-12).	Presence owner, FEAT-024 owner, L17 / C7, C16	Before R2b/R3a production claims
E70	Tracking adapters: at R0, the tally getter and claim pipeline merge canonical counts and markers, and tracking's writers and readers join the inventory with tests; at R2a, own-place detection through E64, claim release on the first explicit Save/Complete in the canonical transaction, presence FormSessionId, dirty = draft-changes flag, draft-aware release (D2-07), and the draft lease on a stable tab ID that works with tracking off (D2-08). Owner session (5 October 2026): D2-07 and D2-08 are decided (form-owned timeout; one shared session across tabs and devices).	Presence owner with L0, L1, L5 / C5, C7, C16	R0, R2a
E71	Target-aware annotation classification: replace the fixed two at StudyStats.cs:353-355, AnnotationThresholds.MinimumNumberSessions (a digest input) and StudyRepository.GetSessionFilter (#3979) with the effective target; catalogue bump and digest migration with a reconciliation plan (forced rebuild of allowlisted projects; retained checkpoints keep their identity); ProjectStageConfigurationChange.AffectedFamilies extended	FEAT-024 owner; architecture-review owner (#3979) / C7	Before R2b pilots on allowlisted projects; before R3a (X-STATS-c)
E72	FEAT-024 canonical-sources amendment: technical-plan amendment and ADR for families over canonical collections in the same pinned snapshot (FormVersionUsage, QuestionVersionAnswers at F2; profile families at F5 per D3-10c); scope kinds and key components with tolerant maps; a new-family onboarding contract with an N-1 test; #3506; usage over explicit versions with drafts counted authoritatively; the scoped-rebuild-at-pinned-snapshot service API; fence-read identity in the manifest; protocol 5 batched after gate (b)	FEAT-024 owner with L2, L7 / C8	F2, F5
E73	C15 v2 in the notification stack: kind registry through DI; Source sub-document; one capture service (bulk upsert with $setOnInsert); deterministic SourceId and row ID; inline and recorded fan-out (NotificationFanOut and a leased expander); server label, context, availability and state; disclosure hook per channel; unknown kinds leave the ledger row ready, one deploy ahead; registry test	Notification programme; L14 (specification), L8 (hook) / C15, C19	ADR in W0; frozen at F1b; landed after the base merges and before the first review-workflow kind
E74	Notification enablement controls (G-NOTIF evidence): tolerant preferences and a kind→category map before #3942 merges; declared email→inbox dependency; operator delivery halt; inbox reads independent of capture admission; per-project notification admission (an interim registry, then an R0 enrolment scope); idle workers when nothing is enabled or pending; route guards with opt-out reachable; flood controls; retention per E32. Owner session (5 October 2026): D3-21 is a brief item; per-project mute and the O2 content policy are prerequisites before any email category is enabled outside Mailpit (ACD §3.5, §3.6, §3.9).	Notification programme with L0 / C15, C16	Before any enablement outside e2e and Mailpit; flood controls before R2c
E75	Flag delivery and evaluation consistency: reviewEligibilityPolicy and proportionalStudyAllocation delivered to PM (one block replacing #3939's partial one) with a cross-host agreement check before either is enabled; PM-hosted branches inventoried; one flag evaluation per request passed into admission, with a test; no gate or evidence relies on runtime overrides until #3975 is fixed; R0 admission is the domain enrolment that P7 per-project targeting keys to	L0 with eligibility, allocation and flag-overhaul owners / C6, C16	Before X-ELIG enablement; F1a (P7 alignment)
E76	The STATUS ledger format, slice-issue labels, claim records and a gh-based weekly digest script (decision ages, start delays, chain RAG, WIP, criteria coverage from the traceability file)	Programme lead	S0 (S0-5)
E77	Flags registered once: the five stream kill switches and R0's admission flag in env-mapping.yaml with regenerated outputs, catalogue counts and consumer-manifest entries; later slices only flip defaults at enablement	Stream A with each stream	S0 (S0-6)
E78	Release-candidate and acceptance-record tooling: candidate commit and image SHAs captured from the staging GitOps values; the acceptance-record template; the rerun rule when later merges touch the release's paths; the staging promotion-pause procedure agreed with the cluster-gitops owner and tested once	Programme lead with L17	Before R0's ship gate
E79	Fresh-context verifier checklists: one per programme rules file (§2.5) and the ship-gate verifier (criterion IDs to evidence; invariants 1 to 12 to INV checks), with a fixed PASS, FAIL or N/A report format and an exceptions list for the dossier	Programme lead	F1a (first use)
E80	CI and host instrumentation: start-delay capture for the digest; path-filtered conformance test projects with a five-minute target and their routing-contract changes; a capped, niced local-build wrapper for Juniper sessions; the Bramble booking table in STATUS	Programme lead with stream A	S0, then F1a
E81	Conflict-avoidance checks: a non-generated, non-test changed-line counter reported in the PR body; an ADR number uniqueness and block check in docs validation; a shell-file lease check against STATUS	Programme lead with L17	S0
E82	Save-status state machine, bounded local copy (IndexedDB) with sequence replay, conflict and take-over screens, typed-outcome recovery copy; lease by stable client tab ID with REST heartbeat; works with tracking off. Owner session (5 October 2026): the bounded local copy is UX ambiguity A1: no offline writes are authorised and protected data is never cached by accident (UX §12).	L5 with L1	F1c (copy), R2a
E83	Copy deck mechanism: deck document, typed message constants per feature, shared core-terms file, banned-string and import guard spec, user-guide glossary parity script in docs CI. Owner session (5 October 2026): the core terms follow D3-03 ("Draft auto-saved" and "Version checkpoint saved", illustrative).	L16	F1c
E84	Pattern inventory as shared components, spec gallery route behind a flag, handoff template, "What changed" panel with per-user dismissal, anchored tour component, contextual help on every new screen	L16 with L5	F1c, R2a (panel), R3a (tour)
E85	Accessibility and browser harness: @axe-core/playwright with baselines and journey-state checks, screenshot matrix at the UI-6 widths, forced-colours and reduced-motion runs, Firefox and WebKit smoke projects, native-drag guard spec, CDK drag for the question tree before R1a, browser floor (.browserslistrc, target, polyfills). Owner session (5 October 2026): D3-15 is decided.	L17	W0 and S0; R1a precondition
E86	My work: read-time counts endpoint over the four queues and admission-based work, project-level surface, global badge, cross-project tab, admin LC1 banner, deep links by task identity and alias; workflow version badge and panel, admission action, containment banner, legacy explainer. Owner session (5 October 2026): D3-07 is decided.	L16 with L6, L4, L0	R0 (panel), R3c, R4a
E87	Reviewer efficiency: keyboard screening path reconciled with DP3 and DP5, live completeness and jump on every host, input-latency budget under autosave, privacy-safe timing events (subject to D3-08) and the baseline measurement protocol. Owner session (5 October 2026): D3-08 is decided: consent-based timing events without answer content.	L5 with L3 and L17	R2a (count, latency), R3a, R3b (keys)
E88	Observation-basis markers and the agreement store: initial-independent-submission marker derived at commit; collective-exposure record at correction with route kinds; "questioned in reconciliation" exposure looked up by session (#3965); imported authority and independence declaration; calibration purpose; computation from canonical revisions into the rebuildable agreement store (D3-11) under the method contract (E9). Owner session (5 October 2026): "imported authority" becomes imported provenance for mapped human imports, machine sources form their own class (RI §3.13), and calibration becomes training (TI).	L1, L11 / C3, C11	F1a (markers), R5c (store)
E89	Full-text retrieval event model: StudyLifecycleEvent kinds for Sought, Retrieved (how) and Not retrieved (reason list, author-contact date) with actor; automatic Pending → Sought on title/abstract collective Include; the "suggest Retrieved" hook from the PDF programmes; full-text admission on fullTextStatus; box derivations per amendment M	L12, L4 / C12, C6	F-P (P1), F3 (admission)
E90	Extraction provenance and validators: extractionMethod and dataSource roles; unit vocabulary with SI-aware labels and the same-measure validator; dispersion catalogue; domain validators; nSource rule; graph-estimated default on region link; extraction QC view queries	L10 / C14	F-O (O1)
E91	PRISMA arithmetic and authoritative snapshots: identity checker I1–I13 with remainders and administrator explanations; entry-phase and per-box combination for external records; computation from authoritative records at a hybrid-logical-clock watermark; template-variant switch for box 1; withdrawn-search exclusion	L12 / C12	F6b (R5b); K and L parts at F-P
E92	Link records: CitationPublicationLink (amendment N; whether P1 also creates Publications for exact DOI/PMID matches) and StudyLink groups (amendment O), with alias and group resolution in counting and exports. Owner session (5 October 2026): StudyLink groups (amendment O) are deferred with D4-08; prepared reference links on StudyVersion stand in for now (RI-R03).	L12, L1 / C12, C11	F-P (N), P2 (O)
E93	Analysis-ready exports and transparency outputs: comparison pairing rules; codebook schema; RIS tag mapping; Record synthesis inclusion capability and attribute; near-miss preset; methods-summary schema; domain × study RoB matrix	L11, L12 / C11, C10	X1, R5b
E94	Traceability file and check: the YAML format in acceptance criteria §9.1; generated views (decision to criteria, criterion to tests, per-release acceptance record, pending view, tag check); a docs-CI job that fails on an uncovered ledger or §1.11 decision, a row without Source or Status, or a test tag naming an unknown or retired ID	L17	S0
E95	Mixed-version harness: starts the current image, writes canonical fixture data to a persistent database, starts the recorded minimum image against it, runs legacy flows and an unrelated-field replace round trip, and reports both image SHAs	L17, L0 / C16	S0 skeleton; F1a
E96	Deterministic barrier harness on MongoDbReplicaSetTestFixture: named interleaving points (after read, before commit, after commit and before dispatch), fixed seeded schedules, and an assertion that the forced interleaving happened	L17 / C18	S0; F1a
E97	Seed-if-absent job: additive and idempotent, keyed by fixed GUIDs, run on preview and staging separately from ownership reconciliation; canonical seed projects created through canonical commands once R0 and R2a exist (D3-14). Owner session (5 October 2026): D3-14 is decided: add missing staging seeds, prefer preserving staging data, allow justified staging changes, never production.	L17, L0	S0; each release
E98	Benchmark arms: today's session submit and screening save, then the canonical-commit arm, on RV-DS-01 to 05 at the D1-08 tiers, with 20 warm-up and 200 recorded iterations, a same-host main baseline and a report naming commit, dataset and host	L17 / C18	S0 baseline; F1a
E99	Cross-language fixture corpus: versioned JSON under src/libs/testing/SyRF.Testing.Common/ with a schema check, loaders for xUnit theories and Vitest describe.each, a differential runner across the .NET and AF2 evaluators, and per-release assertion files	L17 / C1, C2, C5, C12	S0

3. UI validations before building

Each validation also checks accessibility (keyboard paths, screen-reader meaning, contrast in both themes), the copy contract and the Material 3 UI standard (acceptance criteria §3).

ID	What must be shown in a prototype or usability session	Release
U1	The reconciliation workspace handles 3, 4 and more candidates (answers, matching, outcome series) without two-slot assumptions; stable aliases and blinding (RD17, SF4/RE3); agreement icons and prefill when answers are partial or blank (UA1, RE5, no majority); a candidate selector never hides a disagreeing candidate; a keyboard alternative to drag-pairing; performance with N candidates on large forms. Owner session (5 October 2026): context-local aliases and unpredictable order (OS-A02, OS-A03), and the one-candidate layout for target-one human reconciliation (RS §5.1).	R4a
U2	A per-step Skip/handoff action versus study-level Skip; scope is obvious; Skip never records Exclude or completion (RC6)	R3a
U3	Population context placement in the reviewer form; compact cohort selection that doesn't push the form down (RC8)	C1
U4	Clear autofill marks, unseen-control warning with routes, Complete anyway; affected-session Fix navigation, including route choice and the wait for LC1 approval (RE2, SF5). Owner session (5 October 2026): also the reviewer's labelled reconciled-answer hints with explicit click-to-fill (OS-A04).	R2d/R4a
U5	Publication pause/retry and route-change messages preserve work and never reveal votes (OD5)	R2c/R3a
U6	The publication flow as four steps (Review changes → Impact summary → Choices with defaults → Confirm) with a "what reviewers will see" preview and a dry-run summary; completed, saved-incomplete and draft-only impact, existing choices, missing-reason warnings and conflicting per-question decisions within one session (FV1–FV4, VU1–VU3); comprehension per category (AC-UX-02)	R2c
U7	Step strip plus one form area versus card-per-step (Q-12). Owner session (5 October 2026): Q-12 is decided (step selector with one form area); this validation still runs.	R3a
U8	Members & groups with project and stage permission subsections; delegation envelope; why a person can or cannot act	R1b (visibility), R1c (dialog and groups), R1d (delegation)
U9	Ordinary question editor versus profile-owned eligibility editor: one editor, unmistakable ownership	R2a/R3b
U10	Completed-stage change approval dialog (LC1) for automatic and manual modes. Owner session (5 October 2026): Q-02 is decided; the approval dialog covers protected changes, and automatic stages recalculate without a hold.	R3c
U11	Replacement guided setup: resumable draft, preview and publish with impact gates, manual route kept	R3d
U12	Stage designer: dependency edges separate from display order, effective-policy preview, cycle rejection, EW1, VS1, BL1, lifecycle mode, versioned-settings publish preview. Owner session (5 October 2026): the designer shows the stage study filter, step dependencies, exclusion-stop and continuation settings; BL1 and VS1 move to the form or profile (Q-15, Q-28).	R3a
U13	Reviewer states: kept changes vs Save progress vs Complete vs current version, how to tell which version counts, and the slot states (held, released, enough reviewers, offline; U38 details). Owner session (5 October 2026): "Draft auto-saved" versus "Version checkpoint saved" versus completed (D3-03, illustrative wording).	R2a
U14	Forms page, form composition and minimal stage binding	R2a
U15	History panel	R2a
U16	VS1 accepted-answer display with exposure capture and the VS2 disclosure interstitial ("You are about to view accepted answers for this study. Your contribution will be recorded as informed."). Owner session (5 October 2026): VS1 becomes labelled hints with click-to-fill, on by default, with exposure and adoption recorded (OS-A04).	R4a
U17	Profile eligibility questions and derived-decision reasoning on the screening renderer (DP3)	R3b
U18	Deliberate correction of one's own Exclude from history (DP2)	R3b
U19	Question-template browse and import	R1a
U20	Assignment, expiry, release/reacquire and Request an additional review. Owner session (5 October 2026): expiry is optional and off by default (Q-30); requests raise the effective target (RD §3.12).	R4a
U21	Raising a query, the query queue and per-raiser outcomes	R4b
U22	As-of export selector, manifest and coverage labels	R5a
U23	PRISMA views, reconciling #2621's prisma-workflows prototype with FEAT-011 and C12	R5b
U24	Outcome-measure and custom-schema authoring	O1
U25	Review-workflow items in the inbox: action labels, deep links that respect task identity (RE4) and aliases (BL1), "Related item unavailable" (joint with the notification programme)	Per release
U26	Export disclosure: who may unmask identities, and candidate vs gold separation	R2a
U27	Coexistence: navigation and editor behaviour for classic and versioned projects, checked with a tester who holds both kinds of project; the workflow version badge	R2a, GA
U28	Pilot rollback: what reviewers and admins see when a pilot becomes read-only	R2a
U29	Agreement view: its own capability-gated place in the navigation, the independent/informed split, missing-state reporting and compatible-version flags	R5c
U30	My work: from the project index, reach an assignment in an unopened project in one step; as an admin, see a pending change request in the badge and banner without opening the project; the four queue filters; empty states; all with every notification flag off (NS-07, UX-08; pending D3-07). Owner session (5 October 2026): D3-07 is decided.	R3c, R4a
U31	Save-status indicator and recovery: Saving, Kept, Retrying, Offline kept on this device, Failed; take over editing from a second tab; recover a stale base; "keeps both" copies in history (UX-04, UX-17, RT-10; pending D2-08). Owner session (5 October 2026): D2-08 is decided (one shared session across tabs with base checks; take-over is a presentation option); state names follow D3-03.	R2a
U32	Workflow version badge and panel, the admit or remove action, the legacy explainer and the read-only containment banner (UX-11, UX-18, U28)	R0, R2a
U33	Keyboard screening path: 20 studies by keyboard on a desktop and 20 on a 390 px phone with the keyboard hidden; the plain-profile, DP5 reasons and DP3 derived-decision variants; at most two actions per decision beyond answering eligibility questions (UX-02, PH-35; pending D3-05). Owner session (5 October 2026): D3-05 is decided: phones cover full annotation as well as screening.	R3a, R3b
U34	Live completeness ("N required missing · Jump to next") and Unanswered only on a 200-question form; input latency under autosave (AC-UX-04)	R2a, R3a
U35	The "What changed" panel (read, dismiss per user), the anchored tour (pause, resume, replay) and contextual help links (UX-09)	R2a (panel), R3a (tour)
U36	The reconciler journey end to end (pool → task → screening part → matching → form → Complete → next) at 1440 px and 925 px and in the narrow layout; the next-task rule; release and reacquire (UX-14)	R4a
U37	The redesigned notification inbox and preferences (UI-1 to UI-11), mark all read, project and kind filters, context line, hide unavailable, "resolved" state, grouped digest (NS-10, NS-13; pending D3-01, D3-23). Owner session (5 October 2026): D3-01 and D3-23 are brief items.	before R2c
U38	Slot and presence states: held, idle warning, released with and without the capacity cap, an Include refused for a dependent step, offline; presence counts without names (RT-22, RT-14; pending D2-07, D3-17, D3-19, D3-20). Owner session (5 October 2026): D2-07 is decided; D3-17, D3-19 and D3-20 are brief items.	R2b, R3a
U39	The interim readiness-based setup checklist in the navigation footer at R2a, timed to a screenable stage (UX-19)	R2a
U40	Long-running operations in the job language: publication phase 2, ASySD matching, as-of export generation, O2 dry-run, adoption wave; where each appears (Processing or a release-owned surface) and its pause copy (UX-16; pending D2-10). Owner session (5 October 2026): D2-10 is a brief item.	R2c, P2, R5a, O2
U41	The duplicate review queue and the merge or split wizard with alias presentation (V2-25; pending D2-12). Owner session (5 October 2026): D2-12 is replaced. The merge wizard covers preview, conflict tasks, delegation, commit and unmerge with carry-forward choices, with no alias presentation (DM §4).	P2
U42	Terminology card sort and "which version counts" vignettes for the copy deck terms (UX-05; pending D3-03). Owner session (5 October 2026): D3-03 is decided with wording flexibility; the card sort may refine the illustrative labels.	F1c
U43	Pattern gallery review: every shared pattern's states, keyboard model, narrow behaviour and copy keys, accepted per pattern before its first consumer builds (UX-07; pending D3-02). Owner session (5 October 2026): D3-02 is a brief item.	F1c, then per pattern
U44	Screening with bibliographic details hidden per profile (SR-25, PROPOSAL, default off); the exposure provenance records it	R3b
U45	The legacy chrome and shared pages after the Material 3 restyle, walked by a tester who holds both kinds of project; no behaviour change (D3-06). Owner session (5 October 2026): D3-06 is decided: compatible new features as well as the restyle, with workflow semantics unchanged.	GA

4. Provisional assumptions used by the plan

If an assumption turns out wrong, the "cost" column names what changes.

ID	Assumption	Basis	Cost if wrong
A-01	A form version is the immutable, ordered selection of question versions (with ancestors), plus form-owned requirements and target. The QM v2 "question set version" maps to it. Owner session (5 October 2026): confirmed by OS-A12; the standard target is part of the immutable form version.	SF1/SF2, FV1, QM-08/09	Contract C4 changes; R2a scope shifts
A-02	The existing AF2 reviewer form is extended for drafts, Save/Complete versions, needs-updating and provenance; it is not rebuilt. Screening-only steps need an AF2 admission change or a dedicated renderer (F5).	AF2 is on main; COMPARISON lane U	A reviewer-UI rebuild would add a large lane before R2a
A-03	New capability names in this package are placeholders until Q-03 and the endpoint audit	Permission matrix	Naming only
A-04	Admission is per project: new projects and admitted pilots first; no legacy project is adopted automatically. Owner session (5 October 2026): under R4, admission stays per project for trials and pilots; universal baseline waves then convert every remaining project after parity, each wave approved (BC §4.6, §10).	Screening research §5/§7; MIG1	Adoption order changes
A-05	Physical storage is decided by ADR at F1a (E15); the plan presumes no collection layout	Research separates domain from storage	Contract C1 detail
A-06	Cross-stage collective policy (hybrid of Q-15a): unvoted reviewers may proceed once a study is collectively Included; a personal Exclude blocks that reviewer. Retired by the owner session (5 October 2026): Q-15 is replaced, so no cross-stage collective policy exists (SP §14).	Access-policy proposal; within-stage rule	Admission rule in C6
A-07	Review-workflow notifications use the existing notification stack (#3932–#3947, plus #3965) once its owners merge it, through the C15 v2 capture contract, with no parallel notification machinery. Confirmed obligations don't depend on that merge: feature-owned queues are the source of truth and the fallback (my concerns and outcomes for QY6/QY8; changes awaiting approval with an admin alert for LC1; assigned reconciliation work for RA2–RA4; requested reviews for RA5), surfaced without notifications by a badge, a "My work" view and an admin banner. Notifications add delivery only after G-NOTIF, per environment and kind family, with per-project notification admission and an operator delivery halt. Email is never a release dependency.	Chris, 3 October; ledger QY6, QY8, LC1, RA2–RA5; review NS	R3c/R4a/R4b scope; notification enablement timing
A-08	The publication gate reads the version-usage families (PS1) at a fence. A Stale scope is answered by FEAT-024's pinned authoritative value in the same snapshot, or rebuilt through FEAT-024's "scoped rebuild at a pinned snapshot" service API, with the read's identity recorded in the frozen manifest (PS2's "actively update the specific relevant statistics there and then"; D3-10a). The reviewer pause is the engine's scoped write fence. Production publication from the materialised families needs FEAT-024's production chain (X-STATS-b1–b7); per Chris's Q-31 answer, named pilot projects use authoritative counting under the same boundary if that chain isn't complete when R2c is otherwise ready, so that path is designed as the first pilot path. Owner session (5 October 2026): D3-10 is a brief item (RI §3.17).	PS1–PS3; Q-31; review MS	R2c production timing
A-09	Proportional allocation stays off for every canonical stage, whether its form is bound to one stage or several, until lane release AL1 ships; R0 refuses to admit a stage whose allocation is enabled (D3-13a). Owner session (5 October 2026): D3-13 is a brief item. Baseline conversion treats an enabled allocation regime as a blocker until AL1 and never disables it silently (BC-R17, PROPOSAL).	The regime reads stage.SessionCountTarget and requires ReviewMode.Annotation, neither valid on a canonical stage; current allocation is stage-keyed	Pilot configuration limits until AL1
A-10	Lanes are scope responsibilities, not people. One accountable approver (Chris) and agent sessions deliver the plan through five streams: a lane owner is a stream brief plus a stream-lead session, and a programme-owner sign-off is a fresh-context agent checklist against that programme's rules file, with Chris ruling on the exceptions (delivery operating model §2)	DS-01: all 400 PRs since 8 September were authored through Chris's account; main recorded at least 412 PR merges on 24 of the 31 days to 3 October	If human teams were staffed instead, stream leads become people and checklists become signatures; the ready queue, the WIP limits and the order are unchanged
A-11	Until amendment B is approved, exports label citation totals as records, never reports. Retired by the owner session (5 October 2026): Q-06b approved amendment B (E1); report identity follows RI §3.1.	PRISMA amendment B	Reporting copy
A-12	v10 matching weights (0.40/0.40/0.20, threshold 0.50) are configurable initial defaults validated by fixtures, not approved values	MG1	Defaults only
A-13	The notification PR stack and FEAT-024 continue under their current owners; this plan only consumes their contracts	OPS1, 3 October update	Coordination load
A-14	During R2a and R2b, a published form requirement version never changes and no new version can be published until R2c; an unpublished requirement version can change freely, and operational settings change with audit at any time. Pilots that need to evolve a used form wait for R2c, or stop using it. Owner session (5 October 2026): the standard target is part of the form version (OS-A12) and Study target overrides arrive in R2c (RD §10), so pilots that need a different target also wait for R2c.	FV1 without R2c's publication path	Pilot friction until R2c
A-15	Category guidance (today a project value with a per-stage override) is reviewer-facing presentation text, not evidence. It stays a stage-level presentation setting alongside form-level guidance and is not versioned with the form.	SF1 governs evidence, not instructions	Guidance moves into form versions; small C4/C6 change
A-16	Interpretation for Q-24: legacy combined stages migrate to steps without a dependency edge, preserving today's D3b behaviour, and keep their D1/D2 Allow/Stop value as the step's extra-vote admission setting. Owner session (5 October 2026): restated as a candidate mapping that the opt-in wizard verifies and an authorised admin confirms (Q-24; SP §10.4).	Eligibility D1/D2, D3b, D7	Migration mapping for combined stages
A-17	Custom group management and the generalised permissions dialog (#3335 WP11) can't ship before the authorization programme's gates: X-AUTH-SCHEMA (G-D in #3335's handover plan: membership schema 1 in production) and X-AUTH-ENFORCE (the authority-transition plan's M6 staged cutover, its gate G-C), unless parity tests prove legacy and evaluator decisions identical; and WP11 follows WP9	#3335 handover plan; authority-transition plan	R1c timing
A-18	The advanced cross-stage option "own Include sufficient" relaxes the default: own Include or collective Included admits, while personal Exclude and collective Exclude still block (Q-15, part b). Retired by the owner session (5 October 2026): Q-15 is replaced, so no advanced cross-stage option exists.	DP7 describes a faster advanced option, not a stricter one	Admission rule in C6
A-19	Until R2d, no answerable question, including an answerable ancestor, may belong to two forms in one project. Entity-category label questions are answerable (each unit's label), so in practice two forms can't both use the same entity category; Study-level questions (an implicit root without a label) can be split across forms. A fixture with two forms under one entity category proves the refusal is clear.	Avoids SF5 obligations before flags exist	Pilots needing overlapping forms wait for R2d
A-20	Outcome measures are reviewer-created per-study entities, as the owner clarification recorded in the classification research says ("Outcome measures themselves are still created by reviewers from the paper"); direction is a single measure-level answer, revisable and reconcilable, shared across cohorts in that paper (ODIR1). Project-level schemas are definitions; measures aren't.	ODIR1 ("in a paper/population"); classification research 24 and 27 September clarifications	C14 changes; ask Chris before O1 if the C14 ADR finds otherwise
A-21	R2a binds each form version to exactly one stage; multi-stage binding arrives in R2b	Keeps R2a free of multi-stage tally, allocation and claim-sharing joins. R2a is not free of claim joins: it changes own-place detection through the membership-facts seam (canonical sessions live outside Study), releases the slot claim on the first explicit Save or Complete inside the canonical transaction, links presence to FormSessionId and redefines "dirty" as the draft-changes flag (E70); claims stay stage-keyed until R2b	R2a scope grows
A-22	Admission and canonical ownership are data owned by R0's admission service (the enrolment record) and ownership marker, not configuration allowlists. The same admission record carries per-project notification admission, the AF2, shell and eligibility admission slices and the binding-scope tracking pilot, and the flag overhaul's P7 targeting keys to it. FEAT-024's durable eligibility (#3524) stays a separate record with the same shape and audit. Owner session (5 October 2026): the binding-scope tracking pilot becomes project-scope tracking through the admission record (PROPOSAL, SP-AMB-12).	B-01 compatibility analysis; reviews DS-04, PH-14, NS-04, MS-24	R0 design
A-23	Before GA, a new production project joins the canonical path only when its creator opts in at creation; staging and preview pilots use seeded and tester-created projects. Owner session (5 October 2026): A-23 still governs new production projects before GA. Existing projects follow staging trials, production pilots of complete scopes and then universal baseline waves (R4; BC §10).	Q-07 answer (new and seeded projects); production prerequisites	R0's admission rule changes to admit all new production projects
A-24	Chris accepts each release's new and materially changed screens on staging at the ship gate, with the tier-1 design-QA evidence; per-PR preview acceptance is needed only for new shared patterns and for the publication flow, the reconciliation workspace, the stage designer, Members & groups and guided setup (UI-8). "Materially changed" is defined in UX strategy §13.3. Until D3-02 is answered, per-PR preview acceptance applies to every new or materially changed screen. Owner session (5 October 2026): D3-02 is a brief item; each release brief records its design-review schedule (UX §12). The fallback here holds until such a brief is approved.	UI1; D3-02 recommendation; UX-13; review AC-25	If Chris wants per-PR acceptance for every screen, merge throughput falls to his review capacity (about 40 previews) and stream C drops to one release in acceptance
A-25	Question versions form one linear sequence per identity (seq 1..n); branches never exist; a copy from a template or another profile is a new identity at seq 1	FEAT-001's sequential VersionNumber; DP4 copies	Class derivation and classSeq need DAG rules; the designer needs merge semantics
A-26	A requirement version pins at most one version of each question identity; two forms may pin different versions of one question only across forms, never within one	FEAT-001 QSV: one AQVersionRef per question	Composition, the pin map and the head key need a per-pin version dimension
A-27	Production Atlas runs MongoDB 4.4 or later (ADR-019) with the default transactionLifetimeLimitSeconds of 60, an expired-transaction sweep of at most 60 s, majority write concern with journal, and the default minSnapshotHistoryWindowInSeconds. Owner session (5 October 2026): D2-10's limits are a brief item; the 90-second figure is proposed, not approved.	MongoDB defaults; none was read from Atlas (UNVERIFIED)	Drain, watermark and retry values change; D2-10's pause of about 90 s needs L + S of at most about 80 s, or the in-flight beacon
A-28	Clock skew between API and PM pods stays within a configured bound K (proposal 1 s, alarm at 250 ms) under GKE node time synchronisation	Usual GKE node NTP behaviour (UNVERIFIED)	The watermark lag grows; maximum-drift refusals stall writes behind a runaway clock
A-29	Per-study write concurrency is low (at most about 10 concurrent writers on one study at peak), and Study documents of canonical projects stay far below 16 MB with the summary, claims and capture log bounded	FEAT-024's synthetic benchmark cells; canonical studies hold no embedded evidence; production rates UNVERIFIED	The same-study cell exhausts; the storage ADR splits the summary into per-form sub-documents or moves it beside Study
A-30	Project's four embedded job records (search import, bulk study update, bulk PDF upload, risk of bias) stay embedded; their extraction into their own aggregates is not in scope before R7. The contention they cause with grant changes is measured at M0 (AC-M0-02 Project-contention line) rather than designed away now.	No programme owns their extraction; the ADR-020 and M5b operations already keep their heavy state outside Project (pmBulkStudyUpdate*, pmRobRun*)	An extra platform slice before R1c if M0 shows grant changes exhausting retries against running jobs
A-31	The review-eligibility programme stays paused through F3. Owner session (5 October 2026): D3-09 is a brief item (SP §12.1).	Session memory ("paused 25 September until the statistics work finishes"); not recorded in the repository; #3746 had activity on 1 October	If it resumes, X-ELIG slices return to it and R3a's absorbed scope (D3-09) shrinks; if it stays paused, R3a absorbs S6b (and S4-B, S4-C, S6a as needed) and grows
A-32	No legacy untyped slot reservations exist in production, because claims are created only with tracking on, which no deployed environment has enabled	Review RT-23 (code reading); the count is unverified	S4-B must migrate them before eligibility is enabled; an authorised count-only check per environment settles it
A-33	The notification stack owner accepts C15 v2, lands it after the base merges and before the first review-workflow kind, and restacks #3965 onto #3944 (D1-09). Owner session (5 October 2026): C15 v2's disclosure hook must also carry the O2 content policy (Study titles allowed; aliases and content follow recipient permission and form or profile blinding; answers and free text configurable; rights checked at delivery) and per-project mute (ACD §3.5, §3.6). Notification delivery stays unauthorised under the implementation hold.	Review NS §4; the owner has not yet been consulted	Each review-workflow kind edits shared notification files; conversations wait for #3947's isolation review
A-34	The architecture-review programme lands #3985 (non-upsert saves; version bump on direct writes) and #3973 (awaited domain events) before F1a	#3961 Phase 0/1; D1-02	F1a waits, or canonical repositories carry their own isolated-read, non-upsert and awaited-dispatch discipline enforced by an architecture test, and R0's floor also covers the version-less direct writers (StudyRepository.cs:1306-1319, 1620-1650)
A-35	Chris can give the programme about four hours a week: a 30-minute weekly review; one decision sitting per gate (60 to 90 minutes, answering deviations only); one staging walkthrough per release (60 minutes for T1, 30 for T2, a summary read for T3); and about 12 supervised-PR summaries a week at about 5 minutes each	DS-01 and DS improvement 3; delivery operating model §16.2	With less time, the acceptance limit drops to two releases programme-wide and decision sittings merge, so the calendar stretches; the order is unchanged
A-36	Agent engineering throughput is not a binding constraint: main recorded at least 412 PR merges on 24 of the 31 days from 3 September to 3 October 2026 (mean 17 on a merge day, peak 53), all through Chris's account; the constraints are approver time, CI host capacity and Bramble's exclusive windows	git log --first-parent --merges on main at de3e98c59; DS-01	If engineering binds, raise WIP limits once start delays and review latency stay within budget, and split stream C into reviewer workspace and admin UX; the order is unchanged
A-37	FEAT-023's light cutover does not land before R2a's reviewer UI; new screens are built on Material 3 roles over the current components and verified on the Material 2 bridge plus the static checks (UI-3, UI-9, UI-10). Owner session (5 October 2026): D3-01 is a brief item (UX §12).	FEAT-023 README (Waves 0 to 4 open; Wave 5 unscheduled); D3-01 pending	If the cutover lands earlier, the screenshot matrix is re-run on the Material 3 path at cutover; no plan change
A-38	The tester panel (D1-06) and at least two external SyRF users are available for the W0 baseline study and for monthly sessions. Owner session (5 October 2026): D3-08 is decided: the agreed tester panel is enough and external SyRF participants are not required now (UX §3.6).	D1-06 (decided 3 October 2026; the panel was named late that evening, with no external SyRF users yet; register §1.14) and the D3-08 recommendation	AC-UX-03 and AC-UX-04 are re-based on R2a's first summative session, which doubles as the baseline; those thresholds stay PROPOSAL until then
A-39	For canonical projects the initial-independent-submission marker can be derived at commit from the commit order and the visibility events already planned (availability messages, VS1 exposure, conversations); for adopted legacy projects it is unknown, and every legacy decision is labelled "basis unknown" in agreement statistics. Owner session (5 October 2026): the legacy-gap states are named in BC §3.2.	C3 three-state exposure; EX2 (no fabricated history)	R5c shows no IRR for adopted projects, only percent agreement labelled "basis unknown"; or an explicit marker must be written by every submit path
A-40	The funder mapping in methodology-coverage.md §15 reflects docs/funding/ as of 14 March 2026; neither the NC3Rs contract position nor the SSI RSMF outcome has been confirmed since (D4-18)	docs/funding/nc3rs.md, docs/funding/ssi-rsmf.md	Release order could change (for example R4a earlier for NC3Rs); the WCAG audit timing could move