Status correction — 3 October 2026: UNAPPROVED PRELIMINARY MATERIAL. Retained as research input only. Chris has limited the current task to collecting future-planning scope, sources, confirmed decisions and unresolved matters. Actual implementation planning is a separate phase he will initiate. Architecture, sequencing and proposed controls here are not approved or an implementation approval request. Separately recorded owner decisions still apply.

Shared annotation and review implementation plan — 3 October 2026

Current DP6 correction: personal Include governs within-stage steps; cross-stage routing is configurable. DP7 confirms Collective Include required as cross-stage default; advanced own-Include option allowed. Strict within-stage details remain proposed. Older blanket cross-stage DP1 wording below is historical/superseded.

Ready for implementation planning review. Major product decisions are covered; runtime implementation, activation and migration execution are not authorized. Exact proposed permission defaults, protected lifecycle change flow, gold completeness setting and missing-state statistical contract need review. This plan integrates, rather than replaces, the existing M0–M8 convergence programme, combined-domain programme and v10 comparison/dependency map. Older claims of deferred P9 planning or unresolved P10 direction yield to MIG1/ODIR1.

Binding PRISMA dependency and approval correction

The prior package approval request is superseded pending this integration review. PRISMA integration comparison maps the existing Approved FEAT-011 package and Phases 3–16 onto M0–M8. These are distinct milestone numbering systems. Phase 2 source constraints apply now: Citation import evidence and system Publication identity, project Study lifecycle, per-profile FinalOutcome authority, retrieval and source-column counts remain distinct from animal populations, sessions, stage lifecycle and personal progression. M0 must pin reserved count units and authority boundaries before writes; M2/M4 preserve existing collective routing while adding DP6 configurable cross-stage policy and within-stage personal progression, without altering PRISMA authority. DP7 default is confirmed; strict within-stage mode details require design review. Complete PRISMA M6 output depends on Phase 12 identification/dedup/retrieval provenance and Phases 13–15 profile/outcome/pool/reason contracts, not merely on ordinary gold. A truthful M1 current/history export is not a PRISMA claim. Full report-formula amendments gate affected reporting/dedup adoption slices; they do not make the first ordinary-annotation pilot implement Phase 12 or every PRISMA box.

Destination and minimum usable release

Destination: common immutable answer identity/revision/context/submission infrastructure for ordinary answers and specialized profile-owned screening decisions, with form-owned shared reviewer sessions/targets, versioned workflow bindings, source-preserving reconciliation/gold, scoped RBAC, cohort/classifier inference, typed outcome schemas and truthful historical exports. Specialized validation/calculation remains explicit, not guessed from labels or arbitrary rules.

First genuinely usable release is M1 ordinary annotation versioning for an admitted pilot form: use the existing review editor to autosave, explicitly Save incomplete, Complete valid work, later correct it and inspect/export its exact previous completed version. Keep legacy routes for unsupported scopes. Even this pilot uses form-owned identity/session/target (including duplicate stage-binding test fixture); no temporary per-step session or target model to retire later. M0 proof is necessary engineering evidence, not a release. Shortest path: reconcile current contracts/overlaps → minimal common revision/context commit proof → pilot API/adapter → existing Angular editor controls/history → concurrency/export checks → off-by-default project admission.

Acceptance: one effective form contribution per reviewer across stages; latest explicit Save supersedes Complete and removes completion qualification; autosave alone does not; old submissions remain readable, pinned and unmodified; no data/permission regression with pilot off. Unsupported form/context must be rejected before editing, not partially written into different authorities.

Existing statistics/allocation/tracking/batching integration gate

Operational integration map adds source-backed contract amendments and page/settings coverage. Preserve FEAT-024 disposable projections/fallback/checkpoint protocols, allocation buckets/roster eligibility, per-study presence and active-work protection, and #3939 immutable progressive batches. Form-unique contribution and latest explicit status are new source semantics: M0 owners review derivation/invalidation and claim identity before M1 writes, M4 integrates shared-stage/form/step routing and batch eligibility. No parallel counters/reserve pools or arbitrary unit/outcome statistics programme.

