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).

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.

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 are open. Q-03 was answered late on 3 October (decision register §1.14) and stays in the table for traceability.

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	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?	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	R2c, R2d
Q-27	Approve the ledger's "proposed effects" of an incomplete Save, and the cascade rule for cross-stage corrections	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	R2a (Save effects), R3a (cascade)
Q-34	QM v2's publication wizard offers "map answers to updated options", which transforms recorded answers. Is that an approved form of autoUpdate under FV3?	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	F2
Q-15	Cross-stage routing interpretations: candidate rules for the default and for the advanced option	(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	F3
Q-24	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.	Confirm all four; amend the eligibility policy document in the R3a PRs	R3a design follows this mapping (A-16)	F3
Q-26	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	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	F5
Q-28	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?	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	F3 (EW1, VS1, tracking), F4 (BL1)
Q-12	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?	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	R3a
Q-01	Should optional strict within-stage collective gating exist, and in what form?	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)	R3c
Q-02	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	Approve the lifecycle proposal	Lifecycle work stays at design level	R3c
Q-30	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)	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	R3a (VS1), R4a (BL1, RA3)
Q-33	Search and project deletion currently fail closed until the reversible-deletion scheduler exists. When a search is withdrawn, what should PRISMA show?	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	F-P
Q-37	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)	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	F-P (K), P2 (L)

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

ID	Question	Recommendation	Until answered	Needed by
Q-29	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).	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	F4, R6
Q-35	How are legacy reconciled answers (one overwritten set per question, authority unknown) treated in exports, queries, R4a readiness and adoption?	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.	F4, R6
Q-36	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).	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	F4, R4p
Q-04	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)	Approve both as proposed	R4a follows requiredness only (UA1-consistent); statistics show missing counts without an agreement value	F4 / R5c
Q-11	Should admins be able to bulk-approve studies where every candidate agrees (v10 §3; QM v2 RECON-09)?	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	After R4a
Q-32	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?	Allow as a profile setting, default off, for screening-decision adjudication only (RX1); RE1 stays for ordinary reconciled answers	Rationale optional everywhere	R4p
Q-05	Approve the outcome-migration plan: read-only dry-run first, approved manifest, staged copy, project-scoped fence, rollback boundary	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	O2
Q-06b	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)	Approve, so reporting work can start at F6b	Exports label citation totals as records, not reports; no complete-diagram claim	F6b
Q-17	Field-level specification of the event-count schema, and what "variation" means	Domain specification by Chris or a CAMARADES methodologist before the O1 build	O1 builds catalogue infrastructure and the legacy-compatible schema first	F-O
Q-18	Scope of the first classification reasoner	Conjunction, containment, disjointness and exhaustiveness only, as the research recommends	C2 design assumes that scope	C2
Q-19	Who may publish project rules and shared-concept mappings?	Design capability publishes rules; reviewers confirm per-paper applicability through mapping answers; reconciliation applies as normal	Design-only authority	F-C
Q-16	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)	Method review with a statistician; show percent agreement plus explicit denominators first	Percent agreement with counts only	R5c
Q-22	PRISMA reason reporting: one primary reason or several counted reasons per excluded study?	Follow the FEAT-011 primary-reason MVP; report coverage when reasons are pending or off (amendment E)	Primary reason plus coverage status	F6b
Q-23	PRISMA report multiplicity: approve report identity as in amendment B, or keep labelled citation totals?	Approve amendment B; until then label totals honestly	Labelled totals	F6b
Q-21	For each existing project adopted later, what did its legacy screening represent?	Admin-reviewed labelling of a "legacy project screening" compatibility profile, set at adoption	Legacy projects stay on the legacy path	R6 per project

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). The other 61 (D2-01 to D2-16, D3-01 to D3-25, D4-01 to D4-17 and D4-19 to D4-21) are open: none of them is decided until Chris answers. With Batch B's 13 and Batch C's 15, 89 owner decisions are open. They are grouped by when the answer is 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)

