LRENM — Liability Recourse Network Module
LRENM — Liability Recourse Network Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Transfer & Recourse Standard (LTRS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Recourse Network
Module ID: LIGA-LTRS-LRENM-001
Origin ID: OOF.CM.LIGA.10.04.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 24 September 2026
Compatibility: OOF® Methodology OS™ · Modular OOF® Architecture Ecosystem
AI-Readable: Yes
Authority: OOF® — OriginOpen® Foundation
Protection: MIP® — Methodological Intellectual Property
Canonical Language: English (UCL™)
Canonical Definition
The Liability Recourse Network Module (LRENM) governs how multiple primary, secondary, chained, parallel, dependent, or interacting Recourse Relationships are structured as a Liability Recourse Network while preserving the identity, origin, Subjects, Basis, Scope, State, direction, dependencies, and history of every constituent Relationship.
LRENM begins when one or more Identified Liability Recourse Structures interact with other Liability Relationships in a way that cannot be governed reliably as an isolated Recourse Relationship.
It maps Recourse nodes, Relationships, layers, chains, branches, dependencies, convergence points, conflicts, propagation paths, and network boundaries.
LRENM prevents multiple Recourse Relationships from being collapsed into one generic recovery structure merely because they arise from the same Liability, occurrence, payment, Harm, or economic consequence.
It does not establish primary Liability.
It does not create a Recourse Basis.
It does not determine that every identified Recourse Relationship is valid.
It governs the structure and interaction of Recourse Relationships once sufficient network relevance exists.
It governs the transition:
Identified Liability Recourse Structures → Network Relevance → Recourse Nodes → Recourse Relationships → Recourse Layers → Chains & Branches → Dependencies & Interactions → Network Boundary → Governed
Liability Recourse Network
Its foundational distinction is:
One Primary Liability ≠ One Recourse Relationship ≠ One Liability Recourse Network.
Operational Role
The operational role of LRENM is:
to govern how multiple Recourse Relationships coexist, connect, depend upon one another, form chains or branches, and interact across a Liability Network without losing the independent identity of any constituent Relationship.
The module transforms isolated Recourse structures into an explicit network model where network complexity exists.
Position in the LTRS Internal Flow
The internal LTRS progression is:
Liability Transfer Identification → Liability Sharing → Liability Recourse Identification → Liability Recourse Network → Liability Transfer Continuity LRENM governs:
Liability Recourse Network
Its principal input is:
Identified Liability Recourse Structure
or multiple Identified Liability Recourse Structures.
Its principal output is:
Governed Liability Recourse Network
Its downstream handoff is:
LTFCM — Liability Transfer Continuity Module
for continuity of Transfer, Sharing, Recourse, and secondary Liability structures.
Central Operational Question
How do multiple Recourse Relationships connect, branch, depend upon, interact with, or affect one another across the Liability structure while remaining independently identifiable and traceable to their respective origins?
Network Relevance
Network governance becomes relevant where:
multiple Recourse Relationships exist, one Recourse Relationship generates another, multiple Subjects possess Recovery relationships, one payment creates several Recourse paths, multiple primary Liability Relationships feed secondary relationships, Recourse chains intersect, or dependencies exist between different recovery structures.
Therefore:
Multiple Recourse Records ≠ Recourse Network by default.
Network relevance requires actual structural relationship.
Liability Recourse Network
A Liability Recourse Network is a governed structure containing multiple connected Recourse Relationships and their relevant association with primary or preceding Liability Relationships.
The network is not itself a substitute for its constituent Relationships.
Therefore:
Liability Recourse Network ≠ Single Recourse Relationship.
Network Origin
Every Recourse Network should preserve the Liability origin or origins from which its constituent Relationships developed.
A network may originate from:
one Primary Liability, multiple Primary Liabilities, a Liability Network, a Sharing structure, a Transfer structure, or another governed secondary structure.
Single-Origin Network
A Single-Origin Recourse Network develops from one primary Liability structure.
One origin may generate multiple secondary Relationships.
Therefore:
One Primary Liability ≠ One Secondary Liability Relationship.
Multi-Origin Network
A Recourse Network may contain Relationships arising from multiple primary Liability origins.
Those origins should remain separately identifiable.
Therefore:
Multiple Liability Origins ≠ One Liability Origin by aggregation.
Network Node
A Network Node represents a materially relevant Subject, Liability Relationship, Recourse Relationship, Transfer structure, Sharing structure, or other governed object participating in the Recourse Network.
Subject Node
A Subject may occupy one or several positions within the network.
It may be:
Recourse-Seeking Subject, Recourse-Target Subject, Liability-bearing Subject, Paying Subject, Performing Subject, Insurer, Indemnifier, Successor, Contributor, or another relevant role.
Multi-Role Node
One Subject may occupy different roles in different Relationships.
Therefore:
One Subject ≠ One Network Role.
Role identity should be preserved at Relationship level.
Relationship Node
A Recourse Relationship should remain individually identifiable even when represented inside a larger network.
Its identity should preserve:
Origin, Subjects, Recourse Object, Basis, Scope, State, time, and history.
Network Edge
A Network Edge represents a governed connection between relevant nodes.
It may represent:
Recourse, Transfer, Sharing, dependency, Contribution, Indemnification, Succession, or another explicitly classified relationship.
Edge Classification
Different Relationship types should not be represented as one generic connection.
Therefore:
Network Connection ≠ Recourse Relationship by default.
Recourse Direction
Recourse possesses direction.
A Recourse Relationship should identify:
Recourse-Seeking Subject → Recourse-Target Subject Direction should not be inferred from payment flow alone.
Direction vs Value Flow
The direction of value movement may differ from the direction of Recourse.
Therefore:
Value Flow Direction ≠ Recourse Direction by default.
Network Layer
LRENM may organize Relationships into layers.
Possible layers include:
Primary Liability Layer, Transfer Layer, Sharing Layer, Primary Recourse Layer, Secondary Recourse Layer, Further Recourse Layer, or another explicitly governed layer.
Layer Identity
Each Relationship should remain associated with its applicable layer without losing its individual identity.
Therefore:
Network Layer ≠ Liability Relationship.
Primary Liability Layer
The Primary Liability Layer preserves the Liability Relationships from which secondary Transfer, Sharing, or Recourse structures originate.
LRENM does not modify those primary Relationships.
Primary Recourse Layer
The Primary Recourse Layer contains Recourse Relationships arising directly from primary Liability or its immediate consequences.
Secondary Recourse Layer
A Secondary Recourse Layer may arise when a Recourse Relationship or its performance generates another Recourse relationship.
Further Recourse Layers
Additional Recourse layers may exist where legitimate secondary recovery relationships continue.
LRENM should not impose an artificial maximum number of layers.
Recourse Chain
A Recourse Chain is a sequential structure such as:
Primary Liability → Recourse A → Recourse B → Recourse C Each step should retain independent governance identity.
Chain Integrity
A later Recourse Relationship should remain traceable through its immediate origin toward the relevant primary Liability.
Therefore:
Later Recourse ≠ Independent Liability Origin by default.
Immediate Origin
Every Recourse Relationship should identify its immediate originating structure where relevant.
Ultimate Origin
Where a Recourse Chain exists, LRENM should preserve the ultimate primary Liability origin where it remains relevant.
Therefore:
Immediate Recourse Origin ≠ Ultimate Liability Origin by default.
Recourse Branch
One Liability or Recourse Relationship may generate multiple Recourse Relationships.
Example:
Primary Liability → Recourse A Primary Liability → Recourse B Primary Liability → Recourse C This creates a branch.
Branch Independence
Each branch may possess different:
Subjects, Basis, Scope, State, time, and outcome.
Therefore:
Shared Origin ≠ Shared Recourse Structure.
Recourse Convergence
Multiple Recourse paths may converge on one Subject or Relationship.
Convergence should not automatically merge the originating Recourse Relationships.
Therefore:
Shared Recourse Target ≠ Single Recourse Relationship.
Network Divergence
One Relationship may produce several distinct downstream paths.
Each path should remain separately governed.
Parallel Recourse Relationships
Two or more Recourse Relationships may exist simultaneously without depending upon one another.
Parallelism should remain distinguishable from dependency.
Therefore:
Parallel Recourse ≠ Dependent Recourse.
Dependent Recourse Relationship
One Recourse Relationship may depend upon the state or outcome of another.
The dependency should be explicit.
Dependency Direction
A dependency should identify which Relationship depends upon which other structure.
Therefore:
Recourse Relationship A depends on B ≠ B depends on A.
Conditional Network Relationship
A network connection may become operative only if defined conditions are satisfied.
Conditional relationships should not be treated as active relationships by default.
Shared Recourse Basis
Several Recourse Relationships may share the same Recourse Basis.
Shared Basis does not merge the Relationships.
Therefore:
Shared Recourse Basis ≠ Shared Recourse Relationship.
Different Recourse Bases
Relationships within the same network may arise under different Bases.
Network membership does not create a common Basis.
Shared Recourse Object
Multiple Relationships may concern the same economic or performance consequence.
They should remain distinct where Subjects, Bases, Scope, or direction differ.
Therefore:
Shared Recourse Object ≠ One Recourse Relationship.
Recourse Scope Across Network
Every Recourse Relationship should preserve its own Scope.
The network should not impose one universal Scope.
Therefore:
Liability Recourse Network ≠ Universal Recourse Scope.
Overlapping Recourse Scope
Two Recourse Relationships may concern overlapping portions of the same consequence.
Overlap should be explicitly identified to prevent double recovery or false aggregation where relevant.
Non-Overlapping Recourse Scope
Different Relationships may concern separate portions of a shared originating consequence.
Those boundaries should remain explicit.
Aggregate Network Exposure
A system may calculate an aggregate network representation where useful.
Aggregation must remain traceable to individual Relationships.
Therefore:
Aggregate Recourse Exposure ≠ Individual Recourse Liability.
Double-Counting Risk
Network structures may create a risk that the same Liability-related consequence is counted repeatedly across multiple Recourse Relationships.
LRENM should identify such potential duplication.
Double Recovery Risk
Where several Recourse paths seek recovery concerning the same economic consequence, potential double recovery should be identifiable.
Identification does not itself determine the applicable legal outcome.
Network State
A Recourse Network may have an aggregate governance state.
That state should not replace Relationship-level states.
Therefore:
Liability Recourse Network State ≠ Individual Recourse Relationship State.
Relationship-Level State
Each Recourse Relationship may independently be:
Potential, Pending, Conditional, Active, Suspended, Disputed, Unknown, Uncertain, Resolved, Superseded, or another explicitly governed state.
Mixed Network State
A network may contain simultaneously:
Active Relationships, Resolved Relationships, Pending Relationships, Disputed Relationships, and Unknown Relationships.
Therefore:
One Network ≠ One Uniform Liability State.
Local State Change
A State Change in one Recourse Relationship should not automatically change the State of other Relationships.
Therefore:
Local Recourse State Change ≠ Network-Wide State Change.
State Propagation
Where one State Change legitimately affects another Relationship, the propagation path should be explicit.
No Automatic Propagation
Shared origin, shared Subject, shared payment, or network membership does not itself justify propagation.
Therefore:
Network Connection ≠ Automatic State Propagation.
Recourse Payment
Payment within one Recourse Relationship should be associated with that Relationship.
It should not automatically satisfy another Relationship.
Therefore:
Payment in Recourse A ≠ Satisfaction of Recourse B by default.
Recourse Performance
Performance within one Relationship may affect another where a legitimate dependency exists.
The effect should be separately governed.
Recourse Resolution
One Recourse Relationship may reach Resolution while others remain active.
Therefore:
Recourse Relationship Resolution ≠ Recourse Network Resolution.
Primary Liability Resolution
The primary Liability may be resolved while secondary Recourse Relationships continue.
Therefore:
Primary Liability Resolution ≠ Recourse Network Resolution.
Local Resolution vs Network Resolution
A network reaches complete Resolution only when the applicable Relationships have reached their respective governed outcomes.
LTRS does not itself determine final Resolution; it preserves the network structure for LRDS.
Network Change
The Recourse Network may change when:
a Relationship is added, a Relationship terminates, a Subject changes, a Transfer occurs, a new Recourse layer forms, a dependency changes, or another material structural event occurs.
Network Expansion
A new Recourse Relationship may expand the network without altering existing Relationships.
Therefore:
Network Expansion ≠ Existing Relationship Modification by default.
Network Contraction
A Relationship may leave active network governance through Resolution, Discharge, invalidation, or another legitimate state.
Its historical presence should remain preserved.
Therefore:
Network Contraction ≠ Historical Deletion.
Network Reconfiguration
Subjects, Relationships, layers, or dependencies may change while the overall network remains continuous.
Reconfiguration should preserve prior structure.
Transfer Within Recourse Network
A Recourse Right or another relevant object may transfer between Subjects.
The Transfer should remain distinct from the Recourse Relationship itself.
Therefore:
Recourse Right Transfer ≠ Recourse Relationship Erasure.
Succession Within Recourse Network
A successor may assume a relevant position in the network.
Succession should preserve predecessor history.
Therefore:
Recourse Succession ≠ New Recourse Origin by default.
Sharing Within Recourse Network
A Recourse-related burden or right may itself become shared.
The Sharing structure should remain distinguishable from the Recourse Relationship.
Contribution Within Network
Contribution may create additional secondary relationships.
Contribution should be explicitly classified rather than merged generically into Recourse where its governance meaning differs.
Indemnification Within Network
An Indemnification relationship may coexist with Recourse.
Therefore:
Indemnification Relationship ≠ Recourse Relationship by default.
Insurance Within Network
Insurance-related payment or recovery may create additional network nodes and Relationships.
Insurance status should not replace Liability or Recourse identity.
Multi-Party Network
A Recourse Network may involve many Subjects occupying different positions across different Relationships.
Subject identity alone should not be used to merge those Relationships.
Same Subjects, Different Relationships
The same two Subjects may participate in more than one Recourse Relationship under different Bases, Objects, Scopes, or times.
Therefore:
Same Subjects ≠ Same Recourse Relationship.
Same Basis, Different Relationships
Different Relationships may share a Basis while remaining distinct.
Therefore:
Same Basis ≠ Same Recourse Relationship.
Same Event, Different Relationships
Several Recourse Relationships may originate from the same payment, performance, or Liability event.
Therefore:
Same Recourse-Relevant Event ≠ Same Recourse Relationship.
Network Boundary
The Network Boundary should define which Recourse Relationships belong to the governed network and why.
Not every Liability-related Relationship must belong to the same network.
Boundary Inclusion
A Relationship should enter the network where sufficient structural relevance exists through:
origin, dependency, shared consequence, Recourse chain, Subject interaction, or another governed connection.
Boundary Exclusion
A Relationship should remain outside the network where its connection is insufficient or merely coincidental.
Therefore:
Common Subject ≠ Network Membership by default.
Cross-Network Relationship
A Relationship may connect two otherwise distinct Liability Networks.
The cross-network connection should be explicit without forcing full network merger.
Network Merge
Two networks should not be merged merely because a common Subject or event exists.
A merger requires sufficient governance basis.
Therefore:
Network Connection ≠ Network Merger.
Network Split
A network may later require separation into distinct governed networks where previously assumed common structure is no longer justified.
The historical relationship between the networks should remain preserved.
Network Conflict
Relationships within a network may contain incompatible:
Bases, Scopes, States, directions, authority positions, or recovery expectations.
The conflict should remain explicit.
Conflict ≠ Automatic Invalidity
A conflict does not automatically invalidate every affected Relationship.
Therefore:
Network Conflict ≠ Network Invalidity.
Unknown Network Relationship
Where evidence indicates that a relevant Relationship may exist but its structure cannot be established, the Relationship should remain Unknown.
Therefore:
Unknown Network Relationship ≠ No Relationship.
Uncertain Network Structure
Where multiple plausible network structures remain, uncertainty should be preserved.
Therefore:
Uncertain Network Structure ≠ Authority to Select a Preferred Network.
Disputed Network Structure
Where Subjects or authorities dispute network composition or Relationship structure, the dispute should remain explicit.
Duplicate Relationship Detection
Multiple records may represent the same Recourse Relationship.
Duplicates should not create false network expansion.
Therefore:
Multiple Records ≠ Multiple Recourse Relationships by default.
Relationship Identity Resolution
Where possible duplicates exist, LRENM should compare:
Subjects, Origin, Basis, Object, Scope, direction, effective time, and provenance.
Network Temporal Structure
Recourse Networks evolve through time.
LRENM should preserve:
Relationship formation, activation, change, Transfer, Resolution, and historical sequencing.
Relationship Formation Time
Each Recourse Relationship should retain its own formation and effective times.
Network membership time may differ.
Therefore:
Relationship Formation Time ≠ Network Entry Time by default.
Network Entry
A pre-existing Recourse Relationship may later become part of a wider governed network.
Its earlier history should remain preserved.
Network Exit
A Relationship may cease active participation in the network.
Exit should not erase its historical membership.
Therefore:
Network Exit ≠ Historical Deletion.
Network History
LRENM should preserve the evolution of:
nodes, Relationships, layers, chains, branches, dependencies, boundaries, conflicts, and states.
Historical Network Reconstruction
A qualified process should be able to reconstruct the Recourse Network at a materially relevant historical point.
Therefore:
Current Recourse Network ≠ Complete Recourse Network History.
Provenance
Every material network element should preserve sufficient provenance to identify:
its origin, source, Relationship identity, Subjects, Basis, Scope, time, authority where applicable, and supporting governed inputs.
Network Rationale
The reason why Relationships are connected, separated, layered, or bounded should remain reconstructable.
Therefore:
Network Map ≠ Network Rationale.
Evidence Association
Evidence may support network relationships and dependencies.
Evidence does not itself create network membership.
Therefore:
Evidence of Connection ≠ Governed Network Connection.
Authority Structure
Different Recourse Relationships may be subject to different authorities.
Therefore:
One Liability Recourse Network ≠ One Universal Authority.
Multi-Authority Network
LRENM should preserve distinct authority domains where several authorities affect different network Relationships.
Authority Conflict
Where authorities produce incompatible states or outcomes, the conflict should remain explicit rather than being silently harmonized.
Multi-Jurisdictional Network
A Recourse Network may span multiple jurisdictions.
LRENM preserves the methodological network structure without determining jurisdiction-specific legal outcomes.
Primary Liability Preservation
Network governance must not modify the primary Liability merely to simplify the Recourse Network.
Therefore:
Recourse Network Governance ≠ Primary Liability Redetermination.
Primary Scope Preservation
Network aggregation must not silently enlarge or reduce primary Liability Scope.
Therefore:
Network Scope ≠ Revised Primary Liability Scope.
Primary Allocation Preservation
Secondary Recourse distribution should not overwrite original Liability Allocation.
Therefore:
Recourse Network Distribution ≠ Primary Liability Reallocation.
Sharing Preservation
Network governance should preserve existing Sharing structures rather than silently replacing them.
Therefore:
Recourse Network ≠ Liability Sharing Structure.
Transfer Preservation
Transfer history and Recourse history should remain separately reconstructable.
Therefore:
Recourse Network ≠ Transfer History.
Liability State Preservation
A network-level representation should not overwrite Relationship-level Liability States.
Therefore:
Network State ≠ Replacement for Relationship State.
No Resolution Shortcut
Network mapping does not establish Resolution.
Therefore:
Governed Recourse Network ≠ Resolved Recourse Network.
No Finality Shortcut
Network governance does not establish Liability Finality.
Therefore:
Recourse Network Completion ≠ Liability Finality.
Upstream Re-Entry
Where network governance reveals a material defect in an earlier Liability governance space, the matter should re-enter the earliest materially affected space.
The canonical rule is:
Re-enter the earliest materially affected governance space.
Targeted Reassessment
Re-entry should affect only materially impacted governance structures.
The canonical principle is:
Reassess what materially changed. Preserve what remains valid.
Re-Entry Historical Integrity
Any re-entry must preserve prior network states and Relationship history.
Therefore:
Re-entry must not rewrite history.
Automated Network Governance
AI or automated systems may assist with:
Relationship mapping, network construction, chain detection, branch detection, dependency analysis, duplicate detection, scope overlap analysis, conflict detection, and historical reconstruction.
Automation should preserve uncertainty, provenance, and authority boundaries.
Therefore:
Automated Recourse Network Construction ≠ Authoritative Recourse Determination.
Machine-Readable Recourse Network
Where implemented digitally, the network should support machine-readable representation of:
nodes, Relationships, Relationship types, direction, layers, chains, branches, origins, Subjects, Bases, Objects, Scopes, States, dependencies, effective times, authority, conflicts, provenance, and historical states.
Governed Liability Recourse Network
The principal output of LRENM is:
Governed Liability Recourse Network
It should preserve, where applicable:
Primary Liability origins, Recourse Relationship identities, Recourse nodes, Subject roles, Relationship direction, Recourse Objects, Recourse Bases, Recourse Scopes, Relationship States, network layers, Recourse chains, branches, convergence points, parallel Relationships, dependencies, overlapping Scopes, network boundaries, cross-network connections, Transfer associations, Sharing associations, Contribution associations, Indemnification associations, Insurance-related associations, authority structures, conflicts, Unknown Relationships, Uncertain structures, Disputed structures, effective times, network history, rationale, and provenance.
Meaning of the Output
A Governed Liability Recourse Network means that interacting Recourse Relationships are sufficiently structured to understand:
which Relationships exist, how they connect, where they originate, which Subjects participate, what each Relationship governs, how different layers depend upon one another, and how the network has changed through time.
It does not mean that every Recourse Relationship has been resolved.
Therefore:
Governed Liability Recourse Network ≠ Recourse Network Resolution.
Handoff to Liability Transfer Continuity
The Governed Liability Recourse Network proceeds to:
LTFCM — Liability Transfer Continuity Module
where continuity across Transfer, Sharing, Recourse, secondary Relationships, network changes, and downstream Liability governance is preserved.
The boundary is explicit:
LRENM governs the Recourse Network structure.
LTFCM governs continuity of Transfer and Recourse structures through the Liability lifecycle.
Minimum Implementation Framework
A conforming implementation of LRENM must provide exactly the following eight capabilities:
Recourse Network Identity, Origin & Boundary Governance
Capability to identify the Recourse Network, preserve one or multiple Liability origins, establish network inclusion and exclusion boundaries, and distinguish network membership from incidental connection.
Node, Subject, Relationship & Direction Governance
Capability to identify Subjects, multi-role nodes, Recourse Relationships, other relevant Relationship types, Relationship direction, and the distinct identity of every constituent network element.
Layer, Chain, Branch, Convergence & Dependency Governance
Capability to represent primary and secondary Recourse layers, Recourse chains, branches, convergence points, parallel Relationships, dependency direction, and conditional network relationships.
Scope, State, Propagation, Performance & Recovery Interaction Governance
Capability to preserve Relationship-specific Scope and State, identify overlap and double-counting risk, govern legitimate propagation, and distinguish local payment, performance, recovery, and Resolution effects from network-wide effects.
Multi-Relationship, Transfer, Sharing, Contribution, Indemnification & Insurance
Association Governance
Capability to represent the interaction of Recourse with Transfer, Sharing, Contribution, Indemnification, Insurance-related structures, Succession, and other secondary Liability Relationships without collapsing their distinct governance meanings.
Conflict, Unknown, Uncertain, Disputed, Duplicate & Multi-Authority Governance
Capability to preserve network conflicts, Unknown Relationships, Uncertain or Disputed structures, duplicate records, multiple authority domains, authority conflicts, and multi-jurisdictional structures without manufacturing uniformity.
Historical Integrity, Provenance, Reconstruction & Re-Entry Governance
Capability to preserve network evolution, Relationship history, effective times, provenance, rationale, historical reconstruction, targeted upstream re-entry, and the principle that re-entry must not rewrite history.
Liability Transfer Continuity Handoff Governance
Capability to produce a Governed Liability Recourse Network sufficiently explicit, bounded, traceable, historically preserved, and structurally connected for LTFCM to maintain Transfer and Recourse continuity through subsequent Liability governance.
Governance Logic
The canonical LRENM governance logic is:
Identified Liability Recourse Structures
↓
Identify Network Relevance
↓
Identify Liability Origin or Origins
↓
Establish Network Boundary
↓
Identify Nodes & Subjects
↓
Identify Recourse Relationships
↓
Establish Relationship Direction
↓
Classify Relationship Types
↓
Establish Network Layers
↓
Identify Recourse Chains
↓
Identify Branches & Convergence
↓
Identify Parallel & Dependent Relationships
↓
Establish Relationship-Level Scope & State
↓
Identify Overlap / Duplication / Double-Recovery Risk
↓
Map Transfer / Sharing / Contribution / Indemnification / Insurance Associations
↓
Preserve Unknown / Uncertain / Disputed Structures
↓
Preserve Authority Domains & Conflicts
↓
Preserve Temporal Structure / History / Provenance
↓
Governed Liability Recourse Network
↓
Handoff to Liability Transfer Continuity
Governance Outputs
LRENM may produce:
Liability Recourse Network Identity
Network Origin Structure
Network Boundary
Network Node Set
Subject Node Structure
Multi-Role Subject Record
Recourse Relationship Set
Relationship Direction Map
Relationship Classification
Primary Liability Layer
Primary Recourse Layer
Secondary Recourse Layer
Further Recourse Layer
Recourse Chain
Recourse Branch
Recourse Convergence Structure
Parallel Recourse Structure
Dependency Map
Relationship Scope Map
Relationship State Map
Scope Overlap Record
Double-Counting Risk Record
Double-Recovery Risk Record
Transfer Association Map
Sharing Association Map
Contribution Association Map
Indemnification Association Map
Insurance-Related Association Map
Cross-Network Relationship
Network Conflict Record
Unknown Network Relationship
Uncertain Network Structure
Disputed Network Structure
Multi-Authority Structure
Network History
Network Provenance
Network Rationale
The principal output is:
Governed Liability Recourse Network
Critical Distinctions
LRENM preserves the following distinctions:
One Primary Liability ≠ One Recourse Relationship ≠ One Liability Recourse Network Multiple Recourse Records ≠ Recourse Network by default Liability Recourse Network ≠ Single Recourse Relationship One Primary Liability ≠ One Secondary Liability Relationship Multiple Liability Origins ≠ One Liability Origin by aggregation One Subject ≠ One Network Role Network Connection ≠ Recourse Relationship by default Value Flow Direction ≠ Recourse Direction by default Network Layer ≠ Liability Relationship Later Recourse ≠ Independent Liability Origin by default Immediate Recourse Origin ≠ Ultimate Liability Origin by default Shared Origin ≠ Shared Recourse Structure Shared Recourse Target ≠ Single Recourse Relationship Parallel Recourse ≠ Dependent Recourse Shared Recourse Basis ≠ Shared Recourse Relationship Shared Recourse Object ≠ One Recourse Relationship Liability Recourse Network ≠ Universal Recourse Scope Aggregate Recourse Exposure ≠ Individual Recourse Liability Liability Recourse Network State ≠ Individual Recourse Relationship State One Network ≠ One Uniform Liability State Local Recourse State Change ≠ Network-Wide State Change Network Connection ≠ Automatic State Propagation Payment in Recourse A ≠ Satisfaction of Recourse B by default Recourse Relationship Resolution ≠ Recourse Network Resolution Primary Liability Resolution ≠ Recourse Network Resolution Network Expansion ≠ Existing Relationship Modification by default Network Contraction ≠ Historical Deletion Recourse Right Transfer ≠ Recourse Relationship Erasure Recourse Succession ≠ New Recourse Origin by default Indemnification Relationship ≠ Recourse Relationship by default Same Subjects ≠ Same Recourse Relationship Same Basis ≠ Same Recourse Relationship Same Recourse-Relevant Event ≠ Same Recourse Relationship Common Subject ≠ Network Membership by default Network Connection ≠ Network Merger Network Conflict ≠ Network Invalidity Unknown Network Relationship ≠ No Relationship Uncertain Network Structure ≠ Authority to Select a Preferred Network Multiple Records ≠ Multiple Recourse Relationships by default Relationship Formation Time ≠ Network Entry Time by default Network Exit ≠ Historical Deletion Current Recourse Network ≠ Complete Recourse Network History Network Map ≠ Network Rationale Evidence of Connection ≠ Governed Network Connection One Liability Recourse Network ≠ One Universal Authority Recourse Network Governance ≠ Primary Liability Redetermination Network Scope ≠ Revised Primary Liability Scope Recourse Network Distribution ≠ Primary Liability Reallocation Recourse Network ≠ Liability Sharing Structure Recourse Network ≠ Transfer History Network State ≠ Replacement for Relationship State Governed Recourse Network ≠ Resolved Recourse Network Recourse Network Completion ≠ Liability Finality Automated Recourse Network Construction ≠ Authoritative Recourse Determination Governed Liability Recourse Network ≠ Recourse Network Resolution
Cross-Architecture Boundary
LRENM may use governed inputs from adjacent OOF® architectures where they affect the structure of a Recourse Network.
ORA™ may establish relevant operational events and relationships.
HAGA™ may establish Harm structures without determining Recourse.
AGA™ may establish Responsibility, Accountability, Authority, and Delegation structures.
ADIT® may provide evidence and auditability.
VALIDOS™ may validate network-relevant inputs.
OBIDENITY® may govern identity, authority, ownership, provenance, Transfer, and continuity.
VFM® may govern economic and Value Flow relationships.
AIG® and ASGA™ may provide AI or autonomous-system operational relationships.
These structures may explain or affect Recourse Network formation without becoming Recourse Relationships themselves.
The canonical interoperability principle is:
External relationships may create, support, or explain Recourse Network connections, but LRENM governs only the Liability-specific network of Recourse Relationships and their interaction.
Canonical Boundary
LRENM begins when one or more identified Recourse Relationships possess sufficient structural interaction to require network governance.
LRENM governs:
Recourse Network identity, origin, nodes, Subjects, Relationship identity, direction, layers, chains, branches, convergence, parallel Relationships, dependencies, Scope, State, propagation, overlap, double-counting risk, double-recovery risk, Transfer associations, Sharing associations, Contribution associations, Indemnification associations, Insurance-related associations, network boundaries, cross-network relationships, conflicts, Unknown Relationships, Uncertain structures, Disputed structures, duplicate records, authority structures, temporal evolution, history, rationale, provenance, and downstream continuity handoff.
LRENM does not independently govern:
primary Liability Determination, primary Scope or Allocation, initial Transfer identification, initial Sharing formation, initial Recourse identification, Resolution, Discharge, or Finality.
LRENM ends when interacting Recourse Relationships are sufficiently represented as a:
Governed Liability Recourse Network
for continuity governance under LTFCM.
Use Case 1 — Multi-Party Recourse Chain
A primary Liability involves three Subjects.
Subject A satisfies a Liability-related economic consequence and possesses a governed Recourse Relationship against Subject B.
Subject B subsequently possesses a separate Recourse Relationship against Subject C under another Basis.
LRENM represents:
the primary Liability, Recourse A, Recourse B, the immediate origin of each Relationship, the ultimate primary Liability origin, the Subjects, the different Bases, the Scopes, the States, and the dependency between the two Recourse layers.
The network preserves:
Primary Liability → Recourse A → Recourse B without treating the three Relationships as one Liability.
Use Case 2 — Insurance, Indemnification, and Parallel
Recourse
A Liability event produces an established primary Liability Relationship.
An insurer makes a covered payment and acquires potential Recourse against one Subject.
Separately, an indemnifier reimburses another Subject and possesses a different recovery relationship.
LRENM represents the two secondary paths as parallel Recourse Relationships.
Although both originate from the same wider Liability matter, they retain different:
Subjects, Bases, Recourse Objects, Scopes, States, and authorities.
A payment or Resolution in one path does not automatically resolve the other.
The network therefore preserves the distinction between shared origin and independent Recourse structure.
Canonical Closing Statement
Recourse does not always form a single line from one Subject to another.
One Liability may create several recovery paths.
One recovery may create another.
Relationships may branch, converge, overlap, depend upon one another, or remain parallel.
The resulting structure is a network, but the network must never erase the Relationships from which it is built.
LRENM preserves each Recourse Relationship while governing how those Relationships interact as a larger Liability structure.
One Primary Liability ≠ One Recourse Relationship ≠ One Liability Recourse Network.
Govern the network without collapsing the relationships that give it meaning.