Ordered slices, ownership and dependencies

Owner names below are delivery responsibilities, not assigned people or new repositories. Implementation PRs must use current verified PR worktrees and preserve other WIP.

Existing milestone / slice	Deliverable owner and usable outcome	Prerequisites / acceptance / release gate
M0 · contract/owner integration	Domain/API lead with UI and migration owners: exact identity, revision membership, context/ancestors, command/CAS receipts and compatible sharing	Reconcile embedded AV/ASV prior work with common engine before choosing storage. Prove ordinary Answer and ScreeningDecision use same commit checks; PRISMA unit/authority/source version contract and A–F amendment map required; stats/allocation/tracking/batch interface review; no live migration
M1 · ordinary pilot	Domain/API + Angular reviewer: existing form Save/Complete/history/correction and current export	M0; form-owned session/target, immutable explicit versions, separate draft state, validity, two-stage dedup, stale-write/idempotency, old read/export retained; source/projection/claim graduation atomic or safely fenced; fixture confirms no new PRISMA record/report/Study from session or animal cohort
M1/M4 · groups/access foundation	Security/API + membership UI: scoped existing grants and approved separate capabilities	Read-only catalogue first; PM2 owner-granted group delegation, anti-escalation, revoke/read/command checks, owner transfer exception; no new grant from assignment
M1/M2 · initial form and templates	Question-management/API + admin category editor: editable initial form, ordinary question-library selection, independent screening-profile template copies	Reuse #3934/#2781 preview/import/version/dependency contracts; source template versions retained; template edits never live-update profile configuration; exact starter contents proposed
M2 · profile-owned screening	Screening/API + existing screening UI: profile-local eligibility definitions, versioned decision and own-history correction	M1 common engine; template copies not live links; same-profile sharing, different-profile isolation; own Include permits within-stage dependent steps, DP7 collective-default/advanced-personal cross-stage routing; optional strict within-stage design proposed, collective Exclude veto; no autosave vote; Phase 13/15 per-profile outcomes/reasons projection and distinct protocol-entry/admission contract
M3 · evidence/combined step	Workflow + reviewer: resumable reasons and atomic completed form with submitted derived Include/Exclude	M2; source revisions and branches, child validity, explicit submit confirms derived decision, preserve existing work; decision agreement separate from required reason resolution; exclusion veto can precede complete primary-reason breakdown, coverage status retained
M4 · shared workflow/claims	Workflow/API + reviewer workspace: steps, shared forms across stages, typed allocations and guarded corrections	M1–M3; target minimum, all qualifying compatible reviews, group/stage scopes, profile reuse, shared answer context; fresh publish usage, admin impact choices, flag stale dependencies; Phase 14 protocol pool entry provenance separate from personalized batch grants and filters; shared form slot/roster and progressive batch completion contract proven with owners
M4 · publication/lifecycle	Domain/stats owner + stage designer: versioned bindings and protected transition	Current usage across any prior form version; requireReanswer/autoUpdate/doNothing choices; LC1 admin confirm protected changes before automatic Active, explicit manual reopen; no unresolved applicable drafts/corrections at auto completion; Study lifecycle, profile outcome and stage status are different, old report snapshots immutable
M4/schema · replace existing project wizard	Admin UI + template/import owners: robust resumable replacement of existing create/setup wizard, reusing editors/commands	Profile/form/step/schema dependencies ready; editable source templates, DP7 route defaults, scoped groups, deliberate preview/publish; no wizard-created review facts or default unused types
M5 · initial ordinary gold	Reconciliation/API + existing editors: one study/form task, pool/eligible explicit assignment, source vectors and immutable accepted snapshot	M4; >2 candidates UI, label/answer matching suggestions reviewer confirms, stage blinding, optional explanation, exact text prefill, unseen-control warning with Complete anyway but validity enforced
M5 · queries/authority extension	Reconciliation/API + contextual query UI: grouped per-version concerns and replacement gold	Initial snapshot; pending gold effective, valid children before replacement, audited authorized self-review, per-concern outcomes, satisfied-update close, unsatisfied original target open/current flag; permission-filtered notices
M4/M5 · populations/classifiers	Annotation/domain + category UI: population cohort, label/child entities, subset-set annotations and implied cohorts/outcome associations	Stable context/ref identity; one population per recorded instance, multiple independent study populations; physical/entity definitions distinct from animal membership; cross-type concept links evidence/rules; reported vs derived provenance
M5 · inference feedback	Classification/domain + cohort reviewer: simplifications, implied classifications/counts and conflicts	Explicit relation sets scoped to parent/population; Pregnant implies Female without copying reported answer; disjoint/exhaustive coverage and same count basis; withdraw invalidated proof, retain override reason, no count pooling
M5 · outcome schemas/entry	Schema/domain + project designer and extraction UI: legacy-compatible, event-count, project-custom schemas; series/observation fields	Typed roles/types/validators/cardinality/version refs, conditional system cohorts/outcomes/experiments; legacy templates preserved; one direction per outcome measure; event counts not forced into mean/error rows
M5 · outcome reconciliation	Reconciliation + extraction UI: typed series and observation correspondence/source provenance	Outcome entry + ordinary gold; stable row IDs not time/index-only matching; all candidates, missing states, observation sample size vs cohort enrolment distinct; accepted snapshot pins inputs
Phase 12 prerequisite lane · identification/dedup	Import/dedup owner: immutable Citations, Publication identity, retrieval/source provenance and auditable reviewed dedup	Defined at M0; coordinate existing source model/Phase 12 work, no opportunistic merge in outcome migration; report multiplicity/source-rule conflicts amended before full PRISMA
M6 · reporting/history	Export/stats owner + report UI: current/available as-of exports and contextual progress/agreement	Reuse reserved temporal groundwork, implement only recoverable history; AG3 N/A/compatible version flags; missing-method approval; independent/informed distinct; PRISMA Phases 12–15 provenance prerequisite, all box/34-field mapping plus unit/coverage validation; no invented legacy events/majority gold
M7 · reviewed adoption	Migration owner + all writer owners: pilot project migration and writer convergence	Approved migration manifest/dry-run, grants, type aliases, shadow comparison, scoped fence, recovery/rollback; sessions and gold pins preserved; publication separate from migration; PRISMA Citation identity, per-profile mappings, source/retrieval coverage and dedup lineage separately validated
M8 · retirement	Domain/export/integration owners: canonical ownership complete, compatibility projection isolated/read-only	All readers/writers/imports/admin/bulk/background paths inventoried, old clients fenced, evidence retention and canonical-aware rollback proved; retirement explicit, not indefinite optional duplicate authority

