Skip to content

PRISMA and deduplication specification amendments (A–P)

The title read "(A–O)" until the owner session added amendment P on 5 October 2026.

Temporary planning document; planning only. This page is the single register of the changes this programme needs to the Approved PRISMA package (FEAT-011, docs/features/prisma-specification/) and the Approved deduplication service specification (FEAT-012, docs/features/deduplication/service-specification.md). Approved specifications are never changed silently. Each amendment goes through the FEAT-011 change policy (affected box or entity → downstream phase impact → linked specification and query amendments → release checklist update) in a documentation PR opened before the build that depends on it (plan §12, step 3): the write-shaping amendments A and H are frozen at F3, before R3a writes outcomes; C, D, G, J, K, M, N and O at F-P, before the P1 build; L at F-P for its rules and P2 for its parity evidence; B, E and F at F6b. The implementing code PR then updates the specification text it relies on and the release checklist, and cites the amendment. Owner-session addition (PROPOSAL): P's outcome composition fields are part of H's frozen outcome shape at F3; P's reporting rules freeze at F6b with B, E and F; its import lane (XS1) has its own brief and gate. O, now deferred, freezes nothing.

Where each amendment came from:

  • A–F were raised by the earlier PRISMA compatibility review, review-prisma-integration-2026-10-03.md, section "Concrete conflicts, recommendations and amendment gates". This page summarises them.
  • G–J came from adversarial review B (finding B-14) of this package.
  • K and L are Chris's additions of 3 October 2026: manually reported counts for steps done outside SyRF, and ASySD deduplication inside SyRF. Their detailed rules are confirmed under Q-37.
  • M, N and O came from round-2 reviews SR (SR-02, SR-07, SR-15) and V2 (V2-01): full-text retrieval, the Citation to Publication link, and report-to-study linkage.
  • P and the owner-session revisions to A, B, D, E, F, G, H, J, K, L and O came from Chris's owner session of 4–5 October 2026 (consolidation §3 and §5), through the §13 amendment lists of the reporting, imports and AI screening (RI), duplicate merge (DM), stage pools, steps and history (SP), reconciliation and screening (RS) and baseline conversion (BC) specifications.

Approval status (Chris, 3 October 2026): A, C, D, G, H, I and J are approved (Q-06a). K and L were requested; their rules below are proposals under Q-37. B, E and F are open (Q-06b). M and N are new proposals (M depends on D4-07 for actors and the PDF rule). O is conditional on D4-08. Nothing on this page is implemented.

Approval status after the owner session (5 October 2026). The 3 October statuses for B, E, F, K, L, M and O are superseded by the owner session (5 October 2026), see the summary table:

  • B, E and F are approved (Q-06b through E1, 4 October 2026).
  • K is approved (Q-37), with rule 6's extension to accepted external and AI-model-generated decisions a PROPOSAL and rule 7 limited to supplied previous-review counts (D4-11).
  • L is approved (Q-37) with rule 4 replaced: a duplicate merge creates one consolidated current Study with a reversible unmerge (D2-12 replaced; OS-A29). The ASySD parity and QC thresholds stay proposed, not approved, and not achieved (D4-21 brief item, T-SI-04).
  • M is approved (D4-07).
  • O is replaced by prepared multi-source links; grouping distinct reports into one investigation is deferred (D4-08 and Q-23 are carry-forward alignment entries).
  • A, D, G, H and J stay approved and are revised to match the owner decisions: pool history versus actual review (A), consolidated merge (D), universal conversion (G), outcome provenance and Unsure (H), reversible project deletion (J).
  • N stays a proposal. P (external and AI-model screening sources) is a new proposal.

Exact PRISMA box mapping is specialist input (T-SI-05), and every numeric threshold on this page is proposed, not approved. Feature implementation remains on hold (Chris, 5 October 2026). An approved amendment is planning approval for its FEAT-011 or FEAT-012 documentation PR; brief approval and implementation authorisation are separate, per gate (D1-04), and neither has been given. Superseded text is kept and marked "Superseded by the owner session (5 October 2026)". Counts and amendment IDs are reconciled in the owner-session integration.

Summary

