Skip to content

Temporary planning review record. The report below is reproduced verbatim as returned by the independent read-only reviewer (Plan agent, Opus model, launched 3 October 2026 about 04:05 BST). Only this front matter and note were added. Resolutions are in the resolution matrix.

Review A: scope and decision fidelity

Reviewer: independent adversarial reviewer A, read-only, 2026-10-03.

Verdict

The package gets most things right. It restates nearly every confirmed owner decision accurately and states all five required invariants exactly. Strict within-stage mode is consistently treated as a proposal, and DP1 is correctly treated as superseded. The v10 crosswalk has exactly 44 entries, and the QM v2 crosswalk covers all 12 requirement groups (101 requirements). I spot-checked 14 code claims and 13 held up.

There is one Blocker. The notification fallback rule (A-07 and notifications §5) lets R3b and R4b ship without delivering the confirmed QY6/QY8 per-raiser outcomes and the LC1 admin alert. Contract C15 claims to implement exactly those obligations.

There are also 14 Major findings:

  • Proposals presented as decisions. The plan claims "every claim is labelled", which is untrue, and several proposals read as settled.
  • RC10. The crosswalk mapping could let agreement produce gold, which RE2, AG2, SF4 and RE5 forbid.
  • Release structure. The gate entry criteria contradict the parallel windows, and the serialisation is unjustified. As a result, R2 and R3 pilots have no reconciliation or conflict-resolution path.
  • R2 constraint. The one-form-per-question rule cannot coexist with automatically included ancestors.
  • Unmapped earlier decisions. Chris's 22 September eligibility decisions (D1, D2, D4, D6) are not carried into the new model.
  • Product questions not asked. Profile-version evolution and the proposed downstream effects, gold for single-reviewer forms, and conflicts when stage-owned policies apply to shared tasks and sessions.
  • Proportional allocation has no committed release for shared forms.
  • Hidden FEAT-024 dependency. PS1 needs materialized statistics in production, which are still dark.
  • Wrong search-deletion baseline, plus two programmes missed: deletion lifecycle and PDF retrieval.
  • No owners in the inventory.
  • Owner-only ownership transfer is deferred to out-of-scope triage while R1's acceptance asserts it is already enforced.

None of this requires shrinking or restructuring the destination, but these should be resolved before G0. This review covers the package as last modified at 04:06 BST.

Findings

Citation key: - Package files are in /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/. - "ledger" means /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/review-form-owner-decisions-2026-10-02.md. - Other planning documents are in /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/. - Code paths are read at main@78c6d097d via git show in /home/chris/workspace/syrf/main. - v10 means /home/chris/.codex/visualizations/2026/09/23/01a0cbec-0c32-7103-ab5a-bfc05665deb7/syrf-v10-review-2026-10-02/source/design_handoff_syrf_v10/.

