Split/Merge Change Log¶
Split/merge ledger — instantiates Identity-Bounded Change
Records when an entity splits into several or several merge into one, marking the resulting branches and preserving parent-to-child lineage so identity survives cardinality changes.
Most change keeps identity one-to-one: a thing becomes a later version of itself. But sometimes one entity becomes several, or several collapse into one — a record splits, two duplicates merge, a division spins off, two datasets are reconciled — and there the question "is it still the same?" has no single answer, because the count itself changed. Split/Merge Change Log is the mechanism for exactly those events: it records each split and merge, marks the resulting branches, and preserves the many-to-one and one-to-many lineage between predecessors and successors. Its defining move is to represent cardinality changes that a linear version history structurally cannot — refusing to flatten a one-becomes-two or two-become-one event into an ordinary edit — so that references, obligations, and history can be routed to the correct successor rather than silently dropped or duplicated.
Example¶
A company's customer master data holds two records — "Acme Corp" and "Acme Corporation" — that turn out to be the same customer, so they are merged into one golden record. Separately, a single record that had conflated a parent company with its newly-independent subsidiary must be split into two distinct customers.
The log captures both events with their multiplicity. For the merge, it records the two source records, which one survived, and which field values won; for the split, it records the one predecessor and the two successors, and which orders, contracts, and contacts were apportioned to each. A year later the payoff shows: an invoice that still cites the retired "Acme Corporation" record resolves forward through the merge lineage to the surviving golden record, while a support ticket filed against the old conflated record routes to the correct subsidiary through the split lineage. Without the log, the merged-away record's history would simply vanish, and the split's obligations would attach to whichever entity happened to keep the original key.
How it works¶
- Record events with multiplicity intact. Each entry names all predecessors and all successors of a split or merge — never a single before and single after.
- Mark the resulting branches. Every successor is given a distinct marker so it is separately identifiable rather than collapsed under the old key.
- Preserve lineage both directions. Predecessor-to-successor links let references to a retired entity resolve forward to the right successor(s), and successor-to-predecessor links keep the inherited history reachable.
- Record survivorship. The log notes which attributes and obligations flowed to which successor, so nothing is silently overwritten or orphaned.
Tuning parameters¶
- Merge survivorship rule — which source's values win when records merge — most recent, most complete, or most trusted source. This choice determines what the surviving record actually contains.
- Lineage direction — predecessor-to-successor only, or bidirectional. Bidirectional lineage lets old references resolve forward and keeps inherited history reachable, at extra storage and maintenance cost.
- Reversibility window — whether a merge or split can be undone, and for how long. Reversibility guards against wrong merges but complicates the log and the routing.
- Obligation-routing policy — how contracts, citations, and permissions are apportioned to successors on a split. Explicit routing prevents duties from being orphaned or duplicated.
- Event granularity — logging every micro-reconciliation versus batching periodic clean-ups, trading fine traceability against a legible history.
When it helps, and when it misleads¶
Its strength is that it is the only mechanism in the set that handles one-to-many and many-to-one change without corrupting lineage — keeping references and obligations correctly routed across reconciliations, spin-offs, and de-duplications that a version number cannot express.
Its dangers are asymmetric. A false merge that fuses two genuinely distinct entities is far easier to commit than to unwind, and if survivorship silently discarded one side's values, the loss can be practically irreversible;[n1] an over-eager split does the opposite, fragmenting one entity into apparent duplicates. The archetype's own rule names the classic misuse directly: a split or merge cannot be recorded as an ordinary one-to-one modification — doing so collapses the multiplicity and destroys the lineage the log exists to keep. The discipline is to model every cardinality change as exactly that, preserving predecessor and successor multiplicity, and to keep high-stakes merges reversible rather than trusting the survivorship rule to have been right.
How it implements the components¶
change_log— logs each split and merge event, recording which predecessors produced which successors and what was apportioned to each.branch_or_variant_marker— marks the resulting branches after a split, and the surviving line after a merge, so every successor is distinctly identifiable.provenance_record— preserves the many-to-one and one-to-many lineage so a reference to a retired predecessor resolves to the correct successor(s), and inherited history stays reachable.
It does NOT adjudicate or authorize whether an event is a fork, split, merge, or replacement (replacement_or_fork_rule, decision_authority) — that is Replacement or Fork Decision Record; and it does NOT test whether a surviving line remains the same entity (identity_continuity_test) — that belongs to Identity Continuity Review.
Related¶
- Instantiates: Identity-Bounded Change — records the split, merge, and fork relations the archetype requires when identity changes cardinality rather than staying one-to-one.
- Consumes: Replacement or Fork Decision Record supplies the adjudicated decision that a given event is a split, merge, or fork; this log records that outcome and routes references and obligations across it.
- Sibling mechanisms: Version Control System · Legal Amendment Record · Policy Amendment Register · Document Revision History · Persistent Identifier Resolver · Chain-of-Custody Record · Event-Sourced Entity History · Conservation Treatment Record · Identity Continuity Review
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Split/Merge Change Log operates as a persistent ledger, log, register, or case record that preserves history and traceability because it records when an entity splits into several or several merge into one, marking the resulting branches and preserving parent-to-child lineage so identity survives cardinality changes.
Independent corroboration: The frozen evidence defines Split/Merge Change Log as 'Records when an entity splits into several or several merge into one, marking the resulting branches and preserving parent-to-child lineage so identity survives cardinality changes', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Preserving parent-successor identity through split and merge events is authority-control and provenance practice.
Related originating lineages:
- Computer Science & Software Engineering — Version graphs encode branches and merges.
- History & Historiography — Lineage records preserve institutional continuity.
- Law & Governance — Succession affects rights and obligations.
Review resolution: The blind reviewers agree that library_information_science is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Merges and splits are not symmetric in cost. A split leaves its predecessor's data intact and merely apportions it, but a merge can consume data — when the survivorship rule picks one source's value over another's, the discarded value may be gone for good. That asymmetry is why a merge deserves the reversibility window and the confirmation that a split rarely needs, and why a wrong merge is the failure this log should be tuned hardest to prevent.
[n1] In master data management, survivorship rules decide which attribute values persist into the surviving golden record when duplicates are merged. Because a merge discards the values that lose, an incorrect merge can destroy information rather than merely mislabel it — the reason survivorship is treated as a governed decision, not a default. ↩