ID	Question	Recommendation	Until answered	Needed by	Source
D2-01	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".	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	F1a	VA-03, DD-10, DC-06, VB-06
D2-02	When is compatibility between question versions decided, and can it change?	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	F1a	VA-01, VA Q1
D2-03	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.	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	F1a	VA-16, VA Q2
D2-04	What "stage settings bind form versions" (PV2) means.	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	F1a	VA-08, VA Q5
D2-05	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.	Yes. Otherwise a target change or a DP5 toggle forces a publication and a decision over every session.	Every settings change mints a version	F1a	VA-07, VA-08, VA-19, AP-11
D2-06	System question versions.	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)	F1a	VA-09, VB-11, VA Q6
D2-07	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.	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	F1a	PH-03, RT-09, RT Q-RT2
D2-08	Two tabs or devices on one session.	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	F1a	DC-07, VA-12, RT Q-RT7, DC Q-DC4
D2-09	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	F1a (shape), F4	VA-11, VA Q4
D2-10	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.	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	F1a	DC-06, DC-09, VB-06, VB Q1, DC Q-DC2, DC Q-DC3
D2-11	One active publication per form at a time.	Yes. Publications are rare; this removes a class of policy-composition errors.	Overlapping publications stay undefined	F1a	VB-06, VB Q2
D2-12	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.	Yes. Re-keying would rewrite immutable records.	Merges of reviewed studies stay unspecified	F1a (shape), F-P	V2-02, DD-08, DC-19, DD Q-D3
D2-13	Restore policy for canonical data.	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	F1a	DC-17, VB-20, DC Q-DC5
D2-14	Account erasure and immutable answers.	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	F1a	VB-19, DC Q-DC6, VB Q4
D2-15	Who owns question, profile and form templates?	A CAMARADES-curated system catalogue (an application role), plus "copy from a project I administer". Copies only, never links.	Templates stay project-scoped	F1a (R1a scope)	DD-25, PH-27, DD Q-D1, PH Q11
D2-16	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).	Yes; revisit after M0.	No ceiling	F1a	VB-12, VB Q3

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

ID	Question	Recommendation	Until answered	Needed by	Source
D3-01	What UI1 (Material 3) requires before FEAT-023's cutover. The app emits only Material 2 component themes today, with M3 tokens alongside.	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	F1c	UX-12, review AC-17, AC Q1, NS-10
D3-02	Design acceptance cadence.	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)	F1c	UX-13, review AC-25, AC Q2
D3-03	User-facing terms.	"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	F1c	UX-05, PH-19, DD Q-D4, DD Q-D5, UX Q4
D3-04	Button and type language.	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	F1c	UX-07, UX Q3
D3-05	Phone screening.	Supported for title/abstract screening steps; annotation stays tablet and desktop.	No phone criteria	F3	UX-15, UX Q6
D3-06	Visual refresh of legacy screens. Legacy projects stay legacy for years.	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	F1c	UX-11, UX Q7
D3-07	"My work".	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	F3	UX-08, NS-07, UX Q8
D3-08	Research participants and telemetry.	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	F1c	UX-01, UX-21, UX Q5
D3-09	The paused eligibility programme.	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	F3	AP-09, DS Q5, PH-04, PH Q3
D3-10	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.	Yes to all four.	PS2/PS3 block on admin backfill; pilots collide with the statistics pilot	F2 (a, b, d), F5 ©	MS-04, MS-08, MS-10, MS Q1–Q3, Q6
D3-11	Agreement statistics storage.	Their own rebuildable derived store with a watermark, outside FEAT-024 (whose README excludes kappa), with an absolute performance budget.	R5c design open	F4	MS-20, MS Q4
D3-12	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.	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	F3 (first part), F-P (identification part)	PH-02, PH Q1
D3-13	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.	Yes to all six.	Allocation and batches stay legacy-only	F3, F-A	AP-02..06, AP-12, AP Q1–Q6
D3-14	Staging seed data.	An additive, idempotent "seed-if-absent" job on preview and staging that never alters or wipes existing data.	New seeds reach preview only	F1a (S0), or before S0-4 is enabled if earlier	V2-09, review AC-11, AC Q5
D3-15	Browsers and touch.	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	F1c, or before S0-7's browser projects count as evidence if earlier	PH-13, review AC-19, AC Q6
D3-16	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.	(a).	Capacity promises do nothing in production	F1a (contract part: the claim contract fields and route seam), F3 (production route), before any R2b/R3a production pilot	RT-02, RT-03, RT Q-RT1
D3-17	Capacity cap separate from the minimum target.	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	F1a (C7)	RT-13, RT Q-RT3
D3-18	A form bound to stages with different tracking settings (extends Q-28).	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	F3	RT-12, RT Q-RT4, PH-05
D3-19	Places on dependent forms during screening.	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	F3	RT Q-RT5
D3-20	Who may see who is reviewing a study now.	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	F1b (C10)	RT-14, RT Q-RT6
D3-21	Notification enablement.	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	Before any notification enablement	NS-04, NS Q-N1, Q-N8
D3-22	Email content.	Notification emails and digests may name the project; never study titles, aliases, answers or free text.	Titles only	Before production email	NS Q-N2
D3-23	Auto-resolve. When one person resolves a workflow item, others' related notices show "resolved" and leave the unread count, staying in history.	Yes.	Notices stay unread	F3 (R3c)	NS Q-N3
D3-24	Per-project email mute (the inbox still records).	Yes, before production email.	No mute	Before production email	NS Q-N4
D3-25	Reconciliation conversations as records.	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	F4	NS Q-N6

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

