OOF™ Origin Open Foundation™

Independent Methodological Authority

Architecture Ecosystem: Structured Reality Standards™
Architecture Family: TREGA™ — Tax-Relevant Event Governance Architecture™
Parent Standard: TRERLS — Tax-Relevant Event Relationship Standard
Module: ERLMM — Event Relationship Merge & Split Module
Operational Layer: Event Relationship Merge & Split Governance Layer
Category: Governance & Enforcement
Subcategory: Tax-Relevant Event Governance
Type: Core Module
Governed Space: Event Relationship Merge & Split Governance
Origin ID: TREGA-TRERLS-ERLMM-005
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 1 September 2026
AI-Readable: Yes
Authority: OOF®
Protection: MIP® — Methodological Intellectual Property
Canonical Language: UCL — Universal Canonical Language

Canonical Definition

The Event Relationship Merge & Split Module (ERLMM) governs how
already-related Tax-Relevant Events are evaluated for justified
consolidation into one governed Event representation or
separation into multiple governed Event representations when
accumulated relationship governance reveals that the existing
Event structure no longer faithfully represents operational
reality.

ERLMM governs the conditions, justification, decision path,
historical preservation, and downstream relationship consequences
of Event Merge and Event Split.

Its principal transition is:

Governed Event Group Structure

↓

Merge & Split Governance

↓

Governed Event Relationship Structure

ERLMM does not create Event Formation or Event Boundary authority
independently.

Where a Merge or Split changes what the event itself is, ERLMM
coordinates the relationship-level restructuring with the
authoritative upstream governance of TREFS — Tax-Relevant Event
Formation Standard and TREBS — Tax-Relevant Event Boundary
Standard.

The foundational distinction is:

Relationship Convenience ≠ Permission to Merge or Split Events.

Operational Role

Event structures may initially appear correct and later prove
incomplete, fragmented, duplicated, over-aggregated, or
incorrectly bounded.

Several records may have been treated as separate events even
though subsequent governance establishes that they represent one
materially coherent event.

Conversely, one governed event may later prove to contain several
independently meaningful events.

ERLMM provides a controlled mechanism for addressing those
situations.

Its role is not to optimize the Event structure for: tax outcome;
reporting convenience; database architecture; billing
convenience; system migration; reconciliation convenience; or
computational simplicity.

Its role is to preserve the most faithful governed representation
of operational reality.

Internal Module Flow

TRERLS operates through:

ERLIM — Event Relationship Identification

↓

ERLDM — Event
Relationship Dependency

↓

ERLSM — Event Relationship Sequence

↓

ERLGM — Event Relationship Grouping

↓

ERLMM — Event Relationship
Merge & Split

↓

Governed Event Relationship Structure

ERLMM is the final Core Module within TRERLS.

It receives the Governed Event Group Structure and produces the
final Governed Event Relationship Structure for handoff to TREDS.

Operational Transition

The canonical transition is:

Governed Event Group Structure + Formation Evidence + Boundary
Evidence + Relationship History

↓

Merge & Split Governance

↓

Governed Event Relationship Structure

ERLMM may determine that: no structural change is required; Merge
review is required; Split review is required; a Merge is
justified; a Split is justified; the issue must be referred
upstream; or the structure remains unresolved.

Operational Space

ERLMM governs: Merge candidate identification; Split candidate
identification; Merge qualification; Split qualification; Merge
justification; Split justification; Merge decision; Split
decision; Event preservation during Merge; Event preservation
during Split; source-event mapping; resulting-event mapping;
historical relationship preservation; Merge lineage; Split
lineage; partial Merge; partial Split; duplicate-event
consolidation; artificial-fragmentation correction;
artificial-aggregation correction; relationship reassignment;
group restructuring; Event Chain restructuring; Event Network
restructuring; Merge uncertainty; Split uncertainty; Merge
conflict; Split conflict; reconsideration; supersession; and
Merge/Split-specific traceability.

Operational Scope

ERLMM may operate across: enterprise transactions; commerce;
payments; banking; accounting; marketplaces; logistics; supply
chains; ERP environments; digital platforms; distributed systems;
blockchain infrastructures; digital assets; AI agents; autonomous
machines; industrial systems; energy systems; cross-border
operations; and future machine economies.

Merge Candidate