ID Severity Location Finding Evidence Recommended resolution
A-01 Blocker notifications-integration.md:152; open-questions-and-assumptions.md:120 (A-07); contracts.md:362-363 (C15) The fallback "if not merged, the feature ships without notifications rather than building a substitute" applies to every review-workflow event. That lets R4b ship without per-raiser outcomes or addressed-by-update author notices, and R3b without the admin alert. All three are confirmed owner obligations, and C15 says it implements them. ledger:221-224 (QY6: "everyone who raised a concern receives their outcome"); ledger:516-519 (QY8: "notify its author"); ledger:853-857 (LC1: "Alert project admin and obtain confirmation") Either gate R3b and R4b activation on the notification base being merged, or define delivery owned by the feature that is not parallel machinery: a raiser's "my concerns and outcomes" view, and a pending-approval surface for admins. State this in A-07 and C15, and add acceptance tests.
A-02 Major integrated-plan.md:219-220 vs :67-69 and :594-596; source-status-inventory.md:108-113 and §7 R1 acceptance says "ChangeOwner, AssignPermissions and Delete stay owner-only". On main, any project administrator can transfer ownership through PATCH. The plan defers that fix to triage outside its scope, even though PM1 and PM2 make owner-only transfer a confirmed requirement and R1 builds the group administration on top of it. Code: ProjectController.cs:365-390 ([Authorize(ProjectEditPolicy)]); Project.cs:855-866 (Update calls ChangeProjectOwnership); ProjectUpdateDto.cs:17; ProjectChangeOwnerPolicy is only declared (Activity.cs:65). Ledger:775-777 (PM1), :867-868 (PM2) Make enforcing owner-only transfer an R1 (or R1b) entry criterion, or reword the acceptance so it does not imply the rule is already enforced.
A-03 Major integrated-plan.md:18-19; contracts.md:17-19 Both documents claim "every claim is labelled" and "anything not covered by a decision is marked PROPOSAL". In fact the integrated plan never uses the OWNER, PROPOSAL or ASSUMPTION labels and uses CODE-MAIN once. Contracts uses PROPOSAL once. As a result, several proposals read as decisions. integrated-plan.md:358-360 tags "random eligible start, assigned work first" as RA1–RA4, but the ledger (:54, :247-258) only says pool default plus optional assignment. decision-register.md:287 attributes "reconcilers still don't cherry-pick" to RA1–RA4. integrated-plan.md:205 makes the new editor the default with no decision behind it. decision-register.md:182 and :186 give COMPARISON F3/F4 (research) supersession authority. contracts.md:333 presumes a "structured primary reason" while Q-22 is open. contracts.md:285 (F7 re-pairing) and :355 (schema-reference question) are unlabelled. Remove the blanket claim, or apply the labels in release sections and contracts. Mark each item above as PROPOSAL, with its source (v10 r2, FEAT-006, COMPARISON).
A-04 Major decision-register.md:219 (RC10); integrated-plan.md:383-384 (R4b) RC10 is marked "Recovered: re-evaluate current rules … manual work only if still needed". The recovered rule is about screening-profile adjudication. RC10 itself asks whether a corrected annotation-gold input on which candidates now agree can be "confirmed automatically". Read as written, the mapping could permit gold from agreement alone. v10 DECISIONS.md:14-19; COMPARISON syrf-v10-design-comparison.md:141; source rule review-steps-prototype-handoff.md:284-289 ("Profiles support … adjudication"). Ledger:270-276 (RE2), :396-398 (AG2: "Agreement alone does not publish gold"), :447-448 (SF4), :687-688 (RE5) Split RC10 into two rules. Screening decisions re-run profile rules (recovered). Annotation-form gold always needs the reconciler's final submission, and candidate agreement after a correction never auto-confirms. Add a fixture for this.
A-05 Major integrated-plan.md:485, :487, :489 vs :503-504; decision-register.md:203 Gate entry criteria contradict the parallel windows. G3 requires "R2 piloted", yet W3 builds R3 during the R2 pilot. G5 requires "R3 piloted", yet W4 builds R4 during the R3 pilot. The disposition says the inherited ordering is "forced by confirmed decisions (engine before profiles…)". Gold before queries is forced. Requiring a piloted R3 before ordinary-form reconciliation, and a live P1 before as-of annotation exports or the agreement view (G7; R5 at :391-396), are not forced. They are inherited from the preliminary M4→M5→M6 ordering. review-implementation-plan-2026-10-03.md:83-93; ledger contains no decision requiring these orderings Say whether gates are build-entry or release-entry. Justify or remove the R3-pilot prerequisite for ordinary reconciliation. Decouple the EX1 as-of annotation export and the AG1 agreement view from P1. Stop attributing the engine-first order to confirmed decisions (DP4 requires reuse, not sequencing).
A-06 Major integrated-plan.md:231-260 (R2), :306 and :366-367 (R3/R4), :371-374; contracts.md:225; open-questions-and-assumptions.md:28 (Q-07) R2 contains no reconciliation, and R4 "replaces, not wraps" the legacy reconciliation. Real R2 pilots (Q-07) with a target of 2 or more therefore cannot reconcile until R4. R3 profile resolution (adjudication or extra votes) only arrives in R4, so under the cross-stage default (Pending/Conflict means Wait), studies in conflict can never reach the next stage. That undermines R3's headline value, "a real screening-to-extraction workflow". As cited; G5 entry at :487 Restrict R2/R3 real pilots explicitly (for example, target-1 forms, or no cross-stage route), or bring forward ordinary-form reconciliation and profile resolution routes. Add this to pilot exit criteria.
A-07 Major integrated-plan.md:234 and :260; contracts.md:164; decision-register.md:64 The temporary rule "a question can belong to only one form" conflicts with "ancestors included automatically" and with form versions that include all ancestors. Any two forms with questions under a shared parent, such as a system or category label root, become impossible, which effectively limits R2 pilots to one form per tree. This is an unflagged proposal that delays SF3. The register also places SF3 in R2. source-status-inventory.md:41-43 (system questions rebuilt from code); integrated-plan.md:288-292 (SF3 is actually in R2b) Apply the constraint to non-ancestor membership only, or allow shared ancestors read-only. Record it as an assumption with its cost, and fix the register placement.
A-08 Major contracts.md:206-240 (C6); integrated-plan.md:301-320 (R3); open-questions-and-assumptions.md:129 (A-16); migration-adoption-rollback.md §3 Several earlier owner decisions are not carried into the profile/step model and are not listed for supersession. D1/D2 (Chris, 22 September): Allow/Stop for new screening after sufficiency on combined stages, with existing stages defaulting to Allow and new stages to Stop. D4: refuse newly unavailable activity after a stage is disabled or its mode changes, while preserving drafts. D6: capacity and reservation conflicts with "Apply anyway". The package mentions Allow/Stop only as a baseline fact. review-eligibility-policy.md:985-986, :989, :991; review-steps-prototype-handoff.md:157 ("extra-vote admission follows explicit policy"); source-status-inventory.md:87-88 Add an explicit mapping: where extra-vote admission lives (profile or step), migrated combined stages keep their Allow/Stop values, how D4 interacts with EW1, and D6 claim semantics. Otherwise list each as a supersession question for Chris.
A-09 Major open-questions-and-assumptions.md:75 (E5); decision-register.md:225 (OD1) and :240 (OD16); contracts.md:199-201; ui-coverage-comparison.md:75, :137 Profile-version evolution is a product policy question that is treated purely as engineering. The question is whether FV2/FV3-style publish-time admin choices apply to profile versions, affecting cast decisions, collective outcomes and PRISMA snapshots. Similarly, the ledger's "Proposed effects to specify" and the cascade of cross-stage corrections have no point where Chris approves them. The OD1 crosswalk drops v10's "Profile-version evolution is also open". v10 DECISIONS.md:64; review-steps-prototype-handoff.md:631 ("scientific profile-version evolution"); ledger:40 (PV2 transition not decided), :149-156; screening-specialised-annotation-research.md:1283-1286 (a user decision). The historical DP1 text (ledger:410-411) delegated only mechanics. Add owner questions: does the FV1–FV3 model apply to profile versions, and approval of the proposed downstream effects and correction cascade (affected work marked, never silently reopened or deleted).
A-10 Major contracts.md:216-217 (C6), :284 (C9); decision-register.md:180 Several stage-owned policies apply to evidence shared across stages, and the package never says which applies when settings differ. BL1 blinding is stage-owned, while RE4 makes one study×form task reachable through any stage. EW1 is stage default plus step override on one shared form session. VS1 is set per step. The package supersedes "most restrictive wins" without a replacement rule. ledger:59, :328-331 (BL1); :655-669 (RE4); :47 (EW1); :45 (VS1); review-stage-step-access-policy-proposal-2026-10-03.md:50-51 ("route policy may vary by stage") Add an owner question or an explicit proposal. For example: task blinding is the most restrictive of the bound stages; EW1 is evaluated per route without changing the shared target; VS1 exposure is recorded per PV1/VS2.
A-11 Major decision-register.md:286 (RECON-01..05), :297 (MIG) QM v2 RECON-03 (single annotator auto-promoted to authority when MinAnnotators=1) and MIG-08 (single-annotator studies auto-promoted) are folded into "Revised to GS1" with no disposition. Under RE2 and AG2, gold requires an explicit final reconciliation submission, so target-1 forms (common in extraction) have no defined path to gold, now or on adoption. main@78c6d097d docs/planning/qm-v2-context/qm-v2-requirements-tracker.md:86, :152; ledger:270-276, :396-398 Add an open question with a recommendation: auto-promote as a recorded acceptance, reconciler confirmation, or no gold. Add the matching adoption rule for legacy single-reviewer studies.
A-12 Major contracts.md:254; integrated-plan.md:437; open-questions-and-assumptions.md:122 (A-09) Proportional allocation is in the full scope, but shared-form allocation has no committed release. C7 says "later a single plan owner", while the coverage matrix claims R3. R3 acceptance (:322-331) has no allocation criterion, and A-09 has no exit point. This is a silent deferral of a scope item. claude-planning-launch-2026-10-03/prompt.txt:11; review-statistics-allocation-batching-integration-2026-10-03.md:67 ("Later shared allocation contract") Name the release (joined with the allocation owner) that lifts A-09, and add acceptance criteria.
A-13 Major integrated-plan.md:257-259; open-questions-and-assumptions.md:121 (A-08) PS1 requires materialized usage statistics at publication, but FEAT-024 is dark in production and fold enablement is refused on the production database until "gate (b)". R2 production-pilot gating mentions only AF2 (Q-25). A-08's "targeted authoritative refresh" may bypass materialized statistics, which would be a deviation from PS1 that Chris has not approved. ledger:51-53 (PS1–PS3); source-status-inventory.md:114-115; main commit 89d295734 "keep refusing fold enable on the production database until gate (b)" Add FEAT-024 production readiness (version-usage family plus gate (b)) as an R2 production-pilot dependency. Clarify that A-08 refreshes the materialized usage (PS2) rather than replacing it, or ask Chris.
A-14 Major source-status-inventory.md:126-127; integrated-plan.md:406 (P1) The claim "Removing a search hard-deletes its studies" is wrong for the baseline. Both search DELETE routes throw DeletionLifecycleUnavailableException (fail closed with 503), and the repository delete has no production call path. This misses the deletion-lifecycle programme (reversible deletion scheduler, DeletionLifecycle flag). It also misses the PDF acquisition and processing programmes that P1's "retrieval status recording" depends on: Bulk PDF upload, PDF Agent, Study Management Processing, Submit/ApprovePdfCorrections, and #3947. SearchController.cs:108-136; ProjectController.cs:392-411; StudyRepository.cs:1124-1131 ("Search deletion is disabled today"); env-mapping.yaml:786-794; docs/features/materialized-project-statistics/phase0-mutation-ownership-matrix.md:1646 Correct the baseline. Inventory both programmes and add P1 join gates for reversible search removal (preserving Citation history) and for retrieval status.
A-15 Major source-status-inventory.md:168-236; integrated-plan.md:222, :483 The brief's acceptance criteria require owners, but the inventory lists none. #2224 (custom groups) is authored by another contributor (nurikarakaya) while the other in-scope PRs are chrissena's, yet the plan's critical path says "rebase and split into small PRs". G1 requires sign-off from owners who are never named. PLANNING-BRIEF.md:43; gh pr view 2224 --json author Add an owner/author column per programme and PR. Make Q-09 include coordination with #2224's author. Name who signs each gate.
A-16 Minor source-status-inventory.md:99; integrated-plan.md:150; open-questions-and-assumptions.md:44 (Q-24), :129 "D5/D3b: annotation has no screening prerequisite" mislabels D5. D5 is about excluded work: preserve new-annotation exclusion, keep saved-work resumption, and add no new direct-access ban. That is consistent with EW1 and the veto. "R3 must supersede D3a and D5" contradicts Q-24(b), which says D5 "remains". Q-24(a) also asks Chris to confirm a supersession the precedence rule already settles. review-eligibility-policy.md:987-990; ReviewEligibilityPolicyTests.cs:176 (AnnotationHasNoScreeningPrerequisite) Cite D3b plus the test for the no-prerequisite rule and keep D5. Record the D3a supersession under the precedence rule rather than as a question.
A-17 Minor decision-register.md:64, :66, :106-107, :166; integrated-plan.md:47, :590 Placement is inconsistent across documents. SF3/SF5 are in R2 per the register but in R2b per the plan (:288-292). RX2, LC1 and SET2 are in R3 per the register but in R3b per the plan (:336-347). R1 is said to depend on "G0 only", but it also needs G-D (A-17). Q-20 is listed in Batch B but appears in the Batch C table (open-questions:59), although it is needed by R2. As cited Reconcile the register, the plan and the batches.
A-18 Minor decision-register.md:246, :228, :65, :225, :230, :236, :253 Several v10 crosswalk entries are inaccurate. RD2 is shown as settled, but RE2 covers only "matching" prefill and RE5 forbids prefill without exact agreement, so prefill for items recorded by only one reviewer remains open. OD4 and SF4's "selection beyond target" reads as choosing a subset, which SF4 forbids. OD1 drops profile-version evolution. OD6 drops "which transitions need explicit confirmation". OD12 drops population merging and cross-type count solving and gives no release ("C2+"). RD9 omits bulk reassignment. v10 DECISIONS.md:232-238, :86-92, :64, :104, :216, :291; ledger:272-275, :675-678, :416-419 Correct each entry and mark the open remainders.
A-19 Minor decision-register.md:288; source-status-inventory.md:232 RECON-07 ("annotators never see other candidates' answers") is mapped to BL1. It belongs to VS1 candidate isolation; RECON-12 is the one that maps to BL1. QM v2's own "Release R1/R2/R3" labels (traceability table) and "#2461 QM v2 R1 umbrella" collide with the package's R1–R7. qm-v2-requirements-tracker.md:90, :95 Remap RECON-07 to VS1/FORM-08, and prefix or annotate the release names.
A-20 Minor open-questions-and-assumptions.md:31 (Q-10); notifications-integration.md:92, :98 The package calls questioning incomplete sessions in #3944 a "conflict with confirmed VS2". VS2 concerns contributions made after viewing accepted answers, so this overstates it. The VS1 conflict is well founded. Ledger:46; verified in the #3944 worktree: StudyConversationAccess.cs (CanReadAsync gives all participants access; CandidatesAsync has no status filter); StudyConversationRepository.cs (CaptureAsync fans out to all participants) Reframe as an independence or exposure risk that extends the PV1/VS2 principle, and keep the urgency on VS1.
A-21 Minor contracts.md:366 vs notifications-integration.md:72, :131, :119; integrated-plan.md §6 C15 says "Recipients are resolved with fresh authorization at delivery and read", but the existing stack expands recipients at write time and only shapes details at read or send time. Routing to groups is not addressed: new grant holders miss earlier items, and query-review routing "for the stage" is ambiguous when a task spans stages (RE4). The dependency graph has no node for the notification stack. As cited Align the wording. State that workflow queues live in feature aggregates. Add the stack as an external dependency, together with the A-01 resolution.
A-22 Minor notifications-integration.md:108-123 The event catalogue covers publication that requires re-answers, but not: FV4 revision that lifts a requirement, autoUpdate changing a reviewer's answers, publication of a new profile version, or publish-pause/queued-retry messages (Q-20). ledger:376-385, :125 Add rows, or record deliberate omissions with recipients and disclosure rules.
A-23 Minor open-questions-and-assumptions.md:42 (Q-15), :131 (A-18) Q-15 recommends a hybrid rule: collective Included AND not personally Excluded, and the advanced option as own Include OR collective Included. It does not present the alternatives already documented (Mode B, collective only; Mode C, both Includes). It also does not say that A-18 departs from the access-policy proposal, where personal policy with no own decision means the prerequisite remains to do. screening-step-dependency-options.md:50-51; review-stage-step-access-policy-proposal-2026-10-03.md:62 Present B, C and the hybrid explicitly, with consequences.
A-24 Minor open-questions-and-assumptions.md:52 (Q-11), :58 (Q-16) Bulk approve (Q-11) ignores RE2's unseen-control warning and explicit final acceptance. Q-16's "method … for multi-selects" could reopen AG2's exact-set rule. ledger:278-286, :389-393 State how RE2 applies to bulk approval. Limit Q-16 to the formula and denominators.
A-25 Minor contracts.md:216 Three confirmed settings have stage defaults, but no values are proposed or asked for new or migrated stages: VS1 visibility, BL1 blinding and the RA assignment-expiry period. ledger:45, :59, :251 Add default proposals as approval items.
A-26 Minor integrated-plan.md:421-442, :407-408; contracts.md:338-348 The coverage matrix traces only the prompt's list, not the PLANNING-BRIEF scope table. "Full answer-set form membership", "outcome associations", "conflicts with supporting provenance" and "without automatic strictness" (Pregnant implies Female) cannot be traced to C1, C2 or C13. PLANNING-BRIEF.md:21-33 (especially :27, :29) Add a traceability table row by row against the brief's scope table.
A-27 Minor migration-adoption-rollback.md:66 "Direction kept per source, consolidated only when values agree (ODIR1)" can read as a direction per source or context, which ODIR1 forbids. ledger:871-873; outcome-data-migration-plan-proposal-2026-10-03.md:97 State that each measure has a single canonical direction. Per-source values are evidence only, and conflicting values block binding until a reviewed mapping or separate measures.
A-28 Minor decision-register.md:148, :131, :156 The register summaries omit parts of three decisions. PM1: ordinary admins get most or all ordinary permissions by default. QY4: prefer a different authorised reviewer. OC2: direction is never derived from numeric type and is not a validator or treatment-effect claim. ledger:775-777, :216, :730-732 Restore the omitted boundaries.
A-29 Note source-status-inventory.md §4; integrated-plan.md §8 Live state has changed since the 03:30–03:50 snapshot. #3948 merged (main at 9d74077d8, 03:56 BST). #3932 is now CONFLICTING. New PRs #3955 (QuestionAnswers stale scopes on transactional saves) and #3956 (screening rows on inclusion change) touch the C7/C8 seams. gh pr view; git log in main Recheck before G0.
A-30 Note All files (modified 04:06 BST) The package was edited during this review: Q-15(b) and A-18 added, Q-25 references and counts corrected. These findings target that state, and the earlier dangling references are now resolved. ls --time-style=full-iso Re-run reviews if the package changes materially.

