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.
Stage and step access-policy proposal¶
Confirmed direction: within-stage steps normally proceed on the reviewer's own Include, subject to collective Exclude veto. Cross-stage progression defaults to Collective Include required; an advanced option allows own Include sufficient, also subject to collective Exclude veto. Chris confirms PRISMA uses collective authoritative results: collective Exclude remains Excluded regardless of extra annotation/extraction work completed earlier. Preserve that work/history; never turn it into collective inclusion. This supersedes earlier blanket personal-Include cross-stage DP1 wording. PRISMA integration retains authoritative report-unit/count boundaries.
Chris requests investigation of optional very strict within-stage collective-Include gating. Existence/detailed scope/default behavior of that strict mode is not approved. Below is a concrete recommendation, not implemented settings or a replacement for form sufficiency.
Proposed placement and inheritance¶
- Stage → Incoming dependencies → Progression between stages: Collective Include required (confirmed default), own Include sufficient (advanced confirmed option). Configure on the destination stage and reference exact predecessor screening profile/requirement. Stage Design authority applies; no new grant or role implied.
- Stage → Steps → Progression within this stage: own Include sufficient (existing/default), collective Include required (proposed strict mode). Show purpose: faster work versus waiting for team agreement to reduce work on papers that may be excluded.
- Each step inherits stage within-stage policy. Recommend advanced override may tighten to collective Include, not weaken a stage configured strict. To allow faster progression again, designer edits stage policy explicitly, with impact/version gate. Exact restriction is a review proposal; no project-wide extra policy needed for MVP.
- Gates apply only to configured dependency edges; display order alone creates no dependency. Several prerequisite profiles use their explicit existing AND/OR group, not an implicit all-profiles rule. Validate cycles and same-profile simplification.
- Screen/profile decision gating is distinct from question visibility/branch applicability and ordinary form completion prerequisites. A collective Include gate does not require ordinary extraction gold or all form targets fulfilled unless another explicit dependency says so.
Version stage/step policies and predecessor refs. Show an effective-policy summary (“Waiting for team screening decision” / “Your Include allows this step”) beside the locked step, with source profile version. Preserve authoring/exposure history. In a shared form, route policy may vary by stage; evidence/session/target remains shared, not cloned to suit the route.
Proposed evaluation contract¶
| Condition | New dependent work |
|---|---|
| A governing prerequisite route collectively Excluded | Block that route, even when reviewer Included; reason reconciliation may still be pending |
| Reviewer personally Excluded governing prerequisite | Block for that reviewer; collective satisfaction does not silently override own Exclude |
| Collective policy + collective Pending/Conflict | Wait; previous own Include and extra completed work do not satisfy collective gate |
| Collective policy + authoritative Included | Pass this decision gate, subject to personal Exclude and existing permission/allocation/form requirements |
| Personal policy + own Include + no collective Exclude | Pass this decision gate, including collective Pending/Conflict |
| Personal policy + no own decision | Prerequisite remains to do; collective satisfaction only if explicitly configured, no invented personal vote |
Preserve configured compound dependency meaning: vetoes apply to governing prerequisite routes, not unrelated independent work. Normal stage eligibility, study lifecycle Duplicate/Merged checks, active membership, claims, capacity, batches and source-version compatibility still apply. A passed access gate does not create a review submission, vote, profile outcome or gold answer. For a combined screening/extraction step, do not make own Include a prerequisite to the same form that supplies the decision: retain existing atomic explicit completion/derived-decision contract, applying gates to downstream dependent steps instead.
Existing work, amendments and reporting¶
New work/admission and completion of previously saved work are different. Keep EW1 stage default Allow saved completion with advanced step override after exclusion; completed evidence remains readable under current permission. Strict mode does not silently delete drafts, cancel sessions, remove history or stop permitted saved completion. No new auto-count invalidation: latest explicit Save/Complete rules, stale warnings and SF6 remain. LC1 admin-confirmed protected reopening applies to changes affecting Completed stages; no autosave vote or reopening before required approval.
Recommendation for policy tightening: preview affected started/saved work, keep pinned evidence, stop new admissions under effective published rule, and apply explicit existing publication/impact choices to unfinished work. Do not reinterpret previous submissions as never entered. Loosening may open new work but cannot revise collective decisions or previous frozen PRISMA snapshots. Cross-stage paper access and within-stage reviewer work need separate UI/status fields; avoid labeling every stage lock as “Excluded”.
Reporting invariant: extra work completed under personal access is audit/extraction evidence, not authoritative screening inclusion. The report references collective FinalScreeningOutcome and structured primary reason/coverage. A collective Exclude is Excluded even if a full extraction form/outcome exists. Personal skips, unavailable work and batch selection are not Exclude votes or PRISMA count events. Historic reports pin exact source/protocol/outcome versions.
Review and acceptance¶
Review strict-mode placement, tighten-only override and treatment of existing work; default within-stage personal and cross-stage collective decisions are already settled. Implementers may choose intuitive labels; no mandatory persona/group-name question.
Fixtures: default same-stage own Include opens next step while collective pending; default cross-stage remains locked; advanced personal cross-stage opens; proposed strict same-stage waits; collective Exclude blocks each new route without deleting extra work; PRISMA remains Excluded with completed extraction; prerequisite self-cycle rejected; personal Exclude not silently overridden; EW1 saved completion preserved; changed published policy/current versions rechecked on transactional admission. These are future tests, not tests run in this docs task.