A Merge Candidate exists where two or more governed Event
representations may in fact represent one materially coherent
Tax-Relevant Event.

A candidate does not authorize Merge.

Merge Candidate ≠ Governed Event Merge.

The candidate shall be evaluated against Formation, Boundary,
Relationship, and historical information.

Split Candidate

A Split Candidate exists where one governed Event representation
may contain two or more materially independent events.

A candidate does not authorize Split.

Split Candidate ≠ Governed Event Split.

Merge Purpose

Event Merge exists to correct structural over-fragmentation where
several Event representations incorrectly represent what
governance establishes as one event.

Merge is therefore corrective, not convenient.

Merge ≠ Aggregation for Convenience.

Split Purpose

Event Split exists to correct structural over-aggregation where
one Event representation incorrectly contains several
independently meaningful events.

Split is therefore corrective, not a mechanism for generating
preferred downstream results.

Split ≠ Fragmentation for Convenience.

Merge Preconditions

A Merge shall require sufficient governed basis indicating that
separate Event representations should not remain independently
constituted.

Relevant considerations may include: common Event Formation;
overlapping or identical Event Boundary; inseparable operational
substance; duplicated Event representation; duplicate technical
capture; relationship evidence indicating one underlying
occurrence; shared participant structure where materially
relevant; integrated Value Association; and consistent historical
reconstruction.

No single indicator establishes Merge automatically.

Split Preconditions

A Split shall require sufficient governed basis indicating that
one Event representation contains materially distinct Event
structures.

Relevant considerations may include: independently formed
occurrences; separable Event Boundaries; independent
participants; independent Value Associations; materially distinct
timing; materially distinct location; independent operational
purpose; independent dependency or sequence paths; or materially
independent downstream relationships.

Again:

Additional Detail ≠ Split Requirement by default.

Duplicate Event Consolidation

Two records may represent the same governed event because of:
duplicate ingestion; system synchronization; mirrored
infrastructure; replicated ledger entries; platform duplication;
or migration artifacts.

ERLMM may govern consolidation of duplicate Event
representations.

Duplicate Record ≠ Additional Event.

Artificial Fragmentation

Artificial fragmentation occurs when one materially coherent
event is represented as multiple events without sufficient Event
Formation or Boundary justification.

Examples may arise from: technical process steps; API calls;
accounting line items; blockchain operations; machine
instructions; internal workflow stages.

ERLMM shall prevent technical structure from becoming Event
structure by default.

Technical Fragmentation ≠ Economic Event Fragmentation.

Artificial Aggregation

Artificial aggregation occurs when several independently
meaningful events are represented as one event merely because
they share: one contract; one invoice; one payment; one
participant; one platform; one settlement; one technical
workflow; or one reporting record.

ERLMM shall prevent convenience-based Event collapse.

Shared Record ≠ Permission to Merge.

Merge Basis

A valid Merge basis shall arise from governed Event reality.

It shall not arise solely from: desired tax treatment; desired
accounting treatment; lower reporting complexity; database
design; reconciliation preference; system limitations.

Desired Outcome ≠ Merge Basis.

Split Basis

A valid Split basis shall likewise arise from governed Event
reality.

It shall not be created solely because separating the event
produces: preferred tax rates; different jurisdictional
treatment; different taxable periods; exemptions; reduced tax
exposure; reporting convenience.

Desired Outcome ≠ Split Basis.

Tax Advantage and Merge

ERLMM shall explicitly reject tax advantage as an Event Merge
criterion.

Tax Advantage ≠ Event Merge Criterion.

Whether tax law later aggregates events is a separate downstream
legal question.

Tax Exposure and Split

Likewise:

Tax Exposure ≠ Event Split Criterion.

Event structure shall not be redesigned merely because different
representation changes potential tax liability.

Merge and Event Formation

A Merge may reveal that multiple Event records resulted from one
underlying Event Formation.

TREFS remains authoritative for Event Formation.

ERLMM shall not silently override TREFS.

Where Formation must be reconsidered, the issue shall be referred
upstream.

Event Merge ≠ Independent Formation Authority.

Split and Event Formation

A Split may reveal that one original representation contained
several independently formed events.

Where this changes Event Formation, TREFS authority applies.

Event Split ≠ Independent Formation Authority.

Merge and Event Boundary

