Integrated implementation plan

Temporary planning document for Chris's review. Planning only. This plan authorises no runtime code, migration, deployment, flag activation, remote write or notification. Implementation is authorised per freeze gate, when Chris approves that gate's dossier (D1-04).

Owner session (4–5 October 2026). Chris held an owner session on 4 and 5 October 2026. It answered, replaced, removed or deferred most of the open decisions and added requirements of its own. This package integrates it on PR #4045; "What changed in the owner session" in §1 summarises the changes, and §11 gives the decision counts with their scope. The consolidation wins over older text in this plan. Where this plan still shows an earlier decision, it is marked Superseded (5 October) and kept for history. Feature implementation is on hold (Chris, 5 October 2026). This plan keeps three things apart:

1. Planning approval. The owner decisions recorded here approve the plan's direction. They authorise no work.
2. Brief approval and implementation authorisation. Each workstream brief (tracker rows T-RD-00 to T-DH-00 in the implementation tracker) needs Chris's approval, and implementation is authorised per gate (D1-04). Both are on hold. G0 is not approved. Passing G0 and lifting the hold (T-HOLD) are separate decisions.
3. Work started, gate passed, production enabled. None of these has happened. Every work item is at most "Brief drafted".

Evidence baseline: code facts were first verified on main at 78c6d097d (3 October 2026, 01:35 UTC) and re-checked for round 2 on main at de3e98c59 and eb93caffa (3 October 2026, about 19:30 BST). Between those two commits the only change is an auth-migration E2E test commit (#3994), outside every programme this plan touches. Live PR and programme state is as recorded in programme integration §1 (read at 15:18 BST and re-checked at 19:25 BST on 3 October); refresh it at every gate. The owner-session integration (5 October) starts from main at 5245941e9; it re-verified no code facts and no live PR states.

How to read the labels. A behaviour followed by an owner decision ID, such as (SF1), is a confirmed owner decision (OWNER), or a recovered baseline where the decision register says so. Release boundaries, sequencing, gate criteria, default values and anything marked PROPOSAL are this plan's proposals. ASSUMPTION marks a working assumption listed with its cost in open questions and assumptions. Decisions raised by the round-2 reviews cite their Batch D ID (D1-xx to D4-xx), listed in open questions, Batch D. D1-01 to D1-09 are decided (decision register §1.12 and §1.13). D2 to D4 were pending until the owner session of 4–5 October; §11 records their current statuses, and the owner-session integration maps every ID. Requirements the owner session added outside the decision register carry OS-A01 to OS-A30 IDs, defined in the owner-session integration. Not every sentence carries a label; anything without a decision ID is a proposal.

Companion documents: acceptance criteria · delivery operating model · programme integration · domain model and new aggregates · consistency model · versioning model · UX strategy · methodology coverage · PRISMA and deduplication amendments · source and status inventory · decision register · contracts · UI coverage comparison · notifications integration · migration, adoption and rollback · open questions and assumptions · review resolution matrices: round 1 and round 2 · validation evidence.

Owner-session documents (5 October): owner-session integration · specifications overview and the nine specifications listed there · design-prototype handoff · rollout plan · implementation tracker · product-owner guide · archived owner-session bundle.

1. Summary

Destination (full scope, not a pilot): one shared annotation infrastructure in which project forms own evidence, targets and immutable reviewer sessions across stages. Profile-owned screening decisions use the same revision engine. Stages define versioned steps and routing. Reconciliation produces immutable gold snapshots from every qualifying candidate, with queries, matching and blinding. Classification and inference, configurable outcome schemas, scoped group permissions, current and as-of exports, and PRISMA reporting all build on the same contracts. Existing statistics, allocation, presence and claims, batching, eligibility, authorization and notification programmes are integrated, not duplicated, and the changes they need are set out in programme integration.

How it gets there. Six release families (R0–R5) are cut into small releases, each usable or enabling on its own. Eight lane releases run alongside, and a GA milestone, adoption waves (R6) and retirement (R7) follow. An S0 scaffolding release and the M0 walking skeleton come first. Two kinds of gate hold this together. Freeze gates (F1a engine contracts, F1b catalogue and export disclosure, F1c information architecture, copy and AF2 seams, then F2–F5, F6a, F6b and the lane freezes) fix a contract so dependent work can build against fakes. Ship gates decide whether one release may ship, weighted by release tier. Work starts from a dependency-driven ready queue with work-in-progress limits (delivery operating model).

Release	What users get	Ships after
S0 Programme scaffolding	Nothing visible: module skeleton, fixture and benchmark harnesses, seed hooks, status ledger	G0
R0 Compatibility floor and project admission	Nothing visible: old binaries keep canonical data (capture, not ignore), legacy getters and pool predicates read Study.CanonicalSummary, legacy writers refuse canonical scopes through ownership markers, one per-project admission record	F1a
R1a Question library and import	Reviewed template import and library reuse in the new question editor	G0
R1b Members & groups visibility	One place showing every group, member and grant; owner-only ownership transfer enforced (#3964, D1-01); "why can or can't I" explanations once the authorization programme's WP9 lands	G0 (#3964 merged on 3 October 2026)
R1c Configurable groups and permissions dialog	Create and manage project groups; one dialog for every project and stage grant	R1b + authorization gates and WP9
R1d Delegated permission administration	Owner-granted permission administration (PM2)	R1c + Q-03
R2a Versioned forms and immutable sessions	Versioned questions and forms with the standard reviewer target inside the form version (OS-A12); drafts kept as a diff-based change log with base-version checks (D2-07, D2-08; the single-writer lease is Superseded (5 October)); Save creates a version checkpoint and Complete a validated one; history; previous-version export (one stage per form)	R0 + F1b/F1c for its UI
R2b Shared sessions across stages	One reviewer session and one place per study and form wherever it is opened, in any tab or device; form-owned inactivity timeout and in-progress limit (D2-07, Q-28); counted once; claims per the claim contract	R2a
R2c Publication with impact	Forms evolve with admin-chosen treatments over every prior version; publication records a policy and may write attributable generated session versions (D2-01 amended; "writes no evidence" is Superseded (5 October)); target-only publications, Study target overrides and collaborative drafts with presence (OS-A01); current statistics at the fence (Q-31(b) is the designed first pilot path)	R2a + F2
R2d Overlapping forms and Fix	Answers shared across forms within a compatibility class; outdated-annotation flags with a configurable outdated mode (D4-17); explicit Fix and Upgrade; revisable requirements; guided correction of a publication (D2-02)	R2a, R2c
R3a Steps and routing	A stage study filter that defines the stage pool; steps with dependencies inside the stage; own-Include default progression (Q-01); exclusion-stop; pool history and structured events (OS-A07, OS-A11); a step selector with one form area (Q-12); a keyboard screening path. "Collective Include across stages by default" is Superseded (5 October) by Q-15's replacement	R2a + F3
R3b Screening profiles	Profile-owned eligibility questions, templates, derived decisions confirmed on submit, reasons	R3a, R2c + F5
R3c Stage lifecycle	Automatic or manual stage completion (fence, drain, verify): automatic stages recalculate when work appears, and static completion holds until an authorised reopening (Q-02); the optional collective-Include stage setting (Q-01)	R3a
R3d Guided setup	The replacement setup wizard with templates and library	R3b, R2c, R1a
R4a Form reconciliation and gold	A reconciler form for any number of candidates, one task per study and form, an editor claim that works without tracking (X-RECLAIM), match suggestions, prefill with Complete anyway, immutable gold snapshots; target one accepted automatically as Single annotator or by required human reconciliation (Q-29, D4-03); form-owned blinding with context-local aliases (OS-A02, OS-A03); reconciled-answer hints with click-to-fill (OS-A04)	R2b + F4
R4p Profile reconciliation	Screening-decision adjudication in a system adjudication step, assignable to a member or group (OS-A13), with bounded Unsure handling (OS-A16), an optional rationale (Q-32) and optional discussion (D4-02); reason reconciliation	R3b, R4a
R4b Queries	Challenges to accepted answers with per-raiser concern resolutions	R4a
R4c Outcome reconciliation	Outcome-series reconciliation	R4a, O1
R5a History and as-of export	As-of downloads with manifests and coverage labels	R4a + F6a
R5c Agreement statistics	An agreement view separating independent from informed answers, from its own rebuildable store	R4a + Q-04, Q-16
R5b PRISMA reporting	PRISMA flow output from frozen snapshots computed from authoritative records, with published arithmetic identities	P1, P2, R3b, R4p + F6b
Lanes P1/P2, C1/C2, O1/O2, AL1, X1	PRISMA identification and deduplication, with duplicate merge as one consolidated, reversible Study (OS-A29); classification then inference (inference is an opt-in beta, OS-A19); outcome schemas then outcome migration; shared-form proportional allocation; analysis-ready exports (D4-09 decided)	Their own freezes; see §5.8
Owner-session lanes (5 October; names PROPOSAL)	TR1 training with reference answers, scoring, assessment, retries and optional group admission (OS-A18); XS1 external and AI-model-generated screening decisions (OS-A20); XA1 annotation-answer imports; RW1 the in-engine redesign wizard after conversion (OS-A15); PWA1 PWA exploration beyond the MVP (OS-A22); BR1 answer-based step branching, deferred (D4-15). The rollout plan fixes their placement	Their own briefs and freezes (F-TR, F-XS, F-XA); see §5.8
GA milestone	The canonical path becomes the default for new projects	The R2–R4 core piloted, including one production pilot per family (D1-07)
R6 adoption, R7 retirement	R6: universal faithful baseline conversion of every remaining project in waves, after staging trials and production pilots (OS-A15). R7: legacy-writer retirement as its own verified milestone. "Reviewed per-project adoption" is Superseded (5 October)	Separate approvals for every pilot, wave and retirement

What changed after the second review round (3 October). Thirteen independent reviews and a verifier (362 findings, 12 Blockers) led to these structural changes; every finding's resolution is in the round-2 resolution matrix:

• Versioning has one rulebook (versioning model): compatibility declared per question version and immutable once pinned, compatibility classes in the answer key, stable option IDs, requirement versions separate from operational settings, full pin maps, explicit Upgrade, and publication that records a policy without writing evidence. (Superseded (5 October): publication may now write attributable generated session versions, the standard target moved inside the form version, and the publisher's compatibility declaration is immutable from commit.)
• Consistency is designed, not asserted (consistency model): no per-project document in any interactive transaction, per-study serialisation, a canonical command ledger, ownership markers and a write guard, fence-and-drain for publication, completion and cutover, durable post-commit effects, and new contracts C18 and C19.
• Domain design gains a context map, the ReviewerStudyEvidence aggregate, outcome facets with one writer, merge as an alias, one canonical Stage aggregate and a glossary (domain model). (Superseded (5 October): merge as an alias is replaced by one consolidated current Study with reversible unmerge.)
• In-flight programmes are integrated with strategic changes (programme integration): claims and capacity guards exist only when active reviewer tracking is on, so the production claims route returns to Chris (D3-16) and reconciliation gets its own editor claim; FEAT-024's production readiness is a seven-step chain; the notification stack needs a C15 v2 capture contract.
• Delivery is organised for one approver and an agent workforce (delivery operating model); the binding constraint is Chris's decision and acceptance throughput, not engineering.
• UX gains a research plan with real reviewers, measurable criteria and reviewer efficiency in scope (UX strategy); methodology gains an agreement observation basis, retrieval, report linkage and synthesis exports as proposals (methodology coverage; PRISMA amendments M, N and O).

What changed in the owner session (4–5 October). Chris worked through the open decisions with a separate session and recorded the results in a consolidation, archived byte for byte with the session's register, condensed packages and stage-filter model in the owner-session bundle. The owner-session integration reconciles the counts, lists the superseded wording and maps every decision to a specification, contract, criterion, release and tracker row. Nine specifications turn the decisions into buildable designs, the rollout plan places the work, the implementation tracker records progress (none has started), the product-owner guide explains the result in plain English, and the design-prototype handoff (T-DH-00, OS-A30) is a self-contained specification for iterating SyRF Prototype v10. No design session has been messaged and no new prototype has been built. The main changes:

• Review domain and versioning (specification). The Study stays the review unit. One reviewer has one session and one place per Study and form across stages, tabs and devices (D2-08). Autosave keeps a diff-based recoverable draft; Save creates a version checkpoint, which may be incomplete; Complete creates a validated checkpoint. The standard reviewer target is part of the immutable form version (OS-A12), so changing it is a publication with impact. Study target overrides keep their own history, and additional-review requests raise the effective target. Publication may create attributable generated session versions (D2-01 amended). The publisher declares compatibility, and corrections use guided rollback and republication (Q-34, D2-02). Design drafts are collaborative, with presence and live updates (OS-A01). The form owns the inactivity timeout and in-progress limit (D2-07). The largest project is an acceptance case (D2-16 replaced). D2-09 is the one open owner decision.
• Duplicate merge (specification). A merge creates one consolidated current Study, commits atomically, keeps the originals as immutable history and can be reversed by an unmerge (D2-12 replaced, OS-A29). P2 splits into P2a, P2b and P2c (PROPOSAL).
• Stage pools, steps and history (specification). A stage study filter defines the stage pool, and there is no stage-entry gate (Q-15 replaced). Dependencies are between steps inside a stage, and exclusion-stop is a separate step setting. A reviewer may move on after their own Include by default, and a stage setting can require collective Include (Q-01). Automatic stages recalculate when work appears; static completion holds (Q-02). Started work may finish after the Study leaves the pool (OS-A05). Pool history and structured, queryable history events (OS-A07, OS-A10, OS-A11; new contract C20) let an admin explain why a Study was or was not reviewed. StudyEnteredPool is renamed WorkFirstReleased. Reviewer-pool browsing is optional, dynamic and blinded (OS-A27). Answer-based branching between steps is deferred beyond the MVP (D4-15).
• Reconciliation and screening (specification). At a target of one, the form version chooses between automatic acceptance as Single annotator and required human reconciliation; there is no separate verification engine (Q-29, D4-03, OS-A28). The mandatory legacy-authority backfill is removed (Q-35). The form or profile owns blinding, with unpredictable candidate order and context-local aliases (OS-A02, OS-A03). Reviewers see reconciled answers as labelled hints and copy them only by an explicit click (OS-A04). A profile routes ties to extra review or to a system adjudication step assignable to a member or group (OS-A13), and Unsure handling is bounded (OS-A16). Bulk acceptance is optional after the core (Q-11). Automatic acceptance of several agreeing candidates is not approved (T-POL-03).
• Baseline conversion (specification). SyRF ends with one writable engine. After staging trials and production pilots, every remaining project converts to a faithful baseline in waves, including completed and inactive projects (OS-A15). Missing history carries named legacy-gap states. Projects that cannot convert faithfully are quarantined with a remedy. R6 becomes the universal conversion waves and R7 becomes legacy-writer retirement with its own verified milestone. D2-13 recovery is a brief item.
• Training and inference (specification). Training steps with reference answers, scoring, manual assessment, retries and optional group admission are in delivery scope in lane TR1 (D4-04 amended, OS-A18). Inference (lane C2) is a beta, off by default, switched on by a project designer (OS-A19).
• Reporting, imports and AI screening (specification). Reports keep imported references, source documents and Studies apart. PRISMA reports actual review through a stage first; pool history is audit data (OS-A09; box mapping is specialist input T-SI-05). AI-model-generated screening decisions can be imported in a later opt-in lane (XS1) with full model provenance (OS-A20). Report grouping is deferred; links to several source documents are prepared (D4-08).
• UX, devices and work discovery (specification). The reviewer page has a step selector and one form area (Q-12). Full annotation works on phones, tablets and desktops at launch (D3-05). Status labels keep "Draft auto-saved", "Version checkpoint saved" and completion distinct (OS-A21). Legacy screens get compatible improvements without workflow changes (OS-A23). The current tester panel stays, with no external recruitment now (D3-08). PWA exploration (PWA1) is beyond the MVP, with no offline writes (OS-A22). Seeds (D3-14) and Firefox, WebKit and touch coverage (D3-15) are decided.
• Access, catalogue, communications and deletion (specification). Account deletion keeps named attribution (D2-14). Admins may exclude a member's contributions by scope (OS-A24). Ordinary project deletion is reversible (OS-A25). One application-wide CAMARADES catalogue holds versioned items (D2-15). Emails are informative and permission-aware (OS-A26). Permanent physical erasure (T-POL-01) and an identity-erasure process (T-POL-02) are not approved.

Proposed numeric thresholds stay proposals. PRISMA box mapping, agreement methods, event-count definitions, template curation and ASySD parity need specialist input (T-SI-01 to T-SI-05).

Most parallel work starts at G0 and F1a. After plan approval, S0, M0, R1a, R1b, PRISMA identification design, the UX baseline study and the user-interface prototypes run at once, within WIP limits. Since 5 October that start also needs the hold lifted and each work item's brief approved; neither has happened. After the engine freeze (F1a), R0, the R2a back end, C1, O1 and the workflow and publication freezes proceed in parallel. See §7.

Where pilots run (Q-07, decided). Every release starts on synthetic projects in the e2e stack, then pilots on the seeded projects in the preview and staging environments (new seed projects added by an additive seed job; D3-14 decided on 5 October: add missing seeds, prefer preserving staging data, never production) and on new projects. Production pilots also need the prerequisites in §5.11 and D1-07; until those hold, R2–R4 pilots are staging and preview only.

How releases are accepted. Every release ships only against the written criteria in acceptance criteria: merge criteria on every PR, activation criteria on a recorded release candidate, its own criteria and the UI standard, scaled by its tier. Every new and updated screen is consistent, modern and built with Material 3 (UI1).

Decisions so far (Chris, 3 October): the ownership-transfer fix, kept in #3964 over #3969 (D1-01; #3964 merged on 3 October 2026 as 85e6facf7 and #3969 is closed); the #3944 conversation changes (#3965); Batch A (Q-07, Q-08, Q-09, Q-13, Q-03a, Q-25, Q-31, Q-06a, with ASySD deduplication and reported external steps added as amendments K and L); published questions are never permanently deleted (QD1); Material 3 for new and updated screens (UI1); well-defined acceptance criteria (AC1); and, that evening, the rest of Batch D1 as recommended (D1-02 to D1-09: precedence with #3961, activating #3987's families, per-gate authorisation, merging this package to main, the tester panel, production opt-in pilots, the write-path gate and the notification merge order; see the decision register §1.13). Late that evening he gave the G0 inputs (decision register §1.14): Q-03 as recommended (the permission matrix, with each new capability shipping with its feature); the tester names (D1-06; no external SyRF users named yet); #3987's activation from 5 October 2026, staging first and production the following week as a target (D1-03); and D4-18, "independent of funders", whose recorded reading is PROPOSAL until he confirms it in the G0 dossier. Step 0 (D1-05) merged on 3 October 2026 (f5318074d). Parts still open: F1a confirms D1-08's start thresholds from M0 evidence; restacking #3965 onto #3944 (D1-09) depends on the stack owner agreeing. G0 itself, Chris's approval of the G0 dossier, has not happened. On 4 and 5 October Chris's owner session decided most of what remained (above), and on 5 October he put feature implementation on hold.

Still open before the owner session (89 owner decisions, historical count): Batch B (13; Q-03 is answered), Batch C (15) and Batch D from round 2 (71 questions; the nine D1 questions and D4-18 are decided, so 61 are open: D2-01 to D2-16, D3-01 to D3-25, D4-01 to D4-17 and D4-19 to D4-21). See open questions.

After the owner session (5 October), within the same 89: 63 are resolved, replaced, removed or deferred; 25 are alignment, brief, specialist or engineering-contract entries settled in briefs; one owner decision is open (D2-09). G0 items, the hold lift and the owner-session amendments sit outside the 89. §11 gives the breakdown.

2. Confirmed invariants this plan must never break

These come from the owner ledger, for 11 and 12 from Chris's review of this package on 3 October, and for 13 to 18 from the owner session of 4–5 October (consolidation). Every ship gate checks the ones it touches.

1. Forms own evidence; stages own workflow. One reviewer-owned study/form session across stages, one contribution per reviewer, form-owned minimum target (SF1, SF2, SF4). The standard reviewer target is part of the immutable form version (OS-A12); no stage or step sets it.
2. Latest explicit Save or Complete is current. Autosave is a draft. Prior versions are immutable and never counted twice (SL1–SL3, SF6). A publication may create attributable generated session versions (D2-01 amended); one never records an invalid Complete and never overwrites a newer reviewer version.
3. Within a stage, own Include opens dependent steps, subject to a collective-Exclude veto. Across stages, Collective Include is required by default, with an advanced own-Include option that keeps the veto. Strict within-stage collective mode is a proposal only (DP6, DP7). Superseded (5 October) in its cross-stage part and its strict-mode part. A stage's study filter defines its pool, and no stage-entry gate exists (Q-15 replaced). Dependencies are between steps inside a stage. Exclusion-stop is a separate step setting. Own Include is the default progression, and a stage setting can require collective Include (Q-01, decided). "Pending" never ignores an eventual Exclude.
4. PRISMA reports the collective authoritative outcome. A collective Excluded stays Excluded even when extra extraction evidence exists; that evidence and its provenance are preserved (PR1).
5. One versioned outcome-measure direction across cohorts, with no context override (ODIR1).
6. Adding a question creates a new form version. Publication checks sessions under every prior version, requires a recorded admin choice and needs current usage statistics at a protected boundary (FV1–FV3, PS1–PS3). Changing the standard target also creates a new form version and goes through the same impact process (OS-A12).
7. Reconciliation acceptance: final submission accepts the displayed valid answers including prefill; autofill is marked; unseen controls warn; Complete anyway is allowed; validity is enforced; no per-field confirmation; no majority-derived gold (RE2, SF4). This reconciler prefill is unchanged. Reviewers never get reconciled answers prefilled: they see labelled hints and copy one only by an explicit click, which is recorded (OS-A04).
8. Gold is an immutable snapshot. Queries never take gold out of effect until a valid replacement exists (GS1, QY1–QY3).
9. No fabricated history, votes, versions or reasons, including during migration (EX2, research §5). Baseline conversion labels missing history with named legacy-gap states, and the absence of a history record never invents a reason for non-review.
10. Possessing a capability is not administering it. Ownership transfer stays owner-only (PM1, PM2). Assignments never override reconciler eligibility (RA1–RA2), and notifications show details only under fresh authority checks, so neither grants access.
11. A published question is never permanently deleted; it is retired in a new version (QD1, Chris, 3 October).
12. New and updated screens are consistent, modern and built with Material 3, meeting the UI standard in acceptance criteria §3 (UI1, Chris, 3 October).
13. Existing accepted or dependent work is never silently rewritten. The actor is warned before commit about affected work, affected authors are informed, and a new result version comes only from the rule or person entitled to create it (Q-27; consolidation §1 and §4).
14. A duplicate merge yields one consolidated current Study. The commit is atomic, the originals stay as immutable history, and an unmerge reverses it without erasing the merge (D2-12 replaced; consolidation §2).
15. Current pools are calculated from current evidence; history is recorded. Structured history events are immutable and never decide current access. Leaving a pool never erases the evidence that caused it (consolidation §3).
16. Blinding belongs to the form or the screening profile. Candidates are blinded by default, in an unpredictable order, with no alias continuity across Studies. Assignments, browsing and notifications never grant broader rights (consolidation §4; Q-30).
17. One writable engine in the end. Every project converts to a faithful baseline that keeps its workflow semantics. Legacy writers retire only at their own verified milestone (consolidation §5).
18. Full annotation works on phones, tablets and desktops at launch, including the largest project (D3-05; D2-16 replaced).

3. Where the work starts from

This summarises the verified baseline. Full evidence, PR states and the prototype asset inventory are in the source and status inventory.

Almost none of the confirmed model exists in code yet (CODE-MAIN):

• Questions are mutable and embedded in the Project document. Editing applies immediately; deleting a question hard-deletes every answer to it (#3088). System questions are rebuilt from code on every read, and their structure varies with Project.SystemQuestionVersion.
• There are no question, form, session or answer versions anywhere.
• Sessions are per (study, stage, reviewer, reconciliation flag). Answers are already shared by reviewer + question across stages, so a save in one stage silently changes what another stage's session shows. A reviewer can hard-delete their session and all its answers.
• There are no server drafts, and required answers aren't enforced on the server.
• Screening is one decision per reviewer per project under a project-wide threshold. Profiles, eligibility questions, exclusion reasons, screeningOutcomes[] and study lifecycle exist only in documents.
• Stages are three flat modes plus an Active switch; there are no steps or completion state.
• Reconciliation is a legacy shared, overwritten session per study and stage. Its route renders read-only candidate cards, two per row, with no reconciler form; AF2's reconcile host is read-only by rule. Reconciliation reserves nothing.
• Claims, capacity guards and typed admission exist only when active reviewer tracking is on (ActiveReviewerTrackingEnabled && SignalRActive). Tracking is off in every deployed environment and on in the E2E stack, so production saves are unguarded and EnforceAnnotationTarget does nothing there. Reconciliation is excluded at every tracking layer. Turning tracking on is a FEAT-024 durable reviewer-mode transition whose code (M15, AdvanceModeEpochAsync) has no caller (programme integration §6).
• Outcome direction is a per-reviewer bool answer, default false, copied onto rows; there is no measure entity and no event-count shape.
• Only the built-in Administrator group exists, and ownership transfer isn't enforced as owner-only at the evidence baseline (#3964, which fixes this, merged on 3 October 2026 after it).
• Exports are current-state only. There is no PRISMA, Citation or deduplication code. Search and project deletion routes currently fail closed until a separately owned reversible-deletion scheduler exists.
• Study's embedded value objects (ScreeningInfo, ExtractionInfo, SessionTally) use strict class maps, so an older binary throws on new embedded fields rather than ignoring them.

What exists and must be extended, not duplicated:

• AF2 and the reviewer workspace: merged but default-off everywhere except staging; production has only ever used AF1, and the annotationFormV2 flag applies to a whole environment. AF2 doesn't render screening-only stages.
• The new Design/Assign/Preview question editor, on the legacy API; all default entry points still lead to the old editor.
• The review-eligibility programme's admission machinery: typed claims, a claim-revocation outbox, guarded settings and the D7 grouped configuration. It is flagged off, its flag reaches the API host only, the browser doesn't consume it yet, and the programme is paused (since 25 September, per session memory; the repository does not record the pause).
• FEAT-024 statistics: fold slices 0–7 merged and dark; gate (b) failed on latency in the idle-host rerun (Bramble, 3 October 2026, 22:38–23:01 UTC; zero statistics-caused conflicts; #3510), and the soak has not started; enabling fold mode on the production database is refused in code. Staging now pins the fold flag on for both hosts (a project still needs an explicit admin enable).
• The allocation MVP (dark; reviewer validity blocked on #3251; never accepted by a human), reviewer presence and claims (never enabled in a deployed environment) and bulk-update study locks.
• A working group×activity permissions dialog, currently used only for chart visibility, and the authorization programme's plan for group administration (#3335 WP9/WP11).
• The notification stack: eight open, unmerged, stacked PRs, plus #3965 with Chris's Q-10 changes (open and ready, 10 commits pushed, stacked on #3947 and waiting for the stack, D1-09); the stack's E2E specs have never run in CI.
• The architecture review (#3961): a parallel programme whose persistence, messaging, flag-provider and statistics decisions change foundations this plan freezes at F1a (programme integration §10).

Consequences this plan accounts for:

• A compatibility floor (R0) must ship before any canonical write, so rolling deploys and image rollbacks are safe.
• Production pilots depend on several environment-wide flags owned by other programmes (§5.11).
• R1c group management depends on the authorization programme's schema and enforcement gates and on its WP9/WP11 work.
• R2c production publication follows Q-31: the materialised usage family once FEAT-024's production chain (X-STATS-b1–b7) completes; until then named pilots use authoritative counting at the protected boundary, which is therefore designed as the first pilot path.
• Production claims and capacity promises need X-CLAIMS, and R4a needs the reconciliation-task editor claim (X-RECLAIM) in every environment.
• The Study canonical summary (Study.CanonicalSummary) carries per-reviewer membership facts, not only tallies, and R0's floor includes reader logic (consistency model §3.3).
• R3a must carry the eligibility decisions into the step model explicitly (Q-24, decided on 4 October: legacy stages map to steps through the opt-in wizard).
• Every project eventually converts to the new engine (consolidation §5), so every legacy writer and reader needs a canonical replacement before R7.
• R4a must replace, not wrap, the legacy reconciliation session, and needs a new editable AF2 reconcile host.

• 3944 needs changes before its conversations are enabled (Q-10).

4. Workstreams (lanes)

The new aggregates each lane builds, and the changes to Project, Study and SystematicSearch, are set out in the domain model.

A lane is a scope responsibility, not a team or person (A-10). Several lanes extend existing programmes; there, this plan supplies contract amendments and join gates and doesn't take over their PRs. Delivery is organised by stream, not by lane. One accountable approver (Chris) and agent sessions deliver the programme through the five streams in the table after this one; each stream has a brief and a stream-lead session, and implementer and fresh-verifier sessions work slice by slice (delivery operating model §2). The "Signs contract changes" column names the programme whose rules a change must satisfy: a fresh-context agent runs that programme's checklist against its rules file, and Chris rules on the exceptions (§2.5 there). Chris alone signs.

Lane	Mission	Main contracts	Existing programmes/PRs it must extend	Signs contract changes
L0 Integration	Contract registry, ADRs, compatibility floor, admission service, gates, PR dispositions	C16, all	All	Chris (G0, ship gates)
L1 Engine	Annotation identity/revisions/commands, context, provenance, drafts, session lifecycle, Study.CanonicalSummary, legacy adapters	C1, C2, C3, C5, C18, C19	AF2 persistence; QM v2 domain (#2572, harvest per Q-08); bulk-update study locks (#3909)	FEAT-024, presence and AF2 owners for their seams
L2 Definitions	Question/form/profile definitions and versions, library and import, publication and impact, shared editor	C4, C8	Question designer; #3934/#2781 import; #2387; QM v2 #2572–#2575	FEAT-024 owner (C8)
L3 Screening profiles	Canonical screening decisions, profile versions, derived decisions, reasons, collective outcomes, compatibility profile	C1 (kind), C4	Screening settings; #2621 prototypes (reference)	Eligibility owner
L4 Workflow	Stage settings versions, steps, dependencies, routing, admission, lifecycle	C6	ReviewEligibilityPolicy and the eligibility programme (#3746, #3742, #3741; D7 configuration); #3939 ProgressiveBatchCompletion	Eligibility and batch owners
L5 Reviewer workspace	AF2/stage-review changes: drafts, versions, history, needs updating, Fix, steps, screening renderer, population context, reconcile host	C5, C6, C9, C13, C17	AF2 programme PRs (#3546, #3543 and others); Dockview layouts	AF2 and layouts owners
L6 Reconciliation	Task, pool, assignments, matching, gold snapshots, extra review, queries, outcome reconciliation, clarification threads	C9	stage-reconcile host; #3944 (Q-10)	AF2 owner (host); notification owner (#3944)
L7 Operations	Statistics derivations, usage evidence, claims, allocation, batches	C7, C8	FEAT-024 (fold slices 0–7, #3955 and #3956 merged); allocation (#3327); presence; batches (#3936/#3939)	Each programme owner
L8 Permissions	Capabilities, groups, delegation, disclosure policy	C10	Authorization programme #3335 (WP9, WP11, WP-M1/M2); #2224; ResourceSecurity catalogue	Authorization owner; #2224 author
L9 Classification	Entity types/capabilities, populations, relationships, concepts, rules, inference, counts	C13	Annotation categories; classification research	—
L10 Outcomes	Outcome schemas, measures, observations, entry, outcome migration	C14	AF2 outcome matrix/dialog/spreadsheet; outcome export writer	AF2 owner
L11 History	Current/previous/as-of exports, manifests, agreement statistics	C11	Data export; #2461/#2574 reserved modes; #3243 export authorization	—
L12 PRISMA	Identification provenance, deduplication, profile outcomes, pool entry, reasons coverage, report snapshots (PrismaFlowSnapshot), amendments A–P	C12	FEAT-011 package; FEAT-012 dedup spec; Study Management searches; deletion-lifecycle and PDF programmes	FEAT-011 change policy
L13 Setup	Library, initial form, profile templates, replacement guided setup	C4, C17	CreateProjectWizard/ProjectSetup; FEAT-014 (Draft)	—
L14 Notifications	Review-workflow events through the existing notification stack	C15	#3932–#3947 stack (owners unchanged)	Notification owner
L15 Adoption	Writer/reader convergence, per-project adoption, retirement	C16	All writers incl. imports, bulk update, batch RoB, deletion scheduler	Chris (per wave)
L16 Admin UX	IA, coexistence, overviews and settings, Members & groups pages, terminology, design-system consistency	C17	Project/stage overview SignalStores (#3776–#3795); M3 navigation; #2469	Navigation owner
L17 Acceptance	Fixtures, conformance suites, E2E journeys, accessibility, pilot and user testing	All	e2e stack; staging for humans	—

Owner-session scope by lane (PROPOSAL, 5 October). The nine specifications fit the existing lanes; the rollout plan fixes the placement and the implementation tracker holds one brief row per specification. Review domain and versioning (T-RD-00): L1 and L2. Duplicate merge (T-DM-00): L12 with L1. Stage pools, steps and history (T-SP-00): L4, with L7 for capacity and L11 for history queries. Reconciliation and screening (T-RS-00): L6 and L3. Baseline conversion and recovery (T-BC-00): L15. Training and the inference beta (T-TI-00): L4 and L8 for training and group admission, L9 for inference. Reporting, imports and AI screening (T-RI-00): L12, L11 and L3. UX, devices and work discovery (T-UX-00): L5 and L16. Access, catalogue, communications and deletion (T-AC-00): L8, L2 for the catalogue, L14 and L15. The design-prototype handoff (T-DH-00) is an input to L16 and L5. New contracts: C20 structured history events (L4 and L11), C21 duplicate consolidation and reversal (L12) and C22 external and AI-model screening sources (L3 and L12). New lanes: TR1 training, XS1 external and AI-model screening, XA1 annotation-answer imports, RW1 redesign wizard, the PWA1 exploration and the deferred BR1.

Lanes and delivery streams.

Stream	Lanes	Leads
A Engine and definitions	L0 (compatibility floor and enrolment service), L1, L2, L13	S0 engine slices, M0, R0, R1a, R2a backend, R2c, R2d, R3d
B Workflow, profiles and operations	L3, L4, L7	R2b, R3a, R3b, R3c, AL1
C Reviewer workspace and admin UX (sole writer of the AF2 and stage-review shell files)	L5, L16	F1c seams, R1b, the reviewer UI slices of every release, admin and coexistence screens
D Reconciliation, history and notifications	L6, L11, L14	R4a, R4p, R4b, R4c, R5a, R5c
E PRISMA, classification and outcomes	L9, L10, L12	P1, P2, R5b, C1, C2, O1, O2
Cross-cutting roles	L8 permissions, L15 adoption, L17 acceptance; L0's gate and registry work belongs to the programme lead session	R1c, R1d, R6, R7, S0 acceptance tooling

Lanes are delivery roles; the bounded contexts they build in are fixed in the domain model §2: L1 Evidence, L2 Review Design, L3 Screening Outcomes, L4 Review Workflow, L6 Reconciliation and Accepted Answers, L8 Membership and Permissions, L9 Classification, L10 Review Design (outcome schemas), L11 and L12 Reporting and Identification, L0 and L15 Platform and Coexistence. A change to a shared-kernel type or another context's contract is an ADR amendment with consumer sign-off; the F1a fitness tests enforce the map.

5. Releases and milestones

Each release states its user value, MVP boundary, acceptance criteria and shortest critical path. The acceptance bullets here summarise; the authoritative, numbered criteria are in acceptance criteria, with how each is verified. Each criterion carries its source and status; a row that waits on a question, a PROPOSAL threshold or an external join can't pass until that clears. Each release ships behind server-authoritative flags (default off) with an explicit flag decision, and admission per project through R0's admission service. Adoption and rollback per release are in migration, adoption and rollback §5. Every ship gate also applies the common checklist in §6.2.

5.1 M0 Engine proof walking skeleton (engineering milestone, not a release)

• Boundary: a walking-skeleton proof that OrdinaryAnswer and ScreeningDecision share identity, revisions, context, commands, CAS and the command ledger through one logical repository, with Study.CanonicalSummary, per-study ordering with hybrid logical clock (HLC) stamps, the composite write guard and one fenced definition change. No interactive command writes a per-project document. It produces the storage ADR (E15) with the summary-versus-stub decision (E48), the C18 and C19 ADRs (E46, E47), the writer and reader inventory (every UpdateMany on pmStudy, the tracking and notification-stack writers), the compatibility-floor design (C16), and the AF2 adapter and drafts design. The skeleton's end-to-end scope and its go/no-go thresholds are in the delivery operating model §4. Owner-session amendment (5 October). The drafts design follows the decided D2-07 and D2-08: a diff-based draft change log with base-version checks, one shared session and place across tabs and devices, and a form-owned inactivity timeout (review domain specification). The single-writer draft lease is Superseded (5 October); the brief may keep a take-over presentation for small screens. The writer and reader inventory now covers every project, because every project converts (consolidation §5).
• Acceptance: the screening research's cases A1, A3, A7, A8, A11, A13, A14 and A20–A23 pass on synthetic fixtures. The canonical-commit benchmark arm (E56) runs ADR-019's cells (1, 2, 5 and 10 reviewers; same and different study; eligibility off and on; capture on; fold, claims and a sweep running) at the three fixture tiers and meets the D1-08 gate shape (AC-M0-02, AC-ALL-26, C18-T02), with a Project-document contention arm (DD-16). Failure injection (crash points, unknown commit, failover) passes C18-T01 and C18-T04 (AC-M0-06). The architecture fitness tests run in the F1a suite (AC-M0-08). The FEAT-024, presence and allocation owners' checklists pass on the C7 identity amendments and the claim contract, run by a fresh-context agent; Chris rules on exceptions. The C10 catalogue audit is done. The QM v2 harvest decision (Q-08) has been executed. If Chris authorises it, an aggregate-only survey of Study document sizes informs the storage ADR; otherwise benchmarks use the synthetic tiers, and the ADR says so.
• Critical path: storage, C18 and C19 ADR drafts → common command engine spike with the summary and the ledger → contention and failure-injection runs → conformance suite → owner checklists → F1a.

5.2 R0 — Compatibility floor and project admission (platform release)

• Why: an image rollback or rolling deploy must never meet canonical data it can't read, and no configuration change may hand a canonical scope back to legacy writers.
• MVP boundary:
• Capture, not ignore, on every embedded type the programme may extend, deployed one release before the first writer of new fields. No fields are added to ScreeningInfo, ExtractionInfo, SessionTally or StudyBulkUpdateLock, and none inside a persisted computed collection (consistency model §3.6).
• Reader floor: the SessionTallies getter and the claim pipeline merge the canonical summary's per-stage projection; the IReviewMembershipFacts seam and shared predicate fragments let pool, capacity and readiness checks read canonical membership; all inert until a canonical writer exists (§3.4 there).
• Ownership markers and guards: CanonicalScopes on Study and Project, checked in legacy aggregate methods and by a composite registered write guard (composed with the bulk-lock guard), project-wide pre-checks and the extended architecture test, for every writer in the inventory: API saves, PM consumers, Quartz jobs, imports, bulk update, reconciliation, session removal, question edit and delete, the inclusion recalculation and every other UpdateMany on pmStudy, preview seeding, import-failure compensation, bulk PDF finalisation, the tracking writers (hub, consumers, claim pipelines, typed admission) and the notification stack's Study writers. pmCanonicalOwnership stays the audited registry. Flags gate new enrolment only, never ownership.
• A server-authoritative per-project admission (enrolment) service, recorded as CanonicalEnrolment and read by both API and web, with an audited admin action to enrol or remove a project and a rule for enrolling new projects (by environment or creator), so pilots and the new setup wizard have one mechanism. It is never FEAT-024's statistics allowlist.
• Writer floor: canonical commands refuse while any registered API or PM instance runs below R0 (ServiceVersionFloor).
• Operational prerequisites: canonical collections and indexes created at start-up; new pmStudy indexes built through the operator route; notification capture available in PM.
• The minimum rollback image per service is recorded in each release ADR and rehearsed by an image rollback with canonical data present, not only by turning a flag off.
• Floor steps repeat before R2b (form claims), before R3a (screening aggregates), before P1 (Study root fields) and before C1 or O1 if they add embedded fields. Owner-session additions (5 October): a floor step before P2 adds the Study tombstone predicate, so every legacy writer refuses a tombstoned Study (duplicate merge specification); the composite write guard also honours the reversible project-deletion marker (access specification).
• Acceptance: an older binary reading documents with canonical fields neither throws nor strips them, and in a mixed fleet every persisted computed field and tally equals an authoritative recount; a legacy write to a canonical scope is refused and changes nothing, with or without a transaction; removing a project from enrolment doesn't route its canonical scope to legacy writers; canonical commands refuse below the writer floor; an image rollback to the recorded minimum passes with canonical data present; all flags off behaves identically.
• Critical path: writer and reader inventory (M0) → capture on extended types → reader floor → markers, composite guard and architecture test → enrolment service and writer floor → staging rehearsal → R2a may write on staging; production promotion and soak → first production canonical write (delivery operating model §6.6).

5.3 R1 — Library, groups and permissions

R1a — Question library and import

• User value: admins reuse questions through reviewed template import and a library.
• MVP boundary: the new Design/Assign/Preview editor gains reviewed import and library reuse through the open #3934/#2781 contracts (preview, dependency remap, validation, transactional apply, rollback). Import is built behind an import-target port with a legacy adapter now and a canonical adapter later: R1a ships browse, preview and legacy apply, and canonical apply is an R2a slice, so the #3934/#2781 work is not plumbed twice (DS-20). It absorbs the legacy editor's filtered-options authoring, loses the shipped debug text, and gets its 17 CI-excluded specs back (#3655). It stays behind its flags. PROPOSAL: make it the default entry point once the coexistence design (C17) defines its two modes: legacy API for legacy projects, canonical for admitted projects from R2a. Legacy projects keep today's semantics. Templates follow D2-15 (PROPOSAL pending Chris): a CAMARADES-curated system catalogue administered by an application role, plus copying from a project the user administers; every import is a copy. R1a records copy provenance on the DefinitionTemplate aggregate's copy record, not as a new field on the Project's embedded question list, so R1a needs no floor step (V2-16).
• Owner-session amendments (5 October). D2-15 is decided-amended: one application-wide CAMARADES catalogue, administered under a system permission; authorised direct entry or project sharing creates versioned copies with source, version and sharer provenance; other users may request publication to the catalogue; copies and catalogue items never overwrite each other (access specification). Copying from a project the user administers, outside the catalogue, awaits confirmation in that specification's brief (its ambiguity B5). SYRCLE, CAMARADES and ARRIVE templates reach the catalogue only after methodologist curation (D4-06, specialist input T-SI-03). Collaborative question drafts with presence and live updates (OS-A01) are placed differently by two specifications: the review domain specification puts them in R2c, and the UX specification puts question-design presence with R1a and R2a. Recommendation: follow the review domain specification (single editor with base checks in R2a, presence and live updates in R2c), because R1a still writes through the legacy API; the rollout plan makes the same recommendation (R-AMB-04).
• Acceptance: import preview equals the applied result; parents and lookups are remapped; cross-project references are refused; a failed apply leaves no partial questions; the import flow can never delete questions; flags off behaves identically.
• Critical path: audit #3934/#2781 against C4 (both now conflicting) → rebase and split → library browse validation (U19) → staging acceptance → pilot.

R1b — Members & groups visibility and owner-only enforcement

• Entry criterion (security): the server enforces owner-only ownership transfer and refuses owner-reserved activities (ChangeOwner, AssignPermissions, Delete) in the project and stage permission-update endpoints, with the UI copy and user guide corrected in the same PR. Chris decided on 3 October to fix this now, independent of plan approval: #3964, with #3969's active-member check and tests ported into it, merged on 3 October 2026 (85e6facf7), and #3969 is closed (D1-01, decided and carried out).
• User value: one place shows every group, member and project/stage grant, and owner-only actions are genuinely owner-only.
• MVP boundary: a read-only Members & groups page over existing groups, members and project/stage grants (no schema dependency); the route guard typo fixed with a spec (the authorization programme's WP1d, coordinated with it). "Why can or can't I" explanations are the authorization programme's WP9 (after its WP3); they appear on this page when WP9 lands (join X-AUTH-WP9), without blocking R1b. The generalised permissions dialog and the retirement of the mock stage-permissions page are that programme's WP11, which it gates on its schema gate, so they belong to R1c. PROPOSAL: ask #3335 to split WP11, so a dialog over existing groups (no schema dependency) can land with R1b.
• Acceptance: an administrator who isn't the owner can't transfer ownership; no endpoint grants an owner-reserved activity; the page shows exactly the grants the server enforces, in a contract test against the active decision path; revoked access fails on the next request; flags off behaves identically. Once WP9 lands, explanations equal enforcement decisions.
• Owner-session amendments (5 October, placement PROPOSAL). Ordinary account deletion disables access and keeps named attribution on submitted work (D2-14 amended); the join and invitation screens explain contribution retention after legal review of the wording. Disabling a membership keeps the member's contributions valid (D4-20 amended). An identity-erasure process is not decided (T-POL-02).

R1c — Configurable groups and the permissions dialog

• Entry: the authorization programme's gates. X-AUTH-SCHEMA is gate G-D in the handover plan for #3335 (handover/2026-09-08-authorization-3335/PLAN.md): membership schema 1 applied and verified in production, after its migration runner WP-M1 and WP-M2. X-AUTH-ENFORCE is the authority-transition plan's M6 staged cutover to the enforced evaluator (its gate G-C) in the target environment. If legacy-path decisions are acceptable instead of that cutover, parity tests must show custom-group grants decide identically in the legacy and evaluator paths. Also WP9 (X-AUTH-WP9), Q-03a, and agreement with #2224's author (Q-09).
• MVP boundary: delivered jointly with the authorization programme as its WP11. The generalised group×activity dialog covers every project and stage activity, with owner-reserved activities hidden; the mock stage-permissions page and stagePermissionsConfigurable retire; group create, edit and delete and member assignment reuse #2224's API shape and tests (the authorization plan's D10 says not to merge it as is). Custom groups get project and stage grants. Effective Review-grant changes go through #3941's reviewAccessGranted capture with bulk fan-out limits, not a new path. Audit uses the authorization programme's authorizationAudit.
• Acceptance: a membership editor can't add themselves or anyone else to a group whose grants exceed what the editor may administer; ChangeOwner is never grantable; AssignPermissions is grantable only through R1d's envelope (PM2); Delete follows Q-03; holding a grant doesn't allow assigning it; access notices come from the existing capture.

R1d — Delegated permission administration

• MVP boundary: owner-granted permission administration (PM2) inside a delegation envelope, with non-recursive delegation (approved with Q-03 on 3 October) and the existing audit store.
• Entry: R1c; Q-03 (answered on 3 October).

Reviewer design parity is the AF2 programme's work, not a release of this plan. It is a join with an exit set named with the AF2 owner (§8).

5.4 R2 — Versioned forms and shared sessions

R2a — Versioned forms and immutable sessions (one stage per form)

• User value: work is never lost or silently changed. Drafts are kept; Save and Complete create immutable versions; the history is visible; Complete is validated on the server; previous versions can be downloaded.
• MVP boundary (admitted greenfield and pilot projects):
• Engine (C1–C3, C5, C18, C19): one logical repository with CAS, the canonical command ledger (E50; one idempotency authority) and ordering by per-aggregate versions plus the HLC stamp, with no per-project document in the transaction (CR-2; consistency model §5 and §11), real-actor and on-behalf-of provenance (support impersonation can write as a reviewer today), server-minted or validated identities, and an explicit ceiling in pins and bytes (D2-16) until large immutable submissions are proven. (Superseded (5 October): D2-16 is replaced. Limits are engineered for the largest project, which is an acceptance case; no project is excluded for size.)
• Definitions (C4): question identity plus content versions with a compatibility declaration per version and stable option IDs; system question versions stored as data and pinned by (guid, SystemQuestionVersion, seq); forms composed from project questions with ancestors included automatically and composition validated against the pinned parent versions; AF2 renderability checked at publication; a form target and other operational settings outside the requirement version (D2-05; Superseded (5 October) for the target: the standard reviewer target and the ReconciliationPolicy sit inside the immutable form version, OS-A12, and every other setting is classified in the brief); v1 published and bound to one stage through the StageSettingsVersion envelope frozen at F1a (bindings, a step list holding one implicit step, policy slots), so R3a adds step semantics without migrating pilot data (PV2, D2-04; DS-21). An unpublished requirement version can change; a published one never changes (A-14).
• Reviewer form (L5 on AF2): autosaved drafts under the drafts contract (stored outside Study; one draft record per session with lease, etag and conflict copies; audited discard; no TTL; never shown to reconcilers or exports; D2-07 for whether a draft holds a place), recorded by ADR because the AF2 rules forbid implicit per-answer server saves. (Superseded (5 October) for the lease and the D2-07 question: autosave sends diffs with base-version checks into a reconstructable draft change log; one shared session across tabs and devices; the form owns the inactivity timeout, and expiry keeps the draft. D2-07 and D2-08 are decided.) Save creates an immutable incomplete version; Complete a validated immutable version; the latest explicit version is current (SL1–SL3). A history panel shows earlier versions. Presentation state such as entity order is stored outside immutable versions and never affects qualification.
• Reviewer-facing UX (L5, L16): the save-status state machine (Saving, Kept, Retrying, Offline kept on this device, Failed) with a bounded local copy and the conflict and take-over screens (E82; pending D2-07, D2-08; now decided, with the states renamed so "Draft auto-saved", "Version checkpoint saved" and completion stay distinct, OS-A21, and the local copy subject to the UX specification's ambiguity A1 because no offline writes are authorised); live completeness on the form host and the input-latency budget under autosave (E87); the "What changed" panel keyed by change bundle with per-user dismissal, and contextual help links through the user-guide URL pipe on every new screen (E84); the readiness-based setup checklist content (U39); the workflow version badge and the read-only containment banner (E86). Copy comes from the F1c copy deck.
• Server validation: Complete checks required applicable answers using one applicability specification and shared fixtures run by both the .NET validator and AF2, with typed errors naming the blocking question. Harvest the dormant validation PR #2986.
• No hard deletes: canonical sessions can't be deleted; "Remove all annotations" becomes an explicit versioned clear or a draft discard; withdrawal is an append-only transition. A question that has been published can never be permanently deleted; it is retired in a new version (QD1). Only an unpublished draft question can be deleted.
• Study coupling: each canonical commit writes its Study (per-study serialisation): the canonical summary legacy readers need through R0's floor (pool filters, capacity, readiness, statistics, exports), the version bump, and the FEAT-024 part through the source-write seam. It conflicts correctly with bulk-update locks.
• Exports: current answers and previous session versions, under the export disclosure contract (C10/C11).
• Coexistence: for canonical forms, the per-stage target override (#3732) and live question locks become legacy-only. Legacy reconciliation and reconciled-answer writes refuse canonical forms until R4a, through R0's ownership markers.
• History capture from first enrolment: legacy screening writes in enrolled projects are captured inside the Study write (a bounded log moved out by a worker into the LegacyWriteLedger), with one test per named writer, so R3a and R6 can use them.
• Excluded until later: quantitative extraction (Stage.Extraction, OutcomeData) is refused on canonical forms until O1. Two forms can't use the same entity category, because they would share its answerable label question (A-19); R2d lifts this.
• Entry: backend slices at F1a; export slices at F1b (the export disclosure contract); UI slices at F1c (the AF2 extension points merged as code, the Dockview layout-contract amendment for the new history panel, the copy contract). It ships once R0's staging rehearsal has passed; production pilots also need R0's production soak, the AF2 and shell per-project admission slices and D1-07. R2a doesn't wait for F2 or F3.
• Acceptance:
• Autosave leaves status unchanged; Save after Complete removes qualification; Complete restores one contribution; every version stays readable.
• A stale base is rejected with a typed conflict that keeps the draft; a retried command returns the original receipt.
• Complete refuses a missing required applicable answer and never requires a question hidden by a condition (shared conformance fixtures).
• Two tabs editing one session: the second is read-only with "Take over editing"; a non-holder's edits are kept as a conflict copy; a stale autosave after a newer explicit version is rejected; discard is audited; drafts never appear in exports or to reconcilers. (Superseded (5 October) for the read-only second tab: two tabs or devices edit one shared session with base-version checks, and an edit from a stale base yields a recoverable conflict, D2-08.)
• Exports return current and previous versions with per-cell question version, class and option IDs; a previous-version export equals the session version's full pin map; unmasking follows the disclosure contract.
• Legacy reconciliation, session removal and question deletion refuse canonical scopes; legacy readers see correct tallies through Study.CanonicalSummary, merged by R0's floor.
• A support edit-mode write records the real actor, is flagged, and is excluded from independence statistics.
• FX-PRISMA-02a and 04a (single-stage forms).
• Capability tests (positive, negative, revocation) for every new endpoint, each catalogued.
• Legacy projects and flags-off behaviour are unchanged.
• Composing a form with a dangling child condition is refused naming the question. (Compatibility declaration and option-ID validity are accepted in R2c, AC-R2c-21 and AC-R2c-22.)
• The append-only architecture test is green; digests verify on read-back; the collection-name map test passes; the integrity checker reports zero findings on seeds and detects an injected dangling reference per invariant.
• A session pinned to v1 renders v1 through the versioned AF2 data source; a form AF2 cannot render is refused at publication; no canonical route falls back to AF1.
• Unit delete is a withdrawal commit; rename keeps identity; duplicate mints new IDs with provenance; suppressed descendants survive Save and Complete.
• Critical path: F1a → R0 staging rehearsal → engine commands and storage → definitions → AF2 adapter on the F1c seams (drafts ADR, Save/Complete, history) → validation conformance → exports (F1b) → acceptance on a recorded release candidate → staging pilot.
• Pilot and user testing: reviewer-state, forms and history prototypes (U13–U15) before build; synthetic journeys; staging sessions with CAMARADES testers (build a form, review, correct, download versions). Exit: zero lost work, every invariant fixture passes, and testers can say which version is current and why.
• Owner-session amendments (5 October). From the review domain, UX, access and stage pools specifications:
• The form version carries standardTarget and ReconciliationPolicy from the first canonical form, so no settings-only target path ever exists (OS-A12; RD §10). The policy fields are inert until R4a.
• Autosave writes a diff-based draft change log that rebuilds the draft exactly; Save creates a version checkpoint, which may be incomplete; a Save after Complete warns the reviewer about dependent work first (Q-27).
• Full annotation works at 390 px with touch on the largest-project shape, with whole-form validation and virtual scrolling (D3-05; UX §10). The largest project (2,023 questions) is an acceptance case at the max tier (D2-16 replaced).
• Contribution exclusion at form scope behind a new default-off flag, with preview, reason, actor and time (OS-A24; placement PROPOSAL).
• The canonical parts of reversible project deletion (claims and drafts) land here (OS-A25; placement PROPOSAL).
• ReviewStartEligibility could start here for pilot coverage; the rollout plan recommends R3a (R-AMB-05), with R2a pilot starts reconstructable from session versions and route provenance.

R2b — Shared sessions across stages

• User value: one session per study and form, whichever stage it is opened from, counted once.
• MVP boundary: bind the form to several stages, each recording the bound version and time (PV2; D2-04): the live route presents the session's resolved version, and a Completed stage's binding is frozen for display and readiness only. Claims are re-keyed to study + form + reviewer with route-stage provenance (E18, with the presence owner's checklist passing). Tallies are derived once per form and projected per bound stage (C7). Reviewer progress lists (my studies, incomplete studies, the no-work page, StageReviewerProgressStore) stay consistent across stages. Proportional allocation stays refused on every canonical stage, whether its form is bound to one stage or several, from R0 (the E65 guard) until AL1 (assumption A-09; D3-13a).
• Acceptance: form F (target 2) bound to stages A and B: Alice reaches one session from both and counts once; a session saved through A appears in B without double counting; two stage tabs reuse one claim; FX-PRISMA-02b (one form in two stages).
• Owner-session amendments (5 October). One place per reviewer per Study and form across stages, tabs and devices; the form owns the inactivity timeout and per-reviewer in-progress limit; one idle tab never releases the place while another connection is active; expiry keeps the draft (D2-07, D2-08, Q-28). Capacity caps are separate from targets, off by default (proposed), and a stage may only be stricter (D3-17, D3-18 brief items; stage pools specification). Production enforcement still needs X-CLAIMS through the D3-16 route.

R2c — Publication with impact

• User value: forms can evolve without corrupting earlier work, and admins can predict and choose the impact.
• MVP boundary: publishing v2 or later shows impact across all prior versions and all bound stages for completed, saved-incomplete and draft-only sessions (FV2, FV3) with the per-question vocabulary added, removed, changedCompatible, changedIncompatible and mapped (Q-34), the recovered requireReanswer/autoUpdate/doNothing choices (autoUpdate only within a compatibility class for valid answers), the counting choice for sessions left pinned, and the system suggestion (U6, FEAT-003's four steps). Invalidated answers stay visible as Needs updating with optional reasons (VU1–VU3). Publication writes no evidence (D2-01): (Superseded (5 October): D2-01 is amended, and publication may create attributable generated session versions that record the chosen treatment; see the amendments below) phase 1 is O(1) (fence, drain, digest re-check, CAS the form head, record the policy and the operation); phase 2 is an operation that rewrites query-path projections by predicate until clean, writes Q-34 mapping revisions if any, and captures notices; session standing is derived on read by canonical readers; admission and readiness for the form pause while phase 2 runs (D2-10); the impact manifest is an audit snapshot built after commit. One active publication per form (D2-11). A late Save based on v1 is accepted pinned to v1 and never rebased; the reviewer's Upgrade pins v2 with unchanged answers. Usage evidence follows Q-31 (PS1–PS3) with draft_only counted from drafts (MS-03). Reviewers see Needs updating in the form itself; notices go through C15, once per recipient per publication.
• Acceptance: publishing F v2 with sessions under v1 lists all three categories with counts matching authoritative records; the choice is recorded and takes effect by derivation; added required and removed questions carry their own treatments; Needs updating blocks Complete until valid; a missing reason warns; stale usage evidence blocks publication until refreshed; a Save racing phase 1 is accepted pinned to its declared version and swept by the predicate; publication writes no session versions and no revisions, and phase-1 time is flat across 1k, 10k and 100k sessions; a second publish on an active form is refused; FV4 appends a policy generation and restores counting without touching versions or work; deploying a new system-question version prompts no admin; compatibility is declared per question version when committed, immutable once pinned, with classes transitive (three-version chain fixture; AC-R2c-21); renaming an option keeps answers valid and retiring one does not (AC-R2c-22); FX-PRISMA-04b. (Superseded (5 October): "writes no session versions" becomes the generated-version rule, checked by RD-AE16 and RD-AE18; phase-1 time stays flat; the publisher's compatibility declaration is immutable from commit, RD-AE14.)
• Owner-session amendments (5 October) (review domain specification):
• Generated session versions follow the specification's generation table; each is attributed to the publication and the publishing admin, never records an invalid Complete, replays idempotently and never overwrites a newer reviewer version. Reviewers' drafts are kept, and non-overlapping draft edits rebase onto the new version.
• A target-only change is a publication with an impact preview (OS-A12). Study target overrides keep their own immutable history, and publishing a new standard target lists every override with its treatment.
• The publisher explicitly declares compatibility and whether mapping applies; SyRF only suggests a default (Q-34, D2-02 amended). One publication per form at a time, with a final recheck (D2-11). Admins see the impact first; affected reviewers get one notice per publication; a reviewer's own edits give in-form warnings only (Q-20).
• Collaborative design drafts with presence, live updates, safe conflicts and audit stamps (OS-A01; see the R1a placement note).
• Publication active-work protection is tested, and its pause and operation limits are measured (D2-10, brief item); the 90-second and 30-minute figures are proposed, not approved.
• The shared active-work impact preview first appears here (UX and access specifications).
• Critical path: F2 (C4 publication and C8 frozen; Q-31 answered; FEAT-024 checklist passed) → usage family → publication command → impact dialog (U6) → acceptance → pilot.

R2d — Overlapping forms, outdated flags, Fix and requirement revision

• MVP boundary: lift the one-form-per-category constraint. Share compatible same-context answers across forms through one head per context and compatibility class (SF3; C2). Show own prior answers and ancestors across forms, including earlier classes read-only (SF5). Flag the reviewer's other sessions pinning superseded revisions "contains outdated annotations"; two forms on incompatible versions of one question never flag each other. Fix explicitly creates a current incomplete version and opens that session's form; Upgrade pins the current form version with unchanged answers. Apply SF6 counting by derivation. Let an admin revise an unnecessary update requirement as a new policy generation with history (FV4, needs R2c). The eight per-answer states render and are explained (U13).
• Acceptance: the ledger's cross-form reuse list; FV4 preserves versions, transitions and work and never changes a compatibility declaration; a warning alone keeps a Complete counting while a requireReanswer policy removes qualification by derivation (SF6); two forms under one entity category share its label answer with lineage shown; two forms on incompatible versions never flag each other; a v2-only option never appears under v1; Fix shows the in-class current revision; a draft in form G based on a revision changed through form F gets a typed stale-base conflict that keeps the draft.
• Owner-session amendments (5 October). Guided correction of a publication: a mistaken compatibility declaration is corrected by a recorded rollback and a new publication, never by editing the declaration (D2-02 amended). The outdated-answer mode is configurable on the form: warn and allow Complete (the default) or require flagged answers to be addressed first (D4-17). D2-09, accepted answers to a question shared by two forms, is the one open owner decision; FX-VM-45 runs both options until Chris answers.

5.5 R3 — Workflow, profiles, lifecycle and setup

R3a — Steps, routing and canonical screening decisions

• User value: a screening-to-extraction workflow inside one project: own Include opens dependent steps within a stage, and Collective Include gates the next stage by default. (Superseded (5 October) for the cross-stage part: each stage's study filter defines its pool; there is no stage-entry gate; Q-15 is replaced.)
• MVP boundary:
• Decisions: screening decisions become canonical (C1's ScreeningDecision kind) under one default project profile with no eligibility questions. Its collective rule reproduces the project threshold. Decisions are never overwritten. The legacy screening writes captured in the LegacyWriteLedger from R2a are consumed.
• Steps: stage settings versions (on the canonical Stage aggregate) with steps (screening, form or both), dependency edges with AND/OR groups, compulsory/handoff/terminal scope, collective satisfaction, the DP6/DP7 policies, the EW1 default with per-step override, the VS1 and BL1 settings (defaults per Q-30), and atomic Complete-and-Include for combined steps. Navigation Skip records nothing (U2). (Superseded (5 October) for the DP6/DP7 cross-stage policies, which give way to the stage study filter, and for stage-owned VS1 and BL1: blinding belongs to the form or profile, and the form's hint baseline can only be hidden by a step, OS-A02, OS-A04.)
• Admission: one service extending ReviewEligibilityPolicy decides selection, reservation, direct access and submit, including the browser, which today ignores the eligibility response. The eligibility decisions carry over as Q-24 sets out (D3b for independent steps; D1/D2 as extra-vote admission; D4; D6; D5 and D7 unchanged). Stage-owned policies on shared work follow Q-28 (decided on 4 October: the form owns the timeout, the in-progress limit and the capacity baseline; a stage may only be stricter).
• Operations: claim, allocation and batch amendments (C7), joined with #3939; target-aware statistics replace the hard-coded "enough = 2".
• Pages and reviewer efficiency: the study selection preview ("Who is offered what"), mapped to the Monitor capability, whose holders may see personal votes, while reviewer-facing route warnings and messages never reveal them (OD5; V2-08; AC-R3a-09); the stage designer (U12); overviews and settings using C17 DTOs with freshness labels; the step strip (U7) and the keyboard screening path for the default profile (I include, E exclude, N skip, J jump, [ ] steps; at most two actions per decision; kbd hints render only once live) on the screening card, with the anchored tour component built here and reused later (E87, E84, U33, U35); phone screening for title and abstract steps pending D3-05 (decided on 4 October: full screening and annotation on phones, tablets and desktops at launch).
• PRISMA groundwork: per-profile outcomes and pool-entry records (StudyPoolLedger) in C12's write-shaping form, with "entering screening" defined by amendment A. (Superseded (5 October): StudyPoolLedger becomes HistoryEvent; StudyEnteredPool is renamed WorkFirstReleased, and StagePool* events record stage-pool membership separately.)
• Conflicts before R4p: conflicting decisions resolve through extra votes (D1/D2 Allow), as today. A pilot whose step uses Stop on a profile that feeds a cross-stage route waits for R4p (§5.10). (Since 5 October no cross-stage route exists; a pilot whose stage filter reads a profile outcome that needs adjudication accepts that those Studies stay visibly pending until R4p.)
• Entry: F3; R2a shipped; R0's screening floor step; X-ARCH-d and X-STATS-c; for production, X-ELIG and X-CLAIMS (§5.11).
• Acceptance:
• The handoff's worked scenes, as corrected by DP6/DP7 (since 5 October, by the stage study filter and step model: Q-15 replaced, Q-01, Q-24).
• The C6 evaluation table holds for selection, reservation, direct access and submit.
• Autosave never votes.
• FX-PRISMA-03a and 03b; the result stays Excluded despite completed extraction (PR1).
• Statistics count per profile and per form without double counting.
• Capability tests for the designer, monitor and settings.
• Critical path: F3 (C6 frozen; eligibility, allocation, presence and batch checklists passed) → decision commands → admission service → stage designer → reviewer step UI (step strip, U7) → overviews/settings → acceptance → pilot.
• Owner-session amendments (5 October) (stage pools, steps and history specification; UX specification):
• Stage study filter. A versioned filter with clauses on screening-profile outcomes, joined in AND/OR groups, defines the stage pool (Q-15 replaced). Being in the pool says nothing about work: allocation, capacity, step rules and already-sufficient evidence decide what is offered. Reconciled-answer clauses come with or after R4a, behind their own flag; when they ship is a separate rollout decision (the rollout plan recommends an R4a increment inside GA scope, R-AMB-02).
• Steps inside the stage. A step holds screening, annotation or both. Dependencies run between steps; exclusion-stop is a separate step setting; own Include is the default progression (Q-01). New combined steps stop extra screening at sufficiency, with Allow available (Q-24). Saved work may finish after a screening exclusion by default, and a step setting can prevent it while keeping drafts (Q-28). Started work may also finish after any filter-driven departure, with an authorised restriction (OS-A05). Training steps and the system adjudication step are step kinds.
• Pool history and structured events. Targeted reevaluation records StagePoolBaselineMember, StagePoolEntered and StagePoolDeparted with the filter version, matched clauses, cause and actor (OS-A07, OS-A10). A result produced through the stage may move its own Study out of the pool: the result is accepted, the departure recorded and new offers stop (OS-A06). ReviewStartEligibility records why a start was allowed. Events follow the C20 envelope (OS-A11), are never flagged off inside canonical scopes, and answer the required queries. An admin timeline explains review and inactivity (OS-A08), behind the UI flag stageEligibilityTimeline until staging acceptance.
• Reviewer page. A step selector with one form area (Q-12); full screening on phones, tablets and desktops (D3-05).
• Brief items owned here: D3-09 (eligibility alignment), D3-13 (allocation, batches and WorkFirstReleased), D3-16 (capacity pilots; project-scope tracking PROPOSAL), D3-19 (annotation place at personal Include) and D3-20 (active counts and Monitor names).
• Reviewer-pool browsing is a small opt-in slice after R3a (an R3c slice in the rollout plan), behind reviewerPoolBrowsing and a per-stage setting (OS-A27).
• Contribution exclusion at stage scope selects by route provenance (OS-A24).

R3b — Screening profiles

• MVP boundary: profile-owned eligibility questions in the shared editor (DP4); copied templates (SET1); several profiles per project; profile versions with publication impact (Q-26); a derived individual decision with its reasoning, confirmed only on explicit submit (DP3); exclusion reasons and the DP5 setting; deliberate own-history correction of an Exclude (DP2); collective outcomes per profile; a per-profile PRISMA phase mapping. Because AF2 doesn't render screening-only stages, F5 fixes a screening-renderer contract with the AF2 owner: AF2 admission for screening steps or a dedicated renderer. The screening renderer carries the keyboard path under DP3 and DP5: eligibility questions by number keys or arrows, Enter submits the derived decision, E opens the reason picker where reasons are required; I and E are inert under DP3 so one key never contradicts a derived decision (PH-35, U33). Pending Batch D: Unsure at title/abstract (D4-01), the discussion route (D4-02), the primary-reason hierarchy (D4-13) and bibliographic blinding (details hidden per profile; SR-25, PROPOSAL, U44) are profile settings in this release if approved; template defaults for new projects (methodology coverage §3.1) are template content owned by CAMARADES methodologists (D2-15) and recorded as PROPOSAL thresholds at F5; imported decisions carry authority = Imported with an independence declaration (C3).
• Entry: F5; R3a; R2c.
• Acceptance: the same profile in two stages gives one vote; different profiles stay independent; a derived decision never votes before submit; profile publication handles prior decisions as Q-26 decides; FX-PRISMA-02c and 04c.
• Owner-session amendments (5 October) (reconciliation and screening specification; reporting specification). The "pending Batch D" items above are decided:
• Unsure is a per-profile setting, on in the title and abstract template; it keeps a Study available and is never a definite Include (D4-01). Its handling is bounded: Include, Unsure, Include gives a sufficient Include; Include, Unsure, Exclude or a lone Unsure goes to adjudication (OS-A16). The full transition table, all-Unsure behaviour and thresholds are brief items.
• Each profile version states an explicit tie policy (extra review up to a bound, or the system adjudication step) with no imposed default (OS-A13). Discussion after a revealed conflict is optional (D4-02).
• A primary exclusion reason is template and reporting guidance; a profile may ask several reason questions (Q-22, D4-13; OS-A17).
• Profile versions are immutable, and publication detects and treats mismatched decisions and outcomes first (Q-26). The profile owns screening-reconciliation blinding (OS-A02).
• An eligibility-changing profile publication needs a protocol amendment entry (D4-05); the protocol record ships before or with R3b.
• Template content for new projects comes from the one CAMARADES catalogue (D2-15) after methodologist curation (T-SI-03). "Imported decisions carry authority = Imported" is Superseded (5 October): Imported survives only as a candidate provenance kind for mapped human imports. AI-model-generated screening decisions arrive in lane XS1; F5 may reserve the ScreeningSourcePolicy slot in the profile-version shape (PROPOSAL).
• Contribution exclusion at profile scope (OS-A24).

R3c — Stage lifecycle and optional strict mode

• MVP boundary: automatic or manual completion where readiness includes unresolved drafts and corrections; an admin-confirmed change request before a Completed stage reopens; automatic reopening for new arrivals under the same gate; status history (LC1, RX2; flow per Q-02). R3c's readiness source is decided at F3 (the completion definition extracted from #3939, unless #3939 has merged under the X-BATCH criteria in programme integration §4.2); X-BATCH is an entry condition only if batches are used. Readiness is evaluated from authoritative records while FEAT-024 is dark. A feature-owned "changes awaiting approval" queue carries the LC1 alert, whether or not the notification stack is merged. The queue is surfaced flag-independently: a global My work badge with read-time counts, an admin banner on the project overview for pending requests, and the "changes awaiting approval" list on the project-level My work surface (E86, U30; NS-07; pending D3-07). Other admins see "decided" once one admin acts (pending D3-23). Strict mode only if Q-01 approves.
• Acceptance: the lifecycle fixtures in the lifecycle proposal; Fix or a correction on a session pinned to a Completed stage creates a pending change request; everything passes with every notification flag off; FX-LIFE-01 to 10 and FX-PRISMA-04d.
• Owner-session amendments (5 October). Strict mode is the decided Q-01 stage setting: a stage can require the collective Include before anyone progresses; it is off by default and is recommended to ship here after pilot validation (stage pools specification, SP-AMB-11). The lifecycle follows Q-02: an automatic Completed stage is recalculated as soon as remaining work appears, with no confirmation hold; a manually or statically completed stage stays Completed until an explicit authorised reopening; admin changes show their extra work first. LC1's confirmation hold for automatic stages is Superseded (5 October); protected changes to a Completed stage still need approval. A merge changes evidence, never stage status directly. D3-07 is decided (My work, cross-project tab and global badge even when notifications are muted; UX specification); D3-23 is a brief item. Calibration rounds (AC-R3c-18) move to lane TR1 (training specification). Reviewer-pool browsing (OS-A27) is an opt-in slice here in the rollout plan.

R3d — Guided setup and templates

• MVP boundary: the replacement wizard (SET2) keeps every basic field and its validation, offers the guided preclinical route (profile templates, an initial form from the library, a stage/step route with DP7 defaults, team and groups once R1c exists, preview and publish with impact gates) and keeps manual routes. (Since 5 October the route uses stage study filters and steps with the Q-01 default instead of DP7 defaults, and templates come from the CAMARADES catalogue, D2-15.) New projects are admitted by R0's rule. The old wizard retires only after parity (U11) and the GA milestone. The Project setup checklist keeps its navigation placement (21 September decision).
• Entry: R3b, R2c, R1a.
• Acceptance: the setup fixtures in the setup proposal and a parity checklist against CreateProjectWizard and ProjectSetup; FX-SETUP-01 to 13; a new administrator reaches a screenable stage in at most 20 minutes (AC-UX-07).

5.6 R4 — Reconciliation, queries and outcome reconciliation

R4a — Form reconciliation and gold

• User value: a real reconciler form for any number of candidates, with match suggestions and immutable gold history. This is the largest visible gap today: main has no reconciler form.
• MVP boundary:
• Task and pool: one study × form task reachable through any bound stage (RE4), keyed by study and form, with the form version and every qualifying candidate session version recorded as state, a versioned input set that is never part of the key (DD-07); a per-question held state applies when candidates span compatibility classes or a value is invalid under the task's form version (versioning model §9). A shared pool with optional explicit assignment, unstarted-only expiry (default per Q-30), audited override and admin release/reacquire (RA1–RA4). (Q-30 decided on 4 October: expiry of unstarted assignments is optional, admin-configured and off by default; the proposed seven-day expiry is Superseded (5 October).) Random eligible start and assigned-work-first ordering are PROPOSAL (v10 r2); bulk reassignment is open (RD9).
• Candidates and matching: all qualifying candidates in answers, matching and comparisons (SF4/RE3, U1); match suggestions the reconciler confirms (MG1; v10 weights are initial defaults, A-12); re-pairing keeps prior pairings in history (PROPOSAL, COMPARISON F7).
• Reconciliation form on a new editable AF2 reconcile host agreed with the AF2 owner: choice-agreement and exact-text prefill (RE5); autofill marks; an exposure-based unseen-control warning with Complete anyway (RE2); note attribution (NT1); optional explanations (RE1); stage-owned aliases (BL1). (Superseded (5 October) for the aliases: the form owns blinding, blinded by default, with random context-local labels and order per Study and hidden chronology, OS-A02, OS-A03.)
• Gold: immutable snapshots (GS1) with compare-and-set on the current-snapshot pointer. Overlapping forms share question gold (RE4); whether the second task may revise it with provenance or only challenge by query is Batch D D2-09. Gold entries whose class no longer matches the form's current pin are flagged for re-reconciliation and stay effective, labelled with their version. An input-drift state, including a publication policy that de-qualifies a candidate, never retracts gold. Queries target the reconciled revision ID. Target-1 forms follow Q-29, never automatic promotion. Request an additional review (RA5). VS1 gold visibility with three-state exposure recording (VS2). UA1 requiredness behaviour. (Superseded (5 October): a target-one form version chooses AutoAccept, which creates an immutable Single annotator result with system-rule provenance, or RequireHumanReconciliation, which uses this same reconciliation workspace with one candidate; there is no Verified engine (Q-29, D4-03, OS-A28). An additional-review request raises the effective Study × form target explicitly and counts each reviewer once.)
• Legacy: legacy reconciled answers stay readable as LegacyAuthorityUnknown, treated as Q-35 decides. (Superseded (5 October): Q-35 is removed. No legacy reconciliation records are assumed; every conversion dry run checks that premise and stops the project's case if any appear.)
• Work surfaces: the project-level My work surface and the cross-project My work tab list assigned reconciliation work and requested reviews (E86, U30), so assignment never depends on notifications; the reconciler journey has a narrow layout (candidate selector plus single column; a selector never hides a disagreeing candidate) and the VS2 disclosure interstitial (U36, U16).
• Conversations (#3944): not part of R4a's gate. If #3944 and #3965 have merged, R4a rebinds conversations to the reconciliation task; otherwise they stay disabled (DS-22).
• Entry: F4 (C9 ADR; U1 validated; Q-03 reconciliation subset; Q-10, Q-29, Q-35, Q-36 and D2-09; the editable reconcile-host contract); R2b shipped; the task editor claim in every environment (X-RECLAIM, E6). (Since 5 October Q-29 and Q-36 are decided, Q-35 is removed and D2-09 stays open; F4 freezes C9 with D2-09 parameterised if Chris has not answered.)
• Acceptance: the ledger's multi-candidate list (three candidates everywhere, a fourth without truncation, matching groups across all candidates, aliases and blinding correct, no inflated sufficiency, final acceptance rules intact) plus the RE2/RE5 lists. A reconciler is never offered a study they reviewed (the ledger allows audited self-review only for query review, QY4; project-level exceptions are Q-36). An extra reviewer sees no candidate answers. A new snapshot keeps unchanged references. Drag-pairing has a keyboard alternative. Assigned work appears with every notification flag off.
• Critical path: F4 → task and candidate pinning → editable reconcile host → matching → snapshot store → pool and assignment → acceptance → pilot.
• Owner-session amendments (5 October) (reconciliation and screening specification):
• Accepted results are immutable AcceptedResultVersions with authority SingleAnnotator, HumanReconciled, Adjudicated or MergeResolved. A target or policy change may lead to a new result version; raising the target never invents reviewers. Automatic acceptance of several agreeing candidates is not approved (T-POL-03).
• No ordinary self-reconciliation by default; an explicit override grant permits it with a record (Q-36). Optional bulk acceptance, off by default, needs the reconciler's explicit confirmation and ships after the core (Q-11).
• Completeness follows requiredness with a form override; a blank candidate answer is "not assessed", and Unknown and Not reported are answers (Q-04).
• Reviewers see applicable accepted answers as labelled hints by default; the form can disable them, a step can only hide them, and copying one needs a click that is recorded and never counts as independent evidence (OS-A04; Q-28 hint part).
• My work and the cross-project tab list reconciliation work and requested reviews (UX specification).
• The default for target-one handling, re-acceptance under AutoAccept, the Q-36 override reading and the other items in that specification's §12 are owner-visible confirm items.

R4p — Profile reconciliation

• MVP boundary: the screening-profile part (RX1): decision adjudication, must-agree supporting answers and reason reconciliation when DP5 is On. It is a separate aggregate that writes the final screening outcome, because FEAT-011 forbids a reconciliation session from writing screeningOutcomes. Who reconciles each part follows stage grants. Whether a rationale can be required follows Q-32.
• Entry: R3b and R4a shipped; F4 and F5.
• Acceptance: adjudication resolves conflicts that block a cross-stage route; a collective Excluded stays Excluded (PR1); the RX1 fixtures.
• Owner-session amendments (5 October). Ties and bounded Unsure cases routed to adjudication are handled in a system adjudication step inside the stage, never as a stage-entry dependency (OS-A13, OS-A16). An AdjudicationTask can be assigned to a named member or an eligible group; the individual resolver is recorded, and assignment grants nothing. A pending adjudication is not a definite outcome. A profile may require an adjudication rationale, off by default (Q-32). Optional discussion after a revealed conflict keeps the initial observations and falls back to the tie policy (D4-02), behind its own flag. After resolution, a correction or exclusion leaves the adjudicated outcome current and flagged until an explicit reconsideration (RS-R58). "Blocks a cross-stage route" in the acceptance line now reads "blocks a stage filter or step that depends on the outcome".

R4b — Queries

• MVP boundary: accepted-answer queries (QY1–QY9), each a Concern closed by a ConcernResolution, with a feature-owned "my concerns and their resolutions" view as the source of truth, plus per-raiser notices through C15 when the stack is available. Corrections re-evaluate the smallest supported dependency closure (PROPOSAL, COMPARISON F3). The v10 RC10 rule is split: screening decisions re-run profile rules after a correction (recovered), while annotation-form gold always needs the reconciler's final submission, and candidate agreement after a correction never confirms gold automatically (RE2, AG2, SF4, RE5).
• Acceptance: the QY fixtures; agreement after a correction doesn't publish gold; every raiser sees the resolution of their concern with notification flags off.

R4c — Outcome reconciliation

• MVP boundary: outcome-series reconciliation for every candidate (RD15, declared resolved in v10) on canonical outcome data.
• Entry: O1 shipped (canonical projects have no outcome data before it); R4a; AF2 Phase 4 PR 9, which lifts the extraction and Experiment carve-outs on non-review hosts; X-PDFTOOLS (§5.11).

5.7 R5 — History, agreement and PRISMA reporting

R5a — History and as-of export

• MVP boundary: as-of downloads (EX1, EX2) for answers, sessions and gold, each with a manifest, per-dataset coverage labels and the C11 watermark rule; previous gold versions; candidate/gold separation under the export disclosure contract. The "completed sessions only" export fix ships behind a flag.
• Entry: F6a (C11 as-of rules); R4a. It waits for neither PRISMA identification nor the agreement methods.
• Acceptance: an as-of export reproduces a recorded state where history exists and labels gaps where it doesn't; two exports at the same watermark have identical data files for versioned datasets and the same requester authority, with manifests that differ only in generation metadata (AC-R5a-02r); dates before adoption return "not observed", never the adoption snapshot.
• Owner-session amendments (5 October). As-of exports include stage pool membership from the structured history events, with tracking-start coverage disclosed (stage pools specification). Reconciliation conversations export as permissioned audit records, outside candidate-answer exports (D3-25). Dates before a project's baseline conversion carry legacy-gap states (baseline conversion specification).

R5c — Agreement statistics

• MVP boundary: an agreement view behind its own capability, with its own place in the navigation (AG1), applying AG2/AG3, the independent/informed split (VS2) and the Q-04 missing-state treatment, with CSV export. Agreement is computed from canonical revisions, because FEAT-024 excludes agreement statistics. Screening-level agreement per profile and per phase is in scope: percent agreement with explicit denominators and inclusion prevalence always shown; Cohen's or Fleiss' κ for fixed raters, pooled pairwise κ or Krippendorff's α for rotating raters, PABAK and AC1 as supplementary (all PROPOSAL under D4-12 and Q-16); per-criterion agreement from the derived-decision vectors; the default view uses initial independent observations, with current decisions, informed (collective), informed (questioned, NS-06) and declared-independent imported views labelled separately; agreement by screening order (drift); the reconciler override count. Agreement lives in its own rebuildable store (D3-11).
• Entry: R4a (exposure records); Q-04 and Q-16 answered (Q-04 decided on 4 October; Q-16 is specialist input T-SI-02); the method contract (E9); U29.
• Acceptance: agreement figures match hand-computed fixtures under the approved method; informed contributions are never counted as independent; holders of the agreement capability alone see no candidate answers.
• Owner-session amendments (5 October). Q-04 is decided (blank is not assessed). Q-16 and D4-12 are specialist input T-SI-02: one methods specification for denominators, percent agreement, prevalence, initial independent observations and any multi-rater formula, so every formula above stays PROPOSAL until it exists. The agreement store is brief item D3-11, with a budget agreed at the R5c freeze. Adopted hints and discussion exposure count as informed. With lane XS1, machine sources form their own class and no figure combines classes (reporting specification).

R5b — PRISMA reporting

• MVP boundary: report snapshots (PrismaFlowSnapshot) built from P1/P2 identification provenance, R3b profile outcomes, R4p adjudicated outcomes and amendments A–P (Q-06a, Q-06b, Q-37, D4-07, D4-08, D4-11), honouring PR1, computed from authoritative records only at a watermark (never FEAT-024 rows), with explicit coverage where history is missing and evidence-based lower bounds for adopted projects (a study with a recorded legacy decision certainly entered screening). Every snapshot passes the published arithmetic identities per column with remainders shown; a mismatch blocks freezing unless an administrator records an explanation. External step records of every type can be entered here (P1 covers identification and deduplication), with the entry-phase and per-box rules of amendment K; box 1 is populated from "previous review version" records and switches the template variant (D4-11); full updated-review support stays deferred. Box 17 uses the "Synthesis inclusion" attribute under the Record synthesis inclusion capability (placeholder), owned by L12 here. The methods-summary block (PRISMA 2020 items 5–11, 16, 24; PRISMA-S deduplication) and the near-miss excluded list preset are generated from the manifest. Withdrawn searches are excluded from current reports and said so (D3-12). As-of exports and protocol amendments never activate an updated-review population by themselves.
• Entry: F6b (C12 report semantics, amendments B, E and F); P1, P2, R3b and R4p shipped.
• Acceptance: the R5b parts of FX-PRISMA-01 to 08 and FX-PRISMA-08b; every part first passed in an earlier release still passes; every snapshot passes the published arithmetic identities (AC-R5b-09); frozen snapshots never change, and amendments append.
• Owner-session amendments (5 October) (reporting specification). Amendments B, E and F are decided (Q-06b); Q-33, Q-37 (counts and QC part), D4-07 and D4-11 are decided; Q-22 is decided (distinct excluded Studies counted apart from overlapping reasons). The report labels imported references, source documents and Studies, and states report identity coverage. Actual review through a stage, with its contemporary eligibility justification, is the reporting priority; ever-in-pool history is separate audit data, and a filter failure is never a screening exclusion (OS-A09). The stage measures M1 to M5 read the C20 events from R3a onwards. The exact box mapping is specialist input T-SI-05, recorded before F6b. Report-to-study linkage (amendment O) is replaced by prepared multi-source links on StudyVersion, and grouping distinct reports is deferred (D4-08, Q-23 brief items). With lane XS1, the manifest and methods summary show the machine-assisted share.

5.8 Lane releases

Lane release	MVP boundary	Freeze and dependencies
P1 Identification provenance	For new imports in admitted projects: immutable Citation occurrences with source type (SystematicSearch lacks it today); the earliest-source downstream rule (amendment C); the Citation to Publication link record (amendment N); search documentation fields (date searched, platform, strategy, limits and filters, date range) and a minimal searchRound (D4-05, SR-24); full-text retrieval as fullTextStatus with human actions Sought, Retrieved and Not retrieved with reasons, recorded as append-only events, and a PDF attachment that only suggests Retrieved (amendment M, D4-07); the FEAT-024 search-population family extended with source type for statistics screens, never as a report input (MS-11); an admin source-classification tool for projects that imported before P1; per-search records of steps done outside SyRF before import (ExternalStepLedger), with their entry phase and consistency warnings (amendment K); imported screening decisions carry authority = Imported with an independence declaration (C3). Withdrawing a search keeps its Citation history and hides its Studies (amendment J; D3-12); whole-project deletion follows ADR-014. No report. Acceptance includes FX-PRISMA-01 (P1 part) and the retrieval criterion AC-P1-11 (its as-of part is FX-PRISMA-05b at R5b). Owner-session amendments (5 October): D4-05, D4-07 and Q-33 are decided; search documentation is versioned. Imported survives only as a candidate provenance kind for mapped human imports; external and AI-model screening decisions use their own lane. Whole-project deletion is reversible (hide, block, stop allocations and notices, release places, keep data, restore through a restricted view; D3-12 amended, OS-A25); "follows ADR-014" is Superseded (5 October), and permanent physical erasure is an unapproved policy (T-POL-01). New imports get their first StudyVersion with reference links (review domain and reporting specifications).	F-P (amendments A, C, D, J, K, M, N approved; Q-33, Q-37; D4-05, D4-07); R0 floor step for Study root fields; X-DEL design join; X-IMPORT
P2 Identification and deduplication	The FEAT-011 three-level model: Publication (privacy rule: reading a Publication never exposes other projects' identities; enrichment events recorded), Study.citations[] (backfilled from re-parsed retained files, or labelled as derived from current Study metadata), lifecycle status, link records. ASySD deduplication inside SyRF as FEAT-012's Approved specification describes, as amended by L (amendment L): the native C# ASySD implementation, synchronous DOI/PMID matching at import, asynchronous fuzzy matching after import, AutoConfirmed and ProbableDuplicate tiers, the admin review queue (including scenario 2 under amendment D and a QC sample of AutoConfirmed groups), a reviewer "flag as possible duplicate" action, the merge wizard, the audit log (DedupAuditLedger) and retroactive deduplication, proven by the parity suite defined in D4-21. Secondary studies are never deleted. Merge is an alias (mergedInto, StudyAlias on the primary Study): nothing is re-keyed, one reviewer who reviewed both duplicates is counted once, and split is a clean reversal (D2-12; E33). (Superseded (5 October): D2-12 is replaced. A merge creates one consolidated current Study holding the combined bibliography, links to every original reference and the current review work; the originals become tombstoned immutable history, no longer listed, offered or counted. Conflicts, including same-reviewer submissions and differing accepted results, are resolved before commit in a reconciliation-like view, by the merging user or delegated to the original reviewer, with the actual resolver recorded. The commit is atomic. An unmerge is a new action that restores the originals and assigns post-merge work item by item, never to both (OS-A29; duplicate merge specification; contract C21). Delivery splits into P2a (Study state, StudyVersion, consolidation of unreviewed duplicates), P2b (reviewed duplicates, conflict tasks, unmerge carry-forward) and P2c (accepted-result and adjudicated-outcome conflicts, after R4a and R4p), as a PROPOSAL.) The admission service excludes every non-Active lifecycle status (FEAT-012 §12). Report-to-study linkage (StudyLink, amendment O) if D4-08 approves (since 5 October replaced by prepared multi-source links on StudyVersion; grouping distinct reports is deferred, D4-08). Box 3 combines SyRF-detected and externally reported duplicates. The lifecycle "Included" transition needs every required profile Included; the required profiles are those mapped to the title/abstract and full-text phases in the project's versioned phase mapping (C12, set in R3b). Acceptance includes FX-PRISMA-01 (P2 part), FX-PRISMA-07a, FX-PRISMA-08a and, if D4-08 is approved, FX-PRISMA-09. (Since 5 October FX-PRISMA-07a is rewritten for consolidation, FX-PRISMA-09 waits for the deferred grouping feature, and the ASySD parity method and thresholds are specialist input T-SI-04; F1 ≥ 0.99 and 80,000 citations in one hour are proposals, neither approved nor achieved.)	P1; amendments D, L, N (Q-37, D4-21, D2-12), O (D4-08); reviewed-record part and lifecycle transition after R3b; X-IMPORT. Since 5 October: C21 frozen at F-P; the R0 floor step with the tombstone predicate; C20 events; P2b after R2b and R3b; P2c after R4a and R4p
C1 Populations and explicit classification	Entity types with capabilities and TC1 templates; animal populations (AnimalPopulation) with a whole-population cohort; instance isolation; relationship/set annotations with evidence; shared concepts and per-paper mappings; versioned project rules; compact cohort selection (U3); export; the move from category tabs to entity types. No inference. The answer key carries a population from R2a's first write, so turning C1 on never re-keys answers. Acceptance includes FX-PRISMA-06a. Since 5 October Q-19 is decided: the Design capability publishes project rules, reviewers confirm per-paper applicability through mapping answers, and normal reconciliation resolves disagreements.	F-C (C13); R2a; Q-19 (decided)
C2 Inference and counts	Pregnant ⊆ Female style implications without automatic strictness, simplification, suggested inferred cohorts without invented counts, outcome associations shown with inferred cohorts, conflicts shown with their supporting provenance, count feedback (60 = 25 + 35 only with full support), withdrawal, proof provenance; reported answers stay as reported. Population merging and cross-type count solving remain follow-ups. Owner-session amendments (5 October): an opt-in beta, off by default, switched on per project by a project designer and never by baseline conversion; GA promotion is a separate decision (OS-A19). Q-18 is decided: the first reasoner supports conjunction, containment, disjointness and exhaustiveness only. Suggestions come only from the current reviewer's own snapshot or a pinned accepted result, never from a mix of unreconciled reviewers (training and inference specification).	C1; Q-18 (decided); R4a for collective inference
O1 Outcome schemas	Legacy-compatible and event-count schemas plus project customisation (OC1); series and observation fields with roles, types, validators and cardinality; the dispersion catalogue, unit vocabulary with the same-measure validator, domain validators, the sample-size rule and extractionMethod provenance with graph-estimated as the default for linked graph regions (C14, SR-06; graph digitiser decision deferred per D4-10); the system schema-selection question (owner clarification of 27 September, recorded in the classification research); reviewer-created outcome measures with one versioned direction (ODIR1, A-20); bindings through form versions; validation, import and export; the existing matrix/dialog/spreadsheet entry extended (RD16); an extraction QC view (graph-estimated share, unit mismatches, SD/SEM corrections, missing n). Canonical forms admit extraction from here. Acceptance includes FX-PRISMA-06b. Since 5 October D4-10 is decided (estimated-from-graph provenance now; digitisation after pilots), and the event-count schema waits for specialist input T-SI-01 (Q-17).	F-O (C14); R2a; schema changes on used forms need R2c; Q-17 (T-SI-01); D4-10 (decided); X-PDFTOOLS
O2 Outcome migration	Per-project synthetic dry-run first, then an approved manifest, staged copy and fenced cutover. Default values are never read as answers (false direction, SD, mean, zero animals) unless an explicit stored answer is proven. Since 5 October Q-05 is decided-amended through R4: outcome conversion is part of each project's faithful baseline conversion, and untouched defaults convert as ValueOrDefaultUnknown (baseline conversion specification).	O1; Q-05 (decided-amended); separate execution approval; P1 identity gate
AL1 Shared-form allocation	One allocation plan per shared form with equality checks, joined with the allocation programme (#3327; its reviewer-validation blocker #3251); lifts assumption A-09 (proportional allocation refused on every canonical stage from R0, the E65 guard). Acceptance: shares are computed once per shared form and are equal across its bound stages; no study is allocated twice through two stages; turning the flag off returns to refusing proportional shares on every canonical stage.	F-A (the allocation owner's checklist passes on C7, run by a fresh-context agent; Chris rules on exceptions); R2b; X-AUTH-RESOLVER
X1 Analysis-ready exports	After O1 and R4c (D4-09): a comparison-level export (gold by default, candidates optional) with pairing derived from Experiment membership and control flags, shared controls flagged, one row per comparison × timepoint in metafor's escalc() shape, dispersion type carried and never converted, direction, units, extractionMethod, experiment, study, report and StudyLink group; a machine-readable codebook per export (question identity, version, wording, options, semantic role, entity scope, requiredness; per answer answeredUnderVersion and qualificationPolicy); RIS export of any study set (included, excluded with reason, duplicates, not retrieved) from Citation raw fields; the same collective-outcome default as extraction exports (SR-17); the "Synthesis inclusion" attribute exported. No effect-size computation inside SyRF; the recipe is documented in the user guide. D4-09 is decided (5 October).	O1, R4c, R5a; F6a (C11); D4-09 (decided)
TR1 Training (owner session; names and placement in the rollout plan)	Training steps with versioned reference answers; automatic scoring by versioned rules or manual assessment; pass or fail with feedback; retries under a versioned policy; optional admission of a passed reviewer to a permitted project group, never a hidden privilege expansion; explicit promotion to live evidence as a separate action. Training evidence never counts toward live targets, accepted results or PRISMA (D4-04 amended, OS-A18; training specification). Hook-only deferral is not enough without a separate owner agreement. The rollout plan recommends that TR1 does not gate GA (its R-AMB-01)	F-TR; R3a (steps), R2a, R3b; F3 for the step kind; R1c and R1d before automatic group admission
XS1 External and AI-model screening	Import of external and AI-model-generated screening decisions: no fake human login; the machine source is identified apart from the importing user; versioned AIScreeningModelConfiguration; the profile's ScreeningSourcePolicy counts the model as a contributing vote or the sole screener; reruns are versions, never extra voters; model Unsure goes to human adjudication; outputs on training inputs never validate the model (D4-14 amended, OS-A20; reporting specification; contract C22). Per-project opt-in behind a new default-off flag	F-XS (C22); after the first engine release, which the rollout plan reads as after GA (its R-AMB-03; F5 reserves the profile slot so an earlier start stays possible); R3b, R4p, C20, P1 identity matching, DM lineage
XA1 Annotation-answer imports	Imported annotation answers with provenance; no automatic gold; target credit only when mapped to a SyRF reviewer (D4-14)	F-XA; after GA in the rollout plan; R2a
RW1 Redesign wizard	After baseline conversion, an in-engine wizard rearranges a project's stages, steps, forms and profiles through ordinary versioned publication with impact previews and explicit admin confirmation; it is never a second migration (OS-A15)	After GA; R2c, R3a and R3b
PWA1 PWA exploration (beyond the MVP)	A feasibility study of installability, updates, protected-data caching, authentication and offline synchronisation, including possible caching of allocated studies. No service worker and no offline write ships before an owner decision on the report (OS-A22; UX specification)	Timed so it never delays MVP work
BR1 Answer-based step branching (deferred)	Branching between steps on accepted answers is outside the MVP (D4-15); reconciled-answer clauses in stage filters stay in scope	A later lane after R4a; no delivery commitment until its brief is approved

5.9 GA milestone, R6 adoption and R7 retirement

• GA — canonical by default for new projects: after R2a–R2d, R3a–R3d, R4a and R4p have shipped and been piloted; the coexistence UI is complete (navigation per project mode, the editor's two modes, legacy labels); guided setup has reached parity; help pages and an in-product "what changed" page are published; and the production prerequisites hold. Only then does the old setup wizard retire (SET2). Owner-session amendments (5 October): full annotation and screening work on phones, tablets and desktops (D3-05); legacy screens are restyled and gain as many compatible new features as possible without changing workflow semantics (D3-06 amended, OS-A23; UX specification).
• R6 — adoption waves: per-project, reviewed adoption following the adoption protocol, each wave separately authorised. A stage is adoptable for a domain only when every reader and writer of its data is canonical: annotation-only stages without reconciliation after R2a/R2b; Combined stages after R3a; anything reconciled after R4a (R4p for profile reconciliation); extraction after O1/O2. The notification stack's conversations, issues and inbox references are part of each manifest. Rewritten by the owner session (5 October); "reviewed adoption" of selected projects is Superseded. R6 becomes universal faithful baseline conversion waves (OS-A15; baseline conversion specification). The order is fixed: opt-in trials in staging as each scope becomes complete; production pilots with owners who opt in, each separately approved and only for complete scopes (D4-16 amended); then scheduled waves that convert every remaining project, including completed, inactive and deleted ones, once parity is proven on pilots. Conversion preserves workflow semantics and is never a protocol redesign. Each project runs a read-only inventory and dry run (including the Q-35 premise count), a wizard review of the mapping that shows how each legacy stage's screening and annotation work maps to steps, forms and profiles and advises when to convert or wait (OS-A14), an approved manifest, a shadow copy, a parity check and a fenced cutover. Missing history carries named legacy-gap states. A project that cannot convert faithfully is quarantined with a concrete remedy and never forced through. Routing rollback is possible until the first canonical write; after it, recovery moves forward. Each wave passes G-ADOPT and needs Chris's approval. An in-engine redesign wizard (lane RW1) comes later as ordinary versioned publication. No conversion is authorised now.
• R7 — retirement: retire temporary adapters, legacy authority and migration flags only after consumer inventory, parity evidence and restore rehearsal, with separate approval (research §7.3). Each release ADR records its minimum rollback image; R7 is where earlier images stop being valid targets. Owner-session amendment (5 October): R7 is legacy-writer retirement, its own verified milestone: every project converted, an empty consumer inventory, passing access, export and restore checks, approved retention, and Chris's separate approval through G-RETIRE. Legacy originals and manifests stay stored. Disaster recovery (D2-13) is a brief item with a rehearsal before the first production pilot.

5.10 Reconciliation and conflict paths for pilots before R4

• R2a–R2c pilots are chosen so they need no reconciliation before R4a: target-1 forms (exports label them "single reviewer, unreconciled", Q-29) or forms whose reconciliation can wait. Legacy reconciliation refuses canonical forms, so canonical candidates are never overwritten by non-snapshot gold. (Superseded (5 October) for the label: before R4a a target-one pilot keeps its single assessment without an accepted result, labelled "single annotator, acceptance not yet available". When R4a is enabled for the project, an admin-confirmed operation may create Single annotator results for qualifying Studies, with operation provenance and never as a silent backfill; PROPOSAL, reconciliation and screening specification §10.)
• R3a pilots resolve screening conflicts by extra votes (D1/D2 Allow). A pilot using Stop on a profile that feeds a cross-stage route accepts that conflicted studies wait for R4p. (Since 5 October: a profile may already choose adjudication, and Studies that reach it stay visibly PendingAdjudication until R4p; no cross-stage route exists.)
• These are pilot entry and exit criteria, not silent restrictions (acceptance criteria §5.2).
• Pilot projects (Q-07, decided): the seeded projects in preview and staging (the five existing ones plus a new seed project per release, listed in acceptance criteria §6) and new projects. Existing real projects stay legacy until R6 adoption. (Since 5 October: until a production pilot or their universal conversion wave. New seed projects follow D3-14: add only missing seeds, prefer preserving staging data, never production.)

5.11 Production prerequisites per release

Owned by other programmes unless marked; each needs go/no-go evidence at the ship gate. Status as read on 3 October at 15:18 BST; refresh at every gate. Recommended changes to the programmes behind these joins are in programme integration.

Join	Needed by	Owner	Evidence	Status
X-AF2: AF2 production readiness, or the plan-owned AF2 per-project admission slice reading R0's admission record (Q-25, DS-04)	Any production pilot of R2–R4 reviewer UI	AF2 programme (readiness); L5 with L0 (slice)	Agreed per-flag decision; slice merged with tests	Not met: AF2 on in staging only
X-SHELL: stageReviewRedesign / stageReviewDockview readiness, or the shell per-project admission slice	R2a onwards where the new UI extends the shell	Stage-review programme; L5 (slice)	Per-flag decision; slice merged	Not met: off everywhere
X-STATS-a: usage family on in staging and pilot projects allowlisted on both hosts	R2c staging pilot under PS1	FEAT-024 owner	Staging configuration and parity record	Not met: family not built; fold flag now pinned on in staging
X-STATS-b1…b7: idle gate (b); soak (#3510, #3952) with #3840, #3960, #3845 closed for families in use; production pending index; separately approved production rollout lifting the in-code refusal (D1-03 "activate"); production eligibility (#3524 after C16, or the static allowlist for named pilots); usage family built (E72); usage family proven on staging	R2c production publication from the materialised family; until then Q-31(b)	FEAT-024 owner; Chris (b4)	Per step (programme integration §7.2)	b1 failed on latency (idle-host rerun, 3 October, #3510); b2 open; b3–b7 not started
X-STATS-c: target-aware annotation classification at all three fixed-two sites (E71)	R2b pilots on allowlisted projects; R3a (AC-R3a-06)	FEAT-024 owner (+ #3979, architecture review)	Merged with the reconciliation plan executed	Not started; no issue tracks it
X-ELIG: S4-B (targeting the claim contract v2 key), S4-C, S6a, S6b, the fixed-two correction, the Project-token redesign, flag delivery to PM	R3a production admission; X-BATCH activation	Eligibility programme (paused); R3a absorbs per D3-09	Each item merged or extracted; count-only reservation check per environment; the write gate (AC-ALL-26, C18-T02) with eligibility on	Not met; programme paused
X-CLAIMS: production claims route per D3-16 (a brief item since 5 October; tracking per admitted pilot project, with project-scope tracking a PROPOSAL); API and PM switched together statically; load, failover and orphan backstop; E2E in both tracking modes	R2b claim behaviour, R3a reservation admission and any capacity promise, in production	Presence owner with FEAT-024 owner	AC-T-03 to AC-T-07; AC-T-09 (route built); AC-ALL-23 (both tracking modes)	Not met: tracking off everywhere; M15 unowned; #3876 deferred
X-RECLAIM: reconciliation-task editor claim working with tracking off (RA1)	R4a in every environment	L6 with presence owner (internal to this plan)	AC-R4a-36 to AC-R4a-39	Frozen at F4
X-AUTH-SCHEMA: membership schema 1 applied and verified in production (G-D in #3335's handover plan)	R1c	Authorization programme	Production migration evidence	Not met
X-AUTH-ENFORCE: staged cutover to the enforced evaluator (M6, gate G-C, in the authority-transition plan), or parity tests	R1c	Authorization programme	Cutover evidence or parity tests	Not met
X-AUTH-WP9: explanation endpoints and surfaces (#3335 WP9, after its WP3)	Explanations in R1b; R1c	Authorization programme	Contract test: explanation equals enforcement decision	Not met
X-AUTH-RESOLVER: out-of-request, cross-provider authority resolver (#3251) on the single evaluator	AL1; allocation reviewer validity and Phase 2; R3a per-reviewer preview	Authorization programme with allocation owner	Resolver merged; validity checked on save and activation	Not met: #3251 open since 5 September
X-BATCH: evidence seam; pool-entry-based membership; durable opening and grant emitting pool-entry events; read-only status; performance gate; X-ELIG first	R3c readiness reuse; any batch enablement	Batch programme	Merged slices; benchmark; event fixtures (AC-R3a-10, AC-R3c-17)	Not met: #3939 conflicting
X-NOTIF: notification stack steps 1–5 (#3932, #3938, #3941, #3942, #3943) merged with flags off	Notices only: R1c (also needs #3941), R2c, R3c, R4a (conversations also need #3944 and #3965), R4b. Feature queues carry confirmed obligations, so never a release dependency	Notification programme	Merged code; run:e2e-full on retargeted heads	Not met: nothing merged
G-NOTIF (gate): Chris approves each environment and kind family (D3-21, a brief item since 5 October; the email content policy and per-project mute, D3-22 and D3-24, decided)	Any notification enablement outside the e2e stack and Mailpit	Chris	Approval recorded in the flag audit; halt and per-project admission delivered (E74)	No approval given; notification delivery is not authorised under the hold
X-DEL: ADR-014's manifest and tombstone model covers the canonical collections for whole-project deletion; search withdrawal never physically removes identification history (D3-12). Since 5 October: reversible project deletion and restoration cover the canonical collections, and no project is physically deleted without the unapproved policy T-POL-01	P1 search withdrawal; reversible deletion before universal conversion waves	Deletion-lifecycle programme	ADR-014 committed and amended (the deletion design needs a new ADR number, because ADR-014 on main is the PDF viewer)	Not met: ADR-014 uncommitted
X-IMPORT: staged import (as #2612 plans) implemented; sized timeout with heartbeat and stall watchdog; idempotent saga creation	P1, P2	Study Management (import) with L12	AC-P1-19	Not met: #2612 is a plan document
X-AF2-PR9: AF2 Phase 4 PR 9	R4c	AF2 programme	Merged code	Not met
X-PDFTOOLS: v1 pdf-tools migrated behind AF2's data-source seam, or O1's scope states the gap	O1, R4c	AF2 programme	Merged code, or O1 scope note	Not met: unscheduled
X-ARCH-a: non-upsert saves and version bump on direct writes (#3985); awaited domain events (#3973)	F1a	Architecture-review programme	Merged with architecture tests	Not met
X-ARCH-b: MassTransit-after-v8 decision (#3986)	R0 (ownership guards on PM consumers)	Architecture-review programme; Chris	ADR	Not met
X-ARCH-c: runtime flag provider no longer resets overrides (#3975)	R0 admission; G-NOTIF evidence	Architecture-review programme	Merged with a singleton-identity test	Not met
X-ARCH-d: study-library filter fixed two (#3979); ValueObject equality and threshold serialisation (#3980)	R3a	Architecture-review programme	Merged	Not met

5.12 Scope coverage and traceability

Against Chris's authorised scope list:

Scope area	Where it lands
Annotation-question management, tree, library, imports	R1a, R2a, R2c, R2d (L2)
Profile-owned screening questions	R3b (L2 editor reuse, L3)
Question/form versioning, publication impact, fresh statistics	R2a, R2c, R2d (L2, L7, C8)
Shared annotation-form entity, immutable shared sessions	R2a, R2b, R2d (L1, C1–C5)
Stages and configurable dependent steps, availability, skips	R3a, R3c (L4, C6); since 5 October the stage study filter, steps inside the stage, pool history and structured events (C20)
Outcomes, measures, data schemas, migration planning	O1, O2, R4c (L10, C14); migration document
More-than-two-candidate reconciliation, matching, blinding, gold, queries, prefill, Complete anyway, notes	R4a, R4p, R4b, R4c (L6, C9)
Export, history, point-in-time reproducibility	R2a (versions), R5a (as-of, manifests), R5c (agreement), X1 (analysis-ready exports) (L11, C11)
PRISMA identity, source, pool, reasons, report	P1, P2, R3a (pool entry), R3b (profile outcomes), R4p, R5b (L12, C12)
Membership groups, scoped permissions, RBAC	R1b, R1c, R1d, then per-feature capabilities (L8, C10)
Materialized statistics	R2a (projection), R2b, R2c (usage family), R3a; agreement in R5c is computed outside FEAT-024 (L7, C7, C8)
Proportional allocation	R0 (refusal on every canonical stage, the E65 guard; A-09), AL1 (shared-form contract; lifts the refusal) (L7)
Presence and reservations	R2b (claim key), R3a (profile claims), R4a (task editor claim, X-RECLAIM); production claims through X-CLAIMS (L7, L6)
Progressive batching	R3a join with #3939; R3c readiness (L7)
Project/stage/step overviews and settings	R1–R5 (L16, C17)
Replacement guided setup, templates, library	R1a, R2a, R3b, R3d, O1 (L13)
Population, cohort, classification, shared concepts, project rules, inference, compact reviewer UI	C1, C2 (L9, L5)
Notification infrastructure (3 October addition)	Per release through C15 and feature-owned queues (L14); notifications integration
Duplicate merge and unmerge (owner session, 5 October)	P2a, P2b, P2c (L12, L1; C21)
Structured history and eligibility explanation (owner session)	R3a, R3c, R5a, R5b (L4, L11; C20)
Universal baseline conversion and legacy-writer retirement (owner session)	R6 waves, R7 milestone (L15; C16)
Training steps and the inference beta (owner session)	TR1; C2 as an opt-in beta (L4, L8, L9)
External and AI-model screening decisions; annotation-answer imports (owner session)	Proposed lanes XS1 and XA1 (L3, L12; C22)
Contribution exclusion, reversible project deletion, catalogue, informative email (owner session)	R1a, R1b, R2a, R3a, R3b, X-DEL, notification programme (L8, L2, L14, L15)
Phone, tablet and desktop annotation; PWA exploration beyond the MVP (owner session)	R2a, R3a, R3b; the non-MVP exploration PWA1 (L5, L16)
Design-prototype handoff for SyRF Prototype v10 (owner session)	T-DH-00, an input to the W0 prototypes and F1c (L16)

Against the planning brief's scope table, row by row:

Brief area	Required coverage	Where it lands
Shared annotation forms	Shared study/form sessions; form-owned minimum targets; compatible shared answers; repeated-entity and branch context; immutable explicit submissions; separate autosave and completion; prior versions and affected sessions inspectable	R2a (sessions, drafts, versions, history), R2b (cross-stage), R2d (shared answers, outdated flags), R2c (affected sessions in the impact dialog); C2 context key
Stages and steps	Configurable question sets; independent completion; dependency routes; availability and skip reasons; DP6/DP7 defaults and veto; strict mode a design question; EW1 visible. Since 5 October: a stage study filter defines each pool (Q-15 replaced); dependencies are between steps inside a stage; Q-01's collective-Include setting is decided	R3a (filter, steps, routing, skips, EW1, pool history), R3c (the Q-01 setting, the Q-02 lifecycle); C6, C20
PRISMA	Distinct units; profile authority; protocol entry; source attribution; reasons; dedup; report counting; historical reproducibility; PR1	P1, P2, R3a, R3b, R4p, R5b; C12; amendments A–P
Setup and templates	Replace wizard and checklist; copied profile templates; editable initial form; library selection; optional guided route	R1a, R3b, R3d; GA retires the old wizard
Question-management interface	Old/new comparison; profile vs ordinary editors; imports and library; full answer-set form membership; ancestors and repeated entities; reasons vs guidance; version and history views; publication impact, fresh statistics, outdated sessions; entity templates and outcome schema editing; stage/step bindings; consistent navigation	UI comparison; R1a, R2a (form membership incl. ancestors), R2c, R2d, R3b, C1, O1; C17
Reconciliation	More than two candidates; matching with correction; identity blinding; immutable snapshots and queries; exact-match prefill; in-view warning and Complete anyway with validity; note attribution; one study/form task; no majority gold or per-field confirmation	R4a, R4p, R4b, R4c; C9
Classifications and cohorts	Population isolation; whole-population cohort; label annotations and numbered child questions; parent/subset, disjointness, exhaustiveness; shared concepts vs paper mappings; versioned rules; implications without automatic strictness; inferred cohorts, outcome associations, simplified membership, conflicts with provenance; reported answers preserved	C1 (explicit), C2 (inference, conflicts with supporting provenance, outcome associations shown with inferred cohorts); C13
Outcomes	Versioned measure direction without context overrides; series vs observation fields; cardinality, types, validators; schema customisation; migration planning only	O1, O2; C14
Statistics, allocation, active work	Fit existing statistics, allocation, presence/reservations, batching; no competing counters, claims or batch authorities	C7, C8; R2b, R2c, R3a, R3c, AL1
Pages and settings	Overviews; project/stage/step settings; category tabs; batching navigation; forms, profiles, gates, readiness, targets exposed consistently; coordinate ongoing UI work	C17; L16 with the M3 navigation and overview SignalStores
Permissions, history and lifecycle	Scoped group capabilities; owner-controlled grant administration; completed-stage reopening alert/approval; publication impact; current vs historical exports	R1b–R1d, R3c, R2c, R2a, R5a, R5c

6. Gates, dependencies and critical path

6.1 Freeze gates

A freeze gate fixes a contract: its ADR, DTOs, a fake and a conformance suite. Consumers may start building against the fake once it passes. Freezing is about building, not shipping. Each gate has one dossier and, under per-gate authorisation (D1-04, approved on 3 October), passing it authorises the slices its dossier lists (delivery operating model §3). Programme-owner signatures are fresh-context agent checklists against each programme's rules file, with Chris ruling on the exceptions. Each gate's entry names the sitting held before it in the decision calendar and the decisions its freezes depend on; a part frozen at F1a whose decision is a D3 or D4 question is frozen at F1a once that question's F1a part is answered. U validations are listed in the UX strategy §11 with their pass bars.

Owner-session update (5 October 2026). G0 is not approved, and feature implementation is on hold. Passing G0 (T-G0) and lifting the hold (T-HOLD) are separate decisions. Even after both, each workstream brief (T-RD-00 to T-DH-00) needs Chris's approval before its work starts; a gate's "Authorises" column takes effect only within approved briefs. Most decisions the rows below cite are now decided, replaced, removed or deferred, or have become brief items, specialist inputs or engineering contracts; §11 and the owner-session integration give each status. A freeze that depended on such a decision now depends on the recorded outcome. D2-09 is the one open owner decision (F1a freezes C4 and C9 with it parameterised). Specialist inputs gate their own freezes: T-SI-01 (Q-17) at F-O, T-SI-02 (Q-16, D4-12) at R5c, T-SI-03 (D4-06) before catalogue publication, T-SI-04 (D4-21) at P2's parity criteria and T-SI-05 (PRISMA box mapping) before F6b. New contracts: F1a also freezes the C20 envelope (structured history events), F3 its stage-pool and eligibility event types, and F-P freezes C21 (duplicate consolidation and reversal). The rollout plan adds three lane freezes (PROPOSAL): F-TR for TR1's training contracts, F-XS for C22 (external and AI-model screening sources) and F-XA for XA1's annotation-import contract; its gate table lists each gate's owner-session additions. Superseded wording inside the table is marked.

Gate	Freezes	Exit evidence	Authorises (D1-04)	Signs
G0 Plan approval and operating model	This package as amended in round 2; the delivery operating model, its five stream briefs and the decision calendar; Batch A; Batch D1	Entry: step 0 merged (D1-05; met: PR #3617 merged on 3 October 2026, f5318074d). Chris's approval of the G0 dossier (not yet given; the only item still open); the sitting-1 decisions answered (delivery operating model §2.8): D1-02 to D1-09 (met on 3 October, with D1-01 decided earlier; decision register §1.13), the Q-03 catalogue subset (met on 3 October: Q-03 approved as recommended; decision register §1.14) and D4-18's mapping part (met on 3 October: "independent of funders", with the recorded reading for Chris to confirm in the G0 dossier), plus D3-14 and D3-15 only if S0-4 and S0-7 are to be enabled early; tester panel named (met on 3 October: five for T1, three for the rest, per D1-06; no external SyRF users named yet); joint sequencing with #3961 (met: D1-02); a direction for #3987 (met: activate, D1-03) and the date for its activation (met on 3 October: from 5 October 2026, staging first, production the following week as a target that keeps its own approval); PR dispositions (proposed in the G0 dossier: QM v2, #2224, the dormant schema and profile PRs, #2469, the notification merge train ordered by D1-09, with the #3965 restack subject to the stack owner). Since 5 October: D3-14 and D3-15 are decided by the owner session; the tester panel stays as named, with no external recruitment now (D3-08); the PR dispositions are not authorised and no dormant PR is closed; G0 is not approved and implementation is on hold	S0; the M0 skeleton; R1b (#3964 merged on 3 October 2026); R1a's audit, browse and preview; the W0 prototypes; the F1a, F1b, F1c and C15 v2 ADR drafts; the presence owner's baseline docs PR	Chris
S0 Scaffolding (a T3 release, not a freeze)	Nothing	Eight slices merged dark: module skeleton, fixture corpus with the PRISMA fixtures as data, baseline benchmark on today's main, seed-if-absent job, STATUS and templates, flags and kill switches registered once, acceptance tooling, concurrency-barrier and mixed-version harnesses (AC-S0-01 to 07)	—	Chris reads the summary
M0 go/no-go	Storage, commit-shape and E25 evidence	The walking skeleton (one form through engine, CAS, Study.CanonicalSummary, FEAT-024's source-write seam, draft, dark AF2 adapter and export) green; the AC-M0-02 thresholds met, including zero engine-caused exhausted submissions at 1, 2, 5 and 10 reviewers (D1-08)	The F1a ADRs may freeze	Chris
F1a Engine contracts	C1, C2, C3, C5, C16, C18, C19; the storage ADR (E15) with the Study canonical summary; E20 as a form-keyed projection with per-reviewer markers; drafts with the tab lease (E21); E25 (no per-project document in interactive transactions); E27; the canonical command ledger replacing E35; C4's definitions part (identity, content versions, composition, E23, E24); the StageSettingsVersion envelope; C7 identity and the claim contract v2 with hub, DTO and command versioning; the writer and reader inventory; the context map and fitness tests; the evidence aggregate boundary and collection map; the command catalogue and hosting rule; the glossary and naming ADR; the CanonicalScopes marker; context-key and EntityTypeId identities; the ScreeningOutcome facet shape	Entry: M0 go; the sitting-2 decisions answered (delivery operating model §2.8); the freezes depend on D2-01 to D2-16, D1-08's F1a part (thresholds confirmed from M0 evidence), D3-17 (C7) and the F1a parts of D3-16 (the claim contract fields and route seam), D4-06 (the R1a catalogue) and D4-12 (observation markers in C3); X-ARCH-a (#3973, and #3985 or the isolated-read and non-upsert architecture test, D1-02); #3987 decided (met on 3 October: activate, D1-03); the presence owner's docs PR merged. ADRs approved; C# and TypeScript fakes and conformance suites green against fake and real providers; FEAT-024, bulk-lock, repository-cache, presence and AF2 checklists run and their exceptions ruled on; the presence and FEAT-024 checklists cover the claim contract and the CanonicalSummary shape	R0; R2a backend; R2b backend against fakes; the AF2 per-project admission input	Chris; checklists
F1b Catalogue and export disclosure	C10 catalogue and export disclosure (the disclosure matrix; realtime presence as a channel); C11 versions; the C15 v2 capture contract and disclosure hook	Entry: the sitting-3 decisions answered (delivery operating model §2.8); the freezes depend on the Q-03 catalogue subset (answered on 3 October as a G0 input) and D3-20 (C10). ADRs approved; the catalogue coverage test extended; the disclosure probe-suite skeleton; authorization and notification checklists	R2a exports; the C15 v2 implementation (notification programme)	Chris; checklists
F1c IA, copy and AF2 seams	C17 IA and the copy deck; the AF2 extension points merged as code; the Dockview layout-contract amendment (history panel); the shell per-project admission seam	Entry: the sitting-3 decisions answered (delivery operating model §2.8); the freezes depend on D3-01 to D3-04, D3-06 and D3-08 (D3-15 before S0-7's browser projects count as evidence). U9 (ordinary editor), U13, U14, U15, U26, U27 (navigation part), U28, U31, U32, U34, U35 (panel), U38, U39, U42 and U43 passed against their pass bars; seam PRs merged by the shell-writer stream with flags-off behaviour identical; layout, AF2 and Material 3 checklists	R2a UI; R1a's default-entry slice	Chris; checklists
F2 Publication	C4 publication (two-phase; publication writes no evidence, Superseded (5 October): publication may write attributable generated session versions, D2-01 amended; F2 includes the generation table and the draft rebase rule), C8 usage families with new scope kinds by a FEAT-024 technical-plan amendment, the definition-rewrite fence and the digest plan	Entry: the sitting-4 decisions answered (delivery operating model §2.8); the freezes depend on Q-31 (answered), Q-34, Q-20, the Q-03 Publish subset (approved on 3 October; it freezes here), D2-01, D2-10, D2-11 and D3-10 (a, b, d). FEAT-024's new-family onboarding contract; the FEAT-024 checklist; U4 (Fix part), U6 (revised), U5 (publication part), U37 and U40 passed	R2c	Chris; FEAT-024 checklist
F3 Workflow	C6 (including the Q-24, Q-15 and Q-28 mappings and D3-18; since 5 October the stage study filter version, step kinds, exclusion-stop and continuation settings replace the cross-stage route policy), C7 routing, the Stage aggregate and settings placement, C12 write-shaping parts with amendments A and H, C17 DTOs and coexistence	Entry: the sitting-5 decisions answered (delivery operating model §2.8); the freezes depend on the Q-03 stage-lifecycle and Monitor subset (approved on 3 October; it freezes here), D3-05, D3-07, D3-09, D3-12 (first part), D3-13, D3-16 (production route), D3-18, D3-19, D3-23 (R3c), D4-04 and D4-19 (D3-17 is already answered at F1a). Eligibility, allocation, presence, batch and navigation checklists; R3c's readiness source decided; X-ARCH-d scheduled before R3a's build; U2, U5 (route part), U7, U10, U12, U30, U33, U34 (F3 part), U35 (tour) and U38 (F3 part) passed	R3a (with the absorbed eligibility slices and the eligibility per-project admission slice); R3c design	Chris; checklists
F4 Reconciliation	C9 (task key, shared gold, drift, legacy authority, authority policy; since 5 October the legacy-authority part is removed with Q-35, and the authority policy carries ReconciliationPolicy.targetOneHandling and AcceptedResultVersion), the editable AF2 reconcile host, the reconciliation-task editor claim (X-RECLAIM)	Entry: the sitting-6 decisions answered (delivery operating model §2.8); the freezes depend on the Q-03 reconciliation subset (approved on 3 October; it freezes here), Q-29, Q-35, Q-36, D2-09, D3-11, D3-25, D4-03, D4-12 (F4 part), D4-17 and D4-20. U1, U4 (reconcile part), U16, U20, U21 and U36 passed; AF2 and presence checklists	R4a	Chris; checklists
F5 Profiles	C4 profile versions and publication, C8 profile-version usage, the AF2 screening-renderer contract, the PRISMA phase mapping	Entry: the sitting-6 decisions answered (delivery operating model §2.8); the freezes depend on Q-26, D3-10 (c: profile-grain screening statistics), D4-01, D4-02, D4-05 (amendment rule) and D4-13. AF2 and FEAT-024 checklists; U9 (profile part), U17, U18, U33 (F5 part) and U44 passed	R3b; R4p design	Chris; checklists
F6a As-of	C11 as-of rules (watermark, per-dataset coverage, retention)	Entry: the sitting-7 decisions answered (delivery operating model §2.8). C11 ADR approved; U22 passed	R5a	Chris
F6b Reporting	C12 report semantics and manifest	Entry: the sitting-7 decisions answered (delivery operating model §2.8). Amendments B, E and F (Q-06b); Q-22, Q-23; the FEAT-011 change-policy checklist; U23 passed	R5b	Chris
F-P Identification	C12 identification part	Entry: the sitting-7 decisions answered (delivery operating model §2.8). Amendments A, C and D (Q-06a, answered); amendments J, K, M and N (Q-37, D3-12's identification part, D4-05 (search fields), D4-07); amendment O (D4-08); Q-33; the deletion-lifecycle design join; X-IMPORT. Since 5 October: C21 (duplicate consolidation and reversal); amendment O is replaced by prepared multi-source links (D4-08 brief item); Q-33, Q-37, D4-05 and D4-07 decided	P1, P2	Chris; FEAT-011 checklist
F-C Classification	C13	Entry: the sitting-7 decisions answered (delivery operating model §2.8). Q-19; E14; U3 passed	C1, C2	Chris
F-O Outcomes	C14, including confirmation of A-20	Entry: the sitting-7 decisions answered (delivery operating model §2.8). Q-17; D4-06 (F-O part); E12, E14; U24 passed	O1; O2's build (execution separately)	Chris
F-A Allocation	C7 allocation part	Entry: the sitting-7 decisions answered (delivery operating model §2.8). The allocation checklist; X-AUTH-RESOLVER	AL1	Chris; allocation checklist
G-NOTIF (an activation gate, per environment and kind family)	Nothing	The G-NOTIF sitting's decisions that apply answered (D3-21, D3-22 and D3-24; delivery operating model §2.8; since 5 October D3-22 and D3-24 are decided, D3-21 is a brief item, and notification delivery is not authorised under the hold); X-NOTIF met (#3932 to #3943 merged with flags off); per-project notification admission; a delivery halt; inbox reads independent of capture; the email-to-inbox dependency; disclosure fixtures; flood controls before publication notices	Enabling that kind family in that environment	Chris

6.2 Ship gates

Every PR meets the merge criteria on its exact head (acceptance criteria §2.1 and the M rows of the UI standard in §3). Every release then passes its activation criteria once, on a recorded release candidate (commit and image SHAs deployed to staging): its own rows in acceptance criteria §4, its conformance row (AC--CONF), the rows of §2.2 and §2.3 that apply to it, and its pilot rows in §5. A row whose status is pending, PROPOSAL or conditional never counts as passed. How much evidence a release needs depends on its tier (acceptance criteria §8.3; delivery operating model §7).

Tier	Releases	Activation evidence beyond the release's own rows
T1 heavy	R0, R2a, R2c, R3a, R4a, P2, O2; GA, the R6 waves and R7 under their programme gates	Staging image-rollback rehearsal plus the mixed-version harness; five testers; Bramble benchmarks for every named hot path the release touches; run:e2e-full on the candidate; supervised review
T2 standard	R1a to R1d, R2b, R2d, R3b, R3c, R3d, R4p, R4b, R4c, P1, C1, O1, AL1	The mixed-version harness when the release persists data; a staging rehearsal only for a floor step; three testers (five for R3d); benchmarks only when a named hot path changes
T3 light	S0, R5a, R5b, R5c, C2; X1 if D4-09 is approved (approved on 4 October)	AC-ALL-03, 08, 13, 19 and 21, its own rows and one walkthrough

M0 is a milestone: T1 evidence rules with a go/no-go record instead of activation. The rollout plan sets tiers for the owner-session lanes and the P2 split (PROPOSAL).

The common checklist:

1. The release's own criteria, its conformance row and its fixture parts pass on the candidate, including the PRISMA fixture parts first required in the release (acceptance criteria §7.2); the invariant monitor reports zero violations on every admitted project (AC-ALL-21).
2. Capability tests: positive, negative, revocation and blinding cases for every new endpoint, view, SignalR message and notification kind, and the disclosure probe suite (AC-ALL-03, AC-ALL-19).
3. Flags off and legacy projects behave identically (AC-ALL-01, AC-ALL-02), and flag combinations fail closed (AC-ALL-17).
4. Rollback by tier (AC-ALL-04): the mixed-version harness for T1 releases and T2 releases that persist new data; a staging image-rollback rehearsal, with canonical data present, for T1 releases and floor steps, in an approved promotion-pause window.
5. Accessibility and the UI standard: UI-1 to UI-11 and AC-UX-09 for every new or updated screen, at the width matrix in acceptance criteria §3.1 (not only the v10 1440/925 px widths), with the tier-1 design-QA evidence per PR and Chris's release-level acceptance on staging (pending D3-02; a brief item since 5 October). The 390 px row covers full annotation as well as screening (D3-05), and Firefox, WebKit and touch journeys apply (D3-15).
6. User testing for the release's tier (AC-UX-01 to AC-UX-09, with the tasks and rubrics in acceptance criteria §5.3); pilot entry rows held at pilot start (§5.2) and pilot exit criteria PE-01 to PE-08 met (§5.1); staging acceptance by humans on the recorded release candidate.
7. Production prerequisites (§5.11) met before any production pilot.
8. Engineering docs updated in the same PRs (stale docs block the merge); user-guide pages drafted under [TARGET - Phase N] markers and published at production enablement.
9. Any notification kind the release adds is enabled only through G-NOTIF, per environment and kind family (AC-ALL-29).
10. A fresh-context ship-gate verifier report with no open exceptions (AC-ALL-13) and the release's acceptance record committed (acceptance criteria §9.2), then Chris's go/no-go.
11. The release's specification acceptance evidence (RD-AE, DM-AE, SP-AE, RS-AE, BC-AE, TI-AE, RI-AE, UX-AE and AC-AE rows placed in it) passes, and its tracker row records the evidence (PROPOSAL, added for the owner session on 5 October; implementation tracker).

G-GA, G-ADOPT (per wave: approved manifest, separate execution authority, rehearsal, scope completeness) and G-RETIRE (empty consumer inventory, restore rehearsal, retention approval) follow the same pattern.

6.3 Dependency graph

Solid arrows are ship dependencies; dashed arrows are external joins.

X-RECLAIM is built inside R4a by L6 with the presence owner; it is drawn as a join because R4a's production gate depends on it in every environment. G-NOTIF is an enablement gate, not a ship dependency: notices reach users only after Chris approves the environment and kind family. X-ARCH-a points at F1a, the engine-contract freeze.

The graph shows the structure of 3 October. The rollout plan draws the owner-session changes: the P2a, P2b and P2c split, lanes TR1, XS1, XA1 and RW1, the PWA1 exploration, deferred answer-based branching (BR1), R6 as universal conversion waves and R7 as the legacy-writer retirement milestone.

flowchart TB
    G0[G0 Plan approval] --> R1a[R1a Templates and import]
    G0 --> R1b[R1b Groups visibility, owner-only]
    G0 --> S0[S0 Scaffolding]
    G0 --> M0[M0 Walking skeleton]
    S0 --> M0
    M0 --> F1a{F1a Engine contracts}
    F1a --> R0[R0 Compatibility floor, admission]
    R0 --> R2a[R2a Versioned forms, immutable sessions]
    F1b{F1b Catalogue and disclosure} --> R2a
    F1c{F1c IA, copy, AF2 seams} --> R2a
    R2a --> R2b[R2b Shared sessions]
    F2{F2 Publication freeze} --> R2c[R2c Publication with impact]
    R2a --> R2c
    R2a --> R2d[R2d Overlap, outdated flags, Fix]
    R2c --> R2d
    F3{F3 Workflow freeze} --> R3a[R3a Steps, routing, decisions]
    R2a --> R3a
    F5{F5 Profile freeze} --> R3b[R3b Screening profiles]
    R3a --> R3b
    R2c --> R3b
    R3a --> R3c[R3c Lifecycle]
    R3b --> R3d[R3d Guided setup]
    R1a --> R3d
    F4{F4 Reconciliation freeze} --> R4a[R4a Form reconciliation, gold]
    R2b --> R4a
    R4a --> R4p[R4p Profile reconciliation]
    R3b --> R4p
    R4a --> R4b[R4b Queries]
    R4a --> R4c[R4c Outcome reconciliation]
    R1b --> R1c[R1c Groups and permissions dialog]
    R1c --> R1d[R1d Delegation]
    FC{F-C freeze} --> C1[C1 Classification]
    R2a --> C1
    C1 --> C2[C2 Inference]
    FO{F-O freeze} --> O1[O1 Outcome schemas]
    R2a --> O1
    O1 --> R4c
    O1 --> O2[O2 Outcome migration]
    FA{F-A freeze} --> AL1[AL1 Shared-form allocation]
    R2b --> AL1
    FP{F-P freeze} --> P1[P1 Identification provenance]
    R0 --> P1
    P1 --> P2[P2 Identification, dedup]
    R3b -.reviewed records.-> P2
    P1 --> O2
    F6a{F6a As-of freeze} --> R5a[R5a As-of export]
    R4a --> R5a
    R4a --> R5c[R5c Agreement statistics]
    F6b{F6b Report freeze} --> R5b[R5b PRISMA reporting]
    P2 --> R5b
    R4p --> R5b
    R4c --> X1[X1 Analysis-ready exports]
    R5a --> X1
    R2d --> GA((GA canonical default))
    R3c --> GA
    R3d --> GA
    R4p --> GA
    GA --> R6[R6 Adoption waves]
    R6 --> R7[R7 Retirement]
    XSCHEMA[[X-AUTH-SCHEMA]] -.-> R1c
    XENF[[X-AUTH-ENFORCE]] -.-> R1c
    XWP9[[X-AUTH-WP9]] -.explanations.-> R1b
    XWP9 -.-> R1c
    XRES[[X-AUTH-RESOLVER]] -.per-reviewer preview.-> R3a
    XRES -.-> AL1
    XSA[[X-STATS-a]] -.staging pilot.-> R2c
    XSB1[[X-STATS-b1 gate b]] -.-> XSB2[[b2 soak]]
    XSB2 -.-> XSB3[[b3 pending index]]
    XSB3 -.-> XSB4[[b4 rollout approval]]
    XSB4 -.-> XSB5[[b5 production eligibility]]
    XSB5 -.-> XSB6[[b6 usage family built]]
    XSB6 -.-> XSB7[[b7 staging proof]]
    XSA -.-> XSB7
    XSB7 -.materialised production.-> R2c
    XSC[[X-STATS-c target-aware]] -.allowlisted pilots.-> R2b
    XSC -.-> R3a
    XELIG[[X-ELIG]] -.production.-> R3a
    XELIG -.activation.-> XBATCH
    XAF2[[X-AF2]] -.production.-> R2a
    XSHELL[[X-SHELL]] -.production.-> R2a
    XCLAIMS[[X-CLAIMS]] -.production claims.-> R2b
    XCLAIMS -.production reservation.-> R3a
    XRECLAIM[[X-RECLAIM]] -.all environments.-> R4a
    XBATCH[[X-BATCH]] -.-> R3c
    XPR9[[X-AF2-PR9]] -.-> R4c
    XPDF[[X-PDFTOOLS]] -.-> O1
    XPDF -.-> R4c
    XDEL[[X-DEL]] -.-> P1
    XIMP[[X-IMPORT]] -.-> P1
    XARCHA[[X-ARCH-a]] -.-> F1a
    XARCHB[[X-ARCH-b]] -.-> R0
    XARCHC[[X-ARCH-c]] -.-> R0
    XARCHD[[X-ARCH-d]] -.-> R3a
    XNOTIF[[X-NOTIF]] -.notices.-> R1c
    XNOTIF -.notices.-> R2c
    XNOTIF -.notices.-> R3c
    XNOTIF -.notices.-> R4a
    XNOTIF -.notices.-> R4b
    XNOTIF -.-> GNOTIF{{G-NOTIF per environment and kind family}}
    XARCHC -.-> GNOTIF

6.4 Critical path

The GA path is the latest of six chains (delivery operating model §6):

1. Internal chain: G0 → S0 and the M0 walking skeleton → F1a → R0 (staging rehearsal) → R2a (backend at F1a, exports at F1b, UI at F1c) → three branches: R2b → R4a [F4] → R4p; R2c [F2] → R2d; R3a [F3] → R3b [F5, R2c] → R3c, R3d [R1a] and R4p [R4a] → GA readiness (coexistence UI, guided-setup parity, help and "what changed" pages). The earlier chain left out R2d, R3c and R3d.
2. Statistics chain: X-STATS-b1 to b7 (programme integration §7.2). Two of its steps follow this plan's gates (b5 after F1a, b6 after F2). It gates R2c's production publication beyond named pilots, and GA: Chris chose to activate #3987's families (D1-03, 3 October), so Q-31(b) is not extended to GA. Under Q-31, R2c's first production pilots are expected to count authoritatively at the protected boundary: the designed first pilot path, with the materialised family a swap-in behind the same interface.
3. Eligibility chain: X-ELIG (paused programme; remaining slices absorbed into R3a if Chris agrees, D3-09).
4. Admission chain: X-AF2 and X-SHELL, built as plan-owned slices on R0's enrolment service. GA needs AF2 and the redesigned shell on for every new project.
5. Claims chain: X-CLAIMS (presence and FEAT-024 owners; route per D3-16) for R2b claim behaviour, R3a reservation admission and any capacity promise in production. The reconciliation-task editor claim (X-RECLAIM) is internal to R4a and frozen at F4, so "tracking enabled" is no longer an R4a prerequisite.
6. Approver throughput: about 89 open decisions, 14 freeze gates, the M0 go/no-go and 27 ship gates pass through one person. (After the owner session of 5 October: one open owner decision, D2-09; the owner-visible confirm items in the specifications; G0-D1; G0 approval; the hold lift; ten brief approvals, T-RD-00 to T-DH-00; and five specialist inputs, T-SI-01 to T-SI-05.)

The binding constraint is approver throughput. Then, in likely order: the statistics chain with

3987, X-ELIG, tester availability and X-CLAIMS. Engineering is not among them (A-36). Since

5 October the implementation hold comes first: nothing on any chain starts until Chris lifts it.

R0 soak is per environment. A staging rehearsal gates staging canonical writes. One production promotion cycle plus seven days without deserialisation errors gates the first production canonical write. R2a builds meanwhile.

Full-scope tails run in parallel and don't hold up GA: P1 → P2 → R5b (which also needs R3b and R4p); O1 → R4c (which also needs AF2 Phase 4 PR 9 and X-PDFTOOLS) → X1 (which also needs R5a and D4-09); R4a → R5a and R5c; C1 → C2; R2b → AL1; R1b → R1c → R1d (behind the authorization gates and #3941).

Early-value track (each step also waits for the hold lift and its brief's approval since 5 October): #3964 (merged on 3 October 2026), then R1b straight after G0; R1a's browse and preview; R2a opt-in production pilots (D1-07, approved on 3 October) once R0's production soak and the admission slices hold; R4a straight after R2b and F4, not after R3a.

7. Parallel work plan

Work is scheduled by a dependency-driven ready queue, not by windows (delivery operating model §5). A release's slices may start building once its freeze gate has passed and the fakes they consume are merged. A release ships when its graph predecessors have shipped, its joins hold and its ship gate passes. Production enablement is a separate step with its own evidence.

WIP limits (PROPOSAL): per stream, at most two releases building and one in acceptance, and at most four open non-draft PRs; programme-wide, at most three releases in acceptance and eight items waiting on Chris. Finish before starting. At the weekly review, conflicting PRs older than seven days are rebased or closed with a harvest note. While the hold lasts, this rule closes nothing: the owner session authorised no dormant-PR closure.

Conditions the earlier windows hid (brackets): R4a [F4, R2b], not R3a; R2d [R2c]; AL1 [F-A, R2b, X-AUTH-RESOLVER]; C2 [C1, Q-18]; P2 [P1; R3b for the reviewed part]; R4b [R4a]; R5a [F6a, R4a]; R1c [X-AUTH gates, #3941]. The full start, ship and production conditions per release are in the operating model §5.3.

Illustrative timeline only. The windows below show a plausible order and overlap if every item became ready as early as its conditions allow. They are not a schedule, carry no dates and gate nothing.

Window	Typically opens when	Work
Before G0	Package submitted	Batch D1 answered (all nine by 3 October 2026; decision register §1.13); step 0 merged the package to main (D1-05; PR #3617 merged on 3 October 2026, f5318074d); #3964 merged on 3 October 2026 and #3969 is closed (D1-01); the G0 inputs given late on 3 October (Q-03, D4-18, the tester names for D1-06 and #3987's activation date for D1-03; decision register §1.14); Chris approves the G0 dossier. Nothing is built under this plan before G0. Added on 5 October: the owner session of 4–5 October is integrated (PR #4045), feature implementation is on hold, and the design-prototype handoff is written without messaging the design session
W0	G0, the hold lift and the approved briefs for its items	S0 scaffolding; the M0 walking skeleton; R1b; R1a's audit, browse and preview; #3985 and #3973 (architecture review); the F1a, F1b, F1c and C15 v2 ADR drafts; the presence owner's docs PR; the notification merge train; the baseline study; U1 (prototype), U3, U8 (visibility), U9 (ordinary editor), U13, U14, U15, U19, U24, U26, U27 (navigation), U28, U31, U32, U34, U35 (panel), U38, U39, U42, U43; the accessibility and browser harness (E85) and the copy deck mechanism (E83); Bramble: FEAT-024's gate (b) rerun, then the S0 baseline
W1	M0 go and F1a	R0 build and staging rehearsal; R2a and R2b backends against fakes; F1b and F1c; C1 [F-C] and O1 [F-O] design; F2 work with FEAT-024 (onboarding contract, usage families); F3 work; R1a and R1b ship; U2, U4, U5, U6 (revised), U7, U8 (dialog), U10, U11, U12, U30, U33, U35 (tour), U37, U40
W2	R0's staging rehearsal, F1b and F1c	R2a UI on the merged seams; R2a acceptance and staging pilot; R0's production promotion and soak; the X-AF2 and X-SHELL admission slices; R2c [F2]; R3a [F3, X-ARCH-d]; P1 [F-P, X-IMPORT]; F4 and F5 work; U1 validation, U8 (delegation), U9 (profile part), U16, U17, U18, U20, U21, U36, U41, U44
W3	R2a shipped	R2b ships; R2c ships (staging pilot under X-STATS-a; production pilots under Q-31(b)); R2a opt-in production pilot [D1-07]; C1 and O1 ship; R4a [F4] and R3b [F5] build; R3a acceptance; U22, U23, U27 (both project kinds), U29, U45
W4	R2b shipped and F4 passed	R4a ships, not waiting for R3a; R2d [R2c]; AL1 [F-A]; R3a ships; R3c and R4b build
W5	R3a and R2c shipped	R3b and R3c ship; R4b, R5a [F6a] and R5c [Q-04, Q-16] ship; P2 and C2 build
W6	R3b and R4a shipped	R4p and R3d ship; P2 ships; R4c [O1, X-AF2-PR9, X-PDFTOOLS]; R5b builds [F6b]
W7	R4p shipped; GA criteria	R5b ships; X1 [R4c, R5a, D4-09]; GA readiness review; production pilots per family (D1-07)
W8	GA	R6 adoption waves, each through G-ADOPT; R7 after the waves (G-RETIRE). Since 5 October: staging trials and production pilots run earlier as scopes complete; R6 converts every remaining project in universal waves; R7 is the legacy-writer retirement milestone
Floating (owner session)	Each lane's brief approved and its dependencies shipped	TR1 (training); XS1 (external and AI-model screening), XA1 (annotation-answer imports) and RW1 (redesign wizard) after GA in the rollout plan; the PWA1 exploration beyond the MVP; BR1 stays deferred
Floating	External gates clear	R1c [X-AUTH-SCHEMA, X-AUTH-ENFORCE or parity tests, X-AUTH-WP9, #3941]; R1d [R1c, Q-03]; O2 execution only with separate approval

The reviewer workspace is a serialisation point, managed by one writer. R2a, R2b, R2c, R3a, C1, O1, R2d and R3b all change the same large AF2 and stage-review files, and AF2's rule is one writer per worktree. So one stream (C) is the sole writer of those shell files. It merges the AF2 extension points (step host, history panel, outdated and provenance markers, population context, outcome-schema entry) as code at F1c. After that, a slice that needs a shell file takes a lease on it; the first ready slice lands and the later one rebases. Other streams build behind the extension points and reach AF2 through its ports. The reconcile host for R4a and R4c is a separate host and can proceed in parallel.

Coordination rules:

1. Contracts first. The provider stream publishes the interface, DTOs and a fake at the freeze gate. Consumers build against the fake and integrate early: each release's first code slice is a thin end-to-end path behind its flag, and no release merges more than three slices against fakes alone before an integration slice.
2. Change control. Contract changes go through an ADR amendment and the consumers' checklists. Conformance suites run on every PR that touches contract code.
3. Small trunk-based PRs. About 800 changed lines of non-generated, non-test code or fewer, with exceptions declared; flags default off and registered once in S0; no long-lived integration branches; stack depth at most two; generated files regenerated, never hand-merged; one writer per worktree; PR worktrees created with wt under pr/ only after the claim step.
4. Existing programmes keep ownership (statistics, allocation, presence, batches, notifications, AF2, eligibility, authorization, deletion lifecycle, architecture review). This plan's streams request contract amendments, run the programmes' checklists and attend their joins.

8. Integration with ongoing programmes and open PRs

States as read at 15:18 BST on 3 October (main de3e98c59); see the inventory for heads and programme integration for evidence, recommended changes to each programme and what not to build yet. Every PR listed is authored by chrissena (Chris's account, used by his delivery sessions) except #2224, authored by nurikarakaya. Owner-session note (5 October): the dispositions below that close or harvest a PR are not authorised while the hold lasts, and the integration did not re-read these states. The owner session also leaves existing tester scope unchanged and turns no suggested production date into a commitment.

Programme / PR	State	What this plan needs	Join
AF2 parity (#3546 conflicting; #3543 mergeable; #3394, #3292, #3017 and #3288 conflicting and stale)	Open	PROPOSAL for the exit set, to agree with the AF2 owner: land #3546 and #3543; close or supersede #3394 (Focus contract), #3292 (Dockview), #3017 (re-check against bounded rendering) and #3288 (acceptance evidence)	Before R2a UI
AF2 Phase 4 PR 9; editable reconcile host	Planned / not planned	PR 9 lifts host carve-outs; a new editable host contract	F4, R4c
FEAT-024 statistics (fold slices 0–7, #3955 and #3956 merged; no FEAT-024 PR open; gate (b) failed on latency on an idle host (3 October, #3510); soak #3510/#3952 open; staging fold flag pinned on)	Active, dark; production fold enable refused in code	Source-write seam with a projection-only shape; target-aware classification (E71); canonical-sources amendment with new families and scope kinds (E72); scoped-rebuild service API; protocol 5 once, after gate (b); #3524 after C16; activation (D1-03 chose activate; Chris set the date late on 3 October: from 5 October 2026 in staging, production the following week as a target that keeps its own approval and waits for X-STATS-b1 to b7)	F1a, F2, F3, F5; X-STATS-a, X-STATS-b1–b7, X-STATS-c
Proportional allocation (MVP and regime provenance #3603 merged, dark; #3327 conflicting; reviewer validity blocked on #3251; no human acceptance yet)	Partial	Membership-facts seam (E64); allocation refused on canonical stages until AL1 (E65, D3-13a); RA5 scoped admission (E66, D3-13c); AL1 after allocation Phase 2 with regime schema v2	F1a, F-A; X-AUTH-RESOLVER
Active reviewer tracking, claims and presence (merged; off in every deployed environment; on in E2E; M15 unowned; #3876 deferred)	Behind flag	Claim contract v2 and one reservation migration (E68); production claims route (E69, D3-16); R0 and R2a adapters (E70); reconciliation-task editor claim (E6)	F1a, R0, R2a, R2b, F4; X-CLAIMS, X-RECLAIM
Progressive batches (#3936 plan mergeable; #3939 conflicting, 63 files; its denominator decision is not in the ledger)	Open	#3939 merged in slices (D3-13f); evidence seam, pool-entry membership, durable opening with pool-entry events, read-only status, performance gate (E67); denominator recorded (D3-13b)	F3; X-BATCH (after X-ELIG)
Review eligibility (S1a, S1b, S2, S2-C, S3, S4-A and the claim-revoked event merged; #3746 conflicting; #3742 draft without files; #3741 draft audit; flag reaches the API host only)	Paused since 25 September (session memory; not recorded in the repository; A-31)	C6 extends ReviewEligibilityPolicy through the membership-facts seam; X-ELIG enumerated (S4-B, S4-C, S6a, S6b, fixed-two correction, Project-token redesign, flag delivery to PM); R3a absorbs S6b (D3-09); D8 mapping	F1a (seam), F3; X-ELIG
Authorization #3335 (M5b merged; WP1d, WP9, WP11; WP-M1/M2; gate G-D; resolver #3251 open)	Active	WP1d with R1b; WP9 explanations (X-AUTH-WP9) shown in R1b; WP11 delivered jointly as R1c after X-AUTH-SCHEMA and X-AUTH-ENFORCE; the out-of-request resolver (X-AUTH-RESOLVER) for R3a's per-reviewer preview and AL1; presence, study-issue and PDF-correction capabilities in the catalogue; PROPOSAL: split WP11 so a dialog over existing groups can come earlier	R1b, R1c, R3a, AL1
Bulk update v2 and study locks (#3914, #3909 merged)	Behind flag	Canonical commits honour locks and bump Study versions	F1a
Architecture review (#3961, draft; issues #3972–#3990; Phase 0 fixes #3967, #3968, #3970, #3971 merged)	Active (another session)	#3985 and #3973 before F1a (X-ARCH-a); #3986 decided before R0 (X-ARCH-b); #3975 before R0 and any G-NOTIF evidence (X-ARCH-c); #3979 and #3980 before R3a (X-ARCH-d); ProjectStatistics activation (#3987, D1-03: activate); v0/v1 retirement (#3988) folded into E24 or after R2a; #3989 as stream C seam slices under the shell-writer rule (§7); its frontend bug-fix plan's SignalR reconnect fix (#3976) before tracked pilots and G-NOTIF, and its AF2-save and stage-review-effects PRs ordered by the shell-writer stream; one writer per canonical collection	F1a, R0, R3a; D1-02
Search import robustness (#2612 staged-import plan, docs only; parse job 5-minute timeout)	Planned	X-IMPORT: staged import implemented, sized timeout with heartbeat and watchdog, idempotent sagas, pending-dedup aligned with staged-pending status	P1
Feature-flag overhaul (P7 per-project targeting)	Planned	R0's admission record (CanonicalEnrolment) is the domain enrolment P7 keys to; AF2 per-project pilots route through it	F1a
Application authority transition (queued-work ledger, job-family classification)	Approved (2 October)	M5/P9 classification and broker rules for every new job family	C16; each release ADR
Deletion lifecycle (ADR-014, in an uncommitted worktree: 24-hour grace period, then physical deletion with content-free tombstones; deletionLifecycle flag)	Routes fail closed today	Search withdrawal keeps Citations and canonical evidence; whole-project deletion keeps ADR-014's removal with a tombstone (D3-12); ADR-014's manifest covers the canonical collections. Superseded (5 October) for whole projects: ordinary project deletion is reversible (hide, block, stop allocations and notices, release places, keep drafts, data and history; restore through a restricted view), and physical erasure needs the unapproved policy T-POL-01 (D3-12 amended, OS-A25). The design needs a new ADR number, because ADR-014 on main is the PDF viewer	F-P, X-DEL
PDF acquisition and processing (bulk PDF upload, PDF Agent, Study Management Processing, PDF corrections, checked PDF proposals #3947 owned here; AF2 pdf-tools migration unscheduled)	Mixed, flagged	Retrieval status for P1; an approved PDF recorded as a P1 retrieval event; X-PDFTOOLS for O1 and R4c	F-P, O1
M3 navigation (rail and checklist footer rebuilt in September)	Merged	IA changes coordinate with its owner	F3
Notification stack (#3932 conflicting → #3938 → #3941 → #3942 → #3943 → #3944 → #3945 → #3947; #3965 open and ready, its 10 Q-10 commits pushed (head 986b1cdc2, about 20:35 BST), stacked on #3947 and waiting for the stack (D1-09); stack E2E never run in CI)	Open, stacked	C15 v2 (E73); tolerant preferences before #3942 merges; enablement controls and G-NOTIF (E74, D3-21); merge order with #3965 restacked onto #3944 (D1-09); #3941 aligned to the active decision path; "questioned in reconciliation" exposure in C3; StudyConversation to L6 at R4a; study issues and checked PDFs to the Study Management and PDF programmes	F1b (C15 v2), per release; X-NOTIF; G-NOTIF
Template import (#3934, #2781, both conflicting)	Open	R1a; see the harvest map	R1a
Custom project groups (#2224, conflicting)	Open; its author has left	Harvest its API shape and tests into R1c (Chris, Q-09), then close it; the closure waits for G0 and the hold lift (owner session, 5 October); see the harvest map	R1c
QM child visualisation and assign tree (#2387, conflicting)	Open	Review for reuse in the R1a/R2a designer; see the harvest map	R1a
QM v2 stack (#2572 conflicting; #2573–#2575 stacked; #2461 draft)	Dormant since April	Harvest, then close (Chris, Q-08); the closure waits for G0 and the hold lift (owner session, 5 October); see the harvest map	G0, F1a
Schema/profile/response/validation (#2987, #2986 and #2629 mergeable; #2812 conflicting)	Dormant	Harvest #2986 into validation (the G0 dossier recommends instead keeping it open outside this programme, G0-D6, until Chris answers; the harvest map puts its fixtures and rule codes into F1a's E23 corpus, T-RD-01, either way); others are C4/C14 inputs; dispositions at G0; see the harvest map	G0, R2a
Screening-profile prototypes (#2621 draft, conflicting)	Dormant	Seven prototypes compared in the UI comparison	G0, F5
Reviewer no-work page redesign (#2412, conflicting)	Open	Align wording with R3c; progress consistent across stages (R2b)	R2b, R3c
Stage overview chart refactor (#2469, conflicting)	Open	Its stage-target chart change conflicts with SF2 and is partly superseded by #3776–#3795; disposition at G0	G0
Ownership-transfer security fix (#3964; duplicate #3969)	D1-01 decided (Chris, 3 October): keep #3964, port #3969's active-member check and tests, close #3969. Carried out: #3964 merged on 3 October 2026 at 20:27 BST (85e6facf7) after an approving review and green checks; #3969 is closed with a pointer to #3964	Owner-only transfer and no grants of owner-reserved activities; R1b's entry criterion; step 0 of the notification merge order	Merged independently (3 October 2026)
This research PR (#3617)	Merged on 3 October 2026 (f5318074d, D1-05)	Carried the owner ledger, the later research and this package to main as one docs-only PR (step 0); later changes go through ordinary docs PRs	G0 entry (met)

9. Verification, pilot and user testing

How much of this a release needs depends on its tier (T1 heavy, T2 standard, T3 light; delivery operating model §7). Merge criteria apply to every PR; activation criteria are evaluated once per release on a recorded release candidate (§8 there; acceptance criteria §1.3).

1. Contract conformance suites per contract (C1/C2/C5 and the applicability specification first), in path-filtered test projects with a five-minute target each, run on every PR that touches contract code, against both the fake and the real provider. Test IDs are C1-T01 onwards (acceptance criteria §7.5); each release's conformance row names the tests it must pass.
2. Domain and API tests: Mongo transaction and CAS tests on the replica-set fixture, with the deterministic barrier harness forcing every concurrency row's interleaving; permission, blinding and concurrency tests at every read and command boundary; AF2 component specs via pnpm exec ng test.
3. Compatibility tests: the mixed-version harness on every T1 release candidate, every T2 release that persists new data and every floor step; staging image-rollback rehearsals only for T1 releases and floor steps, in an approved promotion-pause window.
4. E2E journeys in the hermetic local e2e stack only, never against staging: per-spec runs locally for evidence; run:e2e-smoke on PRs that touch review flows; run:e2e-full once per T1 release candidate; the affected review flows in both tracking modes. Benchmarks run only in booked Bramble windows, with FEAT-024's gate (b) rerun first on the calendar (run on 3 October; it failed on latency), and are limited to named hot paths measured against the baseline recorded in S0.
5. Migration rehearsals: synthetic fixtures first, then authorised non-production copies.
6. Staging acceptance by humans on the seeded and tester-created pilot projects (acceptance criteria §6), on a recorded release candidate whose commit and image SHAs the acceptance note names.
7. Pilot projects admitted through R0's admission service, with the pilot entry rows and exit criteria PE-01 to PE-08 in acceptance criteria §5 (zero lost work, invariant monitor clean, no permission or blinding leak, minimum exposure, defects triaged by severity) and a documented pilot-operations procedure: who admits or removes a project, and what reviewers see if a pilot is rolled back to read-only.
8. User research and testing per the UX strategy §9: a baseline study of today's screening and annotation before the R2a build; formative sessions on each freeze gate's prototype pack with at least five participants per affected role, at least two external to CAMARADES (D1-06, decided on 3 October; the panel was named that night, with no external SyRF users yet; pending D3-08. Superseded (5 October): D3-08 is decided: the current tester panel, with no extra external recruitment now, and consent-based timing telemetry without answer content); summative sessions per release on staging with the seeded pilots and a realistic open-licence content project; pilot diaries. Every UI validation (U1–U45) runs at least one window before the build that consumes it and is exit evidence of its freeze gate. The UX metrics AC-UX-01 to AC-UX-09 are acceptance criteria with PROPOSAL thresholds; testers must explain which version counts (R2a), why a study is offered or locked (R3a), what a decision rests on (R3b), why an accepted answer is what it is (R4a) and what a publication will do (R2c), scored against model answers. Summative tester counts follow the release tier: five named testers for T1 releases and three for T2 (D1-06).
9. Copy deck (C17, F1c): one definition per term, typed message constants per feature, a banned-string guard spec and user-guide glossary parity. "Save progress", "Complete", "Changes kept, not yet saved", "Needs updating", "Outdated answers", "Fix", "Accepted answers (gold standard)" and "Screening result" are pending D3-03; v10's "Save draft" and v4's "All changes saved" are banned; one alias scheme across candidate cards, threads, history, presence and exports. Owner-session amendments (5 October): D3-03 and D3-04 are decided, with Material 3 sentence case. "Changes kept, not yet saved" is Superseded by "Draft auto-saved", and "Version checkpoint saved" follows Save progress; the words may iterate but the distinction is fixed (OS-A21). Aliases are context-local under form or profile blinding, with no continuity across Studies. AI sources are named "AI screening model" and their output "AI-model-generated screening decision"; "model decision" is banned.
10. Help and change communication: at most three reviewer-visible change bundles before GA; an in-product "What changed" panel from R2a, keyed by bundle with per-user dismissal; the anchored tour component from R3a; contextual help on every new screen; user-guide pages drafted under target markers and published at enablement, with the glossary parity check.
11. UI standard: every new or updated screen is consistent, modern and built with Material 3 (UI-1 to UI-11), verified by tier-1 design QA on every PR (theme guards, the screenshot matrix at the §3.1 widths in light, dark by token check, axe, a keyboard transcript, copy-deck compliance and a second agent's review against the handoff) and by Chris at release level on staging, with per-PR acceptance only for new shared patterns and five high-risk surfaces (pending D3-02; D3-01 and D3-02 are brief items since 5 October).
12. Review tiers: supervised (/claude-review opus, a fresh-context verifier and Chris reading the summary) for engine and CAS, transactions, migrations and adoption, authorization, blinding and disclosure, flags and admission, contracts, claims and CI routing; delegated (the default review) for the rest. Stack depth at most two; PRs retargeted to main before review. At each ship gate a fresh-context verifier maps every criterion ID to evidence and checks invariants 1 to 18 (AC-ALL-13; 13 to 18 were added by the owner session on 5 October).
13. Go/no-go: Chris decides at each ship gate from the dossier and the evidence the acceptance criteria require.
14. Acceptance evidence: fixtures are versioned data that xUnit and Vitest read alike (E99); the invariant monitor (INV-01 to INV-12) runs nightly on admitted projects and after every restore or adoption step; tests carry criterion IDs and the traceability check runs in docs CI (E94); each release's acceptance record lists every applicable row with its evidence on the recorded candidate (acceptance criteria §9).

10. Risks and mitigations

Risk	Mitigation
A rolling deploy or image rollback meets canonical fields it can't read, or a config change hands canonical scopes back to legacy writers	R0: capture (not ignore) one release ahead, the reader floor, ownership markers as data, the writer floor, image-rollback rehearsal
Revision storage inside whole-Study documents hits size, contention or transaction limits	Storage ADR at F1a with Study.CanonicalSummary (revisions never embedded); no per-project document in interactive transactions; benchmark on Bramble; aggregate-only size survey if authorised
A hidden writer or reader bypasses canonical commands (imports, bulk update, batch RoB, deletion scheduler, seeding, #3944)	Writer and reader inventory from M0, frozen at F1a; ownership markers and the composite write guard in R0; per-project fences (L15)
Statistics changes collide with the fold rollout, or production publication waits indefinitely for FEAT-024's production chain	The engine writes only through FEAT-024's source-write seam; new families by technical-plan amendment; Q-31(b) designed as the first pilot path; protocol 5 once, after gate (b)
Large publications exceed transaction limits	Publication writes no evidence (D2-01): an O(1) phase 1 and a phase-2 operation that rewrites projections by predicate; phase-1 time flat across 1k, 10k and 100k sessions. Superseded (5 October) for "writes no evidence": phase 1 still does constant work, and phase 2 writes generated session versions per Study in short idempotent transactions; the pause and operation limits are measured under D2-10 (RD-AE16, RD-AE26)
Generated session versions overwrite newer reviewer work in a race (owner session)	Compare-and-set on each session head, deterministic generated-version IDs, stale saves refused and rebased, barrier-forced race tests (RD-AE16, RD-AE18)
Reconciliation UI doesn't scale past two candidates	U1 prototypes and user tests before F4
Notification payloads leak candidate answers or identities	C15 uses the C10 disclosure policy; fixtures for every event; Q-10
Confirmed obligations (QY6, QY8, LC1, RA2–RA5) slip because the notification stack hasn't merged	Feature-owned queues are the source of truth; acceptance tests pass with notification flags off
Production pilots blocked by environment-wide flags owned elsewhere	Plan-owned per-project admission slices for AF2, the shell and eligibility reading R0's admission record (DS-04); per-flag decisions (Q-25); D1-07
The reviewer workspace serialises every lane	One shell-writer stream merges the AF2 extension points as code at F1c; afterwards a lease per shell file, the first ready slice lands and the later one rebases; other streams use AF2's ports
Dormant PRs drift further from main	Harvest-and-close dispositions at G0 and F1a; a weekly rebase-or-close for conflicting PRs older than seven days, with a harvest note. Since 5 October no closure is authorised while the hold lasts; harvest notes can still be written
Main moves quickly, and staging moves on every merge	Contract tests; PRs of about 800 non-generated, non-test changed lines or fewer; generated files regenerated, never hand-merged; acceptance on a recorded release candidate (commit and image SHAs); promotion-pause windows for T1 rehearsals
Scope breadth exceeds capacity	A dependency-driven ready queue with WIP limits; finish before starting; release tiers; re-plan triggers
Legacy data is ambiguous	Manifests, coverage labels, compatibility profile, admin-labelled semantics (Q-21), "unknown" for defaults that look like answers. Since 5 October: named legacy-gap states (NotRecordedInLegacy, CurrentSnapshotOnly, ValueOrDefaultUnknown and others) and Q-21 decided-amended through R4
PRISMA specification conflicts	Amendments A–P through the FEAT-011 change policy, the write-shaping ones before R3a
New screens drift from the Material 3 programme or from each other	UI-1 to UI-11 in every ship gate; one design system of record and pattern inventory; FEAT-023's checks and the UI-10 guard in CI; tier-1 design QA per PR and Chris's release-level acceptance
Existing approved documents (eligibility D3a, FEAT-008, FEAT-026, FEAT-006/009, annotation versioning) are followed by mistake	Supersession list in the inventory; each amended in the implementing PR
Notification fan-out from publication or outdated-answer events floods inboxes	In-form flags first; recorded fan-out with a recipient threshold; flood controls before R2c (E74); Q-20 narrowed to changes someone else caused
Saved Dockview layouts are refused or reset when panels change	Layout-contract amendment at F1c (history panel) and at F3 for later panels
Claims and capacity guards do nothing in production because tracking is off everywhere	X-CLAIMS; D3-16 (per-pilot binding-scope tracking recommended); E2E in both tracking modes
Switching tracking on breaks saves under FEAT-024 writes (typed 503 on mode disagreement)	Binding-scope setting or an owned M15 transition; static configuration on both hosts
Two reconcilers edit one study (no editor exclusion today)	X-RECLAIM in every environment
Membership facts go wrong once canonical data leaves Study (re-offered studies, 404 resumes, slot miscounts)	Per-reviewer membership projection; membership-facts seam with truth-table parity (E64); R0 floor reader logic
A flag is enabled on one host only (eligibility, allocation)	Delivery to API and PM plus a cross-host agreement check (E75)
Batches activate with a lazily recomputed frontier and no durable opening	X-BATCH criteria; performance gate before any enablement (E67)
Owner decisions recorded only in PR bodies (#3939's denominator)	D3-13b; ledger precedence; such text is treated as PROPOSAL
The fixed two inside FEAT-024's configuration digest makes target-aware counting a migration	X-STATS-c with a reconciliation plan before R2b allowlisted pilots and R3a (E71)
The staging fold flag is on and project 0102 is both FEAT-024's pilot and a plan pilot seed	D3-10b: keep 0102 out of R2a–R3a pilots until C8-T07 passes
Notification category skew blocks opt-out during deploys or rollbacks	Tolerant preferences before #3942 merges; C15-T06
Email continues after the flag is turned off; environment-wide flags; runtime overrides by any administrator	Delivery halt, per-project notification admission, inbox reads independent of capture (E74); G-NOTIF; D3-21
Reconciliation questions leak exposure into agreement figures as "independent"	C3 exposure kind "questioned in reconciliation"; AC-R4a-35, AC-R5c-07
Nine stacked notification PRs with generated-file conflicts and no CI E2E merge badly	Merge protocol (D1-09); run:e2e-full on retargeted heads; an ADR
The architecture review changes foundations F1a freezes and competes for capacity; MassTransit v8 support ends December 2026	D1-02 joint sequencing; X-ARCH-a–d
Runtime flag overrides are silently reset (#3975)	X-ARCH-c; no gate or evidence relies on a runtime override
Deletion physically removes identification history (ADR-014)	D3-12; X-DEL redefined. Since 5 October ordinary project deletion is reversible, and physical erasure needs the unapproved policy T-POL-01 (ACD-AE17)
Imports time out once P1 and P2 add work inside the import job	X-IMPORT; 5,000- and 50,000-record criteria
Presence payloads disclose reviewer identities across blinding	Disclosure-shaped payloads before any tracked pilot with blinding; D3-20
Orphaned claims hold capacity indefinitely	Lease expiry or bounded sweep before X-CLAIMS; AC-T-06
Approver throughput is the binding constraint: about 89 open decisions, 14 freeze gates, the M0 go/no-go and 27 ship gates pass through one person	Per-gate authorisation (D1-04); one dossier per gate; decision sittings tied to gates; a weekly digest with ages; release tiers and two-tier design QA; re-plan when a decision waits more than 10 days. Since 5 October the decision load is one open owner decision (D2-09), the owner-visible confirm items, G0-D1, G0 approval, the hold lift and ten brief approvals; the product-owner guide and the tracker keep each one short
The implementation hold lasts while approved designs and live states age (owner session)	The specifications, rollout plan and implementation tracker keep the work ready; owner-visible confirm items and specialist inputs can be answered during the hold; live PR and programme states are re-read when the hold lifts
Specialist inputs arrive late and block freezes (owner session)	T-SI-01 to T-SI-05 are requested early; each dependent freeze names its input as entry evidence; proposed thresholds never count as approved
Structured history events grow without bound or arrive out of order (owner session)	Targeted reevaluation, never every draft against every stage; C20 idempotency keys and ordering; history writes inside the commit; measured query and sweep budgets on Bramble (SP-AE17, SP-AE42; numbers proposed, not approved)
A merge or unmerge leaves partial or wrong current evidence (owner session)	Atomic activation with failure injection at every write (DM-AE01); the current evidence view equals a rebuild from authoritative records (DM-AE11); unmerge restores digest-identical evidence (DM-AE12)
Universal conversion of every project, including the largest and inactive ones, fails or loses data (owner session)	Staging trials, then production pilots, then waves; read-only dry runs; quarantine with a remedy, never a forced conversion; the first-canonical-write boundary; wave approvals; the largest-project benchmark (BC-AE16)
AI-model-generated screening decisions are mistaken for human evidence or counted as independent (owner session)	A machine source identity with no account; importer stored apart from the source; separate agreement classes; the copy-deck guard against "model decision" (RI-AE20, RI-AE21, RI-AE30)
Phone annotation of very large forms is too slow, or the PWA exploration drifts into offline writes (owner session)	Virtual scrolling, diff autosave and a phone budget set from measurement at the R2a freeze (UX-AE06, RD-AE23); no service worker or offline write before an owner decision on the PWA report (UX-AE25)
Juniper is both the CI host and the agent host, and agent builds starve CI jobs	A session cap with niced, single-project builds; conformance suites in path-filtered projects; Opus only for supervised reviews; batched pushes; start-delay tracking; full suites on Bramble
Bramble is treated as unlimited exclusive capacity, though it runs CI E2E shards and FEAT-024's gate (b) rerun and soak	A Bramble calendar with gate (b) first; benchmarks batched in booked windows; benchmark criteria limited to named hot paths against the S0 baseline
Building against fakes repeats QM v2's "complete but not wired" outcome	The M0 walking skeleton merged before F1a; each release's first slice end to end; at most three slices or ten working days against fakes alone; suites run against fake and real providers
Parallel sessions duplicate work, as #3964 and #3969 did	A claim step before any worktree; claims in STATUS; an open-PR path search
Generated-file and hot-file conflicts	Regenerate, never hand-merge; new canonical code in new files; flags registered once in S0; a hot-file register with leases
Stacked PRs cannot be reviewed (reviews run only on non-draft PRs targeting main)	Stack depth at most two; retarget before review, then merge main so Test Summary reports
A red main now stops all promotion (#3971), and production promotion waits for main's integration tests	Merge criteria on every PR; revert first, fix second; R0's production cycle scheduled on a green main
Tester availability limits acceptance	A named panel (D1-06; named on 3 October, no external SyRF users yet); monthly batched sessions; tiered tester counts. Since 5 October the current panel stays, with no external recruitment now (D3-08)
Worktree and disk exhaustion (195 PR worktrees; root disk 79% used on 3 October)	Cleanup within 24 hours of merge; prune merged or closed worktrees older than 14 days
ADR numbers collide (ADR-008 is already duplicated)	ADR-030 to ADR-069 reserved in STATUS; one C16 compatibility ledger instead of per-release ADRs

11. Decisions

Answered by Chris on 3 October: the ownership-transfer fix, kept in PR #3964 over #3969 (D1-01; #3964 merged on 3 October 2026 as 85e6facf7 and #3969 is closed), Q-10 (PR #3965), Q-07, Q-08, Q-09, Q-13, Q-03a, Q-25, Q-31 and Q-06a (with amendments K and L added), plus three new decisions: a published question is never permanently deleted (QD1), new and updated screens use Material 3 (UI1), and the plan carries well-defined acceptance criteria (AC1). That evening Chris approved the rest of Batch D1 as recommended (D1-02 to D1-09): precedence with the architecture review (#3961), activating #3987's ProjectStatistics families, implementation authorisation per freeze gate, merging this package to main as a docs-only PR, the tester panel and tiers, production opt-in pilots before GA, the write-path gate and the notification merge order. See the decision register §1.11 and §1.12 and §1.13. Q-25's tracking line rested on a false premise and is corrected there; the production claims route is D3-16.

G0 inputs, late on 3 October (decision register §1.14): Q-03 as recommended (the permission matrix is approved; each new capability ships with the feature that uses it; the catalogue subset is settled, and the Publish, stage-lifecycle and Monitor, and reconciliation subsets freeze with their features at F2, F3 and F4); the tester names (D1-06: for T1, Gillian Currie, Alexandra Bannach Brown, Francesca Tinsdeall, Chris Sena and Nadia Soleman; for the rest, the first three; no external SyRF users named yet); #3987's activation from 5 October 2026, staging first and production the following week, the production date being a target that keeps its own approval and waits for X-STATS-b1 to b7 (D1-03); and D4-18, "independent of funders", a different answer from the recommendation, whose recorded reading (the plan maps the NC3Rs and SSI RSMF deliverables to releases itself without waiting for funder confirmation; the GA accessibility audit stays) is PROPOSAL until Chris confirms it in the G0 dossier.

Parts of the D1 answers still open: F1a's confirmation of D1-08's start thresholds from M0 evidence; the stack owner's agreement to restack #3965 onto #3944 (D1-09); and external SyRF testers (D1-06 asked for two "where possible"; D3-08, decided on 4 October, keeps the current panel with no external recruitment now). G0 itself, Chris's approval of the G0 dossier, has not happened.

Owner session, 4–5 October 2026 (consolidation; owner-session integration for the full ID mapping, the superseded register and the coverage matrix). These decisions are planning approval only. Feature implementation is on hold, G0 is not approved, and no brief is approved. Before the session the package had 89 open owner decisions (Batch B 13, Batch C 15, Batch D 61: D2 16, D3 25 and D4 20; D4-18 was answered at G0). The session's register held 74 of them; the other 15 sat outside it. Their statuses now:

Group	Count	IDs
Session register: resolved, replaced, removed or deferred	52	D2-11; Batch B: Q-20, Q-27, Q-34, Q-15 (replaced by the stage study filter and step model), Q-24, Q-26, Q-28, Q-12, Q-01, Q-02, Q-30, Q-33, Q-37; Batch C: Q-29, Q-35 (removed as inapplicable), Q-36, Q-04, Q-11, Q-32, Q-05, Q-06b, Q-18, Q-19, Q-22, Q-21; D3-03 to D3-08, D3-12, D3-22, D3-24, D3-25; D4-01 to D4-05, D4-07, D4-09, D4-10, D4-11, D4-13, D4-14, D4-15 (deferred beyond the MVP), D4-16, D4-17, D4-19, D4-20
Session register: alignment, brief and validation entries (not owner questionnaires)	22	Carry-forward alignment: Q-23, D4-08, D3-17, D3-18. Brief or specialist: D4-06, D2-10, D2-13, Q-17, Q-16, D4-12, D4-21, D3-01, D3-02, D3-09, D3-10, D3-11, D3-13, D3-16, D3-19, D3-20, D3-21, D3-23
Outside the register: decided or replaced by the session	11	D2-01, D2-02 and D2-05 (amended); D2-07 and D2-08 (decided); D2-12 (replaced); D2-14 and D2-15 (amended); D2-16 (replaced); D3-14 and D3-15 (decided)
Outside the register: engineering contracts with no owner question	3	D2-03, D2-04, D2-06 (their PROPOSALs stand and are settled in the brief)
Outside the register: still an owner decision	1	D2-09 (tracker T-OI-01; recommendation unchanged: the second form's reconciler may revise with a new snapshot)

Result over the repository universe of 89: 63 resolved, replaced, removed or deferred (52 + 11); 25 alignment, brief, specialist or engineering-contract entries (22 + 3); 1 open owner decision (D2-09). 63 + 25 + 1 = 89. Never quote "22 remain" or "89 remain" without this scope.

Outside the 89: G0-D1 (confirm the recorded reading of D4-18); G0-D4 to G0-D10, the PR dispositions, which are not authorised (no dormant PR is closed); G0 approval (T-G0); the implementation-hold lift (T-HOLD); ten brief approvals (T-RD-00 to T-DH-00); five specialist inputs (T-SI-01 Q-17 event counts, T-SI-02 Q-16 and D4-12 agreement methods, T-SI-03 D4-06 template curation, T-SI-04 D4-21 ASySD parity, T-SI-05 PRISMA box mapping); the owner-visible confirm items each specification lists (for example reconciliation and screening §12), which refine decided directions; and the session's additional agreed requirements, OS-A01 to OS-A30, which are amendments outside the register count. Not approved: permanent physical erasure (T-POL-01), a separate identity-erasure process (T-POL-02), automatic acceptance of several agreeing candidates (T-POL-03; Q-11 bulk acceptance needs an explicit reconciler confirmation) and every proposed numeric threshold (for example D2-10's pause and operation limits, D4-21's F1 ≥ 0.99 and 80,000 citations in one hour, Unsure thresholds beyond the stated example, and cap defaults).

R4 direction (consolidation §5). One eventual writable engine, universal faithful baseline conversion after trials and pilots, and legacy-writer retirement as its own verified milestone. Q-05, Q-21 and D4-16 are decided-amended through R4; Q-35 is removed, with the no-records premise checked in every dry run; D2-13 is a brief item.

Still open before the owner session (89 owner decisions: Batch B 13, Batch C 15, Batch D 61; historical, kept for the record; current statuses are in the table above):

• Batch D (round 2; 71 questions, 61 open because all nine D1 questions and D4-18 are decided): D2 before F1a (versioning and consistency choices); D3 mostly before F1b, F1c and F3 (UX, workflow and programme choices), with parts needed at F1a (D3-14 for S0, D3-16's contract part, D3-17), F2 (D3-10 a, b, d), F3 (D3-23, for R3c), F4 (D3-11, D3-25), F5 (D3-10 c), F-P (D3-12's identification part) and G-NOTIF (D3-21, D3-22, D3-24); D4 mostly before F4–F6 and the lanes (methodology and scope additions), with parts needed at F1a (D4-06's catalogue and D4-12's marker parts) and F3 (D4-04, D4-19); D4-18 (mapping part at G0, audit at GA) is answered. Each question's "Needed by" entry is its deadline, and it sits in the sitting held before that gate (delivery operating model §2.8).
• Batch B (before F2, F3, F5 and P1): Q-20, Q-27, Q-34, Q-15, Q-24, Q-26, Q-28, Q-12, Q-01, Q-02, Q-30, Q-33, Q-37 (Q-03 was answered on 3 October).
• Batch C (before F4, F6a, F6b, R5c and the remaining lanes): Q-29, Q-35, Q-36, Q-04, Q-11, Q-32, Q-05, Q-06b, Q-17, Q-18, Q-19, Q-16, Q-22, Q-23, Q-21.
• Thresholds marked PROPOSAL in the acceptance criteria are confirmed at each release's freeze gate.

Details and recommendations: open questions. Other data and privacy findings outside the plan (destructive question deletion in legacy projects, unblinded reconciliation payloads, export unmasking, exports ignoring "completed sessions only") are listed for triage in inventory §7, and the follow-ups filed during round 2 are in the round-2 resolution matrix §6.

12. After approval

Approval of this plan is not implementation approval. Implementation is authorised gate by gate (D1-04, approved on 3 October): Chris approves each gate's dossier, including its slice list and its decisions, and merges keep his /approve, batched daily; production enablement, production data operations and adoption waves always keep their own approvals. With Batch A, Batch D1 and the G0 inputs answered, the proposed next moves follow the owner-session update below.

Owner-session update (5 October 2026). Feature implementation is on hold. The steps below keep their 3 and 4 October wording for the record, and each now also waits for three separate decisions: Chris's approval of the G0 dossier (T-G0), the lift of the implementation hold (T-HOLD), and the approval of the workstream brief that covers the work (T-RD-00 to T-DH-00). None has been given. Nothing in this package authorises implementation, migrations, production activation, notification delivery, closing unrelated or dormant PRs, messaging the design session or building a new prototype. The moves that remain open now:

• Chris answers D2-09, G0-D1 and the owner-visible confirm items the specifications list, and routes the five specialist inputs (T-SI-01 to T-SI-05) to methodologists.
• The integration PR (#4045) goes through the ordinary docs review; its owner-session integration records the counts and the coverage matrix.
• The design-prototype handoff (T-DH-00, OS-A30) is ready as an early design input for the W0 prototypes and F1c. Handing it to the Claude Design session that made SyRF Prototype v10 is Chris's own step; this package has not messaged that session.
• When Chris chooses, he approves G0, lifts the hold, and approves briefs one at a time; the implementation tracker records each state separately (Planning approved, Brief drafted, Brief approved, Implementation authorised, In progress, Merged dark, Gate passed, Production enabled). Today every row is at most "Brief drafted".

The proposed next moves of 3 and 4 October:

1. Step 0 (D1-05; done: PR #3617 merged on 3 October 2026, f5318074d): the owner ledger, this package and the research inputs reached main in one docs-only PR, so agents starting from main now see the authority they must follow. Later package changes go through ordinary docs PRs (regenerate the planning index with ./docs/scripts/generate-indexes.sh and the navigation with docs/scripts/generate-mkdocs-nav.py, then validate with docs/scripts/validate-docs.sh --skip-indexes). Contracts are promoted to docs/decisions/ ADRs as they freeze, and each new decision is recorded in the PR that implements it.
2. #3964 merged on 3 October 2026 (85e6facf7; D1-01, decided and carried out: #3969's active-member check and its tests ported, #3969 closed). It was step 0 of the notification merge train (D1-09), because it edits ProjectController.UpdateProject, which #3941 wraps.
3. The G0 dossier is ready for Chris's approval, the only G0 item still open. (Since 5 October the dossier opens with an owner-session update: D3-14, D3-15 and G0-D11 are answered, the PR dispositions are not authorised, and passing G0 does not lift the hold.) It carries the D1 answers (D1-01 to D1-09, decided; decision register §1.13); the G0 inputs given late on 3 October (decision register §1.14: the Q-03 catalogue subset, the tester panel's names for D1-06, the date for #3987's activation for D1-03, and D4-18's recorded reading for Chris to confirm); the five stream briefs (not yet written: the dossier's exception G0-X8); the decision calendar; the joint sequencing with #3961 (D1-02); the proposed PR dispositions (QM v2 and #2224 harvest-and-close, as decided; the dormant schema and profile PRs; #2469); and the slice lists below.
4. On G0, authorise: S0 (eight slices); the M0 walking skeleton; R1b; R1a's audit, browse and preview; the W0 prototypes and validations, including U1, U13–U15, U19 and U26; the F1a, F1b, F1c and C15 v2 ADR drafts; the presence owner's baseline docs PR; the design of the first seed projects.
5. Book the Bramble calendar: FEAT-024's gate (b) idle-host rerun used the first window on 3 October (it failed on latency, #3510); next the S0 baseline.
6. Each later gate's dossier carries its slice list; passing the gate authorises those slices to be built and merged dark.

Nothing is built under this plan before G0. After it, under D1-04, a passed gate's dossier authorises its slices, so no code PR needs its own authorisation; every merge still follows the normal PR and review rules and keeps Chris's /approve. (Since 5 October a passed gate's slices also need the hold lifted and their brief approved before any of them starts.)