Saved verbatim on 3 October 2026 as the record behind the "brief §n" references in this package. It was the orchestrating session's working instruction to the eight round-2 drafters, written at about 15:10 BST after the thirteen reviews arrived. Its adjudications are PROPOSALs for Chris. Where the package says otherwise, the package wins: Batch D's final text is in open questions, D1-01 has since been decided, the verifier V3 alignments are in the round-2 matrix §7, and patch appliers as well as the orchestrator later wrote to the package. Paths in §0 and §4 refer to the session scratchpad, which is not kept.

Round-2 resolution brief (working document; scratchpad only)

Author: the orchestrating session (Claude Code, Opus 5.5) for Chris. Date: 3 October 2026. Purpose: fix every adjudication once, so drafters write consistent text. Drafters write only to the scratchpad output path they are given; the orchestrator is the only writer to the package.

0. Paths, sources and rules

• Package: /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/ (PKG)
• Owner ledger: /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/review-form-owner-decisions-2026-10-02.md; Chris's 3 October decisions: PKG decision-register.md §1.11.
• Round-1 reviews and matrix: PKG reviews/. Round-2 reports (verbatim): PKG reviews/round-2/: verifier-V2-new-documents.md (V2-xx), review-VA-versioning-model-concept.md (VA-xx), review-VB-versioning-implementation-data.md (VB-xx), review-DC-data-consistency.md (DC-xx), review-DD-domain-driven-design.md (DD-xx), review-AC-acceptance-criteria-testability.md (review IDs AC-01..35; call them "review AC-nn" to avoid confusion with acceptance-criterion IDs), review-PH-past-year-planning-coverage.md (PH-xx), review-UX-ui-ux-whole-application.md (UX-xx), review-DS-delivery-strategy.md (DS-xx), review-SR-systematic-review-methodology.md (SR-xx), review-AP-allocation-pools-batches.md (AP-xx), review-MS-materialised-statistics.md (MS-xx), review-RT-… (RT-xx, pending), review-NS-… (NS-xx, pending).
• Architecture review programme (#3961, another session): /home/chris/workspace/syrf/pr/pr3961.awesome-wozniak-anqdaa/docs/planning/architecture-review-2026-10-synthesis.md (issues #3972–#3990).
• Code baseline: /home/chris/workspace/syrf/main (read-only).

Labels (unchanged from the package): OWNER (ledger ID or §1.11 ID), RECOVERED, PROPOSAL, OPEN (Q-xx), ASSUMPTION (A-xx), CODE-MAIN, CODE-PR, DOC-APPROVED/DOC-DRAFT. Never present a proposal as a decision. Never reopen a confirmed owner decision; state consequences instead. Anything needing Chris goes to the Batch D questions in §3 below (drafters cite those IDs; they do not mint new question IDs).

Style: plain, precise British English (behaviour, serialise, favour). Short sentences. Tables where they help. Front matter: title, doc-type: "Discussion", status: "In-Review", author: "Claude Code (Opus 5.5) for Chris", created: 2026-10-03, updated: 2026-10-03, zenhub-ticket: "N/A", tags: [...]. Headings use the form ## 3. Title / ### 3.2 Title; no em-dash or colon in headings (anchors must match in GitHub and MkDocs). Relative links only between package files; cite repo files as backticked absolute or repo-relative paths (not markdown links) unless they are package files. No clinical data, report contents or participant identifiers anywhere.

Finding-resolution table required from every drafter (at the end of the draft, under ## Resolution record): one row per finding ID resolved, columns: Finding | Category | Where | Note. Categories: Corrected (plan wrong or inconsistent; fixed), Adopted (improvement accepted, labelled PROPOSAL where it is a design choice), Question (needs Chris; cite the Batch D ID), Follow-up (recorded in the backlog §2.20, not in this scope), Noted (no change; explain). The orchestrator moves these rows into the round-2 matrix.

ID ranges (no collisions): engineering items E36–E99 are allocated per drafter in §4; assumptions A-25–A-40; UI validations U30–U45; contracts C18 (concurrency, transactions and idempotency) and C19 (durable effects and events) are new; PRISMA amendments M (full-text retrieval), N (Citation to Publication link), O (report-to-study linkage) are new; acceptance criteria follow the existing scheme.

1. Cross-cutting adjudications (binding on all drafters)

1.1 Publication writes no evidence; projections are rewritten by an operation (VA-03 vs DD-10, DC-06, VB-06)

• Publication never writes session versions or answer revisions. The only exception is Q-34 option mapping, which writes policy-derived revisions with provenance, excluded from SF5 outdated flags. SL3 ("latest explicit Save or Complete is current") stays literally true. (VA-03)
• Session effective state (qualifying, needs updating, pinned under an older version, not applicable) is derived from (latest explicit version, its full pin map, current published version, recorded policies, per-answer validity). Canonical readers (admission, qualification, AF2, exports) derive it on read. (VA-03, DC-06)
• Query-path projections (Study canonical summary used by pool filters and legacy readers; FEAT-024 rows) are rewritten by a phase-2 operation (ADR-020 pattern: operation record, lease, generation fencing, chunked, predicate-driven sweep pinnedFormVersionSeq < current ∧ appliedPolicyOp < op repeated until it matches nothing). Admission and reconciliation readiness for the form pause while the operation runs (scoped, VB-06/VB Q1) and fail closed on a stale projection (DC-08). (DD-10, DC-06, VB-06)
• Phase 1 is O(1): fence the form, drain (≥ transaction lifetime + sweep + margin), CAS the AnnotationForm head (current published seq, publication seq) and write the policy record and operation record in one short transaction. The impact manifest is an audit and preview snapshot built after commit (and the preview digest is re-checked before phase 1; if it changed, the admin re-confirms). One active publication per form (unique partial index). FV4 revisions CAS the policy generation. (VB-06, DC-06)
• A Save based on a superseded form version is accepted pinned to the version its client declared; the recorded policy applies to it by derivation. Never rebased. (VA-10, VB-06)
• SF6's conditional wording ("if a recorded admin update treatment creates a new incomplete session version") is read as "changes the session's effective status". This reading is a PROPOSAL put to Chris (Batch D, D2-01).

1.2 No per-project document in interactive transactions; ordering by per-aggregate versions plus HLC (DD-02, MS-12, PH-01, DC-01, VB-12)

• Delete ProjectCommitSequence from interactive commits. Order within a study by the Study version (written by every study-scoped canonical command, see §1.3) and per-aggregate versions; order across a project for as-of reads by a hybrid logical clock stamp (DC-13) on every canonical record. As-of(T) is offered only for T ≤ now − (transaction lifetime + sweep interval + skew bound). Definition-level operations under fences may keep a project-level sequence if useful. E25 is settled at F1a on M0 evidence. PROPOSAL.
• The canonical write gate mirrors ADR-019 gate (b): zero engine-caused exhausted submissions at ½/5/10 reviewers, same-study and different-study, plus absolute p95 budgets set after M0 (Batch D, D1-08). AC-R2a-19's "≤ 1.2× today" is replaced. (DC-16, PH-01, MS Q5, review AC-18)

1.3 Evidence aggregate and the Study canonical summary (DD-01, DC-02, VB-01, AP-01, MS-13)

• Logical consistency boundary for evidence: ReviewerStudyEvidence = (project, study, author or authority scope): FormSessions, heads and revisions for that author on that study (heads and revisions are entities inside it; physical storage decided by the F1a storage ADR, VB storage blueprint as the starting point: revisions never embedded in sessions; full pin map per session version in its own document). PROPOSAL. (DD-01, VB improvement 1)
• Every canonical command that changes study-scoped evidence or derived state also writes that study's Study document in the same transaction (version bump plus canonical summary): per-study serialisation (DC CR-1).
• The Study canonical summary is not the legacy computed fields. Those fields (ExtractionInfo.SessionTallies, SessionTally totals, ScreeningInfo.Inclusion/InclusionInfo/AgreementMeasure/IncludedCount/NumberOfScreenings) are computed getters recomputed from embedded legacy data on every whole-Study save (verified on main: StudyRepository.cs:3176-3227, ExtractionInfo.cs:31-80). So: a top-level Study.CanonicalSummary sub-document (preserved by older binaries via Entity [BsonExtraElements]) holding, per bound stage, the tallies; per form, per reviewer, the membership facts (session state draft_only/saved_incomplete/completed/ withdrawn, claim activities, admitting regime); per profile, the current outcome; readiness flags; and the definition-version vector it was evaluated under (DC-08). R0 ships the behavioural floor: legacy getters merge it and the pool, capacity and readiness predicates also read it; no-ops when absent. The F1a storage ADR chooses between this (DC option a) and VB's option (a) (legacy-shaped stub sessions flagged Canonical) with evidence; this plan's default is CanonicalSummary. Older binaries below R0 are not a rollback target. (DC-02, VB-01, AP-01, MS-13)
• An IReviewMembershipFacts seam (AP R1) is extracted now so Core policies read membership facts without caring whether they come from embedded data or the summary; the truth table becomes its conformance suite.

1.4 Idempotency: canonical command ledger (DC-03, MS-05, VB-04)

• Replace E35. Each canonical command writes exactly one command-bearing immutable record with a unique index on (ProjectId, CommandId), the result IDs and a request digest; retries read it first; a different digest under the same ID is a typed 409; an indeterminate commit returns typed "outcome unknown" (draft kept; client retries the same ID). FEAT-024 reuses the canonical CommandId as its OperationId (correlation only). Inbox SourceIds derive from the CommandId. Retention ≥ client retry horizon (proposal 7 days); after that the base CAS is the backstop. PROPOSAL.

1.5 Legacy refusal by per-document markers and a write guard (DC-04, DD-13, VB-07, DS-10)

• CanonicalScopes marker on Study and Project (scope-aware: annotation form F, screening profile P, …), checked in legacy aggregate methods (one document write with the Audit.Version CAS) and by a composite registered IAggregateWriteGuard for direct writers (composed with the bulk-lock guard); extend StudyWriteLockArchitectureTests; project-wide pre-checks like ThrowIfBulkUpdateInProgressAsync; inventory every UpdateMany on pmStudy (including the inclusion recalculation). pmCanonicalOwnership stays the audited registry with a reconciliation check. Cutover uses ADR-020's lock, verify, stamp, release protocol; AC-R6-05 restated as all-or-nothing via locks. PROPOSAL.

1.6 Durable effects and events (DC-10, DD-03, #3973)

• Three classes: (a) derived on read, no fan-out (outdated flags, task drift, needs updating; VB improvement 4: outdated flags are bounded to one reviewer's sessions on one study); (b) durable intent written in the commit transaction and handled by a leased idempotent dispatcher (claim-revocation outbox pattern) or an ADR-020 operation record (phase 2, sweeps, adoption, merges); © best-effort hints (SignalR, change-stream InboxChanged) that never carry correctness. In-process IDomainEvent only for loss-tolerant effects, and only after #3973 (await handlers). Event catalogue in domain-model. New contract C19.

1.7 Transaction admission ADR and cache rule (DC-11, DC-12, VB improvement 2, #3985)

• One F1a ADR (contract C18): snapshot read, primary, majority write with journal, maxCommitTime; whole-command re-execution from a fresh snapshot within a deadline with jittered backoff; free retries when the Study moved only through fold, claim-token or idle-token writes; typed outcomes (stale base, retryable conflict, locked, fenced, outcome unknown, refused, publication in progress, size limit exceeded, conflicted legacy answer, command digest mismatch); cache eviction on indeterminate commit; canonical collections and indexes created at start-up (pmStudy indexes via the operator route, VB-18); DuplicateKey on natural keys → reload and CAS. Canonical repositories never serve deciding reads from the shared RepositoryCache (BeginIsolatedReads / uncached); non-upsert saves (#3985) are a prerequisite. Command-budget tests pin the commit shape.

1.8 Drafts (DC-07, VA-12, VB-15, PH-03, PH-33, UX-04, review AC-14)

• One draft record per session with lease holder (tab/device), etag and per-holder write sequence; a non-holder's edits are kept as a bounded conflict copy (retained N days; "keeps both" is literal); "Take over editing" transfers the lease; Save/Complete present the draft etag and consume the draft atomically; a stale autosave arriving after a newer explicit version is rejected and discarded by the client; duplicate write sequence = success; draft-only sessions created by upsert on the natural key with a deterministic SessionId (DD-15, VB-16). No TTL on drafts; removal only by audited discard (VB-15, VB Q5). Drafts stored as patches against the base version, size-capped with E28. No long autosave trail beyond the current draft and conflict copies (SL1 satisfied: draft changes are preserved without explicit versions); PROPOSAL. Whether a draft holds the reviewer's place is Batch D D2-07 (recommended middle ground: held while active under today's idle and disconnect timers counting draft activity; released when they lapse, draft kept; Complete still allowed as an extra contribution unless an optional capacity cap applies). The draft lease uses a stable client tab ID shared with tracking's connection model but works with tracking off (RT-10). Save-status UX state machine (Saving / Kept / Retrying / Offline kept on this device / Failed) in ux-strategy (UX-04).

1.9 Versioning rulebook (VA all, VB-05/08/09/10/11/13/16, PH-06, PH-18, SR-16)

New document versioning-model.md. Decisions: compatibility defined once (VA-01) with per-answer validity; compatibility class in the head key (VA-02); option identity (VA-05); composition validity (VA-06); requirement versions vs operational settings (VA-07/08/19, AP-11; Batch D D2-05); system questions stored as data with (guid, SystemQuestionVersion) identity and opt-in adoption (VA-09, VB-11; Batch D D2-06); Upgrade transition (VA-10); added/removed question treatments (VA-14); "in use" (VA-13); QD1 wording (VA-15); identity choice D38 vs D008 (VA-16; Batch D D2-03); mixed-version export and usage rules (VA-17); legacy wording verification (VA-18, VB-13); transaction time only (VA-21); full-map pins (VA-22); query target = reconciled revision ID (VA-23); entity-type identity (VA-25, DD-12); per-answer state enum (VA-27); response modes, metadata and preserved suppressed answers (PH-06); FEAT-001 breaking transitivity and FEAT-003 per-session categories as the impact-manifest categories (PH-18); autoUpdate only within a class with valid values (SR-16, VA-01); context-key hash and partial unique indexes (VB-05); entity instance identity = label head ID, delete = withdrawal revisions, duplicate = new IDs with provenance (VB-09); append-only repositories, explicit collection names, content digests (VB-10); referential invariants and an integrity checker (VB-11); Conflicted head state and LegacyIdAlias for adoption (VB-13); deterministic IDs for natural-key aggregates, client-proposed validated IDs for revisions and instances (VB-16); AF2 VersionedAnnotationFormDataSource, Needs-updating presenter, AF2 renderability validated at publication, no AF1 fallback for canonical routes (VB-08); task key study × form with per-question held state (VA-04, DD-07; correction, RE4 already decides); gold re-reconciliation flag and drift on publication (VA-11 a/b), shared-gold second-task revision (VA-11c; Batch D D2-09).

1.10 Derived records carry input-version vectors (DC-08, VA-20, DD-06)

ScreeningOutcome is a per-(study, profile) record whose value object has facets {candidateResult, voteCounts, ruleVersion, finalResult, finalSource, adjudicationRef, freshness} (DD-06), is a rebuildable projection with a parity fixture (VA-20), stores the definition-version vector it was evaluated under, and has one writer CollectiveOutcomePolicy invoked by submit and adjudication commands. Readers compare vectors; admission fails closed on stale; predicate-driven sweeps repeat until clean (DC-08). The 25 September precedence rule (a DP2 correction makes an old adjudication inapplicable) is recorded as a recovered baseline only if the research source confirms it (verify the cited lines before writing it as RECOVERED; otherwise PROPOSAL).

1.11 Merge is an alias (V2-02, DD-08, DC-19, VB)

Dedup merge never re-keys immutable records: Study.mergedInto plus a StudyAlias set on the primary; per-reviewer resolution when one reviewer reviewed both (choose current session, supersede the other with provenance, counted once); merges and splits run as ADR-020 operations that write both Study documents and refuse busy studies; FEAT-012 scenarios 3 and 4 restated by form and profile instead of stage; FEAT-012's "canonical Study" renamed "primary Study" in amendment L. PROPOSAL; presentation question Batch D D2-12.

1.12 Stage aggregate and settings placement (DD-09, PH-05, AP-11, VA-08)

For canonical projects one Stage aggregate (identity, settings versions, lifecycle status, change requests, status history); Active derived from status; security grants stay in Membership (Project). StageSettingsVersion holds bindings, steps, dependency edges, route policies, VS1/BL1/EW1 defaults and the filter element; it references the allocation regime and batch plan by ID (their records stay in their own collections; embedded Stage.ProgressiveBatches/WorkloadShares legacy-only). A placement table for every existing per-stage setting (target enforcement, in-progress limit, hide excluded, excluded progress grouping, self-reconciliation, search and partition filters, #3876 tracking) says form-owned vs stage-owned and the rule when stages bound to one form differ. PROPOSAL at F3. Stage completion is two-step (Completing fence → drain → verify → Completed) (DC-09).

1.13 Statistics integration (MS all, AP-14, VB-03)

Engine never writes statistics or pending entries; it writes Study through a FEAT-024-owned source-write seam with a projection-only shape (MS-06); X-STATS-b becomes a numbered chain b1–b7 and X-STATS-a (staging) is added (MS-01, MS-10); Q-31(b) (authoritative counting at the protected boundary) is the designed first pilot path, the materialised family a swap-in (MS-01); usage families are new FEAT-024 families with new scope kinds by a FEAT-024 technical-plan amendment at F2/F5 (MS-02); drafts counted authoritatively (MS-03); "current" for PS2/PS3 = a FEAT-024 read at the fence (Materialised-Fresh or pinned-Authoritative) with identity recorded; scoped-rebuild service API; reviewer pause = engine fence (MS-04; Batch D D3-10); target-aware annotation classification is a FEAT-024 change landed before R2b/R3a (MS-07, AP-14); three N-1 mechanisms named (MS-09); PRISMA never from FEAT-024 rows (MS-11); onboarding contract (MS-14); one protocol bump (5) after gate (b), intents only until then (MS-15); rollback order (MS-16); adoption fences and rebuild (MS-17); admitted projects never in transactional point mode (DC-21); agreement in its own rebuildable store (MS-20; Batch D D3-11); overview fields extend existing statistics queries (MS-21).

1.14 Programme integration (AP, MS, RT, NS, DS-02, PH-02/09/14/15/20)

New document programme-integration.md: current state, integration contract, recommended changes (change → rationale → timing vs releases/gates → compatibility → risk → PR slicing → owner) for: proportional allocation and pool partitioning; progressive batches (#3936/#3939); review eligibility (paused); active reviewer tracking (RT, pending); FEAT-024; notification stack (NS, pending); authorization #3335 (including X-AUTH-RESOLVER for #3251, AP-02); architecture review #3961 (#3985/#3973 as F1a prerequisites, #3987 activate or freeze before F1a, #3986 MassTransit before R0 guards PM consumers, #3988 v0/v1 retirement folded into E24 or after R2a, #3989 as L5 seam slices, #3979/#3980 before R3a, #3975 flag provider; DS-02); deletion lifecycle ADR-014 vs amendment J (PH-02; Batch D D3-12); search import robustness X-IMPORT (#2612, timeouts, idempotent sagas; PH-09); flag overhaul P7 per-project targeting vs R0 admission (PH-14); authority-transition job classification M5/P9 for new job families (PH-15); AF2 pdf-tools X-PDFTOOLS for O1/R4c (PH-20); AF2 per-project admission slices (DS-04); FEAT-023 (Batch D D3-01).

1.15 Delivery operating model (DS all, review AC-03/09/25, PH-11, UX-13)

New document delivery-operating-model.md: single accountable approver; stream briefs and stream-lead sessions instead of lane owners; programme-owner sign-off = fresh-context agent checklist against the programme's rules file, Chris reviews exceptions; F1 split into F1a (engine contracts), F1b (catalogue and export disclosure), F1c (IA, copy, AF2 seams merged as code, Dockview amendment); S0 scaffolding release; M0 as a walking skeleton with go/no-go thresholds; dependency-driven ready queue (windows kept as illustration) with WIP limits; gate weight classes (merge heavy/standard/light with review AC's T1/T2/T3); merge criteria vs activation criteria with a recorded release-candidate image SHA; review tiers (supervised: /claude-review opus + fresh verifier; delegated: default); CI budget; Bramble calendar; hot-file and generated-file protocol; DoR/DoD; slice briefs (async-fold format); claim step; PR size (~800 changed non-generated non-test lines); ADR number block; STATUS ledger and weekly digest; user-guide pages drafted under target markers and published at enablement; integrate #3961 roadmap.

1.16 UX strategy (UX all, PH-13/19/35, review AC-17/19/27/28)

New document ux-strategy.md: research plan with real reviewers (baseline study before R2a; formative per freeze; summative per release; pilot diaries); UX metrics as acceptance criteria AC-UX-01..09 (PROPOSAL thresholds); reviewer efficiency (keyboard screening path in R3a/R3b scope, live completeness count, input latency under autosave); U-validation schedule with gate exit evidence; save-status state machine; copy deck and glossary at F1c with typed message constants and guard spec; accessibility harness (axe in journeys, screen-reader matrix, forced colours, 400% reflow, touch targets); design system of record (FEAT-023 contract + shared Angular components) and pattern inventory with a handoff template; "My work" surface (PROPOSAL); change bundling (≤3 reviewer-visible steps) and a "What changed" panel from R2a; staged publication flow; coexistence chrome and workflow-version badge; two-tier design QA (agents per PR, Chris per release); browser and device matrix (Firefox, WebKit smoke; CDK drag, not native HTML5 drag); reuse the approved AF2 four-state readiness vocabulary and "Save progress" (PH-19); width matrix aligned to break-points.ts. Note: themeToggle is default off but ON in staging (cluster-gitops#1357), so dark-mode evidence is reachable on staging.

1.17 Methodology coverage (SR all, PH-10/12/23/24, V2-04)

New document methodology-coverage.md: capability map (today / this plan / proposed / out of scope) for protocol and registration, search documentation, dedup, screening, retrieval, extraction, risk of bias, reconciliation and agreement, export, PRISMA, living reviews, audit, blinding, calibration, QC. Adopted as PROPOSAL: IRR markers in C3 (initial independent submission; collective-exposure at correction time); full-text retrieval workflow (amendment M; FEAT-011 FullTextNotRetrieved lifecycle precedence superseded); imported screening decisions as authority = Imported with independence unknown; extraction provenance, unit vocabulary, dispersion catalogue, domain validators; PRISMA arithmetic identities (AC-R5b); extraction export defaults by collective outcome; reconciler override QC; dedup QC sampling and reviewer duplicate flag; template defaults for new projects; ASySD parity metric = sensitivity/specificity on labelled sets plus pinned R outputs; search rounds minimal; bibliographic blinding option. Questions to Chris in Batch D4.

1.18 PRISMA amendments (V2-01..04, V2-10..14, SR-02/07/09/14/19/22)

Amendment N (Citation to Publication link: create Publications at P1 from DOI/PMID, or a separate link record; linking never rewrites a Citation); L restated (alias merge, primary Study, scenarios by form/profile, privacy: reading a Publication never exposes other projects' IDs; cross-project enrichment visibility and as-of; extended pool exclusion list; parity metric; QC sampling); K extended (entry-phase rule per search or import; per-box combination rules; previous-review step type tied to box 1 via Batch D D4-11; K.2/K.3 agreement; FEAT-012 §11 in "Amends"; withdrawn searches); M (retrieval); O (report-to-study linkage, if Chris approves D4-08); G cites lines 279–280 and covers MIG-13/14 (V2-10); H amends all three placeholders (V2-11); preamble aligned with freeze timing and Q-37 (V2-14); J vs ADR-014 (PH-02, D3-12).

1.19 Acceptance criteria (review AC all, V2-05..07/21..25, plus criteria from every review)

acceptance-criteria.md revision: Source and Status columns on every row (confirmed / pending-Q-xx / assumption-A-xx / PROPOSAL); a conformance row per release (AC--CONF) with IDs per contract test; traceability file format (YAML) and generated views; merge criteria (AC-ALL-14..16) vs activation criteria; release tiers T1/T2/T3; DoR/DoD; L17 acceptance tooling deliverables (personas, axe, screenshots, Firefox/WebKit smoke, barrier harness, mixed-version harness, canonical datasets on FEAT-024's harness); fixtures as versioned data (FX-PRISMA-01..08 with per-release evidence assertions; FX-ACCESS, FX-LIFE, FX-SETUP, FX-PUB-10K, FX-LEGACY); seed-if-absent job and data tiers; invariant monitor and INV-01..12; pilots PE-04r/06/07 and PI entry rows; all missing criteria listed by reviews (AC §3.1 table, VA, VB, DC AC-DC-01..15, AP, MS §7, SR, PH, UX AC-UX). Placeholder criteria rewritten as concrete provisional assertions that block until the question is answered (review AC-02, V2-05).

1.20 Backlog (Follow-up category)

Items recorded but not in this plan's scope go to a "Follow-up backlog" section in the round-2 matrix with an owner suggestion (for example #3964's follow-ups, Dependabot, observability consolidation).

2. Theme-specific notes for drafters

2.1 Active reviewer tracking (review-RT-active-reviewer-tracking.md, RT-01..RT-27)

• Facts to state (verified by RT): claims, capacity guards and typed admission exist only when activeReviewerTrackingEnabled is effective (flag ∧ signalRActive); the flag is off in every deployed environment and ON in the E2E stack; reconciliation is excluded at every tracking layer; enabling tracking is a FEAT-024 durable reviewer-mode transition whose code (AdvanceModeEpochAsync, M15) has no caller; every tracking surface is keyed by stage. Q-25's tracking line ("not needed for slot-reservation claims") rested on a false premise: record a correction and put the production claims route back to Chris (D3-16).
• RT-01 (Blocker) → Corrected: replace X-TRACK with X-RECLAIM: a reconciliation-task editor claim (CAS plus lease on the task, atomic "Start reconciling", assignment and release hooks for RA3/RA4) that works with tracking off, owned by L6 with the presence owner, frozen in C9/C7 at F4. E6 reworded to "always". RA1 acceptance criteria AC-R4a-14..17 (RT §5.2). "Tracking enabled" is no longer a sufficient R4a prerequisite.
• X-CLAIMS (new production prerequisite for R2b claim behaviour, R3a reservation admission and any capacity promise): jointly owned by the presence owner and the FEAT-024 owner; evidence = M15 transition wired and rehearsed on staging OR #3876 reshaped as a binding-scope setting enabled per admitted pilot; API and PM switched together; load and failover runs (RT §5.2 AC-T-03..07).
• Claim contract v2 at F1 (RT-11): typed claims {kind (form slot, profile slot, requested review, task editor, query editor), scope ID, route stage, route step, reserved at, allocation regime}, unique per (study, kind, scope, reviewer), released when the last page using it ends; capacity claims on Study (atomic guard), editor claims on their own aggregates; keyed by form identity, not form version; versioned hub methods (new methods, not new parameters, until MinUiVersion moves), additive DTOs, new command contracts with old handlers kept ≥ suspension grace + idle timeout; presence index migration create-read-both-drop. Legacy v0/v1 pages stay for legacy scopes. One reservation migration with the eligibility programme's S4-B (AP-07).
• Projection and floor (RT-06, RT-07, RT-08): consistent with brief §1.3 (form-keyed with per-reviewer markers; tally merge in R0's floor); tracking writers and readers added to the R0 inventory (hub join/leave/ dirty/disconnect, PM idle/suspension/liveness consumers, claim pipelines, typed admission, direct-navigation claim, screened-reservation release, guarded settings "Apply anyway", reservation restore, presence snapshot, FEAT-024 availability calculators).
• R2a is not claim-free (RT-05): own-place detection, claim release on first explicit Save inside the canonical transaction, presence FormSessionId, dirty = draft-changes flag. A-21's basis rewritten.
• Draft lease built on connection identity (RT-10): stable client tab ID (sessionStorage) on the draft and on ReviewSessionConnection; REST heartbeat lease (bulk-PDF lease pattern) or hub heartbeat; works untracked; explicit take-over (D2-08).
• Capacity vs target (RT-13): optional capacity cap separate from the form's minimum target (D3-17); which sessions hold a place; requested-review claim lets exactly that reviewer past pool and capacity filters (AP-03).
• Presence is a disclosure channel (RT-14): C10 lists realtime presence; non-holders get counts and their own claim only (D3-20).
• E2E in both tracking modes (RT-04); orphan-claim backstop (RT-24); presence/connection erasure and retention in E32 (RT-21); copy for slots (RT-22); D6 screening capacity defect (RT-23: AC-R3a); completion withdraws claims through the outbox (RT-18); target reduction via D6 conflict flow (RT-19); revocation releases claims (RT-20); stale tracking docs corrected by a presence-owner docs PR before F1 (RT-27).

2.2 Notification service (review-NS-notification-service.md, NS-01..NS-26)

• C15 v2 capture contract at F1 (NS-01, NS-03, NS-12): kind registry (kind, email category, scope legacy/canonical/both, admission flag, inline recipient limit, resolver) registered by owning features; generic Source sub-document; one capture service for all writers; server-provided label, context lines, typed availability and workflow state; two capture modes: inline (active source transaction, bounded recipients) and recorded fan-out (durable intent in the source transaction; leased idempotent expander writes rows in batches); time-driven notices are domain transitions run by a scheduler that marks the aggregate and captures inline; SourceId = SHA-256(kind, source type, source ID, occurrence key), row ID = SHA-256(SourceId, recipient), occurrence key from durable identity, upsert with $setOnInsert. This is C19 class (b) for notifications; the "no outbox" wording is replaced by "no second notification store; durable intents are part of C15; in-memory outboxes stay forbidden". Disclosure-policy hook per channel (inbox/email/digest) after every resolver (NS §4.2).
• Before #3942 merges (NS-02): tolerant preferences (unknown keys kept and ignored, missing = off, client sends back unknown keys), kind→email-category map (≤6 new categories, NS §5.2), version-skew test matrix.
• Enablement controls and G-NOTIF gate (NS-04): per-project notification admission (R0 admission scope or interim registry), operator delivery halt (pause not cancel), inbox reads independent of capture admission, declared email→inbox dependency; Chris approves each environment and kind family (D3-21).
• #3965 and merge order (NS-05, NS-17, §4.3): recommended order: step 0 the ownership fix (it edits ProjectController.UpdateProject, which #3941 wraps) → #3932 (regenerate on current main, retargeted checks, run:e2e-full, human approval) → #3938 → #3941 → #3942 (with tolerant preferences) → #3943 → #3944 → #3965 (restacked onto #3944) → #3945 → #3947 last (native PDF tools isolation). Restacking #3965 is the stack owner's call (D1-09). Note: #3965 now has local commits (not pushed) that the NS reviewer could not see; its completed-sessions-only eligibility already excludes RA5 requested reviewers until they return (answers Q-N9; record in the register, no question).
• Exposure (NS-06): C3 exposure kind "questioned in reconciliation"; later versions of that reviewer's session on that study × form are informed; R5c, C11 manifests and R6 consume it.
• Queues surfaced flag-independently (NS-07): global badge with read-time counts over the four queues, cross-project "My work" tab, admin banner for pending LC1 (consistent with UX-08; D3-07).
• Inventory: #3945 (Study bibliographic writes) and #3947 (PDF path) Study writers (NS-08); P2 re-runs DOI/PMID matching on accepted corrections, P1 records retrieval events.

• 3941 legacy-specific (NS-09): active decision path, Reconcile grants, canonical workload suppression; X-NOTIF

  entry criterion for R1c (or AC-R1c-04 conditional); dashed X-NOTIF edges to R1c, R2c, R3c, R4a.
• Stack screens meet UI1 (NS-10; timing in D3-01); flood controls before R2c (NS-13); Q-20 narrowed to someone-else-caused outdated flags (NS-14, PROPOSAL); catalogue rows (NS-15); live-on-merge list (NS-16); ownership: notification programme keeps capture/inbox/email/digest; StudyConversation to L6 at R4a; study issues and checked PDFs to Study Management and PDF programmes (NS-19); C10 capabilities for study issues and PDF corrections (NS-20); E32 extended (NS-21); #3950 does not track retention etc. (NS-22); capture modes per operation in the transaction table (NS-23); issues never carry answer disputes after R4b (NS-24); duplicate invitation email (NS-25); unknown kind leaves ledger row ready one deploy before the first new kind (NS-26).
• AC-C15-01..09 and the release criteria in NS §5.3 go to the acceptance drafter.

3. Batch D questions for Chris (drafters cite these IDs)

D1 — before G0 (operating and delivery) - D1-01 DECIDED by Chris 2026-10-03 (~16:05 BST): keep #3964, port #3969's active-member check and tests, close #3969. (Was: #3964 vs #3969 duplicate ownership fix. Rec: keep #3964 (compares caller with persisted owner; stored ChangeOwner grants cannot bypass it), port #3969's active-member check and tests, close #3969. - D1-02 Precedence with the architecture-review roadmap (#3961). Rec: #3961 Phase 0 continues; #3985 and #3973 are F1a prerequisites; #3986 decided before R0; #3988 v0/v1 retirement folded into E24 or after R2a; #3989 as L5 seam slices. - D1-03 ProjectStatistics activate or freeze (#3987) and GA counting. Rec: activate the families this plan uses on a date; if freeze, extend Q-31(b) to GA. - D1-04 Implementation authorisation per freeze gate (dossier with slice list) instead of per PR. Rec: yes. - D1-05 Commit and merge the ledger, package and research inputs to main now (step 0). Rec: yes, as a docs-only PR; promote contracts to ADRs as they freeze. - D1-06 Tester panel and tiers. Rec: five named CAMARADES reviewers/administrators for T1 releases, three elsewhere; monthly batched sessions; include ≥2 external SyRF users where possible. - D1-07 Production opt-in pilots before GA (A-23). Rec: yes, after staging acceptance, R0 production soak and AF2 per-project admission; one per family (R2, R3, R4a). - D1-09 Notification stack merge order and #3965 placement: ownership fix first; then #3932 → #3938 → #3941 → #3942 (tolerant preferences first) → #3943 → #3944 → #3965 (restacked onto #3944) → #3945 → #3947 last. Rec: yes; 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. - D1-08 Write-path gate shape and scale commitment. Rec: ADR-019 gate (b) shape (zero engine-caused exhausted submissions at ½/5/10); absolute p95 after M0 (start: Save ≤150 ms, Complete ≤300 ms at 200 questions); benchmark tiers typical/p99/max (50/340/2,023 questions); E28 in pins and bytes.

D2 — before F1a (engine and versioning) - D2-01 Publication writes no evidence; effects derived; projections rewritten by an operation (§1.1). Rec: yes. - D2-02 Compatibility declared when a question version is committed (system-suggested, admin-confirmed), immutable once any answer pins it; FV4 revises policy, never compatibility. Rec: yes. - D2-03 Data type and multiplicity: new identity (D38) or incompatible version of the same identity (D008-like). Rec: incompatible version; parent and owner scope stay identity. - D2-04 PV2 meaning: stage binds the form and records the bound version; live route presents the session's resolved version; Completed stages frozen for display/readiness only. Rec: yes. - D2-05 Operational settings (target, compare settings, gold completeness, guidance, DP5, routes, allocation, batches, expiry) are audited settings outside requirement versions; PV1's stamp refers to the requirement part. Rec: yes. - D2-06 System questions stored as versioned data; a new system version reaches a project only when its admin publishes a form version. Rec: yes. - D2-07 Does an autosaved draft hold the reviewer's place? (PH-03 says never; RT-09 says yes until Save/Complete, discard, admin release or 14 days.) Rec (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 (SF4 target is a minimum) unless an optional capacity cap applies (D3-17), in which case they are told honestly and may keep or discard the draft. An unattended draft never blocks capacity for days. - D2-08 Two tabs: second tab read-only with "Take over editing"; other tab's unsaved edits kept as a conflict copy. Rec: yes. - D2-09 Shared-question gold across overlapping forms: second task sees existing gold prefilled as accepted and may revise it (new snapshot with provenance), vs first publisher wins with queries only. Rec: second task may revise. - D2-10 Scoped pauses (publication phase 1 drain, stage completion, adoption cutover; and admission/readiness pause while a publication's phase 2 runs), up to a limit, drafts kept. Rec: yes (phase-1 drain ≤ ~90 s; phase-2 pause shows progress, stops at a limit e.g. 30 min). - D2-11 One active publication per form. Rec: yes. - D2-12 Dedup merge as alias: records stay attributed to the study they were made on; the primary shows them as candidates with lineage; split is a clean reversal. Rec: yes. - D2-13 Restore policy: no selective per-project restore of canonical data; whole-database point-in-time restore into an isolated database plus manifest-driven recovery; history-discontinuity record. Rec: yes. - D2-14 Account erasure: answers stay attributed to an anonymised identity; as-of exports identical except erased identities (manifest records erasure). Rec: yes. - D2-15 Template ownership: CAMARADES-curated system catalogue (application role) plus copy from projects one administers; copies only. Rec: yes. - D2-16 Initial form size ceiling until benchmarks prove larger forms safe (the 2,023-question project stays legacy). Rec: yes.

D3 — before F1c/F3 (UX, workflow, programmes) - D3-01 UI1 before FEAT-023's cutover: M3 roles over current components, routes registered for the cutover baselines; sequence the FEAT-023 light cutover before R2a's reviewer UI if possible; the notification stack's inbox and preferences screens meet UI1 before testers see them, the conversation, issue and PDF screens before production (NS Q-N5). Rec: as stated. - D3-02 Design acceptance cadence: per-release staging walkthrough plus per-PR acceptance only for new shared patterns and five high-risk surfaces. Rec: yes. - D3-03 Copy deck terms: "Save progress", "Complete", autosave "Changes kept, not yet saved", "Needs updating", "Outdated answers", "Fix", "Accepted answers (gold standard)", "Screening result". Rec: yes. - D3-04 Button and type language: M3 sentence case; re-audit the v4 spec. Rec: yes. - D3-05 Phone screening for title/abstract steps (annotation stays tablet/desktop). Rec: yes. - D3-06 Legacy screens M3 restyle (chrome and shared pages, no behaviour change) under FEAT-023. Rec: yes. - D3-07 Project-level "My work" surface in R3c/R4a; global landing after GA. Rec: yes. - D3-08 Research participants and telemetry: external SyRF users in sessions; privacy-safe timing events on pilots. Rec: yes, with consent and no content capture. - D3-09 Eligibility programme: absorb S6b browser consumption (and S4-B/S4-C/S6a if still paused) into R3a; D8 mapping as recommended by PH Q3. Rec: yes. - D3-10 Statistics: (a) fence read counts as "current" for PS2/PS3; (b) keep seed project 0102 out of pilots until the seam fixture passes; © multi-profile screening statistics served live for R3b pilots, FEAT-024 families at F5; (d) preview pilots exempt from PS1. Rec: yes to all. - D3-11 Agreement statistics in their own rebuildable store (not FEAT-024). Rec: yes. - D3-12 Deletion vs history (ADR-014 vs amendment J): withdrawing a search hides its Studies but keeps Citations and canonical evidence; deleting a whole project keeps ADR-014 removal with tombstone. Rec: as stated. - D3-13 Allocation: (a) refuse allocation on canonical stages until AL1; (b) record #3939's denominator decision in the ledger; © RA5 requested reviewer may bypass buckets and the enforced target (single-use, audited); (d) "Who is offered what" ships pool-level until X-AUTH-RESOLVER; (e) pool entry = first release to anyone, shared-open and personal-grant recorded separately; (f) #3939 merged in slices. Rec: yes to all. - D3-14 Seeds: additive seed-if-absent job on preview and staging. Rec: yes. - D3-15 Browsers: Firefox and WebKit smoke journeys and touch-capable drag in acceptance for reviewer and reconciler screens. Rec: yes. - D3-16 Production claims route (corrects Q-25's premise: claims and capacity guards exist only with tracking 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) fleet-wide once FEAT-024's M15 transition has an owner and load tests pass; © no production claims; RA1 met only by the task editor claim. Rec: (a). - D3-17 Optional capacity cap separate from the form's minimum target (off by default; when on defaults to the target; never limits requested extra reviews; never evicts existing work). Rec: yes. - D3-18 A form bound to stages with different tracking settings: 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; tracked if any bound stage is (extends Q-28). Rec: yes. - D3-19 No place held on a dependent form while still screening; claim at Include; if refused show "enough reviewers" for that step and keep the screening decision. Rec: yes. - D3-20 Presence disclosure: reviewers see counts and their own place; names only for Monitor-capability holders; never across reconciliation blinding. Rec: yes. - D3-21 Notification enablement: pilot projects first (per-project notification admission), platform-wide only after pilot exit; staging/preview overrides only with Chris's approval per release, email kept in Mailpit; an operator delivery halt before production email; G-NOTIF gate per environment and kind family. Rec: yes. - D3-22 Notification emails and digests may name the project (never study titles, aliases, answers or free text). Rec: yes. - D3-23 When one person resolves a workflow item, others' related notices show "resolved" and leave the unread count (kept in history). Rec: yes. - D3-24 Per-project email mute (inbox still records), before production email. Rec: yes. - D3-25 Reconciliation conversations are part of the project's audit record (kept while the project exists; exportable only behind an audit/export capability with aliases; never in candidate-answer exports or agreement except as exposure markers). Rec: yes.

D4 — before F4–F6 and lanes (methodology and scope additions) - D4-01 Unsure/Maybe at title/abstract (per profile). Rec: yes, default on in TA template. - D4-02 Discussion resolution route (per profile, default off). Rec: yes. - D4-03 Extract-and-verify step producing Verified gold. Rec: yes. - D4-04 Calibration/training rounds as a step kind (never votes, qualifies or counts for PRISMA). Rec: yes, R3c (or after GA with the admission hook now). - D4-05 Protocol and registration record plus search documentation fields; profile re-publication requires an amendment entry when eligibility changes. Rec: yes. - D4-06 SYRCLE, CAMARADES checklist and ARRIVE templates, owned by CAMARADES methodologists. Rec: yes. - D4-07 Full-text retrieval actions (Sought/Retrieved/Not retrieved with reasons); PDF attachment only suggests Retrieved. Rec: yes. - D4-08 Report-to-study linkage (several papers, one study) for boxes 10/16; linking never merges extraction. Rec: yes. - D4-09 Analysis-ready comparison export and RIS export (lane X1). Rec: yes. - D4-10 Graph digitisation: ship the "estimated from graph" provenance flag in O1; decide a digitiser lane after pilots. Rec: yes. - D4-11 Box 1 from amendment K's "previous review version" reported counts, switching to the updated-review template. Rec: yes. - D4-12 IRR default basis = initial independent observations; screening IRR per profile; pooled pairwise κ or Krippendorff's α for rotating raters; percent agreement and prevalence shown. Rec: yes after statistician review. - D4-13 Primary exclusion reason = first failing criterion in configured order (default on, override per profile). Rec: yes. - D4-14 FEAT-004 annotation import from other tools as a lane after R2a (own provenance, excluded from independence statistics). Rec: yes. - D4-15 Routing studies by answer values as a lane after R4a (not GA). Rec: yes. - D4-16 Early screening-profile adoption for existing projects after R3b. Rec: yes. - D4-17 Stale-answer acknowledgement (FEAT-001 D54/D55) replaced by RE2's non-blocking warning; drop enforcement levels. Rec: yes. - D4-18 Funder deliverables (NC3Rs, SSI RSMF): map each to a release and confirm with funders; WCAG 2.1 AA audit at GA. Rec: yes. - D4-19 Blinding and random serving as core behaviours: candidates always blinded (stage chooses alias scheme only); random serving default, explicit assignment an audited exception. Rec: yes. - D4-20 Completed work of disabled members keeps counting; audited admin exclusion action. Rec: yes. - D4-21 ASySD parity meaning: pinned R outputs, identical AutoConfirmed groups, ProbableDuplicate pair-set F1 ≥ 0.99, published sensitivity/specificity, 80k citations < 1 h on Bramble. Rec: yes.

4. Drafter assignments and E-ranges

• V (versioning-model.md) E36–E45
• C (consistency-model.md, contracts C18/C19 text) E46–E57
• D (domain-model.md revision) E58–E63
• P (programme-integration.md) E64–E75
• O (delivery-operating-model.md) E76–E81
• U (ux-strategy.md) E82–E87; U30–U45
• M (methodology-coverage.md + PRISMA amendment text) E88–E93
• A (acceptance-criteria.md revision) E94–E99 (if any) Assumptions A-25–A-40: V 25–26, C 27–29, D 30, P 31–34, O 35–36, U 37–38, M 39–40.