Merge may require reconsideration of individual Event Boundaries.

TREBS remains authoritative.

ERLMM governs the relationship-level restructuring resulting from
that determination.

Event Merge ≠ Independent Boundary Authority.

Split and Event Boundary

A Split may require creation of distinct governed Event
Boundaries.

TREBS remains authoritative for those boundaries.

Event Split ≠ Independent Boundary Authority.

Merge Direction

A Merge may combine:

Event A + Event B

↓

Event AB

or:

Event A + Event B + Event C

↓

Event ABC

The resulting representation must preserve traceability to all
contributing Event representations.

Split Direction

A Split may produce:

Event A

↓

Event A1 + Event A2

or a broader structure where several new Event representations
emerge from one previously over-aggregated record.

Each resulting event shall remain traceable to the pre-Split
representation.

Many-to-One Merge

Several Event representations may merge into one governed Event
representation.

Many-to-One Representation ≠ Automatic Merge Justification.

The Merge requires substantive governance basis.

One-to-Many Split

One Event representation may split into several governed events.

One-to-Many Representation ≠ Automatic Split Justification.

Partial Merge

Only part of an Event structure may require consolidation.

Where supported, ERLMM may govern a partial Merge without
collapsing unrelated Event structure.

Partial Relationship Overlap ≠ Full Merge by default.

Partial Split

Only one portion of an event may prove independently constituted.

A partial Split may be required while the remaining event
continues.

Partial Independence ≠ Full Event Split by default.

Merge and Event Identity

A governed Merge changes how Event Identity is represented.

The original source records shall not disappear from history.

They become traceably associated with the resulting governed
event.

Event Merge ≠ Historical Erasure.

Split and Event Identity

A governed Split creates or recognizes multiple independently
governed Event representations.

The prior representation shall remain part of the historical
lineage.

Event Split ≠ Historical Erasure.

Source Event Preservation

All events participating in Merge or Split governance shall
remain historically referenceable.

Historical records may be marked as: merged; superseded; split;
replaced; reconstituted; or otherwise structurally transformed.

They shall not simply disappear.

Resulting Event Preservation

Each resulting Event representation shall receive sufficient
identity and traceability to support future governance.

The resulting structure shall clearly indicate its relationship
to predecessor representations.

Merge Lineage

Merge lineage shall preserve:

Source Event(s)

↓

Merge Decision

↓

Resulting Event

The basis, decision, authority, and transformation history shall
remain reconstructable.

Split Lineage

Split lineage shall preserve:

Source Event

↓

Split Decision

↓

Resulting Event(s) Relationship
Reassignment

Merge or Split may require existing relationships to be
reassigned.

For example: dependencies; sequences; group memberships;
settlement links; reversal links; Value Associations.

Reassignment shall be explicit.

Structural Change ≠ Permission to Lose Relationship History.

Dependency After Merge

Where events merge, prior dependency relationships may become
internal to the resulting event or may cease to represent
relationships between independent events.

ERLMM shall preserve the historical distinction.

ERLDM remains authoritative for dependency itself.

Dependency After Split

A Split may reveal new dependencies among the resulting events.

Those dependencies may require renewed ERLDM governance.

Split Result ≠ Automatically Governed Dependency.

Sequence After Merge

Merge may alter how prior Event Sequences are represented.

Historic sequence shall remain reconstructable even where several
earlier event records become one Event representation.

Sequence After Split

Split may create multiple events requiring distinct sequence
relationships.

Those relationships shall be governed through ERLSM where
necessary.

Grouping After Merge

A merged Event representation may replace several group members.

Group membership shall be updated without losing prior history.

Grouping After Split

A Split may create several new group members or may distribute
resulting events across different Event Groups.

ERLGM authority remains applicable.

Event Chain Restructuring

Merge or Split may alter an Event Chain.

For example:

A

↓

B

↓

C

may become:

AB

↓

C

or:

A

↓

B1

↓

B2

↓

C

ERLMM shall preserve structural lineage.

Event Network Restructuring

Complex Event Networks may require relationship-edge reassignment
after Merge or Split.

No relationship should disappear merely because Event
representation changes.

Reversal and Merge

A reversal event shall not normally be merged into the original
event merely because it reverses it.

Reversal Relationship ≠ Merge Requirement.

The events may remain separately governed and related.

