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

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.

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 are still pending. 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.

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; drafts kept with a single-writer lease; Save and Complete create immutable versions; server-validated Complete; history; previous-version export (one stage per form)	R0 + F1b/F1c for its UI
R2b Shared sessions across stages	One reviewer session per study and form wherever it is opened; 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 writes no evidence; 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; explicit Fix and Upgrade; revisable requirements	R2a, R2c
R3a Steps and routing	Review steps with dependencies; own Include within a stage; Collective Include across stages by default; a keyboard screening path	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) with admin-confirmed reopening	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	R2b + F4
R4p Profile reconciliation	Screening-decision adjudication and 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; classification then inference; outcome schemas then outcome migration; shared-form proportional allocation; analysis-ready exports (pending D4-09)	Their own freezes; 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	Reviewed per-project adoption of legacy data; removal of adapters	Separate approvals

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

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. 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, pending D3-14) 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.

Still open (89 owner decisions): 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.

2. Confirmed invariants this plan must never break

These come from the owner ledger and, for 11 and 12, from Chris's review of this package on 3 October. 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).
2. Latest explicit Save or Complete is current. Autosave is a draft. Prior versions are immutable and never counted twice (SL1–SL3, SF6).
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).
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).
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).
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).
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).

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).
• 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–O	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	—

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

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

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

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

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.
• 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).
• 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.
• 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.
• PRISMA groundwork: per-profile outcomes and pool-entry records (StudyPoolLedger) in C12's write-shaping form, with "entering screening" defined by amendment A.
• 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).
• 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.
• 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.

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.

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.

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. 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). 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).
• 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.
• Legacy: legacy reconciled answers stay readable as LegacyAuthorityUnknown, treated as Q-35 decides.
• 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).
• 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.

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.

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.

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

R5b — PRISMA reporting

• MVP boundary: report snapshots (PrismaFlowSnapshot) built from P1/P2 identification provenance, R3b profile outcomes, R4p adjudicated outcomes and amendments A–O (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.

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).	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). The admission service excludes every non-Active lifecycle status (FEAT-012 §12). Report-to-study linkage (StudyLink, amendment O) if D4-08 approves. 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.	P1; amendments D, L, N (Q-37, D4-21, D2-12), O (D4-08); reviewed-record part and lifecycle transition after R3b; X-IMPORT
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.	F-C (C13); R2a; Q-19
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.	C1; Q-18
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.	F-O (C14); R2a; schema changes on used forms need R2c; Q-17; D4-10; 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.	O1; Q-05; 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.	O1, R4c, R5a; F6a (C11); D4-09

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

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

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; 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	Any notification enablement outside the e2e stack and Mailpit	Chris	Approval recorded in the flag audit; halt and per-project admission delivered (E74)	—
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)	P1 search withdrawal	Deletion-lifecycle programme	ADR-014 committed and amended	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)
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

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	R3a (steps, routing, skips, EW1), R3c (strict mode via Q-01); C6
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–O
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.

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

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.

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.

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

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: #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.

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

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	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	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	R1c
QM child visualisation and assign tree (#2387, conflicting)	Open	Review for reuse in the R1a/R2a designer	R1a
QM v2 stack (#2572 conflicting; #2573–#2575 stacked; #2461 draft)	Dormant since April	Harvest, then close (Chris, Q-08)	G0, F1a
Schema/profile/response/validation (#2987, #2986 and #2629 mergeable; #2812 conflicting)	Dormant	Harvest #2986 into R2a validation (the G0 dossier recommends instead keeping it open outside this programme, G0-D6, until Chris answers); others are C4/C14 inputs; dispositions at G0	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); 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.
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).
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 12 (AC-ALL-13).
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
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
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
PRISMA specification conflicts	Amendments A–O 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
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
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
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"). G0 itself, Chris's approval of the G0 dossier, has not happened.

Still open (89 owner decisions: Batch B 13, Batch C 15, Batch D 61):

• 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 are:

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