Sub-slices may ship independently when they deliver a real journey and preserve these dependencies. Outcome entry can precede broad classification inference; classification polish does not block ordinary versioned reviews. Event/custom schemas remain first-release schema requirements, not speculative extras. Exact solver optimizations, match thresholds and rich tours are later work.

Existing delivery overlap and UI contract

The comparison's original PR inventory is 2 October point-in-time evidence. The PRISMA integration recheck on 3 October finds #3925/#3926 merged and #3939 open with actual implementation files; this supersedes the prior open/empty-file observation, without asserting deployment. Recheck heads/status before implementation and extend the owning work, rather than clone it:

• 3617 owns research. #2572–#2575 QM domain/impact/migration/web and #2461 historical export

  contracts inform versioning; #2398 merged plan is not full runtime historical retrieval.

• 3546 category tabs/focus/action bar, #3394 Study fullscreen, #3292 panel boundaries own reviewer

  interaction. #3936/#3939 progressive shared batches own offered-work progression; compare their actual code before selection/dependency changes. #3746/#3742/#3741 eligibility and migration work own admission compatibility; don't bypass with UI-only step hiding.

• 3925/#3926 statistics point-fold/claim transitions own projection inputs; use their source

  revisions rather than new independent mutable counters. #3941 owns inbox capture.