Refund and Merge

A refund may remain a separate event related to an earlier
purchase or payment.

Refund Relationship ≠ Merge Requirement.

Correction and Merge

A correction record may or may not constitute an independent
event.

ERLMM shall not assume Merge or independence solely from the
label “correction.” Replacement and Merge

A replacement event may remain separate from the original event
while preserving a replacement relationship.

Replacement Relationship ≠ Merge Requirement.

Continuation and Split

A long-running event shall not be split merely because it
contains several operational phases.

Operational Phases ≠ Multiple Events by default.

TRECLS remains authoritative for lifecycle continuity.

System Migration

Migration from one platform to another may create duplicate Event
representations.

This may justify duplicate consolidation.

However:

System Migration ≠ New Event Formation.

and:

System Migration ≠ Event Split.

Database Consolidation

Combining database records does not establish Event Merge.

Database Consolidation ≠ Event Merge.

Likewise, separating a database record does not establish Event
Split.

Database Separation ≠ Event Split.

Accounting Structure

Accounting systems may aggregate or separate activity according
to ledger requirements.

Those structures do not automatically define TREGA™ Event
structure.

Accounting Aggregation ≠ Event Merge.

Accounting Disaggregation ≠ Event Split.

Invoice Structure

Several events may appear on one invoice.

One event may span several invoice lines or documents.

Therefore:

Invoice Consolidation ≠ Event Merge.

Invoice Separation ≠ Event Split.

Payment Structure

One payment may settle multiple events, and several payments may
relate to one event.

Therefore:

Payment Aggregation ≠ Event Merge.

Multiple Payments ≠ Event Split.

Blockchain Merge & Split

Blockchain infrastructure may represent one economic activity
through several technical transactions or combine many operations
inside one transaction.

ERLMM shall not derive Merge or Split mechanically from ledger
structure.

Multiple Blockchain Transactions ≠ Event Split Requirement.

Single Blockchain Transaction ≠ Event Merge Requirement.

Smart-Contract Structure

One smart contract may execute several independent events.

Several contracts may participate in one event.

Therefore:

Smart-Contract Boundary ≠ Event Boundary.

AI-Agent Workflow

An AI agent may generate hundreds of technical actions in
executing one governed event or several independent events within
one workflow.

ERLMM shall rely on Event governance rather than agent workflow
structure.

One Agent Workflow ≠ One Event by default.

Machine Operations

Machine systems may generate high-frequency technical actions.

Those operations shall not be split into independent Tax-Relevant
Events without appropriate Formation and Boundary governance.

Machine Operation Count ≠ Event Count.

Cross-System Merge

Records from several systems may represent the same event.

ERLMM may govern consolidation where Event Formation and Boundary
support one Event Identity.

Different Systems ≠ Different Events by default.

Cross-Organization Merge

Different organizations may hold records referring to the same
governed event.

Their separate records do not automatically mean separate events.

However, separate organizational participation also does not
automatically justify Merge.

Cross-Border Merge & Split

An event may cross national borders.

Geographic distribution does not by itself justify Event Split.

Likewise, shared jurisdiction does not justify Event Merge.

Multiple Countries ≠ Multiple Events by default.

One Country ≠ One Event by default.

Multi-Jurisdiction Neutrality

ERLMM shall preserve a jurisdiction-neutral Event structure.

Different tax systems may later aggregate or separate the events
differently for legal purposes.

The TREGA™ representation shall remain stable unless Event
reality itself changes.

Jurisdictional Tax Treatment ≠ TREGA™ Merge/Split Authority.

Merge Uncertainty

Available information may suggest Merge without providing
sufficient basis.

ERLMM shall preserve that uncertainty.

Merge Uncertainty ≠ Permission to Merge.

Split Uncertainty

Likewise:

Split Uncertainty ≠ Permission to Split.

Merge Conflict

Different systems or governance sources may disagree on whether
events constitute one event.

ERLMM shall preserve the conflict.

Merge Conflict ≠ Permission for Convenient Consolidation.

Split Conflict

Conflicting evidence regarding Event independence shall remain
explicit.

Split Conflict ≠ Permission for Convenient Fragmentation.

Merge Reconsideration

A prior Merge may later be reconsidered if materially relevant
information changes.

Historical Merge state shall remain reconstructable.

Split Reconsideration