Verified as correct

  • Confirmed decisions. Every confirmed ID listed in the brief appears in decision-register §1 with a faithful short form. Settled items (FV4, SF6, QY8/QY9, AG2/AG3, EX2, ODIR1, MIG1, SET2, OPS1) are not asked again. DP1 is listed as superseded (decision-register.md:174).
  • Invariants. All five are stated exactly at integrated-plan.md:80-87 and carried through C6, C12, C14 and R3 acceptance item 5. Strict within-stage mode is consistently a proposal (Q-01).
  • Recovered and proposed items. requireReanswer/autoUpdate/doNothing is labelled as a recovered baseline, not a new decision. The publish-pause UX stays a recommendation (Q-20/U5). The earlier drafts' dispositions are themselves labelled proposals.
  • v10 crosswalk. Exactly 44 entries, matching the IDs in v10 DECISIONS.md. RD15/RD16 are labelled "declared resolved in v10", not owner decisions.
  • QM v2 crosswalk. Covers all 12 v1 groups (101 requirements) plus SHARE/AQM. The ARCH-07/PRISMA-03 supersession matches the domain model in CLAUDE.md.
  • Code spot-checks at 78c6d097d (13 of 14 held):
  • Question deletion cascades to answers, with the #3088 gap acknowledged in code.
  • Answer replacement is independent of stage, with one session per stage, investigator and reconciliation flag (ExtractionInfo.cs:183-206).
  • Optional is never read on the server.
  • Ownership transfer works through PATCH.
  • The catalogue has 25 project and 4 stage activities.
  • minNumberSessions = 2 is hard-coded (StudyStats.cs:355).
  • The reconcile response maps all sessions (StudyDto.cs:57).
  • The reconcile route shows read-only candidate cards in 50/50 columns.
  • Screening is one decision per reviewer per project, with the stage overwritten on re-screen.
  • ReviewEligibilityPolicy has 14 actions.
  • The membership route guard has the editMembership typo.
  • OnlyCompleted is forwarded but never used by the writers.
  • Schema 0 has no custom groups.
  • The one that failed is search deletion (A-14).
  • Notification stack. All eight heads and open states match live gh output. The #3944 behaviours were verified in its worktree. The notifications document separates what is merged, what exists only in PRs and what is missing. It proposes no parallel machinery and sends no messages.
  • Prototype assets. The QM v2 prototype hash 032fe56e…a999a and its location, the location of Review Prototype v4, and the v5 reference at RECONCILIATION.md:90 all check out.

