Specification: duplicate merge and unmerge

Planning specification (prefix DM; tracker row T-DM-00). Feature implementation remains on hold (Chris, 5 October 2026). The owner decisions cited here are planning approval only. Brief approval and implementation authorisation are separate, per gate (D1-04), and are still on hold. No merge, unmerge, deduplication run or data change is authorised by this page. Nothing here says that work has started, that a gate has passed or that anything is enabled in production. Storage shapes and names are PROPOSALs until the F1a storage and naming ADRs and the F-P freeze fix them. Thresholds quoted from earlier documents are proposed and not approved.

Sources. "Consolidation" is the owner-session consolidation §2, which wins over older text. "Register" is the 74-entry session register ("Decisions already fixed for this review"; Q-37). Package context: domain model §4.7, consistency model §7.8, contracts C1, PRISMA amendments D and L, and the Approved deduplication service specification (FEAT-012). The base Study, StudyVersion, reference and session definitions are in review domain and versioning (RD). Pool history is SP; accepted-result authority is RS; counts, QC sampling and ASySD parity are RI; disaster recovery is BC. New contracts referenced: C20 structured history events and C21 duplicate consolidation and reversal.

Labels. OWNER (a decision ID or a consolidation section), PROPOSAL (this specification's recommendation for the brief), BRIEF (an engineering or validation item the brief settles).

1. Summary in plain English

A merge makes one consolidated current Study. When two or more Study records turn out to be the same study, typically the same paper imported from two databases, the merge creates one current Study that holds the combined bibliography, links to every original reference and carries the review work. The original Studies are kept, unchanged, as history. They are no longer listed, offered for review or counted in current totals.

Nothing in the originals is edited. Their references, sessions, decisions and accepted results stay exactly as they were. The consolidated Study is a new record (PROPOSAL) that links the references and holds copies of the current review work, each copy pointing to the exact version it came from.

Conflicts are settled before the merge commits. If one reviewer reviewed both duplicates, their two submissions are shown side by side in a reconciliation-like view, with agreeing answers filled in. The admin can choose between them or hand the choice to that reviewer, who gets a task naming the merge and the exact submissions. SyRF records who actually made each choice. Differing accepted results, differing adjudicated screening outcomes, differing reviewer targets and differing bibliographic fields are confirmed in the same way.

The commit is all or nothing. SyRF checks that nothing changed since the preview, then in one step makes the consolidated Study current and marks the originals as merged. If anything fails, the originals stay current and nothing partial is visible. Notifications and statistics follow reliably afterwards.

An unmerge is a new action that undoes the merge without erasing it. The consolidated Study becomes history and the originals become current again, exactly as they were. Work done on the consolidated Study after the merge is assigned item by item to one of the restored Studies or left in the merged history. It is never copied to both automatically.

Bibliography comes from the reference unless someone overrides it. With one reference and no override, the Study shows that reference's values and says so. Study-level values can be picked from any linked reference or typed manually; each field records where it came from, who decided and when. References themselves never change.

This is only for duplicates. Different reports of the same investigation, such as a conference abstract and the later journal article, are not merged. Grouping distinct reports is a deferred feature.

2. Decisions covered

ID	Decision in one line	Status	Section
Consolidation §2 (one consolidated Study)	A merge yields one consolidated current Study; originals are historical inputs, not allocated, listed or counted	Decided	§3.1, §4.5
Consolidation §2 (mutable parent, immutable history)	The Study parent holds a tombstone or current state and a pointer to its current immutable version; version and operation histories never change	Decided	§3.1, §3.2
Consolidation §2 (current evidence view)	A stored current evidence projection for efficient reads; performance and consistency proved before its design freezes	Decided (design is a brief item)	§3.6, §12
Consolidation §2 (atomic commit)	Validate current input versions, then activate, tombstone and write the manifest together; failure leaves the originals current	Decided	§4.5, §8
Consolidation §2 (conflicts before commit)	Same-reviewer conflicts and conflicting accepted results use a reconciliation-like view; answers and status resolved together; Complete still validates	Decided	§3.4, §4.2
Consolidation §2 (delegation)	The merging user resolves or delegates to the original reviewer; the actual resolver is recorded; unresolved conflicts stay visibly pending	Decided	§4.3, §6
Consolidation §2 (merge provenance)	Merge-created results cite exact source versions, the merge, the choices, the actor and the time	Decided	§3.5
Consolidation §2 (targets)	Conflicting reviewer targets are shown and the authorised merger confirms the effective target; reviewers count once	Decided	§4.4
Consolidation §2 (active work)	Warn about active reviewers, reconcilers, drafts, reservations and dependencies; recheck at commit; keep drafts; refuse stale saves	Decided	§7, §4.8
Consolidation §2 (unmerge)	A new immutable action; tombstone the consolidated state; restore the originals with links; never erase the merge	Decided	§3.7, §4.9, §4.10
Consolidation §2 (carry-forward)	Post-merge work goes to one restored Study or stays only on the historical merged Study; no automatic copy to both; warn about results with changed inputs	Decided	§4.9
Consolidation §2 (bibliography)	Values come from the single reference unless overridden; per-field value, source, actor, time and rule or confirmation; references unchanged	Decided	§3.2, §4.11
Consolidation §2 (duplicates only)	Distinct investigations and distinct reports are never silently merged	Decided	§3.9, §4.12
D2-12	One consolidated current Study with immutable history and reversible unmerge replaces the alias proposal	Replaced	Whole page
Q-37 (merge part)	The alias-only rule is replaced; imports preserved; non-current records excluded from admission; privacy kept; QC samples and reviewer flags feed merges	Decided-amended (merge part; counts and QC are RI's)	§4.1, §5
PRISMA amendment D (merge parts)	Kept where compatible; "moving Citations" and alias wording superseded	Superseded in part	§13, §14
FX-PRISMA-07a	"Identity mapping is an alias" superseded	Superseded	§11, §14
Q-02 (merge part; owned by SP)	Merges change review evidence and remaining work, not stage status directly	Decided	§4.6
D4-08, Q-23 (owned by RI)	Prepared multi-source links; distinct-report grouping deferred	Brief item (carry-forward alignment; owned by RI)	§4.12
D2-13 (owned by BC)	Disaster recovery is separate from merge reversal	Brief item	§8

3. Concepts, entities and storage

Each entity says what it is, how it is identified, which versions and pointers it has, what may change, where it is proposed to live, and what it is not.

3.1 Study parent and tombstone

• What it is. The mutable parent of every Study (RD §3.1). For merges it carries state ∈ Current, Tombstoned and a tombstone record.
• Identity. The Study GUID. Inputs keep theirs; the consolidated Study gets a new one (§3.10).
• Versions and pointers. currentVersionId points to the current StudyVersion. A tombstone is {reason (ConsolidatedByMerge or ReversedByUnmerge), operationId, at, actor, successorStudyIds}. consolidatedInto on a merged input points to the consolidated Study for redirects.
• Mutability. state, tombstone and consolidatedInto change only in a merge or unmerge activation, by compare-and-set on the Study's Audit.Version.
• Proposed storage (PROPOSAL). Fields on the existing pmStudy document. lifecycleStatus is set to the FEAT-011 value Merged on a merged input and restored from the manifest on unmerge; state is the authority for every current query. The R0 floor step before P2 adds state = Tombstoned to the shared pool, capacity and list predicate fragments, so legacy readers also exclude tombstoned Studies (consistency model §3.4).
• What it is not. "Historical" never means corrupt or deleted. A tombstoned Study stays readable in history, as-of exports and audit (consolidation §2).

3.2 StudyVersion and field provenance

• What it is. The immutable content version defined in RD §3.2. This page fixes its field provenance.
• Field value. Each displayed bibliographic field stores {value, origin, decidedBy, decidedAt, confirmation}. origin is one of: InheritedFromReference(citationId), used when the Study has one reference and no override; SelectedFromReference(citationId), a value chosen from one of several linked references; ManualOverride, a typed value; or SystemRule(ruleId, ruleVersion), a value picked by a rule such as FEAT-012 §6.1's best-of-breed selection. confirmation is SystemOnly or ConfirmedBy(actor, at).
• Fields. Title, authors, abstract, year, journal, volume, issue, pages, DOI, PMID and ISBN or ISSN (FEAT-012 §6.1), plus any field the F-P freeze adds.
• Precedence (OWNER). The displayed Study metadata uses the StudyVersion values. A manual override or a selected reference value takes precedence over the default. References never change.
• Cross-project enrichment. A FEAT-011 Publication value never changes a Study's fields silently. An admin may adopt it as a manual override, and the field then records that source (PROPOSAL).
• What it is not. It is not a merged citation. Every reference keeps its own raw values.

3.3 StudyMerge (operation and manifest)

• What it is. One duplicate consolidation, from preview to commit, with the manifest that records exactly what it combined and how.
• Identity. A GUID, plus the reserved GUID of the consolidated Study minted when the merge is created.
• Versions and pointers. inputs[] holds {studyId, studyVersionId, evidenceWatermark, evidenceDigest} for each input, taken at the latest preview. The evidence watermark is the study clock of the input's last canonical evidence change, so maintenance-only Study writes (fold entry removals, schedule tokens) never count as a change (consistency model §10.2). status is Draft, AwaitingResolution, ReadyToCommit, Staging, Committed, Abandoned or Failed (with a reason; Failed can return to AwaitingResolution). The header also holds the entry point (duplicate queue item, reviewer flag or library selection, with the ASySD algorithm version where relevant), conflict counts, target confirmations, the draft consolidated StudyVersion, other attribute decisions, the active-work digest, initiator, committer and times. Manifest items list every evidence item with its exact source versions, its treatment (CarryForward, Resolved(conflictTaskId) or NotCarried(reason)) and, after staging, the resulting record IDs.
• Mutability. The header changes by compare-and-set until Committed; after that the header and items never change.
• Proposed storage (PROPOSAL). pmStudyMerge (header) and pmStudyMergeItem (chunks). A unique partial index on inputs.studyId for non-terminal merges keeps a Study in at most one active merge.
• What it is not. It is not an alias and not a link between two current Studies.

3.4 MergeConflictTask

• What it is. One conflict that must be resolved before commit, assigned to someone.
• Identity. A GUID with its mergeId.
• Kinds.

Kind	Detected when	Who may resolve	Result
Same-reviewer form sessions	One reviewer has an explicit version on the same form on two or more inputs	The merging user, choosing among the inputs' values; or the original reviewer, choosing or editing their own answers	One MergeResolved session version on the consolidated Study
Same-reviewer screening decisions	One reviewer has a decision under the same profile on two or more inputs	As above	One MergeResolved profile-session version
Conflicting accepted results	Two inputs have current accepted results on the same form that differ	A user with Reconcile on the form: the merging user or a delegated reconciler	An AcceptedResultVersion with authority MergeResolved, or "no accepted value carried", which leaves reconciliation pending
Conflicting adjudicated outcomes (PROPOSAL, added in the 5 October harmonisation)	Two inputs have current adjudicated screening outcomes under the same profile that differ	An eligible adjudicator for the profile (RS-R53): the merging user if eligible, or a delegated adjudicator	An AdjudicationVersion with finalSource = MergeResolved (RS §3.8), or "no adjudication carried", which leaves the outcome to the profile rule
Differing reviewer targets	The inputs' effective targets for a form differ	The authorised merger	The confirmed effective target (§4.4)
Differing bibliographic fields or Study attributes	Reference values, retrieval status, custom ID or source documents differ	The merging user	The consolidated StudyVersion and attribute decisions

• Versions and pointers. inputs with exact versions; assignee (merging user, original reviewer, reconciler or eligible group); status (Open, Delegated, Resolved, Stale, Withdrawn); working state through the draft mechanics keyed by the task; resolution (chosen value per question with its source, chosen status, validation result); resolverId, resolvedAt; a delegation record.
• Mutability. Resolution changes until commit. A task becomes Stale when any of its input versions changes and returns to its assignee.
• Proposed storage (PROPOSAL). pmMergeConflictTask, a collection of its own because assignees find tasks through My work queries by assignee.
• What it is not. It is not a reconciliation task. A screening decision tie on the consolidated Study is ordinary workflow after commit (RS), not a merge conflict.

3.5 Merge-created and unmerge-created records

Record	When written	Content and provenance
MergeCarriedForward session version	Staging, for each current explicit session version on an input with no conflict	A new session on the consolidated Study (deterministic ID from project, consolidated Study, form, reviewer) whose version 1 copies the pin map into the consolidated Study's heads and revisions. Provenance: source session version, source revisions, merge. Effective author: the reviewer. Actor: the merge operation for the committing user. Status copied
MergeResolved session or profile-session version	Staging, from a resolved conflict	The chosen answers and status. Provenance: every source version, the per-question choice, the resolver, the merge. Complete only when validation passes under the declared form version
Carried accepted result	Staging, when one input has a current accepted result and no conflict exists	An AcceptedResultVersion keeping its original authority, with origin = MergeCarriedForward (RS §3.2). Flagged "inputs changed" when the consolidated Study's candidates differ from the result's input set
MergeResolved accepted result	Staging, from a resolved accepted-result conflict	Authority MergeResolved, resolver, source result versions
Screening outcome	Activation	The candidate facet is recomputed by the collective outcome policy over the consolidated Study's decisions. Where exactly one input holds a current adjudicated outcome under the profile, it is carried as the consolidated Study's final facet with origin = MergeCarriedForward, flagged "inputs changed" when its input vector differs from the consolidated decisions, until an eligible adjudicator explicitly reconsiders it (RS-R58). Differing adjudicated outcomes need a conflict task (§3.4). A pending adjudication is not an outcome. PROPOSAL, replacing the earlier use of the 25 September rule here
StudyTargetOverride with basis MergeConfirmation(mergeId)	Staging	Written when the confirmed effective target differs from the standard target
UnmergeCarriedForward session version, result or override	Unmerge staging	A copy of a post-merge item onto the chosen restored Study, with provenance: source record on the consolidated Study, unmerge, choice, actor

Only current state is copied. Full histories stay on the inputs and are reached through provenance. Exposure and initial-observation markers are copied from the sources; a merge resolution is never a new independent observation. Drafts are never carried (§4.8).

3.6 CurrentEvidenceView

• What it is. A stored projection of a Study's current review associations, for fast reads.
• Content. Per form: the effective target with its source; each session's reviewer, session ID, current version, status, standing and origin (own, carried from an input with the source version, or resolved by a merge); the current accepted result with its authority, origin and an "inputs changed" flag. Per profile: current decisions and the current outcome. Lineage: consolidatedFrom and the merge, or restoredBy and the unmerge.
• Identity. One per Study.
• Writes. In the same transaction as every canonical command that changes current evidence on the Study (CR-1), and by merge and unmerge activations for every Study involved.
• Proposed storage (PROPOSAL). A top-level currentEvidence sub-document on pmStudy. It takes over the per-form member list of Study.CanonicalSummary; the legacy-shaped stageProjection[] stays in the canonical summary until R7.
• Proof before freeze (OWNER: "performance and consistency proved before freezing its design"). Size at the max tier with many reviewers; write cost per command; a rebuild-parity fixture; read cost for project lists.
• What it is not. It is not authoritative. It is rebuildable from authoritative records, and a gate reads it only when its definition-version vector is current.

3.7 StudyUnmerge and carry-forward items

• What it is. The reversal of one committed merge, with a recorded choice for every item created on the consolidated Study after the merge.
• Identity. A GUID with its mergeId and consolidatedStudyId.
• Versions and pointers. The consolidated Study's StudyVersion and evidence watermark at preview; the restored Studies with the new StudyVersion each receives (reason Unmerge); items[] holding {kind, sourceRecord and version, lineageSuggestion, choice (CarryTo(studyId) or LeaveOnHistorical), warnings, resultingRecordIds}; status as for merges; actor and times.
• What counts as a post-merge item. Anything created on the consolidated Study after activation: new explicit versions on carried or resolved sessions, new sessions, decisions, accepted-result versions, override versions, bibliographic StudyVersions, retrieval actions and source-document links. A merge-time copy that nobody changed afterwards is not an item: the inputs already hold its original.
• Proposed storage (PROPOSAL). pmStudyUnmerge, with an item chunk collection if needed.
• What it is not. It is not a deletion of the merge, and it never offers "both" as a choice.

3.8 History events and pool consequences

• Events (C20 envelope; names PROPOSAL). StudyMerged on the consolidated Study, StudyTombstoned on each input, MergeConflictResolved per task, StudyUnmerged, StudyRestored, and StudyTombstoned on the consolidated Study after an unmerge. Each carries the operation as its causal operation, the actor, the effective time (the activation stamp) and the recorded time.
• Pools (SP). Inputs leave every current pool at activation because current pools filter on state. SP records StagePoolDeparted for each input with reason STUDY_NOT_CURRENT_MERGED and cause StudyMerged (SP §3.5.3, §3.12). The consolidated Study is evaluated against every stage study filter and enters those it matches (StagePoolEntered, cause StudyMerged). An unmerge records the reverse: reason STUDY_NOT_CURRENT_UNMERGED for the consolidated Study and entries with cause StudyUnmerged for the restored Studies.
• Counting (RI, T-SI-05). Distinct-Study counts follow merge lineage, so tombstoned inputs are never counted as additional current Studies, and as-of views before the merge still show the inputs.
• First release (PROPOSAL). The consolidated Study records WorkFirstReleased with releaseKind = InheritedThroughMerge (SP §3.7) at activation, for each stage where an input was already released, with a link to the earliest input release, so it is never delayed behind work that was already released.

3.9 Duplicate review outcomes

A FEAT-012 DuplicateReviewItem ends in one of: Confirm duplicate (starts a StudyMerge), Not a duplicate, Distinct report (related reports such as an abstract and an article; no merge; grouping is deferred, D4-08), or Defer. "Not a duplicate" and "Distinct report" are never re-queued for the same pair and algorithm version (amendment L.5).

3.10 Identity of the consolidated Study

Option	What happens	Assessment
A. New identity (PROPOSAL)	The merge creates a new Study; every input is tombstoned; an unmerge tombstones the consolidated Study and restores every input	Matches the owner's wording ("tombstone the historic consolidated state; restore current originals"); keeps both originals' histories untouched; makes "leave on the historical merged Study" a real place; post-merge work is isolated on one record. Cost: Study IDs change on merge, handled by consolidatedInto redirects and lineage columns in exports
B. Survivor identity	One input survives with a new content version; the others are tombstoned	Keeps one ID stable. Post-merge work lands on the survivor, so an unmerge must write reversal versions on the survivor and "leave on the historical merged Study" has no separate place

Recommendation: A. It is a brief decision (§12), stated here once.

4. What loads and writes when

"Study write" means the per-study compare-and-set with the canonical summary and currentEvidence (CR-1).

4.1 Start a merge and preview it

Aspect	Detail
Entry points	The duplicate review queue (ASySD AutoConfirmed and ProbableDuplicate groups, including the QC sample; RI), a reviewer's "Flag as possible duplicate of…" item, or an admin's selection in the Library
Reads	Each input's state (must be Current), StudyVersion and references; each input's currentEvidence; current session versions per form and profile; accepted results and outcomes; overrides and effective targets; drafts (authoritatively from the draft store); claims and connections; reconciliation tasks and editor claims; stage statuses (for information)
Writes	StudyMerge (Draft, then AwaitingResolution if conflicts exist) with the reserved consolidated ID, manifest items, conflict tasks assigned to the merging user, the preview and active-work digests
Transaction boundary	One transaction for the merge header, items and tasks. Inputs are not written; the unique partial index refuses a second active merge on the same Study
Shown	The evidence inventory per form and profile, each conflict, target differences, the suggested bibliography, active work and what the consolidated Study will look like

4.2 Resolve a conflict directly

Aspect	Detail
Reads	The task's exact input versions (rechecked as current), the form versions they pin, the compatibility classes
Shown	A reconciliation-like view. Agreeing compatible answers populate the resolution controls; conflicting answers sit side by side with their source and version
Writes	Working state on the task while editing; on Resolve, the task's resolution with the resolver and time. No evidence is written yet
Rules	The merging user chooses among the inputs' values or leaves an answer unanswered; they never type a new value into a reviewer's session (PROPOSAL). Answers and status are resolved together, and Complete is accepted only when validation passes under the declared form version
Derived afterwards	When no task is open or stale, the merge moves to ReadyToCommit

4.3 Delegate a conflict to the original reviewer

Aspect	Detail
Writes on delegation	Task assignee becomes the reviewer; a delegation record; a notice identifying the duplicate merge, the Studies and the exact submissions; a My work item
Reviewer reads	Only their own input versions, side by side
Reviewer writes	Working state; on Resolve, the resolution with the reviewer as resolver. The reviewer may choose or edit their own answers and may Complete if validation passes
Refusals	Delegation is refused if the reviewer no longer has access to the project or form; the admin then resolves it or uses contribution exclusion (AC)
Pending state	The merge shows "1 conflict waiting for Alice Martin, delegated 5 October" to users allowed to see the name, and "waiting for the original reviewer" to others

4.4 Confirm the effective target and the bibliography

Aspect	Detail
Target	Per form where the inputs' effective targets differ, the merger sees each value with its source (standard, override, request) and confirms the consolidated Study's effective target. Confirmation needs the authority that applies a Study target override (RD §6). Qualifying reviewers count once
Bibliography	Field by field, SyRF suggests a source by FEAT-012 §6.1's rules. The merger confirms, picks another reference's value or types a value. Each field records its origin, actor, time and confirmation
Other attributes	Retrieval status, custom ID and source-document links are confirmed side by side (PROPOSAL)
Writes	The merge header (draft consolidated StudyVersion, target and attribute decisions) by compare-and-set

4.5 Commit: staging and atomic activation

1. Preconditions. No open or stale conflict; every confirmation made; the active-work summary recomputed and acknowledged.
2. Staging (an operation; resumable). Writes, under the reserved consolidated ID: StudyVersion version 1, carried and resolved sessions with their versions, heads and revisions, accepted-result versions, the merge-basis override and retrieval events. These records are invisible because no Study document with that ID exists yet.
3. Activation (one transaction).
4. Read every input Study in the transaction snapshot: state must be Current, and its current StudyVersion and evidence watermark must equal the recorded values; otherwise refuse with InputsChanged, abandon the staged records and mark affected conflict tasks Stale. Each input is then written by compare-and-set on the Audit.Version read in the same snapshot.
5. Refuse with Locked if a bulk-update lock covers an input.
6. Recompute the active-work digest; if new drafts or claims appeared, refuse with ActiveWorkChanged for re-confirmation.
7. Insert the consolidated Study (Current, currentVersionId, currentEvidence, lifecycle from its outcomes).
8. Tombstone each input by compare-and-set (reason ConsolidatedByMerge, consolidatedInto, lifecycle Merged) and remove their claims.
9. Mark the merge Committed and freeze its manifest.
10. Write the StudyMerged and StudyTombstoned events and the durable intents: notifications, claim revocations, the FEAT-024 staged rebuild for affected families, pool history evaluation.
11. Size. The activation writes a handful of documents whatever the evidence volume, because the evidence was staged before it.

4.6 After activation

• Durable intents deliver notices once per recipient: reviewers with evidence or drafts on an input, reconcilers with tasks or editor claims on an input, delegated resolvers and admins. Content follows the project's notification content policy and blinding (O2, AC).
• SP records pool departures and entries with the merge as cause. Automatic stages re-evaluate remaining work. A manually completed stage stays completed (Q-02; consolidation §3).
• A reconciliation task for the consolidated Study and each form exists once the form has a qualifying candidate there (RS §3.1); its input set is the consolidated Study's current sessions. Tasks on the inputs are frozen with their drafts kept.
• FEAT-024 families rebuild under their staged operation fence.

4.7 Work on the consolidated Study

Reviewers open the consolidated Study and find their carried or resolved session. Saves, Completes, decisions, reconciliation and target changes work as on any Study (RD §4). The Study page shows "Consolidated from S-204 and S-377 on 5 October (merge M-17)".

4.8 Someone reaches a tombstoned input

Aspect	Detail
Reads	The input's state and consolidatedInto
Writes	Every write to a tombstoned Study is refused with StudyConsolidated and a redirect. A draft on that Study is kept
Shown	A read-only historical view: "Merged into S-512 on 5 October by Priya Shah". "Continue in S-512" opens the reviewer's session there and offers to apply their kept draft as a new draft, an explicit action recorded with its source
Links	Bookmarks and API reads of a tombstoned Study return the redirect, following chains to the current Study

4.9 Preview an unmerge

Aspect	Detail
Preconditions	The consolidated Study is Current and is not an input of a later merge; a chain is reversed from the latest merge first
Reads	The merge manifest; every record on the consolidated Study created after activation; the inputs' pre-merge state; active work on the consolidated Study (drafts, claims, reconciliation in progress)
Shown	Every post-merge item with a lineage suggestion (a session carried from S-204 suggests S-204; a resolved or new record has no suggestion) and the choices "move to S-204", "move to S-377" or "leave in the merged history". Warnings for accepted results whose inputs came from both originals, and for reviewers whose moved work would supersede a different current version on the target Study
Writes	StudyUnmerge (Draft) with its items. Every item needs an explicit choice; bulk choice per kind is allowed; "both" is never accepted

4.10 Commit the unmerge

1. Staging. For each item moved to a restored Study, write the copy keyed to that Study, not yet linked to any session head; write a new StudyVersion for each restored Study (reason Unmerge, pre-merge content plus any moved bibliographic choice).
2. Activation (one transaction). Check the consolidated Study's StudyVersion and evidence watermark against the preview (otherwise refuse and re-preview). Tombstone the consolidated Study (reason ReversedByUnmerge). Return each input to Current, clear consolidatedInto and restore its lifecycle from the manifest. Link the staged copies to their session heads and assign their sequence numbers. Write currentEvidence for every Study involved, mark the unmerge Committed, write the events and the durable intents (notifications, pools, statistics, claim revocations on the consolidated Study).
3. Result. The restored Studies hold exactly their pre-merge evidence plus the moved items, each moved item marked "moved from S-512 by unmerge U-4". Items left behind stay readable on the historical consolidated Study.

4.11 Edit a bibliographic field on a current Study

Aspect	Detail
Reads	The current StudyVersion and the linked references
Writes	A new StudyVersion with the field's origin (ManualOverride or SelectedFromReference), the Study's projection fields and a history event, in one study-scoped transaction
Revert	"Use the reference value" writes another version with origin InheritedFromReference or SelectedFromReference
Never	A reference is never edited

4.12 Decide "distinct report" or "not a duplicate"

The queue item records the decision, actor and time. Both Studies stay current and keep their evidence. For "distinct report" the page explains that grouping reports into one investigation is a deferred feature (D4-08, RI); no link is created by this decision in the MVP.

4.13 Automatic consolidation of unreviewed duplicates

For FEAT-012 scenario 1 (AutoConfirmed, and neither input has any explicit version, decision, accepted result, draft or claim), the system runs the same merge with no conflicts, the bibliography picked by the system rule and recorded as SystemOnly, and the system as actor. A pair with any review activity, including a draft, is admin-reviewed (amendment D; PROPOSAL for drafts). An unmerge reverses an automatic merge exactly as it reverses a manual one.

5. Rules

ID	Rule	Source
DM-R01	A merge produces one consolidated current Study with consolidated metadata, reference links and current review associations. Originals are historical inputs and are not allocated, listed or counted in current totals.	OWNER consolidation §2
DM-R02	The Study parent is mutable (state and current-version pointer). Version and operation histories are immutable. Historical never means corrupt or deleted.	OWNER consolidation §2
DM-R03	The consolidated Study is a new identity reserved when the merge is created; inputs are tombstoned at activation.	PROPOSAL (§3.10)
DM-R04	The preview shows inputs with exact versions, the evidence inventory, every conflict, target differences, the suggested bibliography and active work before anything commits.	OWNER consolidation §2
DM-R05	Same-reviewer sessions or decisions and conflicting accepted results are resolved in a reconciliation-like view: agreeing compatible answers populate the controls, conflicts sit side by side, answers and status are resolved together, and Complete still passes validation.	OWNER consolidation §2
DM-R06	The merging user resolves a conflicting candidate contribution directly or delegates it to the original reviewer, who receives a task naming the merge and the exact inputs. The actual resolver is recorded; an admin's choice is never presented as the reviewer's.	OWNER consolidation §2
DM-R07	Conflict resolution precedes commit. Unresolved conflicts stay visibly pending and the merge cannot commit while any is open or stale.	OWNER consolidation §2
DM-R08	Every merge-created record cites its exact source versions, the merge, the recorded choices, the actor and the time. Original route and stage provenance stays inspectable through the inputs.	OWNER consolidation §2
DM-R09	Conflicting reviewer targets are shown; the authorised merger confirms the consolidated effective target; qualifying reviewers count once.	OWNER consolidation §2
DM-R10	Active reviewers and reconcilers, interruptions, drafts, reservations and dependency changes are shown before confirmation and rechecked at commit. Drafts are kept; stale saves never overwrite new state.	OWNER consolidation §2
DM-R11	Activation validates every input's current version, then inserts the consolidated Study, tombstones the inputs and writes the manifest, audit and current evidence in one transaction. A failure leaves the originals current.	OWNER consolidation §2
DM-R12	Notifications, statistics and pool history follow through durable intents and never expose partial authoritative state.	OWNER consolidation §2; C19
DM-R13	The current evidence view is a stored projection written with every change to current evidence; its design is proved for performance and consistency before freeze.	OWNER consolidation §2; design PROPOSAL
DM-R14	An unmerge is a new immutable action. It tombstones the consolidated Study, restores the originals with links to the merge and the reversal, and never erases the merge.	OWNER consolidation §2
DM-R15	Each post-merge item goes to one restored Study or stays only on the historical consolidated Study, by explicit choice. Nothing is copied to both automatically. Provenance and the unmerge decision are kept.	OWNER consolidation §2
DM-R16	The unmerge warns about accepted results whose inputs change, keeps existing result versions, and creates replacements only by explicit action.	OWNER consolidation §2
DM-R17	Bibliography comes transparently from a single reference unless overridden. Study-level fields may hold a selected reference value or a manual override, which take precedence. Each field keeps its value, source reference and version, actor, time and rule or confirmation. References never change.	OWNER consolidation §2; register "Decisions already fixed"
DM-R18	Only duplicates are merged. Distinct investigations and distinct reports are never merged silently; "distinct report" is an explicit outcome and grouping is deferred.	OWNER consolidation §1, §2
DM-R19	A merge changes review evidence and remaining work, not stage status directly. Pool membership follows the stage filters over current evidence.	OWNER consolidation §3; Q-02
DM-R20	A tombstoned Study refuses every write, including legacy writes through the R0 floor predicate, and redirects readers to its current successor.	PROPOSAL
DM-R21	Imports are preserved; references never move; non-current Studies are excluded from admission; cross-project identities never appear in a preview; QC samples and reviewer flags are entry points. ASySD parity is D4-21 (RI).	OWNER Q-37 (merge part)
DM-R22	The merging user never types a new value into a reviewer's session; they choose among the inputs' values or leave an answer unanswered.	PROPOSAL
DM-R23	A Study is an input to at most one active merge at a time; an unmerge reverses the latest merge in a chain first.	PROPOSAL
DM-R24	Merge reversal is separate from disaster recovery (D2-13, BC).	OWNER register D2-13 context
DM-R25	Nothing on this page authorises implementation, a deduplication run or a data change.	OWNER hold, 5 October 2026

6. Authorisation, blinding and provenance

• Capabilities (placeholders until A-03). Starting, committing and reversing merges needs Manage studies. Resolving a same-reviewer conflict directly needs Manage studies; the original reviewer resolves their own conflict with their ordinary Review access. Resolving an accepted-result conflict needs Reconcile on that form; resolving an adjudicated-outcome conflict needs the adjudication capability for the profile (RS-R53). Confirming a target needs the override authority (RD §6). Editing a bibliographic field needs Manage studies.
• Blinding. Detecting that one reviewer reviewed both inputs needs identities, so the preview shows reviewer names only to users allowed to see reviewer identities for that form (Monitor or project admin, D3-20, C10). A merging user who is blinded for the form sees context-local aliases such as "Reviewer 1 (same person on both)" and can delegate without learning who it is. A delegated reviewer sees only their own submissions. A reconciler resolving an accepted-result conflict sees candidates under the form's reconciliation blinding (RS).
• Privacy. A preview never shows project or citation identities from projects the user cannot access (amendment L.7).
• Provenance. Every merge-created and unmerge-created record carries its source versions, operation, choices, resolver, actor and time (§3.5). Tombstones, the manifest, the conflict tasks and the history events keep the full account.

7. Active-work impacts

Action	Warned before commit	Rechecked at commit	Notified after	Apply anyway
Merge	Active reviewers and reconcilers on any input; drafts; reservations; reconciliation drafts; accepted results and adjudicated outcomes whose inputs change (carried and flagged, §3.5); readiness changes	Each input's StudyVersion and evidence watermark; active-work digest	Reviewers with evidence or drafts on an input; reconcilers; delegated resolvers; admins	Not offered. Reservations on inputs are released because the inputs are tombstoned; drafts are kept
Delegation	The reviewer is told what the task is and that the merge waits for it	Task inputs	The merging user when the reviewer resolves	Not applicable
Unmerge	Active work on the consolidated Study; results with changed inputs; moved work that supersedes a different current version	The consolidated Study's StudyVersion and evidence watermark; active-work digest	Reviewers whose work moved or stayed; reconcilers; admins	Not offered; drafts on the consolidated Study are kept and can be applied explicitly
Bibliographic edit	None (no review impact)	Study version CAS	None	Not applicable

8. Failure and recovery

Failure	Handling	What the user sees
An input changed after the preview	Activation refuses with InputsChanged; staged records are abandoned and discarded by audited cleanup; affected conflict tasks become Stale	"This study changed since the preview" with a refreshed preview
New active work appeared	ActiveWorkChanged; re-confirmation	The updated active-work list
Bulk-update lock	Locked with retry-after	A specific message
Staging crash	Lease expiry and takeover; staging resumes idempotently	Progress resumes
Activation crash	The transaction either committed or did not; the merge status shows which	Either committed or ready to retry
Notification or statistics failure after commit	Durable intents retry; FEAT-024 fails closed on stale families	A delayed notice or a statistics refresh state
A delegated reviewer loses access	The task returns to the merging user	"Reassign or resolve"
Save to a tombstoned input	StudyConsolidated with redirect; draft kept	"Merged into S-512" and "Continue in S-512"
Unmerge input changed	Refused; re-preview	The new post-merge items
Data loss needing restore	D2-13 isolated point-in-time recovery (BC), separate from merge and unmerge	A recorded history discontinuity

9. User flows and examples

The project is "Stroke neuroprotection review". Priya Shah is the admin. Alice Martin, Ben Okoro, Carmen Diaz and Gita Rao are reviewers. Dev Patel reconciles. S-204 is "Lee 2021, Journal of Cerebral Blood Flow and Metabolism" imported from PubMed; S-377 is the same paper imported from Embase.

Evidence before the merge.

Item	S-204	S-377
Title and abstract profile	Alice Include; Ben Include	Alice Exclude; Ben Include; Carmen Include
Risk of bias form (standard target 2)	Alice Complete (version 2); Ben Complete	Alice Save, incomplete (version 1); Carmen Complete
Accepted RoB result	Dev, HumanReconciled from Alice and Ben	None
Target override	None	RoB target 3, set by Priya
Drafts	None	Carmen has a draft on the Extraction form

9.1 Preview (loading, pending, conflict)

Priya opens the duplicate queue item (ProbableDuplicate). The preview loads, then shows:

• Conflicts. Alice: screening Include versus Exclude. Alice: RoB version 2 (Complete) versus version 1 (incomplete). Ben: screening Include on both, which agree and are prefilled. RoB target: 2 (standard) versus 3 (override).
• Carried without conflict. Ben's RoB on S-204, Carmen's screening and RoB on S-377, Dev's accepted RoB result (to be flagged "inputs changed" because S-512 will have Carmen's Complete as a third candidate).
• Bibliography. Title from PubMed (longer); abstract from Embase (PubMed's is empty); DOI from PubMed. Each is a system suggestion awaiting confirmation.
• Active work. Carmen's draft on S-377 Extraction.

The merge status is "Pending: 3 conflicts and 1 agreeing item to confirm".

9.2 Priya resolves and delegates

Priya confirms Ben's identical screening decisions; the resolution records her as resolver and notes that the inputs were identical. She confirms target 3 for RoB. She confirms the bibliography. She could choose between Alice's answers herself, but she delegates both of Alice's conflicts to Alice. The status reads "1 reviewer to respond: Alice Martin, delegated 5 October 10:12".

9.3 Alice resolves her own conflicts

Alice gets a My work item: "Duplicate merge needs your input: Lee 2021 was imported twice and you reviewed both copies." She sees her RoB versions side by side: 18 agreeing answers are filled in and 3 differ. She picks two from version 2, edits the third, and presses Complete; validation passes. For screening she chooses Include. Both resolutions name Alice as resolver.

9.4 Stale input before commit

While the merge waited, Ben saved a correction to his S-204 RoB. Priya presses Commit. Activation refuses with "S-204 changed since the preview". Nothing changed for anyone. The preview refreshes and shows Ben's new version as the carried item. No conflict involved Ben, so nothing returns to anyone. Priya commits again.

9.5 Commit

Activation succeeds. S-512 is current; S-204 and S-377 show "Merged into S-512 on 5 October by Priya Shah". S-512 has RoB candidates Alice (resolved, Complete), Ben and Carmen, so it meets target 3. Its screening outcome is recomputed from Alice, Ben and Carmen's Include decisions. Dev is told that the accepted RoB result moved to S-512 with inputs changed. Carmen is told that her Extraction draft on S-377 is kept; she opens S-377, chooses "Continue in S-512" and applies the draft there.

9.6 Work after the merge

Ben edits his RoB on S-512 and Saves. Dev reconciles RoB on S-512 with all three candidates and publishes a new accepted result. Gita completes Extraction on S-512. Priya corrects the year by a manual override.

9.7 Unmerge two weeks later

Priya learns that S-377 is actually the 2021 conference abstract, which the protocol keeps as a separate Study, so the two were not duplicates. She opens "Unmerge" on S-512. The preview lists:

Post-merge item	Suggestion	Priya's choice
Ben's RoB version on S-512	S-204 (carried from S-204)	Move to S-204
Dev's accepted RoB result on S-512	None; warning: its inputs came from both originals	Leave in the merged history
Gita's Extraction session	None	Move to S-204
Priya's year override	None	Move to S-204
Carmen's applied Extraction draft	Not an item (a draft); kept on S-512 and Carmen is told	Not applicable

Alice's resolved session had no post-merge change, so nothing moves; S-204 and S-377 get Alice's originals back, including her incomplete S-377 RoB. On commit S-512 becomes historical and S-204 and S-377 are current with exactly their pre-merge evidence plus the moved items. Dev is told to reconcile S-204 again; his S-512 result stays readable in history. The screening outcomes on S-204 and S-377 are what they were before the merge.

9.8 Distinct report at the queue

ASySD flags S-410 "Kumar 2020" (journal) and S-411 "Kumar 2019" (conference abstract). Priya chooses "Distinct report". Both stay current. The pair is not queued again for this algorithm version.

9.9 A bibliographic override with one reference

S-102 has one reference. Its title shows "from reference: PubMed import, 2 October". Priya fixes a typo; version 2 records ManualOverride by Priya. The reference is unchanged. "Use the reference value" later writes version 3 with origin InheritedFromReference.

9.10 An automatic consolidation (empty and historical states)

At import, S-601 and S-602 are AutoConfirmed duplicates with no review activity. The system merges them into S-603 with the bibliography picked by rule. The merge's conflict list is empty. S-601 and S-602 appear only in the "Show merged records" filter of the Library, as historical records.

10. Rollout and adoption

Scope	Release or lane	Dependencies
Study state and tombstones; StudyVersion with field provenance and bibliographic overrides; consolidation and unmerge of unreviewed duplicates (automatic and admin); the R0 floor tombstone predicate; history events; the current evidence view shell	P2a	P1; R0 floor step before P2; C21 frozen at F-P; C20
Reviewed duplicates: carried and resolved sessions and decisions, conflict tasks and delegation, target confirmation, unmerge carry-forward	P2b	R2b (shared sessions), R3b (profiles), SP structured events
Accepted-result and adjudicated-outcome conflicts; carried results and carried adjudications	P2c	R4a, R4p (RS)
Existing Studies' first StudyVersion	On first need or at baseline conversion	BC (CurrentSnapshotOnly)

• Baseline and MVP. P2a and P2b are the MVP for deduplication of canonical projects; P2c follows reconciliation. There is no opt-in beta.
• Legacy projects. No merge runs on a project before it is enrolled or converted. FEAT-012 is not live today, so this removes no existing behaviour.
• Deferred. Grouping distinct reports into one investigation (D4-08, RI).
• Flags. Per-project enrolment governs merges. A project-level switch that stops new merges while keeping unmerge available is proposed as the kill switch (PROPOSAL). The queue and wizard live in Study Management's Processing area (behind studyManagementProcessing today).
• Pilots. Staging seeds include duplicate pairs for every scenario (D3-14). A production pilot needs its own approval.

11. Acceptance evidence

ID	Evidence	Verification	Amends
DM-AE01	Failure injected at every write of staging and activation leaves either the originals current with no consolidated Study visible, or the consolidated Study current with every input tombstoned and the manifest committed; never anything partial	Integration (failure injection)	AC-P2-05
DM-AE02	A Save on an input after the preview makes activation refuse; the originals stay current; affected conflict tasks become stale	Integration	New
DM-AE03	A save to a tombstoned input is refused with a redirect and the draft is kept; "Continue" applies it explicitly on the consolidated Study	Integration, e2e	New
DM-AE04	Commit is refused while any conflict is open or stale; pending conflicts are listed with their assignee	Integration, e2e	New
DM-AE05	A delegated reviewer receives a task naming the merge and exact inputs; the resolution records the reviewer as resolver; an admin resolution records the admin and never the reviewer	Integration, e2e	New
DM-AE06	Agreeing compatible answers are prefilled; conflicts are side by side; a resolved Complete passes validation or is refused	Conformance, e2e	New
DM-AE07	A reviewer on two inputs counts once on the consolidated Study × form; different reviewers form a union; no target is double counted and no accepted result is promoted automatically	Conformance	FX-PRISMA-07a (rewritten)
DM-AE08	The confirmed effective target is applied through a merge-basis override and recorded in the manifest	Integration	New
DM-AE09	Every merge-created record links exact source versions, the merge, the choices, the actor and the time; original routes are visible through the inputs	Integration	AC-P2-05
DM-AE10	Tombstoned inputs are absent from pools, allocation, normal lists, current totals and current statistics, and present in history, as-of exports and audit	Integration, e2e	AC-P2-06r
DM-AE11	The current evidence view equals a rebuild from authoritative records after every merge, unmerge and ordinary command, and list reads stay within a measured budget (target proposed, not approved)	Integration, benchmark	New
DM-AE12	With no post-merge work, an unmerge restores every input's evidence digest-identical to its pre-merge state; the merge record is intact	Conformance	AC-P2-04
DM-AE13	Every post-merge item needs a choice of one restored Study or the merged history; the API refuses "both"; moved records carry provenance; left items stay only in the merged history	Integration	New
DM-AE14	An unmerge warns about results whose inputs change, keeps existing result versions and creates replacements only by explicit action	Integration, e2e	New
DM-AE15	A single reference displays transparently; overrides take precedence; each field keeps origin, actor, time and confirmation; references are byte-unchanged	Integration, conformance	New
DM-AE16	"Distinct report" leaves both Studies current, records the decision and never merges evidence	Integration, e2e	AC-P2-12
DM-AE17	A blinded merging user sees aliases and can delegate without learning identities; a delegated reviewer sees only their own submissions	Integration, e2e	New
DM-AE18	After commit each affected reviewer and reconciler gets one notice whose content follows the notification content policy	Integration	New
DM-AE19	A manually completed stage stays completed after a merge; automatic stages re-evaluate; pool events carry the merge as cause	Integration	New
DM-AE20	Every inventoried legacy writer refuses a tombstoned Study through the floor predicate	Integration	R0 floor criteria
DM-AE21	Automatic consolidation of a large import stays within a measured budget (target proposed, not approved; D4-21 is RI's)	Benchmark	AC-P2-13 (related)
DM-AE22	PRISMA distinct counting follows merge lineage once T-SI-05 fixes the box mapping	Conformance	Pending T-SI-05
DM-AE23	An unmerge is refused on a consolidated Study that is an input of a later merge until that merge is reversed	Integration	New
DM-AE24	A single input's adjudicated outcome is carried as the consolidated Study's final facet, flagged "inputs changed" when the consolidated decisions differ, until explicit reconsideration; differing adjudicated outcomes block commit until a conflict task resolves them or records "no adjudication carried"	Integration	New

12. Brief items, specialist inputs and unapproved proposals

This specification owns none of the 22 session-register brief entries; D4-21 (ASySD parity, T-SI-04) and the counts and QC part of Q-37 are RI's, and D2-13 is BC's. Its brief items are:

Item	Proposal
Identity of the consolidated Study	Option A in §3.10
Carried evidence: copy or reference in place	Copy current state at staging (§3.5), so every current record of a Study is keyed to that Study and an unmerge has clear choices. The alternative, a view that points at input records with copy-on-first-write, is measured before freeze
Current evidence view design	§3.6, with the size, write-cost, parity and read-cost proofs the owner requires
Admin authoring limit	DM-R22
One active merge per Study; chain order	DM-R23
Drafts and automatic merges	Any draft makes the pair admin-reviewed
Allocation, batch and partition placement of the consolidated Study	Inherit the most advanced placement among the inputs; record it in the manifest (SP)
First release of the consolidated Study	§3.8
Staged-record cleanup	Audited discard of staged records of an abandoned merge or unmerge; retention measured
Lifecycle mapping	Merged on inputs, restored on unmerge (§3.1)
PRISMA box 3 arithmetic and distinct counting under consolidation	Specialist input T-SI-05 with RI. FEAT-012 §11.2's equation needs restating because citations no longer move
Agreement statistics for a merged same-reviewer observation	Specialist input T-SI-02 (Q-16, D4-12)

Ambiguities, each stated once.

1. May a merge commit with some conflicts still pending? Option A: never. Option B: allow it by explicit choice, holding the conflicting contribution out of current counts until resolved. Recommendation: A for the MVP, because the consolidation says resolution precedes commit; revisit after pilots.
2. Consolidated identity. Recommendation: option A in §3.10.
3. Admin values in a reviewer's session. Option A: choose among inputs only. Option B: allow new values with attribution. Recommendation: A, so a reviewer's evidence never contains an answer they did not give.

Proposals not approved. Every numeric threshold (QC sample share, throughput, read budgets). The ASySD F1 ≥ 0.99 and 80,000-citations-in-one-hour figures (D4-21) are proposals, neither approved nor achieved.

Harmonisation notes (5 October 2026).

• §3.5 screening-outcome row: no longer applies the 25 September rule. A single input's adjudicated outcome is carried as the consolidated Study's final facet, flagged "inputs changed", until explicit reconsideration, matching RS-R58 and the owner rule that dependent results are never silently rewritten (Q-27; O1 amendment; consolidation §1). PROPOSAL.
• §3.4: new conflict kind for differing adjudicated outcomes, resolved by an eligible adjudicator into a MergeResolved final facet (RS §3.8 already listed MergeResolved; no DM path produced it before). §1, §6, §7, §10 (P2c) and new DM-AE24 follow.
• §3.5 carried accepted result: origin = MergeCarriedForward now names RS §3.2's new origin field.
• §3.8: pool departure reasons and causes use SP's codes (STUDY_NOT_CURRENT_MERGED, STUDY_NOT_CURRENT_UNMERGED, causes StudyMerged and StudyUnmerged); the tombstone reason ConsolidatedByMerge is unchanged. First release uses SP §3.7's new releaseKind = InheritedThroughMerge.
• §4.6: the consolidated Study's reconciliation task exists once a form has a qualifying candidate, as RS §3.1 now requires for every form (it no longer waits for readiness).
• §2: Q-37 (merge part) is Decided-amended and D4-08 and Q-23 are brief items (carry-forward alignment), matching RI.

13. Amendments to existing package documents

• domain-model.md → header note: replace "duplicate merge is an alias, never a re-key" with consolidation. §2 Identification context: replace StudyAlias with Study state, StudyVersion, StudyMerge, StudyUnmerge, MergeConflictTask. §4.7: replace the StudyAlias and mergedInto row with rows for the entities in §3; keep DuplicateReviewItem with the outcomes in §3.9. §6.2: replace StudyMerged, StudySplit with StudyMerged, StudyUnmerged. §6.3: replace MergeStudies, SplitStudies with PrepareStudyMerge, ResolveMergeConflict, DelegateMergeConflict, CommitStudyMerge, PrepareStudyUnmerge, CommitStudyUnmerge, SetStudyField; typed refusals gain InputsChanged, ActiveWorkChanged, StudyConsolidated. §7.1: remove AliasResolutionPolicy; ContributionQualificationPolicy counts once across merge lineage. §7.2: remove StudyAliasEntry. §8: replace "Primary and secondary study" with "consolidated Study and input Studies". §9 invariant "Merge or split never re-keys" becomes "Merge and unmerge never edit an input's records". §10: add pmStudyVersion, pmStudyMerge, pmStudyMergeItem, pmStudyUnmerge, pmMergeConflictTask. §12 P2 row and §14 diagram updated.
• consistency-model.md → §3.4: the floor step before P2 adds the tombstone predicate. §4.2 "Merge and split" row: replace with staging plus activation per §4.5 and §4.10. §7.8: replace with this specification's protocol (warn, recheck, activate; no refusal of busy Studies). §15: replace the merge row with "an activation and any command on an input conflict on the input's Study document". §19.3: D2-12 replaced.
• contracts.md → C1 "Merge and split" row: replace with a pointer to C21. C9 drift trigger "a dedup alias": replace with "a duplicate consolidation or reversal".
• prisma-amendments.md → summary row L: "merge as an alias" becomes "one consolidated current Study, reversible unmerge". D: "Moving Citations needs an identity and lineage manifest plus dedup reversal" becomes "References never move; the consolidated Study links them; the manifest records lineage". L.4: rewrite to this specification. L.5: restate scenarios 2 to 4 as consolidation with conflict resolution; scenario 4's Publication-only link becomes the "distinct report" outcome. L.10: reversal is an unmerge. The FEAT-012 change-policy documentation PR carries these into the Approved specification (§7, §9, §11.2, §12).
• acceptance-criteria.md → rewrite AC-P2-04 and AC-P2-05; amend AC-P2-12; rewrite FX-PRISMA-07a ("originals kept as history; one consolidated Study; conflicts resolved before commit; one contribution counted; no automatic target double count or result promotion"); add DM-AE rows marked New.
• integrated-plan.md → §5.8 P2: replace "Merge is an alias … split is a clean reversal (D2-12; E33)" with consolidation and unmerge; add the P2a, P2b and P2c split.
• open-questions-and-assumptions.md → D2-12: Replaced. E33: rewrite as the consolidation and unmerge operations with the current evidence view proof.
• versioning-model.md → §9.3: "a dedup merge or split aliases the study" becomes "a duplicate consolidation or reversal".
• decision-register.md → D2-12 replaced; superseded rows per §14.
• ux-strategy.md → U41: the merge wizard covers preview, conflict tasks, delegation, commit and unmerge with carry-forward choices.

14. Superseded wording

Old wording	New wording	Where it appears today
A merge is an alias: two active Studies linked by mergedInto and StudyAlias	One consolidated current Study; originals are tombstoned history; atomic merge; reversible unmerge	domain-model §4.7, §6.2, §6.3, §7.1, §7.2, §9, §14; contracts C1; consistency-model §4.2, §7.8, §15, §19.3; prisma-amendments summary, L.4; integrated-plan §5.8; AC-P2-04, AC-P2-05; open questions D2-12, E33
"The admin's identity mapping is an alias"	Conflicts resolved before commit into one consolidated Study	FX-PRISMA-07a
Split removes the alias and re-derives	An unmerge tombstones the consolidated Study, restores the originals and records per-item carry-forward choices	domain-model §4.7, §6.2, §6.3; consistency-model §7.8; integrated-plan §5.8
Merges refuse busy Studies (claims, drafts, open tasks)	Warn about active work before confirmation, recheck at commit, keep drafts, refuse stale saves	domain-model §4.7, §6.3; consistency-model §4.2, §7.8
Moving Citations needs an identity and lineage manifest	References never move; the consolidated Study links them	prisma-amendments D
Primary and secondary Study (dedup)	Consolidated Study and input Studies	domain-model §8; prisma-amendments L
The current session is chosen (default the later Complete) and the other superseded	The merging user or the original reviewer resolves the two submissions in a reconciliation-like view; the actual resolver is recorded	prisma-amendments L.4; AC-P2-05
Scenario 4: link via a shared Publication without merging review data (different stages)	Sessions belong to forms; a real duplicate is consolidated; related reports take the "distinct report" outcome	FEAT-012 §7.1, §9.2; prisma-amendments L.5
A dedup alias drifts a reconciliation task	A duplicate consolidation or reversal drifts it	contracts C9; versioning-model §9.3