A prior Split may likewise be reconsidered.

Reconsideration shall not erase previous
governance states. Supersession

A new Event representation resulting from Merge or Split may
supersede prior Event representations for current governance
purposes.

However:

Supersession ≠ Historical Deletion.

Governance States

ERLMM may represent:

Merge & Split Governance Ready

Merge & Split Under Governance

No Structural Change Required

Merge Candidate

Split Candidate

Merge Qualification Required

Split Qualification Required

Merge Qualified

Split Qualified

Merge Rejected

Split Rejected

Merge Referred Upstream

Split Referred Upstream

Merge Approved

Split Approved

Partial Merge

Partial Split

Duplicate Event Consolidation

Artificial Fragmentation Corrected

Artificial Aggregation Corrected

Merge Ambiguous

Split Ambiguous

Merge Conflicted

Split Conflicted

Merge Under Reconsideration

Split Under Reconsideration

Relationship Structure Reconstituted

Governed Event Relationship Structure
Established Governance Requirements

ERLMM implementations shall ensure that: Merge and Split operate
only on governed Event structures; Merge Candidate remains
distinct from Merge Decision; Split Candidate remains distinct
from Split Decision; Event Merge is supported by substantive
Event governance; Event Split is supported by substantive Event
governance; technical fragmentation does not automatically create
Split; technical aggregation does not automatically create Merge;
duplicate records can be distinguished from separate events;
desired tax outcome does not govern Merge or Split; tax advantage
is not a Merge criterion; tax exposure is not a Split criterion;
Event Formation authority remains under TREFS; Event Boundary
authority remains under TREBS; source Event representations
remain historically traceable; resulting Event representations
remain traceable to source events; Merge lineage can be
reconstructed; Split lineage can be reconstructed; dependency
relationships can be reassigned where necessary; sequence
relationships can be reassigned where necessary; group
memberships can be updated where necessary; Event Chains can be
restructured without losing history; Event Networks can be
restructured without losing history; ambiguity remains visible;
conflict remains visible; reconsideration remains traceable;
supersession does not erase historical states; system migration
does not redefine Event structure automatically; accounting,
invoicing, payment, blockchain, AI-agent, and machine-system
structures do not independently determine Merge or Split; and
jurisdiction-specific tax aggregation remains downstream.

Governance Logic

IF several governed Event representations appear to represent one
materially coherent event, THEN ERLMM shall establish a Merge
Candidate rather than automatically merging them.

IF one governed Event representation appears to contain several
materially independent events, THEN ERLMM shall establish a Split
Candidate rather than automatically splitting it.

IF Merge would alter Event Formation or Event Boundary, THEN the
relevant matter shall be coordinated with TREFS and TREBS before
final structural change.

IF Split would alter Event Formation or Event Boundary, THEN the
relevant matter shall be coordinated with TREFS and TREBS before
final structural change.

IF records are merely technical duplicates of one governed event,
THEN duplicate consolidation may be performed while preserving
source lineage.

IF several technical operations belong to one materially coherent
event, THEN technical fragmentation alone shall not justify
multiple Event Identities.

IF several independently meaningful events share one invoice,
payment, contract, workflow, or settlement, THEN that shared
structure alone shall not justify Event Merge.

IF tax advantage is the only material basis for Merge, THEN Merge
shall be rejected.

IF tax exposure is the only material basis for Split, THEN Split
shall be rejected.

IF Merge or Split remains ambiguous or conflicted, THEN the
corresponding governance state shall remain visible.

IF Merge or Split is approved, THEN source Event representations,
resulting Event representations, relationship reassignment, and
historical lineage shall remain reconstructable.

IF the final relationship structure is sufficiently governed,
THEN ERLMM shall produce the Governed Event Relationship
Structure for TREDS.

Minimum Implementation Framework

A minimum ERLMM implementation should support:

Event Group Structure Reference The ERLGM output entering Merge &
Split governance.

Structural Review Identifier A stable identifier for the
Merge/Split governance process.

Review Type Merge, Split, Duplicate Consolidation, or No
Structural Change.

Candidate Event References The governed events under structural
review.

Merge Candidate State Whether Merge is under consideration.

Split Candidate State Whether Split is under consideration.

Formation Reference Relevant TREFS governance supporting or
constraining structural change.

