LREIM — Liability Recourse Identification Module
LREIM — Liability Recourse Identification 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 Identification
Module ID: LIGA-LTRS-LREIM-001
Origin ID: OOF.CM.LIGA.10.03.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 Identification Module (LREIM) governs how a potential Recourse relationship arising from established Liability, Liability Sharing, Transfer, payment, performance, Contribution, Indemnification, Insurance-related performance, Succession, reimbursement, or another Liability-related consequence is identified, bounded, classified, and associated with the primary or preceding Liability structure from which it arises.
LREIM determines whether circumstances create sufficient Recourse relevance to identify a potential secondary Liability Relationship, who may exercise Recourse, against whom Recourse may be directed, what Recourse Object is involved, what Basis may support the relationship, what consequence or performance generated the Recourse relevance, and how the potential Recourse remains connected to the primary Liability.
LREIM does not assume that payment, excess performance, insurance payment, indemnification, Contribution relevance, or economic burden automatically creates Recourse.
It does not redetermine primary Liability.
It does not collapse Recourse into the primary Liability Relationship.
It governs the transition:
Governed Liability Transfer / Sharing Structure + Recourse-Relevant Event → Recourse Origin Identification → Recourse Subjects → Recourse Object → Recourse Basis → Recourse Boundary → Recourse Qualification →
Identified Liability Recourse Structure
Its foundational distinction is:
Recourse-Relevant Event ≠ Established Recourse.
Operational Role
The operational role of LREIM is:
to identify whether a Liability-related consequence creates a sufficiently governed basis for a distinct potential Recourse relationship while preserving the Liability structure from which that relationship originated.
The module identifies:
why Recourse becomes relevant, who may seek recovery, against whom, for what, under what Basis, within what Scope, and in relation to which primary or preceding Liability structure.
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 LREIM governs:
Liability Recourse Identification
Relevant inputs may include:
Identified Liability Transfer Structure
Governed Liability Sharing Structure
and other governed Liability structures producing Recourse relevance.
Its principal output is:
Identified Liability Recourse Structure
Its downstream handoff is:
LRENM — Liability Recourse Network Module
where multiple, chained, layered, or interacting Recourse Relationships require network governance.
Central Operational Question
Has a Liability-related consequence created a sufficiently governed potential Recourse relationship, between which Subjects, for what Recourse Object, under what Basis, and with what relationship to the primary or preceding Liability?
Recourse-Relevant Event
LREIM begins where an event creates a legitimate reason to examine whether a secondary recovery relationship may exist.
Possible Recourse-Relevant Events include:
payment, excess performance, Contribution, Indemnification, Insurance-related payment, reimbursement, Succession, Transfer, satisfaction of another Subject's obligation, or another Liability-related consequence.
The event itself does not establish Recourse.
Therefore:
Recourse-Relevant Event ≠ Established Recourse.
Recourse Origin
Every potential Recourse Relationship should identify the Liability structure from which it originates.
This may be:
Primary Liability, a secondary Liability Relationship, a Sharing structure, a Transfer structure, or a preceding Recourse Relationship.
Primary Liability Association
Where Recourse originates from primary Liability, the association should preserve:
Liability Origin, Determination, Scope, Allocation, Subjects, Relationships, State, and relevant history.
Therefore:
Recourse without Primary or Preceding Liability Association ≠ Fully Governed Recourse.
Recourse Origin vs Recourse Relationship
The Liability structure creating Recourse relevance is not the Recourse Relationship itself.
Therefore:
Recourse Origin ≠ Recourse Relationship.
Recourse-Seeking Subject
LREIM should identify the Subject potentially entitled to seek recovery.
This Subject may be:
a Liability-bearing party, a paying party, a performing party, an insurer, an indemnifier, a successor, a contributor, or another governed Subject.
Recourse-Target Subject
LREIM should identify the Subject against whom Recourse may be directed.
The Recourse-Target Subject should remain distinguishable from every other Subject in the primary Liability structure.
Subject Role Distinction
The Recourse-Seeking Subject may have occupied a different role in the primary Liability structure.
Therefore:
Recourse-Seeking Subject ≠ Primary Liability-Bearing Subject by default.
Likewise:
Recourse-Target Subject ≠ Harm-Producing Actor by default.
Multi-Role Subjects
A Subject may simultaneously be:
Liability-bearing, paying, performing, insured, insuring, indemnifying, contributing, or seeking Recourse.
Each role should remain separately identifiable where methodologically relevant.
Recourse Object
LREIM should identify exactly what is sought through Recourse.
Possible Recourse Objects may include:
reimbursement, Contribution, economic recovery, performance recovery, indemnification, payment recovery, or another defined Liability-related consequence.
Recourse Object Identity
The Recourse Object should possess sufficient identity to distinguish it from:
primary Liability, primary Liability Scope, original payment, original performance, and another Recourse Object.
Recourse Object vs Primary Liability
The object sought through Recourse may differ substantially from the original Liability.
Therefore:
Recourse Object ≠ Primary Liability Object by default.
Recourse Basis
Every potential Recourse Relationship requires an identifiable Recourse Basis.
Possible Bases may arise through:
law, agreement, Contribution structure, Indemnification, Insurance-related mechanism, Succession, Transfer, guarantee, or another legitimate source.
Primary Liability Basis vs Recourse Basis
The Basis that established primary Liability does not automatically establish Recourse.
Therefore:
Primary Liability Basis ≠ Recourse Basis by default.
Recourse Basis Sufficiency
A Recourse-Relevant Event is insufficient by itself.
The potential relationship should possess a sufficiently identifiable Basis before it is represented as an Identified Liability Recourse Structure.
Therefore:
Payment + Primary Liability ≠ Recourse Basis by default.
Recourse Conditions
A Recourse Basis may require conditions to be satisfied before Recourse becomes relevant or operative.
Possible conditions may concern:
payment, performance, timing, Scope, Subject status, prior demand, coverage, Contribution structure, or another applicable condition.
Recourse Condition State
A condition may be:
Satisfied, Unsatisfied, Partially Satisfied, Pending, Unknown, Uncertain, Disputed, or otherwise governed.
Condition Satisfaction vs Recourse
Satisfied conditions do not automatically establish the complete Recourse Relationship.
Therefore:
Recourse Condition Satisfaction ≠ Established Recourse by itself.
Recourse Connection
LREIM should identify the governed relationship between:
the originating Liability, the Recourse-Relevant Event, the consequence borne, the Recourse-Seeking Subject, the Recourse-Target Subject, and the Recourse Basis.
Connection Requirement
Temporal proximity or economic interaction alone should not establish Recourse.
Therefore:
Economic Connection ≠ Recourse Connection by default.
Payment as Recourse Trigger
Payment may create Recourse relevance.
It does not automatically create Recourse.
Therefore:
Payment ≠ Recourse Right by default.
Excess Performance as Recourse Trigger
A Subject may perform more than its governed share or obligation.
That may create Recourse relevance.
Therefore:
Excess Performance ≠ Established Recourse.
Underperformance by Another Subject
Another Subject's underperformance may contribute to Recourse relevance.
It does not by itself establish the Recourse Relationship.
Therefore:
Underperformance ≠ Recourse by default.
Contribution as Recourse Relevance
A Contribution structure may provide a Basis for recovery among Subjects.
Contribution should remain methodologically distinguishable from Recourse identification.
Therefore:
Contribution Relevance ≠ Established Recourse.
Indemnification as Recourse Relevance
An Indemnification relationship may create reimbursement or recovery relevance.
The indemnification mechanism and Recourse Relationship should remain distinguishable.
Therefore:
Indemnification ≠ Recourse by default.
Insurance Payment as Recourse Relevance
Insurance payment may create potential recovery or subrogation relevance.
It does not automatically establish Recourse against another Subject.
Therefore:
Insurance Payment ≠ Established Recourse.
Succession and Recourse
Succession may alter which Subject possesses or bears a Recovery or Recourse Right.
The succession mechanism should remain distinct from Recourse itself.
Transfer and Recourse
A Transfer may create or move a Recourse Right.
Transfer and Recourse remain separate governance structures.
Therefore:
Liability Transfer ≠ Liability Recourse.
Sharing and Recourse
Sharing may create Recourse relevance where one Subject performs or pays beyond its governed share.
Therefore:
Liability Sharing ≠ Liability Recourse.
Share–Performance Imbalance
Where actual performance differs materially from a governed share, LREIM may identify potential Recourse relevance.
The imbalance alone does not determine the Recourse outcome.
Therefore:
Share–Performance Imbalance ≠ Established Recourse.
Share–Payment Imbalance
Where a Subject pays more than its governed economic or Liability-related share, potential Recourse may arise.
Therefore:
Share–Payment Imbalance ≠ Established Recourse.
Economic Burden vs Recourse
Bearing an economic burden does not automatically create a recovery right.
Therefore:
Economic Burden ≠ Recourse Right by default.
Liability-Bearing Party vs Recourse-Seeking Party
The party bearing primary Liability may or may not become the Recourse-Seeking Subject.
Therefore:
Liability-Bearing Party ≠ Recourse-Seeking Party by default.
Paying Party vs Recourse-Seeking Party
The paying party may become Recourse-relevant, but payment alone is insufficient.
Therefore:
Paying Party ≠ Recourse-Seeking Party by default.
Recourse Scope
LREIM should identify the potential Scope of Recourse.
This may concern:
all or part of a payment, all or part of performance, a Contribution amount, an indemnified amount, or another bounded Recourse Object.
Primary Liability Scope vs Recourse Scope
The Scope of Recourse may be narrower than primary Liability.
Therefore:
Primary Liability Scope ≠ Recourse Scope by default.
Partial Recourse
A Recourse Relationship may concern only part of the relevant economic or performance consequence.
Therefore:
Partial Recourse ≠ Complete Recovery.
Multiple Recourse Objects
One Recourse-Relevant Event may produce more than one potential Recourse Object.
Each should remain separately identifiable.
Therefore:
One Recourse-Relevant Event ≠ One Recourse Object by default.
Multiple Recourse Targets
A Recourse-Seeking Subject may possess potential Recourse against multiple Subjects.
Each relationship should remain separate unless a governed network structure establishes otherwise.
Multiple Recourse-Seeking Subjects
Several Subjects may possess separate potential Recourse relationships arising from the same primary Liability.
Therefore:
One Primary Liability ≠ One Recourse-Seeking Subject.
One Primary Liability, Multiple Recourse Relationships
A single primary Liability may generate several secondary recovery relationships.
Therefore:
One Primary Liability ≠ One Recourse Relationship.
Recourse Relationship Identity
Each potential Recourse Relationship should possess its own identity.
That identity should remain distinct from:
Primary Liability Relationship identity, Transfer Relationship identity, Sharing Relationship identity, and other Recourse Relationship identities.
Recourse Relationship Boundary
The boundary should identify:
originating Liability, Recourse-Seeking Subject, Recourse-Target Subject, Recourse Object, Basis, Scope, conditions, and temporal structure.
Recourse State
A potential Recourse Relationship may be identified as:
Potential, Pending, Conditional, Active, Partially Established, Unknown, Uncertain, Disputed, Superseded, or another explicitly governed state.
These are methodological states, not universal legal classifications.
Potential Recourse
Potential Recourse means sufficient relevance exists for continued governance but the relationship is not yet fully established.
Therefore:
Potential Recourse ≠ Established Recourse.
Pending Recourse
A Recourse Relationship may remain Pending while required conditions, authority, evidence, payment, performance, or other dependencies remain unresolved.
Conditional Recourse
A Recourse Relationship may depend upon future or unresolved conditions.
Therefore:
Conditional Recourse ≠ Active Recourse by default.
Unknown Recourse
Where available information cannot establish whether Recourse exists, the state should remain Unknown.
Therefore:
Unknown Recourse ≠ No Recourse.
Uncertain Recourse
Where several materially plausible interpretations remain, uncertainty should be preserved.
Therefore:
Uncertain Recourse ≠ Authority to Select a Preferred Recourse Outcome.
Disputed Recourse
Where materially competing governed positions exist concerning Recourse, the dispute should remain explicit.
Therefore:
Disputed Recourse ≠ Established Recourse.
Primary Liability State vs Recourse State
The primary Liability and Recourse Relationship may possess different states.
Therefore:
Primary Liability State ≠ Recourse Liability State.
Primary Liability Resolution vs Recourse State
Primary Liability may reach Resolution while a Recourse Relationship remains active.
Therefore:
Primary Liability Resolution ≠ Recourse Resolution.
Recourse Trigger Time
The event creating Recourse relevance should have an identifiable time where possible.
Recourse Formation Time
The time a Recourse Relationship becomes sufficiently established may differ from the trigger time.
Therefore:
Recourse Trigger Time ≠ Recourse Formation Time by default.
Recourse Effective Time
The operative time of a Recourse Relationship may differ from:
payment time, performance time, identification time, or recording time.
Recourse Identification Time
LREIM should preserve when Recourse was identified.
Therefore:
Recourse Identification Time ≠ Recourse Effective Time by default.
Recourse Recording Time
The time a Recourse Relationship is recorded may differ from its effective time.
Therefore:
Recourse Recording Time ≠ Recourse Effective Time by default.
Retrospective Recourse Identification
A Recourse Relationship may be identified after the relevant payment or performance occurred.
The historical event and later identification should remain distinct.
Prospective Recourse
A future event may be expected to create Recourse relevance.
Expectation alone should not be represented as existing Recourse.
Therefore:
Expected Future Recourse ≠ Current Recourse.
Recourse Dependency
A potential Recourse Relationship may depend upon:
payment, performance, condition satisfaction, authority, another Liability Relationship, another Recourse Relationship, Transfer, Sharing, or another governed structure.
Dependencies should remain explicit.
Recourse Authority
Where authority is required to establish, recognize, or exercise Recourse, LREIM should identify the relevant authority and its scope.
Authority Boundary
Authority over primary Liability does not automatically establish authority over Recourse.
Therefore:
Primary Liability Authority ≠ Recourse Authority by default.
Recourse Evidence Association
Evidence may support:
payment, performance, Recourse Basis, Subject identity, Scope, conditions, or connection.
Evidence does not itself create Recourse.
Therefore:
Evidence of Recourse-Relevant Facts ≠ Established Recourse.
Recourse Provenance
LREIM should preserve sufficient provenance to reconstruct:
the originating Liability, Recourse-Relevant Event, Subjects, Recourse Object, Basis, conditions, Scope, time, authority, and supporting governed inputs.
Recourse Rationale
The reason a secondary relationship is classified as Recourse-relevant should remain explicit.
Therefore:
Recourse Classification ≠ Recourse Rationale.
Duplicate Recourse Identification
Multiple records may refer to the same potential Recourse Relationship.
Duplicate records should not create multiple Recourse relationships.
Therefore:
Multiple Recourse Records ≠ Multiple Recourse Relationships by default.
Conflicting Recourse Structures
Different sources may indicate incompatible Recourse structures.
The conflict should remain explicit.
Therefore:
Conflicting Recourse Structures ≠ One Governed Recourse Relationship by default.
Recourse Chain Candidate
A Recourse Relationship may itself create another Recourse-relevant consequence.
Example:
Primary Liability → Recourse A → Recourse B LREIM should identify when such a chain may exist.
Recourse Layer
Each Recourse Relationship in a chain should retain its own:
origin, Subjects, Basis, Object, Scope, State, and history.
Therefore:
Recourse Layer A ≠ Recourse Layer B.
Immediate vs Ultimate Recourse Origin
A Recourse Relationship may have:
an immediate origin in a preceding secondary Relationship, and an ultimate origin in primary Liability.
Both should remain identifiable where relevant.
Recourse Network Relevance
Where multiple Recourse Relationships interact, LREIM should identify the need for network governance.
The matter then proceeds to:
LRENM — Liability Recourse Network Module
No Network Collapse
Multiple potential Recourse Relationships should not be collapsed into one generic recovery structure.
Therefore:
Multiple Recourse Relationships ≠ One Recourse Relationship.
Recourse and Liability Network
A Recourse Relationship may become one layer within a broader Liability Network.
It should retain independent identity within that network.
No Primary Liability Redetermination
LREIM does not determine whether primary Liability originally attached.
Therefore:
Recourse Identification ≠ Primary Liability Determination.
No Primary Scope Rewrite
Recourse identification does not alter primary Liability Scope.
Therefore:
Recourse Scope ≠ Revised Primary Liability Scope.
No Primary Allocation Rewrite
A potential Recourse Relationship should not silently alter original Liability Allocation.
Therefore:
Recourse Distribution ≠ Primary Liability Reallocation.
No Sharing Rewrite
Recourse identification should not silently change a governed Sharing structure.
Therefore:
Recourse Identification ≠ Liability Sharing Modification.
No Transfer Rewrite
Recourse identification should not silently reinterpret a Transfer.
Therefore:
Recourse Identification ≠ Liability Transfer Modification.
No Resolution Shortcut
Identification of Recourse does not resolve either primary Liability or the Recourse Relationship.
Therefore:
Recourse Identification ≠ Liability Resolution.
No Finality Shortcut
Recourse identification does not establish Liability Finality.
Therefore:
Recourse Identification ≠ Liability Finality.
Historical Integrity
Recourse identification should preserve the sequence:
Primary Liability → Liability-Related Consequence → Recourse-Relevant Event → Potential Recourse
Relationship
The secondary relationship should not replace the primary history.
Therefore:
Recourse Identification ≠ Historical Rewrite.
Origin Continuity
Recourse should remain connected to its Liability Origin through the relevant chain of relationships.
Therefore:
Recourse Relationship ≠ New Liability Origin by default.
Upstream Re-Entry
Where Recourse Identification reveals a material defect in an earlier Liability governance space, governance should return to the earliest materially affected space.
The canonical rule is:
Re-enter the earliest materially affected governance space.
Re-Entry Integrity
Where re-entry occurs:
Reassess what materially changed. Preserve what remains valid.
and:
Re-entry must not rewrite history.
Automated Recourse Identification
AI or automated systems may assist with:
payment analysis, share–performance comparison, Subject mapping, Recourse Basis association, relationship detection, chain identification, and conflict detection.
Automation should preserve uncertainty and authority boundaries.
Therefore:
Automated Recourse Identification ≠ Authoritative Recourse Determination by default.
Identified Liability Recourse Structure
The principal output of LREIM is:
Identified Liability Recourse Structure
It should identify, where applicable:
Recourse Identity, Primary or Preceding Liability association, Recourse-Relevant Event, Recourse Origin, Recourse-Seeking Subject, Recourse-Target Subject, Subject roles, Recourse Object, Recourse Basis, Recourse Conditions, Recourse Connection, Recourse Scope, Recourse State, trigger time, formation time, effective time, identification time, dependencies, authority, payment association, performance association, Sharing association, Transfer association, Contribution association, Indemnification association, Insurance-related association, potential Recourse Chain, network relevance, uncertainty, dispute, conflict, rationale, provenance, and history.
Meaning of the Output
An Identified Liability Recourse Structure means that a potential secondary recovery relationship has been sufficiently identified, bounded, and associated with its originating Liability structure for continued Recourse governance.
It does not mean that Recourse has been finally determined, performed, recovered, resolved, or discharged.
Therefore:
Identified Liability Recourse Structure ≠ Completed Recourse.
Handoff to Liability Recourse Network
Where one or more Recourse Relationships create:
multiple Subjects, multiple Recourse layers, Recourse chains, parallel recovery relationships, cross-Relationship dependencies, or wider Liability Network effects, the Identified Liability Recourse Structure proceeds to:
LRENM — Liability Recourse Network Module
The boundary is explicit:
LREIM identifies Recourse Relationships.
LRENM governs their network structure and interaction.
Minimum Implementation Framework
A conforming implementation of LREIM must provide exactly the following eight capabilities:
Recourse Origin & Recourse-Relevant Event Identification
Capability to identify the primary or preceding Liability structure and the payment, performance, Sharing, Transfer, Contribution, Indemnification, Insurance-related, Succession, or other event creating Recourse relevance.
Recourse Subject & Role Identification
Capability to identify Recourse-Seeking Subjects, Recourse-Target Subjects, multi-role Subjects, and distinguish Liabilitybearing, paying, performing, insuring, indemnifying, contributing, and recovering roles.
Recourse Object, Basis, Condition & Connection Governance
Capability to identify the Recourse Object, establish the applicable Recourse Basis, represent conditions, and govern the connection between originating Liability, borne consequence, and potential secondary recovery relationship.
Recourse Scope, State & Temporal Governance
Capability to establish Recourse Scope and govern Potential, Pending, Conditional, Active, Unknown, Uncertain, Disputed, and other explicit states while preserving trigger, formation, effective, identification, and recording times.
Sharing, Transfer, Payment, Performance, Contribution & Indemnification
Distinction Governance
Capability to distinguish Recourse from Liability Sharing, Transfer, payment, performance, Contribution, Indemnification, Insurance-related performance, and economic burden.
Multi-Relationship, Recourse Chain, Layer, Duplicate & Conflict Governance
Capability to identify multiple Recourse Relationships, Recourse Chains, immediate and ultimate origins, distinct Recourse layers, duplicate records, conflicting structures, and Liability Network relevance.
Historical Integrity, Provenance, Authority & Re-Entry Governance
Capability to preserve primary Liability history, Recourse rationale, provenance, evidence association, authority boundaries, Origin continuity, and targeted upstream re-entry without rewriting earlier Liability governance.
Recourse Network Handoff Governance
Capability to produce an Identified Liability Recourse Structure sufficiently explicit, bounded, traceable, and historically connected for LRENM to govern multi-Relationship Recourse Networks.
Governance Logic
The canonical LREIM governance logic is:
Governed Liability Transfer / Sharing Structure
↓
Identify Recourse-Relevant Event
↓
Associate Primary or Preceding Liability
↓
Identify Recourse Origin
↓
Identify Recourse-Seeking Subject
↓
Identify Recourse-Target Subject
↓
Identify Recourse Object
↓
Identify Recourse Basis
↓
Assess Recourse Conditions
↓
Establish Recourse Connection
↓
Establish Recourse Scope
↓
Establish Recourse State & Temporal Structure
↓ Distinguish Recourse from Transfer / Sharing / Payment / Performance / Contribution / Indemnification ↓
Identify Recourse Chains & Network Relevance
↓
Preserve Uncertainty / Dispute / Conflict
↓
Preserve Authority / Rationale / Provenance / History
↓
Identified Liability Recourse Structure
↓ Handoff to LRENM where applicable
Governance Outputs
LREIM may produce:
Recourse Identity
Primary Liability Association
Preceding Liability Association
Recourse-Relevant Event Record
Recourse Origin
Recourse-Seeking Subject
Recourse-Target Subject
Recourse Subject Role Structure
Recourse Object
Recourse Basis
Recourse Condition Structure
Recourse Connection
Recourse Scope
Potential Recourse
Pending Recourse
Conditional Recourse
Unknown Recourse
Uncertain Recourse
Disputed Recourse
Recourse Temporal Structure
Payment Association
Performance Association
Sharing Association
Transfer Association
Contribution Association
Indemnification Association
Insurance-Related Association
Recourse Chain Candidate
Recourse Layer Record
Network Relevance Record
Recourse Conflict Record
Recourse Rationale
Recourse Provenance Record
The principal output is:
Identified Liability Recourse Structure
Critical Distinctions
LREIM preserves the following distinctions:
Recourse-Relevant Event ≠ Established Recourse Recourse without Primary or Preceding Liability Association ≠ Fully Governed Recourse Recourse Origin ≠ Recourse Relationship Recourse-Seeking Subject ≠ Primary Liability-Bearing Subject by default Recourse-Target Subject ≠ Harm-Producing Actor by default Recourse Object ≠ Primary Liability Object by default Primary Liability Basis ≠ Recourse Basis by default Payment + Primary Liability ≠ Recourse Basis by default Recourse Condition Satisfaction ≠ Established Recourse by itself Economic Connection ≠ Recourse Connection by default Payment ≠ Recourse Right by default Excess Performance ≠ Established Recourse Underperformance ≠ Recourse by default Contribution Relevance ≠ Established Recourse Indemnification ≠ Recourse by default Insurance Payment ≠ Established Recourse Liability Transfer ≠ Liability Recourse Liability Sharing ≠ Liability Recourse Share–Performance Imbalance ≠ Established Recourse Share–Payment Imbalance ≠ Established Recourse Economic Burden ≠ Recourse Right by default Liability-Bearing Party ≠ Recourse-Seeking Party by default Paying Party ≠ Recourse-Seeking Party by default Primary Liability Scope ≠ Recourse Scope by default Partial Recourse ≠ Complete Recovery One Recourse-Relevant Event ≠ One Recourse Object by default One Primary Liability ≠ One Recourse-Seeking Subject One Primary Liability ≠ One Recourse Relationship Potential Recourse ≠ Established Recourse Conditional Recourse ≠ Active Recourse by default Unknown Recourse ≠ No Recourse Uncertain Recourse ≠ Authority to Select a Preferred Recourse Outcome Disputed Recourse ≠ Established Recourse Primary Liability State ≠ Recourse Liability State Primary Liability Resolution ≠ Recourse Resolution Recourse Trigger Time ≠ Recourse Formation Time by default Recourse Identification Time ≠ Recourse Effective Time by default Recourse Recording Time ≠ Recourse Effective Time by default Expected Future Recourse ≠ Current Recourse Primary Liability Authority ≠ Recourse Authority by default Evidence of Recourse-Relevant Facts ≠ Established Recourse Recourse Classification ≠ Recourse Rationale Multiple Recourse Records ≠ Multiple Recourse Relationships by default Conflicting Recourse Structures ≠ One Governed Recourse Relationship by default Recourse Layer A ≠ Recourse Layer B Multiple Recourse Relationships ≠ One Recourse Relationship Recourse Identification ≠ Primary Liability Determination Recourse Scope ≠ Revised Primary Liability Scope Recourse Distribution ≠ Primary Liability Reallocation Recourse Identification ≠ Liability Sharing Modification Recourse Identification ≠ Liability Transfer Modification Recourse Identification ≠ Liability Resolution Recourse Identification ≠ Liability Finality Recourse Identification ≠ Historical Rewrite Recourse Relationship ≠ New Liability Origin by default Automated Recourse Identification ≠ Authoritative Recourse Determination by default Identified Liability Recourse Structure ≠ Completed Recourse
Cross-Architecture Boundary
LREIM may use governed inputs from adjacent OOF® architectures.
ORA™ may establish payment, performance, Transfer, or other Operational Reality.
HAGA™ may establish Harm without determining Recourse.
AGA™ may establish Responsibility, Accountability, Authority, or Delegation structures.
ADIT® may provide evidence and auditability.
VALIDOS™ may validate Recourse-relevant inputs.
OBIDENITY® may provide Subject identity, authority, ownership, provenance, Transfer, and continuity.
VFM® may govern Value Flow and economic movement.
AIG® and ASGA™ may provide AI or autonomous-system operational structures.
Those inputs may create Recourse relevance without themselves establishing Recourse.
The canonical interoperability principle is:
An external event may create Recourse relevance, but LREIM governs whether that relevance forms an identifiable Liability Recourse relationship within LIGA™.
Canonical Boundary
LREIM begins when an established Liability, Transfer, Sharing structure, payment, performance, Contribution, Indemnification, Insurance-related event, Succession, or another Liability-related consequence creates legitimate Recourse relevance.
LREIM governs:
Recourse Origin, Recourse-Relevant Events, Recourse Subjects, Subject roles, Recourse Objects, Recourse Basis, conditions, connection, Scope, State, temporal structure, dependencies, payment and performance associations, Transfer and Sharing associations, Contribution and Indemnification associations, Insurance-related associations, Recourse chains, Recourse layers, network relevance, uncertainty, disputes, conflicts, authority, rationale, provenance, historical integrity, and downstream handoff.
LREIM does not independently govern:
primary Liability Determination, primary Scope or Allocation, complete Liability Transfer, complete Liability Sharing, Recourse Network interaction, Resolution, Discharge, or Finality.
LREIM ends when the potential secondary recovery relationship is sufficiently represented as an:
Identified Liability Recourse Structure
for continued LTRS governance.
Use Case 1 — Excess Payment After Shared Liability
Three Subjects participate in a Governed Liability Sharing Structure.
Subject A pays materially more than its governed share.
LREIM identifies the excess payment as a Recourse-Relevant Event.
It then identifies:
the primary Liability, the existing Sharing structure, Subject A as the potential Recourse-Seeking Subject, the relevant potential Recourse-Target Subject or Subjects, the excess payment as part of the Recourse Object, the applicable Recourse Basis, the potential Scope, and the relevant conditions.
The module does not assume that excess payment automatically establishes Recourse.
The resulting relationship proceeds as an:
Identified Liability Recourse Structure
for continued governance.
Use Case 2 — Insurance Payment and Secondary Recovery
An insurer pays a covered Liability-related loss on behalf of an insured Subject.
The payment creates potential recovery relevance against another Subject connected to the underlying Liability.
LREIM preserves the distinction between:
the primary Liability, the insured Subject, the insurer as paying Subject, the insurance payment, the potential Recourse-Target Subject, and the separate Recourse Basis.
The insurer's payment does not automatically transfer primary Liability and does not automatically establish Recourse.
The module identifies whether a distinct secondary Recourse Relationship is sufficiently supported for continued governance.
Canonical Closing Statement
Recourse begins with a relationship to an existing Liability consequence, but it is not simply another name for that Liability.
A party may pay.
A party may perform more than its share.
An insurer may satisfy an economic loss.
An indemnifier may reimburse another Subject.
Any of these events may create Recourse relevance.
None establishes Recourse by itself.
LREIM preserves the primary Liability while identifying whether a distinct secondary recovery relationship has emerged.
Recourse-Relevant Event ≠ Established Recourse.
Identify the recovery relationship without rewriting the Liability from which it arose.