ID Amends One-line change Status Lands in
A FEAT-011 constraints Keep authoritative collective profile outcomes for PRISMA; separate within-stage admission and configurable routing; define "entering screening". Owner session: WorkFirstReleased replaces StudyEnteredPool; stage pool history is a separate audit dataset; actual review through the stage is the reporting priority (box mapping T-SI-05) Approved; revised by the owner session (5 October 2026) R3a (write shape), R5b
B FEAT-011 flow mapping Count reports by real report identity, not by Citations. Owner session: three labelled units (records, reports, Studies) and report identity coverage Open (Q-06b). Superseded by the owner session (5 October 2026): Approved (Q-06b through E1, 4 October 2026); Q-23 is a carry-forward alignment entry R5b
C FEAT-011 mapping and taxonomy One downstream source column from the earliest import Approved P1
D FEAT-011 and FEAT-012 Reviewed duplicates need admin-reviewed mapping; never double count a reviewer's contribution; scenario 2 becomes admin-reviewed. Owner session: one consolidated current Study with conflicts resolved before an atomic commit and a reversible unmerge; references never move; lineage-aware distinct counting Approved; revised by the owner session (5 October 2026; D2-12 replaced) P2
E FEAT-011 reasons Report reason coverage honestly; keep screening and ordinary gold apart; FEAT-009 truncation becomes a coverage value. Owner session: the exclusion-reason template is guidance (S3); distinct excluded Studies are counted apart from overlapping reason counts Open (Q-06b). Superseded by the owner session (5 October 2026): Approved (Q-06b through E1; Q-22 and D4-13 through S3, 4 October 2026) R5b
F FEAT-011 time and history Append corrections; freeze reports; no rollback by removing fields Open (Q-06b). Superseded by the owner session (5 October 2026): Approved (Q-06b through E1, 4 October 2026) R5b
G FEAT-011 Phase 16 (MIG-11 to MIG-14) Per-project adoption replaces platform-wide backfills. Owner session: per-project conversion inside the universal baseline conversion waves Approved; revised by the owner session (5 October 2026; R4 owner direction) R6 (P1 for the classification tool)
H FEAT-011 ScreeningOutcome (three placeholders) Outcome per profile with route provenance and complete authority values, including Imported. Owner session: the authority list becomes RS's finalSource plus RI's composition fields; resolutionState; Unsure counted as not excluded and never a definite Include Approved; revised by the owner session (5 October 2026) R3a, R3b
I FEAT-011 rollback Canonical-aware rollback replaces $unset Approved All PRISMA-writing releases
J FEAT-011 deletion cascade Withdrawing keeps Citation history; whole-project deletion per D3-12 (recommended: ADR-014 removal with a tombstone). Owner session: ordinary project deletion is reversible; permanent erasure is the unapproved policy T-POL-01 Approved for withdrawal (presentation per Q-33); whole-project scope pending D3-12. Superseded by the owner session (5 October 2026): Q-33 decided; D3-12 decided with reversible deletion (O1 final clarification) P1
K FEAT-011 flow mapping; FEAT-012 §11 Manually reported counts for steps done outside SyRF, with an entry-phase rule and per-box combination Requested; rules proposed (Q-37). Superseded by the owner session (5 October 2026): Approved (Q-37, 4 October 2026); rule 6's extension to accepted external decisions is a PROPOSAL; previous-review counts are supplied values only (D4-11) P1 (identification and deduplication records), R5b (other step types, reports)
L FEAT-012 ASySD deduplication inside SyRF; merge as an alias; privacy; QC sampling; parity metric. Owner session: "merge as an alias" becomes one consolidated current Study with a reversible unmerge Requested; rules proposed (Q-37, D4-21, D2-12). Superseded by the owner session (5 October 2026): Approved (Q-37) with rule 4 replaced by the consolidated Study model (D2-12 replaced); thresholds proposed, not approved (D4-21 brief item, T-SI-04) P2
M FEAT-011 taxonomy, mapping and three-level model Retrieval is fullTextStatus only; human retrieval actions; the FullTextNotRetrieved lifecycle precedence is superseded Proposed (D4-07). Superseded by the owner session (5 October 2026): Approved (D4-07 through E2, 4 October 2026) P1 (events), R3a/R3b (admission), R5b (boxes)
N FEAT-011 three-level model Citation to Publication link held in a link record; linking never rewrites a Citation Proposed P1, P2
O FEAT-011 flow mapping (boxes 10, 16, 17) Report-to-study linkage: several reports, one study; linking never merges evidence Proposed (D4-08). Superseded by the owner session (5 October 2026): Replaced by prepared multi-source links; grouping deferred (D4-08, carry-forward alignment) P2 (or R5b with B). Owner session: none in this rollout
P FEAT-011 flow mapping, ScreeningOutcome and methods summary External and AI-model screening sources in FEAT-011 terms: outcome composition, the machine-assisted share, and the box 3 versus box 5 question for sole-screener AI exclusions Proposed (owner session, 5 October 2026; E3 AI expansion, OS-A20) F3 (composition fields in H's shape); XS1 lane; R5b (reports)

A. Within-stage admission and configurable routing, separate from PRISMA outcomes

  • Today: older screening and profile documents say operational pools use the final outcome, and FEAT-011 treats "screened" as pool entry.
  • Problem: confirmed decisions DP6 and DP7 let a reviewer's own Include open steps within a stage, and make cross-stage routing configurable. That must never change what PRISMA reports. Owner session: the cross-stage routing part is superseded by the owner session (5 October 2026), see SP §3.3: a stage study filter defines each stage's pool and dependencies are between steps inside a stage (Q-15 replaced). Own-Include progression within a stage stays the default (Q-01).
  • Amendment:
  • PRISMA keeps the authoritative collective outcome per profile.
  • Personal admission and routing are recorded separately and never counted as collective Included.
  • Skipping a step never invents a final screening vote.
  • "Entering screening" (boxes 4 and 8, "made available to screeners") means protocol scope, or actual release including shared batches and personal grants, recorded as a StudyEnteredPool event (FEAT-011's pool-entry event) in StudyPoolLedger with the filter and profile versions used. Superseded by the owner session (5 October 2026), see the revision below: the event is renamed WorkFirstReleased and lives in pmHistoryEvent.
  • Fixtures: FX-PRISMA-03a, and FX-PRISMA-03b for early-stopped and batched reviews.

Owner-session revision (5 October 2026; SP §3.5, §3.7, §3.13; RI §3.3, RI-R04 to RI-R09; OS-A07, OS-A09, OS-A10, OS-A11).

  • Rename. FEAT-011's pool-entry event becomes WorkFirstReleased: exactly one per (Study, stage), recording the first release of work to anyone, with releaseKind ∈ SharedBatchOpened, PersonalBatchGrant, ExplicitAssignment, UnbatchedAvailability, InheritedThroughMerge. The rename avoids a clash with stage pool entry. It is not pool entry, a review start or a completion (D3-13 treatment).
  • Stage pool history is a separate dataset. StagePoolBaselineMember, StagePoolEntered and StagePoolDeparted (C20 HistoryEvents) record filter-based pool membership with entry justification (filter version, clause evaluation, input versions, cause, actor) and departure reason codes. Re-entry opens a new episode and never adds a distinct Study. A filter departure is never reported as a screening exclusion unless its reason is a screening Exclude outcome.
  • Reporting priority. Flow reporting prioritises actual review through the stage, with the eligibility justification recorded when the review started. Reporting reads five stage measures, each counting distinct current Studies: M1 ever in the pool (audit only), M2 work first released, M3 reviewed through the stage (the priority), M4 satisfied by evidence collected elsewhere (shown separately, never counted as reviewed in that stage) and M5 departed, by reason category. Ever-in-pool membership is never the reviewed count (superseded wording 16).
  • Coverage. Reports state when pool tracking began and never fabricate earlier membership; an eligible Study that nobody reviewed shows "no review recorded" with no invented reason.
  • Box mapping is specialist input (T-SI-05). Which boxes use M3 with its eligibility provenance, which use pool-history measures, how distinct identity is counted across merge lineage and how coverage limits are disclosed are decided before F6b. RI §3.3 holds a reading for the specialist (records screened = Studies with at least one counted decision under the phase-mapped profile; M2 Studies with no counted decision form the "not yet screened" remainder); it is a proposal, not approved. Until the specialist input is recorded, reports present the measures with their labels and do not silently pick a mapping.
  • Fixtures (added, PROPOSAL): a Study in the pool and never reviewed is in M1 and not M3; a Study satisfied elsewhere is in M4 and not M3; a Study that entered twice counts once (RI-AE04 to RI-AE06).

B. Records versus reports

  • Today: FEAT-011's flow mapping counts reports (boxes 10, 16, 17) as a sum of Citations, but a Citation is every import occurrence.
  • Problem: one report imported twice gives two records, one report and one study. Two real reports of one investigation need two report links, not two inferred cohorts.
  • Amendment: count reports by exact report identity, with explicit coverage. Until this is approved, exports label citation totals as records, never as verified reports.
  • Status: open (Q-06b, Q-23). Superseded by the owner session (5 October 2026): approved through E1 (Q-06b, 4 October 2026); Q-23 is a carry-forward alignment entry that applies the unit distinction and keeps report grouping deferred.

Owner-session revision (RI §3.1, RI-R01 to RI-R03; Q-06b, Q-23, D4-08).

  • Three labelled units. Reports, exports and screens keep three units apart and label every count with its unit: an imported reference (a Citation, shown as "record": one row of one import file), a source document (shown as "report": a distinct article, abstract, preprint or thesis) and a Study (the project's reviewable item, where forms, sessions and targets attach). Two imports of one article are two records, one report and, after a duplicate merge, one Study.
  • Report identity. A source document's identity is established from a Publication match (DOI or PMID, P2), from a duplicate merge that asserts "same document", or from an administrator's confirmation. It is held as an optional sourceDocumentKey, with the basis it was established on, on each referenceLinks[] entry of the immutable StudyVersion (RD §3.3; PROPOSAL).
  • Report identity coverage. Every snapshot and export carries reportIdentityCoverage per counted population (PROPOSAL name): Established, Partial (with the count of unconfirmed Studies) or Not established. Where identity is partial or missing, the figure is labelled as records or as "one report per Study assumed (identity not verified)", never as verified reports.
  • Deferred grouping. While report grouping is deferred (amendment O), each Study has at most one distinct source document in practice, so "reports of included studies" equals "included Studies". The report says so in a footnote ("Report grouping across Studies was not performed; each Study is counted as one report"). A conference abstract and its journal article stay separate Studies and separate reports in this rollout (consolidation §1).
  • Fixtures: two imports of one article give 2 records, 1 duplicate, 1 report and 1 Study after the merge; an abstract and its article give 2 Studies and 2 reports with the footnote (RI-AE01, RI-AE02).

C. One downstream source column

  • Today: the mapping uses "has a Citation from source X" predicates, so a study can fall into both source columns, while the taxonomy says the earliest import decides one column.
  • Amendment:
  • Apply the earliest-import rule everywhere downstream, with deterministic tie handling.
  • Every import still counts at identification.
  • An unknown legacy source stays "unknown/unclassified"; it is never guessed as Database.

D. Duplicates that already have review data

  • Today: FEAT-012's scenario table allows merging when one study is reviewed. Its invariant says never auto-merge studies with review data, and reviewed records in different stages may stay separate Studies sharing a Publication.
  • Amendment:
  • Use admin-reviewed mapping whenever review evidence exists.
  • Keep both candidate sets, but never double count the same reviewer's contribution to the same form (SF2).
  • Flag conflicts rather than choosing one duplicate automatically.
  • Moving Citations needs an identity and lineage manifest plus dedup reversal. Superseded by the owner session (5 October 2026), see the revision below: references never move; the consolidated Study links them; the manifest records lineage.
  • Outcome migration must never deduplicate as a side effect.
  • Engine link: reviewed-record merge and split are a C1/C2 contract operation (E33). Superseded by the owner session (5 October 2026): duplicate consolidation and reversal are the new contract C21 (DM spec).

Owner-session revision (D2-12 replaced; OS-A29; DM §3, §4, DM-R01 to DM-R25; consolidation §2).

  • One consolidated current Study. A confirmed duplicate merge creates one consolidated current Study with consolidated bibliographic metadata, reference links and current review associations. The inputs are tombstoned as immutable historical inputs: they are not allocated, listed or counted in current totals, and they stay readable in history, as-of exports and audit. "Historical" never means corrupt or deleted. Two active Studies linked by an alias is superseded (superseded wording 2).
  • References never move. Each Citation keeps its home Study. The consolidated Study's StudyVersion.referenceLinks[] link every input's references by ID, and the merge manifest records the exact inputs, versions, conflict resolutions, target confirmation, actor and time.
  • Admin-reviewed whenever review evidence exists. Same-reviewer screening decisions or annotation sessions, conflicting accepted results and conflicting adjudicated outcomes are resolved before commit in a reconciliation-like view, by the merging user or by delegation to the original reviewer, with the actual resolver recorded. Answers and completion status are resolved together; Complete still passes validation. Unresolved conflicts stay visibly pending and block the commit.
  • Atomic commit. One activation transaction validates every input's current version, inserts the consolidated Study, tombstones the inputs and writes the manifest and audit. A failure leaves the originals current. Notices, statistics and pool history follow through durable intents.
  • Reversible unmerge. A new immutable action tombstones the consolidated Study and restores the originals, with an explicit per-item choice for work done after the merge (move to one restored Study, or leave on the historical consolidated Study; never both). The merge is never erased.
  • Counting. A qualifying reviewer counts once across merge lineage, and the authorised merger confirms the consolidated effective target. Distinct-Study counts are lineage-aware: a tombstoned input is never an extra current Study, and as-of views before the merge still show the inputs. Whether a PRISMA box counts recorded identities or consolidated lineage is specialist input T-SI-05 (SP ambiguity SP-AMB-08 recommends supporting both, with the PRISMA default set there).
  • Duplicates only. Distinct reports and distinct investigations are never merged silently; "distinct report" is an explicit duplicate-review outcome and grouping stays deferred (amendment O).
  • Fixture FX-PRISMA-07a, rewritten: originals kept as history; one consolidated Study; conflicts resolved before commit; one contribution counted; no automatic target double count or result promotion. "The admin's identity mapping is an alias" is superseded.

E. Reasons and gold

  • Amendment:
  • Screening rules may produce a final outcome from candidate agreement; ordinary annotation matching never produces gold automatically.
  • DP5 Off (exclusion-reason reconciliation off) stays allowed.
  • When primary reasons are unavailable or still being reconciled, reports state reason coverage instead of claiming a complete breakdown.
  • Screening gold and ordinary gold versions are never conflated.
  • Status: open (Q-06b, Q-22). Superseded by the owner session (5 October 2026): approved through E1 (Q-06b) and S3 (Q-22, D4-13), 4 October 2026.

Owner-session revision (S3 clarification, OS-A17; RS-R65 to RS-R67; D4-01, OS-A16).

  • Template guidance, not a platform limit. A recommended exclusion-reason template may nominate a primary reason for a simple, mutually exclusive reporting breakdown, by default the first failing criterion in the profile's configured order, with a per-profile option for reviewer choice (D4-13). Profiles still support several screening annotation questions and recorded reasons, with explicit must-agree answers, and additional answers are never discarded. Agreement requirements follow the profile's explicit configuration, never an inferred count of reasons.
  • Two kinds of count. Reports always count distinct excluded Studies separately from per-reason counts. Multi-reason categories may overlap: they are labelled "reasons can overlap" and never summed as a distinct-Study total. Diagram-compatible configurations are documented with the template. Reason coverage is disclosed whenever primary reasons are pending, disabled or absent.
  • Unsure. A screening Unsure is counted as not excluded in PRISMA. It is never a definite Include and never counts toward agreement for a definite outcome; a pending outcome (awaiting extra review, in discussion or awaiting adjudication) is reported as pending, never as Included or Excluded. How Unsure and pending adjudication map to boxes is specialist input T-SI-05.
  • Gold. "Screening rules may produce a final outcome from candidate agreement" stays limited to the configured screening profile rule. Automatic acceptance of several agreeing annotation candidates is a separate, unapproved policy (T-POL-03).
  • Template content (the reason list and advice text) is written by CAMARADES methodologists in the S3 brief (RS §12).

F. Time, protocol amendments and frozen reports

  • Amendment:
  • Corrections and protocol amendments append; they never edit old report counts.
  • Reports freeze against exact evidence, and current views are recomputed under explicit profile and filter versions.
  • Where history is missing, reports show unknown coverage, never reconstructed decisions or timestamps.
  • "Rollback by removing fields" is unsafe after canonical writes (see I).
  • Status: open (Q-06b). Superseded by the owner session (5 October 2026): approved through E1 (Q-06b, 4 October 2026). RI-R10 adds that merges, unmerges and search withdrawals also append and appear only in later snapshots, and that regenerating a frozen snapshot from its manifest gives identical numbers and digests (RI-AE08).

G. Per-project adoption replaces platform-wide backfills

  • Today: prisma-constraint-annotations.md Phase 16 requires backfilling lifecycleStatus = Active on all studies (MIG-11, line 279), migrating all screening decisions into screeningOutcomes[] (MIG-12, line 280), populating sourceType from LibraryFileType (MIG-13, line 281) and migrating stage settings to a unified schema (MIG-14, line 282); three-level-data-model.md lines 319–322 list the same Phase 16 backfills; the taxonomy (line 397) requires an admin bulk classification tool.
  • Problem: this programme keeps legacy projects unchanged until each is adopted after a reviewed manifest (MIG1 planning, assumption A-04). A platform-wide rewrite would contradict that, and would fabricate per-profile outcomes from one project-wide decision. Owner session: "until each is adopted" is superseded by the owner session (5 October 2026), see the revision below; every project converts, but still one project at a time and never by a platform-wide rewrite.
  • Amendment:
  • MIG-11 and MIG-12: lifecycle status and screening outcomes are created per project at adoption (R6), from the approved manifest, with coverage labels and authority = LegacyUnknown where the authority is not recoverable (H). Legacy projects that aren't adopted keep their current-state counts, labelled with their basis. Superseded by the owner session (5 October 2026), see the revision below: LegacyUnknown is removed, and "projects that aren't adopted" exist only until their conversion wave.
  • MIG-13: sourceType is never backfilled platform-wide. P1 ships the admin source-classification tool for searches imported before P1 (AC-P1-04); at adoption (R6) the manifest proposes Database only for PubmedXml searches and leaves every other source null ("unknown/unclassified") until an administrator classifies it. An unknown source is never guessed.
  • MIG-14: stage settings are not migrated to a unified schema platform-wide. Canonical projects use StageSettings versions from R2a/R3a; legacy stages keep their booleans until the project is adopted, when the manifest maps them (per-stage placement table, brief §1.12).
  • FEAT-011's release-3 checklist items for these backfills are tested per adopted project (migration §7); the checklist line "ALL existing studies have lifecycleStatus backfilled" is read as "all studies of adopted projects".

Owner-session revision (R4 owner direction, OS-A15; BC §3.4, §10.1, BC-R08, BC-R20, BC-R33; BC §13). Per-project adoption becomes per-project conversion inside the universal waves: staging trials, production pilots, then every remaining project, including completed and inactive ones. Each project still converts on its own, from its approved manifest, so the platform-wide backfill stays rejected.

  • MIG-11 and MIG-12. Lifecycle status and per-profile screening outcomes are created at each project's conversion. Legacy screening maps to one legacy-compatible screening profile whose collective rule reproduces the characterised legacy maths; outcomes are recalculated under it and compared for parity, and an admin confirms the profile's scientific meaning (Q-21). There is no LegacyUnknown outcome authority (Q-35 removed; amendment H as revised). Missing history is labelled with legacy-gap states (CurrentSnapshotOnly for the decision, NotRecordedInLegacy for reasons and earlier decisions). A legacy-compatible profile whose meaning is not confirmed carries no PRISMA phase (BC ambiguity A2, PROPOSAL).
  • Pool history. Conversion writes StagePoolBaselineMember events with coverage BaselineAtTrackingStart; earlier pool history is NotRecordedInLegacy, and reports disclose the gap (amendment A as revised).
  • MIG-13 and MIG-14 are unchanged in substance: no platform-wide sourceType guess, and stage settings map per project through the conversion manifest and wizard.
  • Checklist. "All studies of adopted projects" now reads "all studies of converted projects", which at the end of the waves is every project. The exact PRISMA treatment of converted history is specialist input T-SI-05.

H. Screening outcome shape

  • Today: FEAT-011 defines the ScreeningOutcome in three places that differ: study-lifecycle-and-source-taxonomy.md lines 267–294 ({profileId, stageId, result, primaryExclusionReason, resolvedAt, authority} with ScreeningAuthority = CandidateAgreement | Reconciled); three-level-data-model.md lines 221–234 ({profileId, stageId, finalOutcome, primaryExclusionReason, decidedAt, source} with source = Reconciled | CandidateAgreement | Admin); and prisma-constraint-annotations.md, which pins the taxonomy's shape in the Phase 11 MUST NOT (line 180), the Phase 13 MUST (line 226) and the Release 3 checklist (line 331). None has a legacy or unknown authority value; only the second has Admin.
  • Problem: a profile can be shared by several stages, so one stageId misstates where the decision came from. Adopted legacy decisions have no known authority. Imported decisions (CSV mapping, FEAT-004) have an authority of their own.
  • Amendment (one shape, applied to all three places in one change):
  • The outcome is per profile, with route provenance (the stages and steps that contributed, with their settings versions) instead of a single stage ID.
  • authority ∈ {CandidateAgreement, Reconciled (profile adjudication, R4p), Admin (override, with an audit record), Imported (decisions imported from another tool or a CSV column, with the independence declaration), LegacyUnknown (adopted without recoverable authority)}. Ordinals are appended, never reordered. Superseded by the owner session (5 October 2026), see the revision below: this single list is replaced by finalSource plus the composition fields.
  • The reason is structured with a coverage status; its shape allows either one primary reason or several counted reasons until Q-22 decides, and carries the primary-reason rule that produced it (D4-13) and FEAT-009's truncation as a coverage value ("primary agreed; sub-reason not agreed"). Owner session: Q-22 is decided through S3, so the shape holds several recorded reasons and an optional template-nominated primary reason (amendment E as revised).
  • result ∈ {Pending, Included, Excluded, Conflict, Unsure (D4-01)}; a collective Unsure is never Excluded. Superseded by the owner session (5 October 2026), see the revision below: result becomes resolutionState.
  • The Phase 11 MUST NOT, the Phase 13 MUST and the Release 3 checklist cite this shape; the taxonomy and three-level placeholders are replaced by one reference to the frozen C12 write-shaping contract.
  • Timing: frozen at F3 with amendment A, before R3a writes outcomes.

Owner-session revision (RI §3.13, RI §13; RS §3.8, RS-R47, RS-R48, RS §5.10; D4-01, S1 amendment OS-A16; E3 AI expansion OS-A20; Q-35 removed). The outcome keeps one shape, per profile with route provenance, applied to all three FEAT-011 places in one change. Outcome provenance is kept separate from accepted-result authority (AcceptedResultVersion.authority ∈ SingleAnnotator, HumanReconciled, Adjudicated, MergeResolved; RS §3.2), and has two parts (PROPOSAL names):

  • finalSource ∈ ProfileRule, Adjudicated, MergeResolved says how the outcome was resolved. External or AI-model-generated decisions resolve through ProfileRule under the profile's declared source policy, and a human resolution of one through Adjudicated. No extra value is needed for them.
  • Composition fields say which source classes the outcome rests on, derived at commit: machineContribution ∈ None, Contributing, Sole, and externalHumanContribution (boolean). They keep machine-assisted outcomes distinguishable from exclusively human ones in reports, exports and the methods summary (RI-R45; amendment P).

The retired list maps as follows: CandidateAgreement → ProfileRule; Reconciled (profile adjudication) → Adjudicated; Imported → ProfileRule or Adjudicated with the composition fields set, while Imported survives as a candidate provenance kind for mapped human annotation imports (RI §3.10); LegacyUnknown → removed, because converted legacy outcomes are recalculated under the legacy-compatible profile (Q-35 removed; amendment G as revised); Admin → no value, unless RS §12's Q-36 reading creates an outcome override. Legacy-gap states (BC §3.2) are a different thing and stay.

resolutionState replaces result: Pending, AwaitingExtraReview (with the remaining bound), InDiscussion, PendingAdjudication, Included, Excluded. Only Included and Excluded are definite outcomes. Pending adjudication is not an outcome. A collective all-Unsure state waits for its rule, which the screening brief settles (RS §5.10 item 1; recommendation: adjudication by default).

Unsure. Unsure is a reviewer decision value, configurable per profile and on in the title/abstract template (D4-01). It counts as not excluded for availability and for PRISMA, and it is never a definite Include: it never counts toward agreement for a definite collective outcome (RS-R48). Unresolved combinations follow the profile's bounded extra-review or adjudication rule (RS-R49 to RS-R51). A model Unsure under a sole-screener policy goes to human adjudication (RI-R39). The PRISMA box treatment of Unsure and pending adjudication is specialist input T-SI-05.

Adjudicated outcomes are flagged, never rewritten, when their inputs change after resolution (RS-R58); a new adjudicated outcome exists only after an eligible adjudicator explicitly reconsiders it. Frozen reports keep the outcome versions they pinned.

I. Canonical-aware rollback

  • Today: three-level-data-model.md (lines 291–322) describes rollback by $unset of the new fields, and FEAT-006's design decision D18 says the same.
  • Problem: once canonical data exists, removing fields destroys evidence and breaks older readers.
  • Amendment: after canonical writes, roll back by stopping new writes, keeping new data authoritative, and using read-only containment or a verified forward-recovery adapter (contract C16; migration §1). Never down-migrate destructively.
  • Owner session (BC-R27, BC-R28). For converted projects the boundary is exact: routing rollback to intact legacy data is possible only while the scope's firstCanonicalWriteAt is null; after the first canonical write, recovery is canonical-aware and moves forward. Recovery after data loss is the D2-13 brief item (isolated point-in-time restore and manifest-driven forward recovery), and a restore that loses history writes a discontinuity record that reports disclose.

J. Deletion and withdrawn searches keep identification history

  • Today: three-level-data-model.md line 262 says "Delete Study removes its Citations" and line 263 removes all Studies with a project. ADR-014 (product decisions approved 12 August 2026; flag deletionLifecycle on main) schedules project and standalone-search deletion with a 24-hour grace period and then physically deletes Project, Search and Study documents, leaving minimal tombstones (ADR-014-reversible-deletion-and-permanent-tombstones.md lines 59–74, 142–146, 220–250). Search and project deletion fail closed on main until that lifecycle is enabled.
  • Amendment (scope per D3-12):
  • Citations are immutable identification history.
  • Withdrawing a search is a reversible appended event that hides its Studies from pools and from current reports but keeps Citations and all canonical evidence; its external step records (K) are withdrawn with it. Current reports exclude withdrawn searches and say so ("excluded from this report: n records from withdrawn search X", Q-33). Frozen reports never change.
  • Deleting a whole project keeps ADR-014's physical removal with a tombstone; PRISMA snapshots and canonical evidence do not survive their project. The user guide tells administrators to export reports before scheduling deletion, and the grace period allows restore. Which canonical collections join ADR-014's deletion scope is X-DEL (programme integration), not this amendment. Superseded by the owner session (5 October 2026), see the revision below: ordinary project deletion is reversible (superseded wording in ACD §14).
  • Deleting a single study outside a search withdrawal is not offered for admitted projects; RemovedOther (box 3) is the methodological equivalent and keeps the record.
  • Still open: none for scope; presentation copy is Q-33's recommendation.

Owner-session revision (Q-33 decided; D3-12 decided with the O1 final clarification, OS-A25; RI §3.5, RI-R17, RI-R18; ACD §3.3, ACD-R14 to ACD-R19).

  • Withdrawn searches (Q-33, decided). Withdrawal keeps the search's Citations and appends a SearchWithdrawn event with actor, time and reason; reinstating appends SearchReinstated (PROPOSAL name). A Study identified only by withdrawn searches leaves current pools through a StagePoolDeparted event with reason HIDDEN_BY_SEARCH_WITHDRAWAL and leaves current reports. A Study also identified by a current search stays, and its identification counts come from the current search's records only (PROPOSAL counting detail). Review evidence on every Study stays intact and visible in history, and the search's external ledger entries (K) are withdrawn with it. Current reports say what they excluded ("Excluded from this report: n records from withdrawn search B; m Studies are no longer identified by any current search"). Frozen reports never change.
  • Whole-project deletion is reversible. Ordinary deletion hides the project from ordinary lists, blocks review and editing, stops allocations and project notifications, releases active reservations and keeps drafts, immutable evidence, history and PRISMA snapshots. An authorised admin restores it from a restricted deleted-projects view; restoration re-evaluates availability and capacity and revives no stale reservation. No scheduler physically deletes a deleted project's data. Permanent physical erasure is a separate, unapproved policy (T-POL-01). Exports are unavailable while the project is deleted (PROPOSAL). Search withdrawal and project deletion stay distinct.
  • Fixtures: a Study in withdrawn search C and current search A stays and is counted from A only; a Study only in C departs with reason "search withdrawn"; the explanation line appears; the frozen snapshot is unchanged; reinstatement re-enters matching Studies (RI-AE12).

K. Steps done outside SyRF: manually reported counts (Chris, 3 October)

Problem: many reviews deduplicate, and sometimes screen or retrieve, outside SyRF before or alongside import, for example ASySD's R package or Shiny app, EndNote, or another screening tool. FEAT-011 derives every count from SyRF data. For example, database_results is the sum of SystematicSearch.numberOfCitations (the imported count), so a search deduplicated before import understates identification and leaves box 3 without its duplicates; a review that screened titles and abstracts outside SyRF gets box 6 = 0 and an overstated box 10 (V2-04). FEAT-011 has no way to record these steps.

Amends: FEAT-011 flow mapping (boxes 1–9, 11–15; fields #3–#30); FEAT-012 §11.1 (box 3 formula) and §11.2 (count consistency).

Proposed amendment (rules under Q-37): Owner session: approved through Q-37 on 4 October 2026 (external-step ledger, per-box combination, reported versus computed counts, no double counting, permissions, warnings and withdrawal treatment). The rules below stand, with the revisions marked in rules 2, 6 and 7.

  1. External step record. Each record is project-scoped, optionally tied to one systematic search or source, and holds:
  2. the step type: identification at source, deduplication, automation removal, other removal, title/abstract screening, full-text retrieval, full-text assessment, or studies from a previous review version;
  3. the affected PRISMA field(s), restricted to fields #3–#30 (the derived fields #31–#34 are never reported, always computed);
  4. a non-negative count;
  5. timing: before import, or outside SyRF after import;
  6. the search round it belongs to (searchRound, SR-24);
  7. the tool or method, as free text with suggested values such as "ASySD (R)" or "EndNote";
  8. a description and an optional evidence note;
  9. who entered it and when.

Records are append-only: a correction supersedes the previous record and keeps its history. A record tied to a withdrawn search is withdrawn with it (J). 2. Entry phase per search or import. Each search or import carries an entry phase derived from its external records: identified, after deduplication, after title/abstract screening, after retrieval, or after full-text assessment (included elsewhere). Records imported after an outside step count as having passed that step: they create no pool-entry or outcome counts for that phase in SyRF, and the external record supplies the phase's counts with coverage "reported externally". For "included elsewhere", admission sets lifecycleStatus = Included and records the required profiles' outcomes with authority = Imported, coverage "external" (H), so box 10 counts them without inventing SyRF decisions. Owner session: authority = Imported is superseded by the owner session (5 October 2026), see H as revised. Under RI §3.13's mapping these outcomes carry finalSource = ProfileRule with externalHumanContribution = true and coverage "external" (PROPOSAL mapping). 3. Per-box combination. For boxes 2–9 and 11–15 each field value is the computed SyRF value plus any applicable reported external value for the same field; the report manifest stores both parts, the diagram shows the total and marks fields that include reported values ("includes 120 duplicates removed outside SyRF before import"), and exports include the breakdown. Boxes 10, 16 and 17 are computed only. Box 1 comes only from "studies from a previous review version" records (rule 7). 4. Identification (K.2 and K.3 agree). For the identification fields (#3–#6, #10–#12, #29–#30) the "reported" part is the "identified at source" count, which replaces the imported count for that search when it exists, because the imported count is the post-processing count; otherwise identification uses the imported count, labelled "as imported; processing before import not reported". The difference between identified at source and imported records is accounted for in box 3 by the reported removals (rule 6). 5. Consistency check. For a search with an "identified at source" count: identified at source − reported removals before import = imported records. A mismatch warns and asks for an explanation; it never blocks entry. A snapshot that still mismatches cannot be frozen until an administrator records the explanation (C12 identities). 6. No double counting. External screening, retrieval or assessment counts are allowed only for records not screened, retrieved or assessed in SyRF at that phase; records with SyRF decisions, including imported decisions (authority = Imported), count as "screened in SyRF" and refuse an external count for the same phase. Owner session (RI-R15, PROPOSAL extension): records with accepted external or AI-model-generated screening decisions (amendment P) also count as "screened in SyRF" and refuse an external count for that phase; "authority = Imported" reads as the composition fields of H as revised. When SyRF also deduplicates (L), box 3 duplicates = SyRF-detected duplicates (FEAT-012 §11.1) + reported external duplicates; FEAT-012 §11.2's count-consistency equation holds over SyRF-held Citations only, and the manifest keeps both parts. 7. Box 1 (D4-11). A "studies from a previous review version" record supplies previous_studies and previous_reports; when one exists the diagram switches to the updated-review template variant and box 16 = new + previous (FEAT-011 mapping §6). Full updated-review support (importing the previous review's included studies with PreviouslyIncluded) stays deferred. Owner session (D4-11 decided through E1; RI §3.4, RI-R13): previous-review counts are only ever explicitly supplied values. A field nobody supplied shows "not supplied". SyRF never derives previous_studies or previous_reports from its own data, from a reference list or from an earlier snapshot. The full updated-review workflow stays deferred (RI-AE10). 8. Authority and audit. Entering or correcting external counts needs the PRISMA report capability from the permission matrix (Q-03). Every change is audited, and frozen reports pin the record versions they used. 9. Withdrawn searches. A withdrawn search's records are excluded from current reports with its Citations (J); frozen reports keep them.

Fixtures: a search deduplicated outside SyRF before import; a mismatch warning and its explanation; a correction superseding a record while an earlier frozen report stays unchanged; combined external and SyRF deduplication in box 3; a search imported after external title/abstract screening (box 4 and 5 reported, box 6 from SyRF retrieval); an "included elsewhere" import counted in box 10 with Imported authority (owner session: with the composition fields of H as revised); a previous-review record switching the template variant (owner session: an unsupplied previous-review field shows "not supplied"); an external screening count refused for records with accepted AI-model-generated decisions (owner session, PROPOSAL).

Releases: P1 records external identification and deduplication counts per search, with the entry phase; R5b adds entry of the other step types and uses all records in reports.

L. ASySD deduplication inside SyRF (Chris, 3 October)

Today: FEAT-012's Approved service specification already makes ASySD the deduplication algorithm, implemented natively in C#:

  • a synchronous DOI/PMID exact match during import (Stage 1), and asynchronous fuzzy matching after import (Stage 2): four-round blocking, Jaro-Winkler similarity on ten bibliographic fields, 25 classification rules, and grouping;
  • AutoConfirmed and ProbableDuplicate tiers, an admin review queue, a merge wizard and an audit log;
  • retroactive deduplication for older projects, and the box 3 derivation and count-consistency rule (spec §§1–4, 7–11).

The Draft brief (docs/features/deduplication/brief.md) still says ASySD runs as an R subprocess; the Approved specification supersedes it. FEAT-012 calls the surviving record of a merge the "canonical Study" (§7, §9); this programme calls it the primary Study, because "canonical" means the engine here. Superseded by the owner session (5 October 2026), see DM §3: the terms are now the consolidated Study (a new current Study created by the merge) and the input Studies (tombstoned historical inputs).

Proposed amendment (alignment with this programme; rules under Q-37, D4-21 and D2-12): Owner session: approved through Q-37 on 4 October 2026, with rule 4 replaced by the consolidated Study model (D2-12 replaced; OS-A29) and rule 5 restated. Every threshold in rules 2 and 8 stays proposed, not approved and not achieved (D4-21 brief item, specialist input T-SI-04). The FEAT-012 change-policy documentation PR carries the revisions into the Approved specification (§7, §9, §11.2, §12).

  1. P2 implements FEAT-012 as specified, except where amendment D and this amendment change it: native C# ASySD, the two-stage pipeline, confidence tiers, the admin review queue, the merge wizard, the audit log and retroactive deduplication.
  2. ASySD parity (D4-21). A conformance suite runs the C# port against reference outputs from a pinned commit of the ASySD R package on the labelled benchmark datasets published with Hair et al. 2023 (dataset names and licences UNVERIFIED; pinned by commit in the fixture) and on SyRF's seeded PRISMA pilot data. The fixture pins the normalisation table (case, punctuation, Unicode, DOI prefix) so "identical" is testable. Pass conditions: identical AutoConfirmed groups on the pinned fixture; ProbableDuplicate pair-set F1 ≥ 0.99; sensitivity and specificity on the labelled datasets each within 0.5 percentage points of the R package (PROPOSAL); every divergent pair listed for review; 80,000 citations processed in under one hour on Bramble. Differences beyond these block the release. Owner session: F1 ≥ 0.99, the 0.5-point tolerance and 80,000 citations in under one hour are proposed, not approved and not achieved. The parity and benchmark method is specialist input T-SI-04, recorded before the P2 release decision (RI-R49).
  3. No hard deletes. FEAT-012 scenario 1's table says "delete secondary Study", while its detailed steps keep the secondary with lifecycleStatus = Duplicate. The detailed steps win: the secondary Study is never deleted, which also keeps box 3 counts derivable. Owner session (DM §3.1): no input Study is ever deleted; each is tombstoned (state = Tombstoned, reason ConsolidatedByMerge) with the FEAT-011 lifecycle value Merged, restored from the manifest on unmerge. Whether Duplicate or Merged is the lifecycle value for an input is a brief item (DM §12, PROPOSAL: Merged).
  4. Merge is an alias, never a re-key. Superseded by the owner session (5 October 2026), see rule 4R below and DM §4 (C21). Every natural key in the engine carries studyId and revisions are never edited (C1), so a merge cannot move sessions, gold or outcomes. Instead the secondary Study gets mergedInto and the primary gets a StudyAlias set. Reads, reconciliation candidate selection, statistics and PRISMA resolve aliases; the ContributionQualificationPolicy counts a reviewer once across aliased studies (SF2). When one reviewer reviewed both duplicates, the wizard resolves per reviewer: the current session is chosen (default the later Complete; admin choice), the other is superseded with provenance, and the reviewer is counted once; no candidate count is inflated (amendment D). The primary's gold and outcome histories continue; the secondary's become candidates with lineage, never promoted automatically. Merges and splits are ADR-020 operations that write both Study documents and refuse busy studies; split removes the alias and re-derives the primary's projections (E33 restated).

Rule 4R, as revised by the owner session (5 October 2026; DM §3 to §8; contract C21). A confirmed merge creates one consolidated current Study with a new identity reserved when the merge is created (PROPOSAL, DM §3.10). Every natural key still carries studyId and revisions are still never edited, so current state is copied at staging into records keyed to the consolidated Study (carried sessions, resolved sessions, carried accepted results, the merge-basis target override), each citing its exact source versions, the merge, the choices, the resolver, the actor and the time. Full histories stay on the inputs. Same-reviewer conflicts are resolved before commit by the merging user or the original reviewer (the actual resolver is recorded; the merging user chooses among the inputs' values and never types a new value into a reviewer's session, PROPOSAL). One activation transaction validates the inputs' current versions, inserts the consolidated Study, tombstones the inputs and writes the manifest; a failure leaves the originals current. Busy Studies are warned about and rechecked at commit, never refused, and drafts are kept. Reads, reconciliation candidate selection, statistics and PRISMA use the consolidated Study; tombstoned inputs redirect to it. A reviewer counts once across merge lineage, and no candidate count is inflated. An unmerge is a new immutable action that tombstones the consolidated Study, restores the inputs and records an explicit choice for every post-merge item (rule 10). 5. Scenarios by form and profile, not stage. Sessions belong to forms (SF1), so FEAT-012's "same stage" and "different stages" tests (§7.1 scenarios 3 and 4) are restated: - Scenario 1 (neither reviewed, high confidence): auto-confirmed alias merge, as specified. - Scenario 2 (one reviewed, high confidence): admin-reviewed under amendment D (not auto-confirmed as §7.1 says); the reviewed Study is the primary. §8.1's queue population therefore includes scenario 2. - Scenario 3 (both have evidence on at least one shared form or profile): admin-reviewed alias merge with candidate joining and per-reviewer resolution (rule 4). - Scenario 4 (evidence only on disjoint forms and profiles): admin-reviewed alias merge; no candidate collision arises. The former "link via Publication only" outcome remains for the case where the administrator judges the records to be different studies of one publication (then they are reports, amendment O). - Scenario 5 (probable duplicate): unchanged; "Not duplicate" is never re-queued for the same pair and algorithm version.

Scenarios as restated by the owner session (5 October 2026; DM §3.9, §4.13). "Alias merge" in scenarios 1 to 4 now reads "consolidation". Scenario 1 (neither input has any explicit version, decision, accepted result, draft or claim) is an automatic consolidation with no conflicts, the bibliography chosen by the system rule and recorded as system-only; any review activity, including a draft, makes the pair admin-reviewed (PROPOSAL for drafts). Scenarios 2 to 4 are admin-reviewed consolidations with conflict resolution before commit. Scenario 4's "link via Publication only" outcome becomes the explicit "Distinct report" outcome of the duplicate review queue: both Studies stay current with their evidence, no link is created in the MVP, and grouping reports into one investigation stays deferred (amendment O). "Not a duplicate" and "Distinct report" are never re-queued for the same pair and algorithm version. 6. Admission. Studies with lifecycleStatus ∈ {PendingDedupCheck, PendingDuplicateReview, Duplicate, Merged, RemovedByAutomation, RemovedOther} are excluded by the single admission service (C6) as well as by pool filters (FEAT-012 §12), so no path can offer them; only Active studies enter pools (taxonomy §4 rule 1). Owner session (DM-R20, DM-R21): Studies with state = Tombstoned are excluded too, including by legacy readers through the R0 floor step before P2, and every write to them is refused with a redirect to the current consolidated Study. 7. Privacy and enrichment visibility. Cross-project Publication enrichment shares bibliographic metadata only, never review data. Reading a Publication never exposes project or citation IDs from projects the caller cannot access: linkedProjectIds[] and metadataProvenance[].sourceProjectId and sourceCitationId are internal and served only to platform administrators; a project sees "metadata enriched from another SyRF project (not identified)". Each enrichment is a recorded event with a hybrid-logical-clock stamp, so an as-of export states the Publication metadata version it used, and Citations stay the raw, immutable source so an export is reproducible without the Publication. 8. QC sample and reviewer flag. A configurable share of AutoConfirmed groups (PROPOSAL default 5%, minimum 20 groups) is shown in the review queue for human confirmation; a reviewer action "Flag as possible duplicate of…" creates a DuplicateReviewItem from the screening or extraction page. Owner session: the QC share and minimum are proposed, not approved; the QC sample and the reviewer flag are merge entry points (DM §4.1). 9. Box 3 and transparency. Box 3 combines SyRF-detected and externally reported duplicates (K), and the manifest keeps both parts, plus the ASySD algorithm version (AlgorithmVersion), the tier-rules version, the auto-confirmed versus reviewed share, reversals and the QC sample result (PRISMA-S item 16). Owner session: FEAT-012 §11.2's count-consistency equation must be restated because references no longer move under consolidation; the restatement and the distinct counting across merge lineage are specialist input T-SI-05 (DM §12; AC-P2-07). 10. Audit. Audit entries are never deleted (FEAT-012 §10.3); reversal restores the previous lifecycle status and pool membership and is itself audited. Owner session: reversal is an unmerge (DM §4.9, §4.10), a new immutable action that never erases the merge; restored Studies re-enter the pools they match through ordinary reevaluation, recorded as pool events with cause StudyUnmerged. Merge reversal is separate from disaster recovery (D2-13).

Fixtures: FX-PRISMA-01 (P2 part) and FX-PRISMA-07a; ASySD parity; a reversed duplicate decision restoring pool membership; a merge where one reviewer reviewed both duplicates (counted once); a split after a merge; cross-project enrichment visible without project identity (FX-PRISMA-08a). Owner session: "a split after a merge" reads "an unmerge after a merge, with post-merge work carried to one restored Study"; FX-PRISMA-07a is rewritten as in amendment D; after a merge, current counts include the consolidated Study once and no tombstoned input, and after an unmerge a new snapshot counts the restored Studies while the earlier frozen snapshot is unchanged (RI-AE07).

Release: P2, after P1 and amendment D; reviewed-record scenarios after R3b.

M. Full-text retrieval

  • Today: study-lifecycle-and-source-taxonomy.md makes FullTextSought (3) and FullTextNotRetrieved (4) lifecycle states (lines 100–102, 148–166) with transitions T4, T12 and T13 (lines 241, 249–250), calls FullTextNotRetrieved terminal (line 258), derives box 6 from lifecycle ∧ title/abstract Included (line 453) and box 7 from lifecycle (line 461), and gives the lifecycle precedence over an Included outcome (lines 597–601). prisma-flow-diagram-mapping.md already derives boxes 6, 7, 8, 12, 13 and 14 from Study.fullTextStatus (lines 126, 132, 138, 152, 158, 164), and three-level-data-model.md defines FullTextStatus {Pending, Sought, Retrieved, NotRetrieved} (lines 211–219) while offering both derivations for box 7 (line 368).
  • Problem: the two derivations disagree; the precedence rule contradicts "lifecycle = pipeline position" and amendment H's per-profile outcomes; and no human action populates the boxes, so box 7 would always be 0 and box 8 would not equal box 6 (SR-02, SR-15).
  • Amendment:
  • Retrieval is fullTextStatus only. Lifecycle never changes for retrieval. T4, T12 and T13 are removed; ordinals 3 and 4 remain reserved and are never written. The precedence rule at lines 597–601 is deleted; the Included transition (taxonomy rule 6) is unaffected by retrieval.
  • Actions (actors and the PDF rule per D4-07): Sought (date); Retrieved (how: PDF in SyRF, read externally); Not retrieved (reason from a controlled list plus free text, and an author-contact date). Reasons (PROPOSAL): not available from any source; paywalled and not obtainable; author contacted, no response; wrong document supplied; language or format not usable; other.
  • Actors: project administrators and reviewers holding a stage grant (capability placeholder, A-03). Each action is an append-only StudyLifecycleEvent with actor and time.
  • Defaults: a title/abstract collective Include sets Pending → Sought (system actor, recorded). Attaching a PDF (manual link, bulk PDF, study-source upload) only suggests Retrieved; a human confirms. Reading the full text outside SyRF is Retrieved with how = external.
  • Admission: full-text steps admit only Retrieved studies (admin override, audited); a Not retrieved study receives no full-text outcome.
  • Boxes (by source column, amendment C): 6 and 12 = title/abstract Included with fullTextStatus ∈ {Sought, Retrieved, NotRetrieved}; 7 and 13 = title/abstract Included with NotRetrieved, with the reason breakdown exported; 8 and 14 = Retrieved ∧ entered the full-text pool. Adopted legacy projects without retrieval history show "retrieval not recorded" coverage, never an inferred Retrieved.
  • Superseded wording for the decision register §2: taxonomy T4/T12/T13, rule 5's FullTextNotRetrieved terminal state, the precedence edge case at lines 597–601, and the lifecycle-based box 6/7 derivations at lines 453 and 461.
  • Fixtures: a study title/abstract-included, marked Not retrieved and never full-text screened appears in boxes 6 and 7 and not in box 8, with its reason in the export (AC-P1-11, AC-R5b-18); a PDF attached without confirmation leaves fullTextStatus = Sought; FX-PRISMA-05b (retrieval change events reproduced as-of).
  • Releases: P1 (events and actions), R3a/R3b (admission), R5b (boxes).
  • Status (owner session, 5 October 2026). Approved: D4-07 decided through E2 on 4 October 2026. Explicit Sought, Retrieved and Not retrieved actions with actor, time and reasons; authorised administrators and reviewers with a grant on a stage using the Study record them; a PDF only suggests Retrieved and a human confirms; retrieval stays separate from lifecycle (RI §3.8, RI-R23 to RI-R26). The automatic Sought after a collective title/abstract Include and the reason list stay PROPOSALs. Studies of converted projects without retrieval history show "retrieval not recorded" coverage, never an inferred Retrieved.
  • Today: three-level-data-model.md makes Citation.publicationId required ("Nullable: No", line 147) and forbids changing a Citation after creation (line 167); Study.publicationId is set from the Citation (line 249). P1 writes immutable Citations before any Publication exists (Publication arrives in P2).
  • Problem: P2 would have to rewrite P1's Citations to link them (V2-01).
  • Amendment:
  • The link is held in an append-only CitationPublicationLink record (citation, publication, how linked: DOI, PMID, fuzzy group, admin; time). Linking never rewrites a Citation.
  • Citation.publicationId becomes optional and write-once at creation, set only when the identifier is known at import; it is never updated afterwards.
  • Study.publicationId stays a mutable pointer, maintained by the dedup operations.
  • Whether P1 also creates Publications for exact DOI/PMID matches (FEAT-012 Stage 1 brought forward) is decided at F-P (E92); a link record is needed either way for Stage 2 results.
  • FEAT-012 Stage 1 and Stage 2 write link records and Publications, never Citations (consistent with spec §1 invariant 3); the Release 3 checklist's "ALL Citations are immutable" check extends to link creation.
  • Fixtures: a P1 Citation linked at P2 without any change to the Citation document (AC-P2); FX-PRISMA-01 (P2 part).
  • Releases: P1 (record shape), P2 (links written by dedup).
  • Owner-session note (5 October 2026; DM §3.2, RD §3.3). N stays a proposal. Under the consolidated merge, Study.publicationId is maintained on the consolidated Study, and a Study's links to its references live on its immutable StudyVersion.referenceLinks[]; Citations never move and are never rewritten. A cross-project Publication value never changes a Study's displayed bibliographic fields silently; an admin may adopt it as a manual override with that source recorded (PROPOSAL).

O. Report-to-study linkage

  • Today: prisma-flow-diagram-mapping.md lines 56–70 map "study" to a Study after dedup consolidation and "report" to a Study with fullTextStatus; box 10 counts lifecycle Included Studies and reports as the sum of their Citations (lines 178–179). Amendment B (open) fixes report identity, but nothing groups several reports (papers) into one study (SR-07). Cochrane Handbook chapter 4 requires collating reports of the same study.
  • Status (owner session, 5 October 2026). Superseded by the owner session (5 October 2026), see RI §3.1 and RI-R03. D4-08 replaced immediate report linking with prepared multi-source links: a StudyVersion may hold several reference links (each with an optional sourceDocumentKey and its basis) and several source-document file links, while forms, sessions and targets stay on the Study. The workflow for grouping distinct reports into one investigation is deferred with no delivery commitment; no "link reports to one study" action exists in this rollout, and no operation merges distinct reports silently (RI-AE03). D4-08 and Q-23 are carry-forward alignment entries. The amendment text below is kept as the starting design for that later feature (StudyLink stays a future design) and freezes nothing now.
  • Amendment (conditional on D4-08):
  • A "Link reports to one study" action for administrators and reconcilers creates an append-only StudyLink group (members, reason, provenance, actor); dissolving a group is an appended event. Groups are shown in the study view and in exports.
  • Linking never merges screening or extraction evidence: each report keeps its sessions, outcomes and gold; extraction stays per report with a group key.
  • Counting: a group counts once as a study when at least one member is Included; included members count as reports (with B's report identity); an excluded member stays in box 9 with its reason. new_studies and total_studies resolve groups once; new_reports ≥ new_studies.
  • The duplicate review queue's pair view is reused with the outcome "same study, different report".
  • Fixtures: FX-PRISMA-09 (if D4-08 is approved): two reports linked → 1 study, 2 reports in box 10; an excluded companion report stays in box 9 and the group still counts once.
  • Releases: P2 (action and group), R5b (counting with B). Owner session: none in this rollout; FX-PRISMA-09 waits for the deferred grouping feature, and AC-R5b-15 is replaced by RI-AE03.

P. External and AI-model screening sources in FEAT-011 terms (owner session, proposed)

  • Today: FEAT-011 derives every screening count from SyRF reviewers' decisions. FEAT-011 field #8 excluded_automatic ("records marked ineligible by automation tools", box 3) is defined from a RemovedByAutomation lifecycle status. The package listed "machine-learning prioritisation or automated exclusion" as out of scope.
  • Owner decision (E3 AI expansion, 4 October 2026; OS-A20; RI §3.11 to §3.14, RI-R32 to RI-R47). SyRF will accept externally produced screening decisions, including AI-model-generated screening decisions, in a later opt-in lane (XS1, after the first engine release; no import is authorised now). The AI screening model is a machine source with its own versioned AIScreeningModelConfiguration in the project, never a person and never a login; the importer and accepter are recorded separately. A screening profile version declares each source's role, ContributingVote or SoleScreener, in its ScreeningSourcePolicy. Reruns create new versions of one source's decision, never extra voters. A model Unsure is never an Include: under a sole-screener policy it goes to human adjudication. Outputs on the model's training or evaluation inputs are flagged and are never independent validation. Prioritisation stays out of scope.
  • Proposed amendment (PROPOSAL):
  • Outcome composition. H's outcome shape carries machineContribution ∈ None, Contributing, Sole and externalHumanContribution, derived at commit (H as revised).
  • Machine-assisted share. Every frozen snapshot discloses, per PRISMA phase, the share of outcomes that rest on machine sources, and keeps a machine-only breakdown in its manifest (RI-R12, RI-AE29).
  • Methods summary. When external or AI sources contributed, the methods summary reports model name and version, role, thresholds as supplied, training-set description and Unsure handling (RI-AE36). Exports carry the source columns (decisionSourceType, aiModelConfigurationVersion, externalRunId, confidence, thresholdApplied, onTrainingInput, and machineContribution on outcomes).
  • No count before acceptance. A validated but unaccepted run changes no outcome, pool or count. Accepted decisions enter outcomes and pools only under the declared policy, for current Studies and profile versions, with structured pool history (RI-R43).
  • Double counting. Records with accepted external or AI-model-generated decisions count as screened in SyRF for amendment K rule 6 (RI-R15).
  • Sole-screener exclusions: box 3 or box 5. A sole-screener AI Exclude is a profile outcome at the title/abstract phase, which FEAT-011's excluded_automatic does not describe. Options: (a) count it in box 3 as automation removal; (b) count it in box 5 as a screening exclusion with a machine-only breakdown; © let the specialist decide, with both computations stored in the manifest. Recommendation: ©, decided under T-SI-05 before F6b (RI ambiguity A1).
  • Terminology. Documents and user-facing attribution say "AI-model-generated screening decision" and "AI screening model"; non-AI external sources keep their real type (superseded wording 14).
  • Fixtures (PROPOSAL): a sole-screener fixture where Include and Exclude become machine-only outcomes and Unsure creates an adjudication task (RI-AE26); contributing-vote fixtures under the profile rule (RI-AE27); training-input outputs excluded from sufficiency by default (RI-AE28).
  • Releases: the composition fields in H's shape at F3; the XS1 lane under its own brief, gate and default-off flag; the reporting parts with R5b.

Owner-session amendment record (5 October 2026)

Amendment Source Where on this page
Statuses of B, E, F, K, L, M and O; the revision note on A, D, G, H and J RI §13; DM §13; owner decisions Q-06b, Q-37, D4-07, D4-08 Approval status, summary table
WorkFirstReleased replaces StudyEnteredPool; stage pool history separate; reporting priority is actual review through the stage; box mapping T-SI-05 SP §13; RI §13; OS-A07, OS-A09, OS-A10, OS-A11 §A revision
Reporting units and report identity coverage; "one report per Study assumed" label Q-06b (E1); Q-23; RI §13 §B revision
Consolidated merge with atomic commit and reversible unmerge; references never move; lineage-aware distinct counting; FX-PRISMA-07a rewritten D2-12 replaced; OS-A29; DM §13 §D revision, §L rules 3, 4R, 5, 6, 9, 10, naming
Exclusion-reason template guidance; distinct excluded Studies apart from overlapping reason counts; Unsure counted as not excluded S3 (Q-22, D4-13), OS-A17; D4-01, OS-A16 §E revision, §H revision
Frozen reports also append merges, unmerges and withdrawals Q-06b (E1); RI-R10 §F
Per-project conversion inside the universal waves; no LegacyUnknown; conversion baseline coverage R4 owner direction, OS-A15; BC §13 §G revision
finalSource plus composition fields replace the authority list; resolutionState; adjudicated outcomes flagged, never rewritten RI §13; RS §14; RS-R58 §H revision
Exact recovery boundary for converted projects; D2-13 BC-R27, BC-R28; D2-13 brief item §I
Withdrawn searches decided; reversible project deletion Q-33; O1 final clarification, OS-A25; ACD §14 §J revision
Ledger approved; rule 6 extension; previous-review counts supplied only Q-37; D4-11; RI §13 §K header, rules 2, 6, 7, fixtures
ASySD thresholds proposed, not approved, not achieved D4-21 brief item; T-SI-04 §L rules 2 and 8
Retrieval approved D4-07 (E2) §M status
Prepared multi-source links; grouping deferred D4-08; RI-R03 §O status, §N note
External and AI-model screening sources in FEAT-011 terms E3 AI expansion, OS-A20; RI §13 §P (new)