Boundary Reference Relevant TREBS governance supporting or
constraining structural change.

Relationship Basis The TRERLS relationship information supporting
structural review.

Merge Basis The governed substantive basis for Merge where
applicable.

Split Basis The governed substantive basis for Split where
applicable.

Duplicate State Whether candidate records represent duplicated
Event capture.

Fragmentation State Whether artificial Event fragmentation has
been identified.

Aggregation State Whether artificial Event aggregation has been
identified.

Source Event References All Event representations preceding
structural change.

Resulting Event References All Event representations resulting
from approved Merge or Split.

Transformation Direction Many-to-one, one-to-many, partial Merge,
partial Split, or other governed transformation.

Relationship Reassignment Record How dependencies and other Event
Relationships are reassigned.

Sequence Reassignment Record How Event Sequence is affected.

Grouping Reassignment Record How group membership is affected.

Value Association Reference Any material TRVAS reference affected
by the structural change.

Historical Lineage Record The complete relationship between
source and resulting Event representations.

Merge/Split Justification Record The governed rationale for the
decision.

Decision State Approved, Rejected, Referred Upstream, Ambiguous,
Conflicted, or Unresolved.

Uncertainty State Any remaining structural uncertainty.

Conflict State Any materially conflicting governance information.

Reconsideration Reference Where a prior Merge or Split decision
has been reopened.

Supersession Reference Where a resulting Event representation
supersedes an earlier representation.

Traceability Reference Information required to reconstruct the
full Merge/Split decision.

Governance State The current ERLMM state.

Handoff State Whether the Governed Event Relationship Structure
is ready for TREDS.

Governance Outputs

ERLMM may produce: No Structural Change Determination; Merge
Candidate Record; Split Candidate Record; Merge Qualification
Record; Split Qualification Record; Merge Decision; Split
Decision; Duplicate Event Consolidation Record; Artificial
Fragmentation Correction; Artificial Aggregation Correction;
Partial Merge Record; Partial Split Record; Source Event Mapping;
Resulting Event Mapping; Merge Lineage Record; Split Lineage
Record; Relationship Reassignment Record; Sequence Reassignment
Record; Group Reassignment Record; Merge Uncertainty State; Split
Uncertainty State; Merge Conflict State; Split Conflict State;
Merge Reconsideration Record; Split Reconsideration Record;
Supersession Record; Merge/Split Traceability Record; and the
principal output: Governed Event Relationship Structure.

Critical Distinctions

Relationship Convenience ≠ Permission to Merge or Split Events.

Merge Candidate ≠ Governed Event Merge.

Split Candidate ≠ Governed Event Split.

Merge ≠ Aggregation for Convenience.

Split ≠ Fragmentation for Convenience.

Additional Detail ≠ Split Requirement by default.

Duplicate Record ≠ Additional Event.

Technical Fragmentation ≠ Economic Event Fragmentation.

Shared Record ≠ Permission to Merge.

Desired Outcome ≠ Merge Basis.

Desired Outcome ≠ Split Basis.

Tax Advantage ≠ Event Merge Criterion.

Tax Exposure ≠ Event Split Criterion.

Event Merge ≠ Independent Formation Authority.

Event Split ≠ Independent Formation Authority.

Event Merge ≠ Independent Boundary Authority.

Event Split ≠ Independent Boundary Authority.

Many-to-One Representation ≠ Automatic Merge Justification.

One-to-Many Representation ≠ Automatic Split Justification.

Partial Relationship Overlap ≠ Full Merge by default.

Partial Independence ≠ Full Event Split by default.

Event Merge ≠ Historical Erasure.

Event Split ≠ Historical Erasure.

Structural Change ≠ Permission to Lose Relationship History.

Split Result ≠ Automatically Governed Dependency.

Reversal Relationship ≠ Merge Requirement.

Refund Relationship ≠ Merge Requirement.

Replacement Relationship ≠ Merge Requirement.

Operational Phases ≠ Multiple Events by default.

System Migration ≠ New Event Formation.

Database Consolidation ≠ Event Merge.

Database Separation ≠ Event Split.

Accounting Aggregation ≠ Event Merge.

Accounting Disaggregation ≠ Event Split.

Invoice Consolidation ≠ Event Merge.

Invoice Separation ≠ Event Split.

Payment Aggregation ≠ Event Merge.