Missing coverage

  • How eligibility decisions D1, D2, D4 and D6 carry forward into the profile/step model (A-08).
  • Policy for profile-version transitions, and approval of the ledger's proposed downstream effects and correction cascade (A-09).
  • Gold for single-reviewer (target-1) forms, and the matching adoption rule (A-11).
  • Rules for stage-owned policies (BL1, EW1, VS1) on tasks and sessions reachable through several stages (A-10).
  • The deletion-lifecycle programme and the PDF retrieval and processing programmes as P1 dependencies (A-14).
  • Owners for programmes and PRs, including #2224's author (A-15).
  • A reconciliation or conflict-resolution path for R2/R3 pilots (A-06).
  • A release that lifts the restriction on shared-form proportional allocation (A-12).
  • FEAT-024 production readiness as an R2 production-pilot dependency (A-13).
  • Notification events for FV4, autoUpdate and profile publication, and how routing to groups works (A-21, A-22).
  • Default values for VS1, BL1 and assignment expiry (A-25).
  • Traceability against the brief's scope table: outcome associations, conflicts, "without automatic strictness", population merging (A-18, A-26).
  • Earlier-year documents not referenced, whose disposition should be confirmed: screening-step-dependency-options.md (Draft, 24 September), active-reviewer-tracking-overhaul.md (Approved, April), review-access-state-overhaul.md, session-capacity-suspended-sessions-handover.md, session-copy-review.md, data-export-analysis.md, and the stage-review-layouts contract.
  • The default authority policy raised in research §8 #3 (adjudication override grants, stale authority for admissions) beyond QY4, and bulk reassignment of reconciliation assignments (RD9).

Critical Files for Implementation

  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/integrated-plan.md
  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/decision-register.md
  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/open-questions-and-assumptions.md
  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/notifications-integration.md
  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/source-status-inventory.md