PRISMA compatibility and implementation-plan integration¶
Planning/research only, checked 3 October 2026. The previous package approval request is superseded pending this integration review. Preserve the existing FEAT-011 specification; do not silently replace its entity model or count formulas. This document supplies a compatibility map and explicit amendment recommendations. The revised implementation plan incorporates these dependencies into its slices, not only into a later reporting appendix.
Source authority and current evidence¶
The binding PRISMA package is Approved and constrains Phases 3–16. Its mapping, three-level model, lifecycle/source taxonomy and phase constraints are source requirements, not proof of implementation. Screening annotations, profile workflow, stage filtering, dedup service and Release 3 plan provide related decisions/proposals. The referenced old annotation-management-reconciliation/design-decisions.md path is absent; use surviving reconciliation docs/owner ledger, not an invented recovered D1–D50 document.
Inspected Study and ScreeningInfo still expose legacy screenings/tracked thresholds; screener+project lookup is not profile-scoped. SystematicSearch exposes NumberOfStudies through reference files, not verified immutable Citation/sourceType storage. Bounded search of project-management/API found no corresponding full pmPublication/Citation/ screeningOutcomes model or PRISMA generator. This is a local-source gap, not proof about every branch or deployed environment. Current statistics code is present: the authoritative screening query checks visibility, durable controls and in-progress inclusion/definition rewrites before a transactional read. That legacy screening metric is not automatically the 34-field PRISMA dataset.
GitHub read-only status recheck: #2398 is a merged documentation roadmap; #2461 and #2574 remain open QM/export groundwork; #2621 remains open profile prototypes; #3742 open eligibility migration. Stats #3925 and #3926 are now merged, superseding the earlier open inventory, without asserting deployment. #3939 now has actual progressive-batch files and reports validation, remains open; its shared completion/personal grants are workload concepts, not PRISMA screened counts. #3936 planning remains open. No new PRISMA-specific implementation PR appeared in the bounded open-PR title search (limit 300); not an exhaustive historical search. Heads/source hashes are packaged in prisma-integration-evidence.json.
Terminology and count-unit boundaries¶
| Concept | Existing specified meaning | Shared-annotation consequence |
|---|---|---|
| Citation / record | Project immutable import occurrence; one per citation per import | Preserve source/search/raw fields, even repeated imports. Not a reviewer answer or cohort. |
| Publication / deduplicated identity | System-scoped bibliographic identity, shared across projects | Does not grant access to another project's review evidence or imply same research cohort. |
| Report | Full-text document; spec represents retrieval on project Study | Do not count animal cohorts, reviewer sessions or repeated imports as distinct reports. See source inconsistency below. |
| Study | Project reviewable entity representing research investigation; spec allows multiple Citations | Shared form sessions use exact Study identity; bibliographic sameness alone cannot merge study reviews. |
| Study population / cohort | Our recorded animal set inside a reviewable Study; multiple independent populations possible | Not PRISMA studies/reports. Whole-population inferred cohort/count does not add a PRISMA inclusion. |
| Classification entity / shared concept | Local entity instance inside one animal population; global concepts can be referenced | No collision with system Publication scope; entity templates/outcome associations do not change bibliographic counts. |
Official PRISMA templates distinguish new/updated reviews and source layouts. Existing SyRF box 1 updated-review support is deferred; as-of history and protocol amendments do not silently activate an updated-review population.
Compatibility and coverage map¶
| PRISMA phase/contract | Required integration into current proposal |
|---|---|
| Identification, boxes ⅔/11; phases 7/12/16 | Count recorded import occurrences/search sources and dedup/pre-screen dispositions. Preserve raw Citations and dedup audit. Never derive identified/removed counts from today's work pool or personal suppression. |
| Title/abstract, boxes ⅘; phases 13–15 | Profile-owned eligibility questions and rule versions determine profile FinalScreeningOutcome. Record unique study/report-unit entry into protocol screening scope with source/filter versions; within-stage personal work access remains separate; cross-stage admission uses configured DP6 policy. Reusing same profile in stages creates no extra outcome/count. |
| Retrieval/assessment, boxes 6–8/12–14 | FullTextStatus Sought/Retrieved/NotRetrieved is evidence of retrieval, not stage Active/Completed. Assessed counts follow specified protocol entry/retrieval contract, not merely UI visit, extraction result or reviewer target. |
| Excluded with reasons, boxes 9/15; phase 15 | Use profile authoritative decision and structured primary reason with source/candidate/reconciler references. Collective Exclude may veto new work before required reason reconciliation finishes; expose pending/unavailable reason coverage, never fabricate a primary reason from majority/free text. |
| Included and synthesis, boxes 10/16/17 | Preserve explicit Study Included and metaAnalysisIncluded meaning. Linking outcomes to inferred/explicit cohorts, completing extraction or meeting form target does not imply either flag. Review counts remain study/report units, not animals. |
| Profile outcomes vs lifecycle | Per-profile array/projection, never one Study screening status. Ordinary annotation gold cannot write screening outcomes. Common revision engine shares infrastructure; specialized screening authority remains distinct. |
| Shared forms/stages and progressive batches | One form contribution per reviewer; all compatible qualifying candidates. Stage claim, personal Include/batch access, save allowance and selection limits cannot increase or erase PRISMA source/decision denominators. Pool-entry facts pin protocol/filter versions, not personal availability snapshots. |
| Corrections/publication/LC1 | Append exact decision/reason, form/profile and binding versions; old report snapshot retained. Required reason work and applicable drafts/corrections affect readiness independently of target sufficiency. Confirm protected reopening changes before commit; no autosave vote or retroactive rewrite of prior counts. |
| Entity templates/extraction | Reuse legacy templates and require cohort/outcome/experiment types only with applicable extraction/export feature. Single measure direction remains ODIR1. Schema migration never creates an Included Study/report or unique animal count by implication. |
| Historical export/freshness | One report manifest pins source/search/dedup/retrieval/profile/filter/outcome/reason versions and snapshot/as-of basis. Reuse stats revision/freshness gates; answer-history alone cannot reproduce PRISMA if import/pool/retrieval history is absent. Preserve available legacy coverage under EX2, label unreconstructable boxes. |
Concrete conflicts, recommendations and amendment gates¶
A — within-stage personal progression and configurable cross-stage routing. Older screening/profile docs say operational pools use FinalOutcome. Current DP6 corrects the earlier blanket cross-stage DP1 extension: own Include opens within-stage steps while collective state is pending/conflict with Exclude veto; cross-stage availability is configurable. Proposed choices Collective Include required / own Include sufficient, DP7 confirms collective default, with advanced own-Include option. Recommend retain authoritative collective profile outcomes for PRISMA, add explicitly separate within-stage reviewer admission and configurable cross-stage routing, and a protocol-scope entry projection with provenance. Revise affected stage/profile constraints via FEAT-011 impact policy before M2/M4 shipping only where configurable route extension affects them; collective-only routing remains a supported baseline. Do not count a personal Include as collective Included or invent a final screening vote when a step is skipped. “Screened” source rule currently means pool entry, not completion: preserve that labeled baseline, then resolve protocol entry definition in amendment.
B — records/report multiplicity. Mapping boxes 10/16/17 use SUM(Citations) as reports, despite Citation being every import occurrence; Study has one Publication/fullTextStatus yet research may have multiple reports. Synthetic case: one report imported twice gives two records, one bibliographic report, one study; two true reports for one investigation require two report links, not two inferred cohorts. Recommend exact report-identity/reference coverage and approved report-unit query correction; retain original cited formulas until amendment approval. Export cannot label citation totals “verified reports” where distinction lacks evidence. No automatic multi-report consolidation or new universal Report entity has been approved by this task.
C — dual source columns. Mapping uses HAS Citation source predicates, allowing both columns; taxonomy §7 says earliest import determines one downstream sourceColumn, all imports still count at identification. Recommend use the existing explicit first-import rule consistently for downstream boxes, deterministic tie/unknown handling, and update conflicting mapping queries through the spec amendment process. This is a source inconsistency to correct, not a fresh “which source strategy?” product question. Unknown legacy source remains unknown/unclassified, never guessed Database.
D — dedup with reviewed records. Service scenario table allows one-reviewed merge, but blanket invariant says never auto-merge studies with review data; cross-stage reviewed records may remain separate Studies sharing Publication. Recommend conservative admin-reviewed mapping whenever review evidence exists; preserve both candidate sets without doubling the same reviewer/form contribution, flag conflicts rather than selecting a duplicate automatically. Citation moves need identity/lineage manifest and dedup reversal; source array movement cannot clone immutable imports. Existing M7 outcome migration must not perform bibliographic dedup as a side effect. Recommend explicit reconciliation of these source contradictions before dedup adoption, not a new silent rule.
E — reasons and gold. CandidateAgreement can supply a FinalOutcome under documented screening rules; ordinary annotation matching is never auto-gold. DP5 Off remains allowed and no reason collection hard gate is invented. If primary reason is unavailable or reconciliation pending, propose preliminary report + explicit reason coverage/discrepancy status, retaining reliable excluded decision counts without claiming a complete reason breakdown. Final PRISMA publication validates required structured categories; exact partial-report presentation is a review proposal. Top-level reasons follow existing MVP; subreason detail/export provenance retained without new mandatory synthesis. Different screening and ordinary gold versions must never be conflated.
F — time and protocol amendments. Specs require versioned authority/derivations but do not establish a full historical import/retrieval/pool-entry ledger or exact new export manifest. Recommend append corrections/amendments, freeze reports against exact evidence, recompute current views under explicit profile/filter versions without editing old report counts. Pending query gold remains effective; profile decision change, stage reopening and Study lifecycle are distinct events. Historical availability is EX2-settled; where history is absent, report unknown coverage, not synthetic original decisions/pool timestamps. Roadmap “rollback by removing fields” is unsafe after canonical writes; use the migration plan's canonical-aware rollback boundary.
Regression fixtures required before implementation approval/activation¶
- Duplicate imports, mixed sources: two immutable Citations of one report, earliest-source downstream classification once; later import affects identification only. Distinct report vs same-report imports tested separately, no report/study/animal unit mixing.
- Same profile in two stages and one form in two stages: one effective decision per profile, one qualifying form contribution per reviewer; repeated pool evaluations/personal batch grants do not add screened units. Different profiles stay independent.
- Own Include + collective Pending opens permitted within-stage extraction, no collective Included claim; cross-stage remains blocked under Collective Include policy and may admit under explicitly configured own-Include policy; collective Exclude blocks new dependent work while reasons pending, retain saved-work policy. Current/preliminary report exposes reason coverage and pinned decision sources.
- Save after Complete removes qualifying contribution; autosave alone does not, but applicable unresolved work blocks automatic readiness. LC1 protected correction/new-arrival confirmation followed by auto/manual transition; old PRISMA snapshot unchanged.
- Correct Exclude→Include, amend profile/filter, change retrieval status, reverse dedup: append events/provenance and reproduce old as-of counts when recoverable. Missing legacy history produces coverage status, not a reconstructed fiction or arbitrary retention cutoff.
- One Study with multiple animal populations, implied cohorts, outcome assignments and custom schema: PRISMA Study count unchanged; no meta-analysisIncluded from extraction completion.
- Reviewed duplicate candidates, same reviewer/form twice: retain originals, explicit admin identity mapping and conflict handling; no automatic double target count/gold promotion.
- Stale statistics/rewrite lock, concurrent report snapshot, permission revocation or cross-project Publication lookup: consistent manifest or explicit retry; no mixed-epoch counts/candidate leak.
These are proposed meaningful tests, not tests run here. Documentation checks are separate.
Narrow review items¶
DP7 confirms cross-stage collective default and advanced own-Include option. Within-stage default is personal Include; optional strict mode details remain a separate proposal.
Review the explicit amendment recommendations A–F and exact report-unit/coverage mapping before claiming complete PRISMA output. Approve protocol-entry event contract, partial-reason presentation, coherent historical manifest and conservative reviewed-dedup handling after evidence. Existing source taxonomy/profile ownership, PRISMA new-review baseline and owner workflow directions are not reopened. Follow FEAT-011 change policy: affected box/entity → downstream phase impact → linked spec/query amendments → release checklist update. This task makes no authoritative spec rewrite, migration, grant, code, merge, publication or activation.
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.