ID	Question	Recommendation	Until answered	Needed by	Source
D4-01	"Unsure" at title/abstract.	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	F5	SR-13, SR Q-1
D4-02	Discussion as a conflict-resolution route.	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	F5	SR-23, SR Q-2
D4-03	Extract-and-verify.	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	F4	SR-12, SR Q-3
D4-04	Calibration or training rounds.	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	F3	SR-11, SR Q-4, PH Q12
D4-05	Protocol, registration and search documentation.	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	F-P (search fields), F5 (amendment rule)	SR-04, SR-24, SR Q-5
D4-06	Risk-of-bias and reporting-quality templates.	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	F1a (R1a catalogue part), F-O	SR-05, SR Q-6
D4-07	Full-text retrieval.	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	F-P	SR-02, SR-15, SR Q-7
D4-08	Several reports describing one study.	A "link reports to one study" action for boxes 10 and 16 (amendment O); linking never merges extraction.	Reports counted as studies	F-P	SR-07, SR Q-8
D4-09	Analysis-ready and RIS exports.	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	F6a	SR-08, SR-20, SR Q-9
D4-10	Graph digitisation.	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	F-O	SR-06, SR Q-10
D4-11	Box 1 (previous review version).	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	F6b	SR-14, V2-04, SR Q-11
D4-12	Agreement observation basis.	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	F1a (markers in C3), F4	SR-01, SR Q-12
D4-13	Primary exclusion reason.	The first failing criterion in the profile's configured order, on by default, with a per-profile override allowing reviewer choice.	Reviewer choice	F5	SR-10, SR Q-13
D4-14	Importing answers from other tools (FEAT-004).	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	After R2a	PH-10, PH Q6
D4-15	Routing studies by answer values.	A lane after R4a, expressed as a step-dependency rule on gold values; not required for GA.	Not in scope	After R4a	PH-05, PH Q8
D4-16	Early screening-profile adoption for existing projects.	Allow admin-initiated adoption of screening-only, unreconciled stages after R3b, reversible until the first canonical write.	Adoption waits for R6	After R3b	PH-23, PH Q9
D4-17	Stale-answer acknowledgement (FEAT-001 D54/D55).	Replace with RE2's non-blocking warning and Complete anyway; drop per-project enforcement levels.	E34 open	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	Blinding and random serving as core behaviours.	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	F3	PH-12, PH Q5
D4-20	Completed work of disabled members.	Keeps counting and stays in reconciliation; an audited admin action can exclude a reviewer's contributions from a form.	"Eligible" undefined	F4	PH-22, PH Q7
D4-21	What ASySD parity means (Q-37).	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)	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	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)	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)	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	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)	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)	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	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)	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	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	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	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	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	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	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	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	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)	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	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)	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	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	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	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)	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	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	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)	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	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)	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	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)	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)	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	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	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)	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.")	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	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)	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)	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)	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)	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)	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)	R2c, P2, R5a, O2
U41	The duplicate review queue and the merge or split wizard with alias presentation (V2-25; pending D2-12)	P2
U42	Terminology card sort and "which version counts" vignettes for the copy deck terms (UX-05; pending D3-03)	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)	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)	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.	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	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	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.	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)	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	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.	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	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)	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	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	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	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	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	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)	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)	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	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	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