• 3934/#2781 template imports and #2987/#2986/#2812/#2629 schema/response validation own boundaries;

  #2621 profile exploration must be reconciled, not assumed accepted production behavior.

Current web package declares Angular 22.1; reuse Angular/Material, existing signal/NgRx patterns, category tabs, numbered/indented question trees, Settings/Preview and reconciliation editors. Prototype React is visual evidence, not a proposed production framework change. Keep compact cohort selection and visible outcome badges, avoid long listings that push the form down. New semantic controls appear beside their annotations; exceptional Unknown/Not reported/N/A via overflow; initial blank gives direct input. Inference “Why?” links show exact supporting rule/revision, not long generic text. Preserve source panels, keyboard focus, dark theme and draft restoration.

PRISMA data/release contract within the sequence

Protocol/profile eligibility describes review criteria; LC1/workload readiness describes pending work. Neither can substitute for the other. Store/report screening authority per profile with candidate/reconciled source refs, ordinary gold per form/task, retrieval lifecycle separately. Repeated stages sharing a profile/form count once in their respective semantic context. Source Citations count import occurrences; report/Study identifiers and animal cohorts remain distinct. Never derive PRISMA box populations from current selectable work, personal grants, claims or UI visits. Required top-level reason data feeds FinalOutcome/reporting; pending/off reason settings need explicit preliminary/coverage status, not fabricated complete reason breakdown.

Report manifest proposal pins identification sources/dedup lineage, retrieval status, protocol entry/filter/profile versions and decision/reason snapshot references at one coherent as-of basis. M6 must reuse existing statistics source revisions/freshness fences, not add a second mutable KPI store. Current-definition rewrite pending rejects/retries coherent export instead of mixing epochs. Amendments append versions; previous frozen report stays reproducible when actual history supports it. Multi-report/dual-column formula conflicts require linked FEAT-011 amendments before complete PRISMA labeling. See integration A–F for exact source conflicts and alternatives.

Meaningful validation and gates

Contract/domain fixtures: Save-after-Complete, draft-only qualification, duplicate retries, repeated entities with same labels/question IDs, ancestor sharing, profile decision versus reasons, N/A/blank distinction, required gold validation and compatible/incompatible versions. API/Mongo checks: transaction/CAS failure and replay; two-tab/stage edits; stale pins/claim release; revoked or cross-project grants; permission administration without recursive escalation; freshness publication fence and LC1 approved change invalidated by concurrent edits. Use isolated fixtures, not production history manipulation. Browser journeys: >2 candidates plus blinded aliases; matching confirm; unseen control Complete anyway and required blank rejection; shared session through two stages; manual/automatic approval flows; compact cohort selection and Pregnant→Female inferred/redundant/conflicting cases. Existing category/editor routes and flag-off regression are required, not a new frontend redesign. Exports/migration: golden semantic fixtures before/after, current/candidate/gold separation, recoverable as-of boundaries, typed event/custom round-trip, unknown legacy history, duplicated observation times and source-null/default ambiguity; dry-run rerun identity and rollback rehearsal.

PRISMA fixtures from the integration comparison cover duplicate imports, multi-report units, mixed-source attribution, shared-stage reuse, pending reasons, corrections, partial history and stale projections.

Release gate per slice: approved contract, applicable FEAT-011 phase/release checklist and amended unit queries, meaningful focused tests, source/writer compatibility, permission coverage, off-by-default admission and documented canonical-aware rollback. Broader performance/resilience work follows evidence; do not repeat already-passing checks without changes. These are future test requirements, not tests claimed run for this planning package.

Parallel delivery and page integration