Multiple Payments ≠ Event Split.

Multiple Blockchain Transactions ≠ Event Split Requirement.

Single Blockchain Transaction ≠ Event Merge Requirement.

Smart-Contract Boundary ≠ Event Boundary.

One Agent Workflow ≠ One Event by default.

Machine Operation Count ≠ Event Count.

Different Systems ≠ Different Events by default.

Multiple Countries ≠ Multiple Events by default.

Jurisdictional Tax Treatment ≠ TREGA™ Merge/Split Authority.

Merge Uncertainty ≠ Permission to Merge.

Split Uncertainty ≠ Permission to Split.

Merge Conflict ≠ Permission for Convenient Consolidation.

Split Conflict ≠ Permission for Convenient Fragmentation.

Supersession ≠ Historical Deletion.

Enterprise Application

ERLMM provides the final structural-control layer of TRERLS.

A typical enterprise path is:

ERLIM — Governed Event Relationship
Candidate Set

→ ERLDM — Governed Event Dependency Structure

→ ERLSM — Governed Event Sequence Structure

→ ERLGM — Governed Event Group Structure

→ ERLMM — Merge & Split Governance

→ Governed Event Relationship Structure

→ TREDS — Tax-Relevant Event Determination

This allows enterprises and digital infrastructures to correct
duplicated, fragmented, or over-aggregated Event representations
while preserving operational reality, historical lineage, and
jurisdiction neutrality. Use Case 1 — ERP, Payment, and
Marketplace Duplicate Event Reconciliation

A marketplace, merchant ERP, and payment infrastructure each
create separate records for the same purchase activity.

Initial integration produces three apparent Tax-Relevant Events.

Relationship governance later establishes that two of those
records are duplicate representations of one underlying governed
event, while the payment event remains independently constituted
and related.

ERLMM evaluates the Merge Candidate, coordinates the relevant
Event Formation and Boundary references, consolidates the
duplicate Event representations, preserves all source-record
lineage, and retains the independent payment Event Relationship.

The resulting structure corrects technical duplication without
collapsing materially distinct activity. Use Case 2 — Autonomous
Workflow Incorrectly Aggregated as One Event

An autonomous industrial platform records an entire multi-stage
service workflow as one event.

Subsequent governance establishes that resource allocation,
machine service delivery, and later digital settlement possess
independent Formation, Boundaries, participants, and Value
Associations.

ERLMM establishes a Split Candidate and coordinates the required
Formation and Boundary governance.

The original over-aggregated Event representation is preserved
historically while three independently governed Event
representations are established and linked through dependency,
sequence, and grouping relationships.

The Split is justified by operational reality rather than tax
treatment.

Canonical Boundary

ERLMM owns relationship-level governance of Merge Candidates,
Split Candidates, duplicate consolidation,
artificial-fragmentation correction, artificial-aggregation
correction, Merge/Split qualification, decision structure,
source-to-result mapping, relationship reassignment, lineage,
uncertainty, conflict, reconsideration, supersession, and
Merge/Split-specific traceability.

ERLMM does not independently create Event Formation authority,
redefine Event Boundaries without TREBS governance, determine
Event Timing, Event Location, Event Participation, underlying
Value governance, taxpayer status, tax aggregation, tax
jurisdiction, Tax Base, Tax Liability, or another
jurisdiction-specific legal consequence.

Where Merge or Split changes Event Formation or Event Boundary,
TREFS and TREBS remain authoritative.

ERLMM governance ends when the final relationship structure among
the relevant governed events is sufficiently represented for
downstream Tax-Relevant Event Determination under TREDS.

Canonical Handoff

ERLGM — Governed Event Group Structure

↓

ERLMM — Governed Event
Relationship Structure

↓

TREDS — Tax-Relevant Event Determination

Canonical Closing Statement

ERLMM corrects the structure of related events when governance
establishes that reality has been fragmented or aggregated
incorrectly, while preserving every material step in the history
of that correction.

Events should be merged or split because the governed reality
requires it — never because a technical system, reporting
structure, or preferred tax outcome makes another representation
more convenient.

Event Merge ≠ Historical Erasure.

Event Split ≠ Historical Erasure.

Tax Advantage ≠ Event Merge Criterion.

Tax Exposure ≠ Event Split Criterion.