After common interfaces at M0, template/setup and existing UI owners can develop against stable DTOs in parallel with profile, stats and allocation/tracking adapters. Owning PRs stay separate; join source-writer/projection/claim tests before M1/M2 release, all workflow/allocation/batch and project/stage/step settings/overview contracts at M4. Project overview shows distinct study/form/ profile populations; stage overview shows bound form target/steps/gates/readiness/batches; settings bind versions and inherit step policy. Do not ship a step editor while overview/completion still counts separate stage copies of shared form evidence. See operational map for exact responsibilities, resumption/capacity identity and current active #3948/#3949/#3327/#3939 overlaps.

Guided setup/library integration

Setup/template plan covers the requested optional admin wizard and exact reuse boundaries. M1 adds an encouraged editable initial form and ordinary library browse/import; M2 supplies default copied profile eligibility templates; M4/schema delivers replacement of the current create/setup wizard with the guided stage/team/extraction journey. Preserve basic fields/name validation, create actions, manual routes and checklist navigation; retire first-stage/global heuristics after parity, not backend create APIs. It orchestrates category editor/import/publication rather than introducing duplicate template or question storage. FEAT-014 is Draft, #3934/#2781 remain open; reuse reviewed foundation and do not claim full onboarding is already implemented. Template contents and setup order are proposals; mandatory type dependencies apply only to enabled features.

Stage/step progression design review

Access-policy proposal makes DP7 cross-stage collective default/advanced personal option explicit in M2/M4, with normal personal within-stage progression. Optional strict within-stage collective gating is a concrete recommendation for design review, not an approved required first-release feature. Gate new admission separately from saved-work completion/EW1 and evidence sufficiency. Test PRISMA Excluded despite completed extra extraction; access cannot promote inclusion or erase authoritative decisions/history.

Proposed settings and execution approvals

Concrete artifacts to review:

1. Permission matrix with RBAC research: exact separation/defaults and bounded owner delegation. Intuitive group templates are implementation discretion, not a blocker question.
2. Lifecycle/gold settings: exact admin change approval flow, Follow-requiredness project default/form override, and separate statistical missing/Unknown comparison/denominator recommendation. Product LC1/UA1/ODIR1 not reopened.
3. Migration plan: read-only first slice, reviewed mapping, staged copy/fence and rollback after target writes. Plan approval is not a run.
4. Review optional strict within-stage settings and guided setup/template contents, including ownership/dependency preview.
5. Review PRISMA compatibility amendments and coverage; full diagram claims wait for source/unit/history prerequisites, not only M1 export.
6. Approve M0→M1 implementation boundary and owners only after checking overlap/current branch state. Later slice scopes and migration/activation require explicit implementation authorization.

No remaining blanket claim that all details are resolved. Major decisions support coherent planning; remaining items are precise proposals and engineering contracts, already supplied for review.

DP6 — current cross-stage correction (supersedes DP1 cross-stage extension)

Chris, 3 October 2026, during PRISMA integration: personal Include with collective Exclude veto applies to steps within the same stage. Between stages, route availability should be configurable. Proposed choices are Collective Include required versus own Include sufficient; collective Exclude veto, permissions/allocation and independent gating remain. DP7 confirms default Collective Include required, with advanced own-Include option; collective Exclude veto retained. Record this as a change of direction, not a denial of earlier DP1 confirmation. Older blanket personal-Include cross-stage language in historical sections is superseded. Keep within-stage personal work, cross-stage routing and PRISMA collective report authority separate. Cross-stage default is settled under DP7. Review strict within-stage proposal and PRISMA amendments before implementation approval.

DP7 / PR1 — confirmed cross-stage default and collective reporting

Chris confirms cross-stage default waits for collective Include; advanced own-Include access is allowed with collective Exclude veto. Within-stage default remains own Include. Optional strict within-stage collective gate needs design; its exact inheritance/override/unfinished-work handling is proposed in the access-policy document. PRISMA reports collective authoritative outcome: Excluded stays Excluded even when extra review/ annotation work was completed under earlier access. Preserve that work and provenance. This settles DP6's pending default, superseding provisional package wording; no runtime approval follows.