LRSIM — Liability Resolution Initiation Module
LRSIM — Liability Resolution Initiation Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Resolution & Discharge Standard (LRDS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Resolution Initiation
Module ID: LIGA-LRDS-LRSIM-001
Origin ID: OOF.CM.LIGA.11.01.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 25 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 Resolution Initiation Module (LRSIM) governs how an established active Liability requirement enters Resolution & Discharge governance.
It identifies whether a Resolution-relevant event, process, condition, proposal, performance, payment, agreement, authoritative action, or other mechanism creates a legitimate basis to initiate Resolution governance; identifies the exact Liability requirement or Relationship to which the initiation relates; establishes the Resolution Object, participating Subjects, preliminary Resolution Basis, Scope, Boundary, dependencies, and applicable authority; and preserves the active Liability state until subsequent governance establishes Satisfaction, Settlement, Discharge, or another legitimate Resolution state.
LRSIM prevents a Resolution-relevant event from being represented prematurely as Liability Resolution.
Its foundational distinction is:
Resolution-Relevant Event ≠ Liability Resolution.
Operational Role
The operational role of LRSIM is:
to establish whether an active Liability requirement has legitimately entered Resolution governance and to define exactly what is entering that process without prematurely treating the Liability as resolved.
LRSIM establishes the governed starting point for LRDS.
Position in the LRDS Internal Flow
The internal LRDS progression is:
Liability Resolution Initiation → Liability Satisfaction → Liability Settlement → Liability Discharge → Liability
Resolution Verification
LRSIM governs:
Liability Resolution Initiation
Its principal input is an:
Active Liability Structure
including relevant Transfer, Sharing, Recourse, or secondary Liability structures where applicable.
Its principal output is:
Governed Liability Resolution Initiation Structure
The output proceeds to subsequent LRDS governance according to the applicable Resolution pathway.
Central Operational Question
Has an active Liability requirement legitimately entered Resolution governance, what exactly is proposed or expected to be resolved, for which Subjects and Relationships, under what preliminary Basis, Scope, Boundary, conditions, and authority?
Resolution Initiation
Resolution Initiation is the governed transition from active Liability into a process capable of producing Resolution or Discharge.
Initiation does not mean that the process has succeeded.
Therefore:
Resolution Initiation ≠ Liability Resolution.
Active Liability Prerequisite
LRSIM requires an identifiable Liability structure to which the proposed Resolution relates.
The structure should preserve, where relevant:
Liability Origin, Liability Relationship, Liability Subject, Scope, Allocation, State, Transfer, Sharing, Recourse, and other active requirements.
Resolution-Relevant Event
A Resolution-Relevant Event is an event or condition that creates a legitimate reason to examine whether active Liability may proceed toward Resolution.
Examples may include:
payment, performance, offer of performance, Settlement proposal, Settlement agreement, release proposal, Discharge mechanism, authoritative decision, Extinguishment mechanism, waiver where applicable, or another legitimate Resolution-related event.
Event vs Resolution
The existence of a Resolution-Relevant Event is insufficient to establish Resolution.
Therefore:
Resolution-Relevant Event ≠ Liability Resolution.
Resolution Trigger
A Resolution Trigger is the specific event, condition, or governed change that causes Resolution governance to begin.
The trigger should remain explicit.
Trigger vs Completion
A Resolution Trigger initiates governance.
It does not determine its outcome.
Therefore:
Resolution Trigger ≠ Resolution Completion.
Resolution Initiation Basis
Every initiated Resolution process should possess an identifiable preliminary Basis explaining why Resolution governance has become relevant.
Liability Basis vs Resolution Initiation Basis
The original Liability Basis and the Resolution Initiation Basis may differ.
Therefore:
Liability Basis ≠ Resolution Initiation Basis by default.
Resolution Object Identification
LRSIM should identify exactly what Liability requirement is entering Resolution governance.
The Resolution Object may be:
a complete Liability Relationship, part of a Liability Relationship, a monetary requirement, a performance requirement, a shared Liability component, a transferred requirement, a Recourse Relationship, or another bounded Liability requirement.
Resolution Object vs Liability Object
The object being resolved is not necessarily identical to the original Liability Object.
Therefore:
Resolution Object ≠ Liability Object by default.
Resolution Object Identity
The Resolution Object should possess sufficient identity to remain distinguishable from other active Liability requirements.
Complete Resolution Object
Where the complete Liability Relationship is proposed for Resolution, that Scope should be explicit.
It should not be inferred from a generic closure action.
Partial Resolution Object
Resolution may concern only part of the active Liability.
Therefore:
Partial Resolution Object ≠ Complete Liability Relationship.
Multi-Object Resolution
One Resolution process may concern multiple Liability requirements.
Each requirement should remain independently identifiable.
Therefore:
One Resolution Process ≠ One Resolution Object by default.
Resolution Subject Identification
LRSIM should identify Subjects participating in or affected by Resolution Initiation.
These may include:
Liability-bearing Subjects, performing Subjects, paying Subjects, receiving Subjects, Settlement participants, Recourse Subjects, authorized representatives, or other relevant parties.
Subject Role Distinction
A Subject's role in Resolution may differ from its role in the underlying Liability.
Therefore:
Liability-Bearing Subject ≠ Resolution-Performing Subject by default.
Paying Subject
A paying Subject may participate in Resolution without being the primary Liability-bearing Subject.
Therefore:
Paying Subject ≠ Liability-Bearing Subject by default.
Performing Subject
A Subject performing a requirement may differ from the Subject whose Liability is being resolved.
Therefore:
Performing Subject ≠ Liability-Bearing Subject by default.
Resolution Beneficiary
Where relevant, the Subject receiving performance, payment, release, or another Resolution-related benefit should remain identifiable.
Multi-Subject Initiation
A Resolution process may affect several Subjects differently.
Subject-specific effects should remain explicit.
Therefore:
Multi-Subject Resolution Initiation ≠ Uniform Subject Resolution.
Resolution Relationship Identification
LRSIM should identify the exact Liability Relationship or Relationships affected by Resolution Initiation.
Relationship-Specific Initiation
Initiation concerning one Liability Relationship should not automatically initiate Resolution of another.
Therefore:
Resolution Initiation for Relationship A ≠ Resolution Initiation for Relationship B.
Primary Liability Initiation
A primary Liability Relationship may enter Resolution independently of secondary Relationships.
Recourse Resolution Initiation
A Recourse Relationship may enter its own Resolution process.
Therefore:
Primary Liability Resolution Initiation ≠ Recourse Resolution Initiation.
Network Resolution Initiation
A wider Liability Network may contain multiple independently initiated Resolution processes.
A local initiation should not be treated as network-wide initiation.
Therefore:
Local Resolution Initiation ≠ Liability Network Resolution Initiation.
Resolution Scope
LRSIM should establish the preliminary Scope of the proposed Resolution.
The Scope may be:
complete, partial, Subject-specific, Relationship-specific, obligation-specific, Recourse-specific, conditional, or otherwise bounded.
Scope Sufficiency
The proposed Resolution Scope should be sufficiently explicit to determine what subsequent Resolution governance must evaluate.
Resolution Scope vs Liability Scope
Resolution Scope may concern only part of established Liability Scope.
Therefore:
Resolution Scope ≠ Liability Scope by default.
Resolution Boundary
LRSIM should establish a boundary distinguishing:
what enters Resolution governance, what remains active outside it, which Subjects are affected, which Relationships are affected, and which requirements remain unchanged.
Boundary Integrity
A Resolution process should not silently expand beyond its established Boundary.
Therefore:
Resolution Initiation ≠ Authority to Resolve Unbounded Liability.
Remaining Active Liability
Any Liability outside the Resolution Boundary should remain active unless independently changed through legitimate governance.
Therefore:
Resolution Initiation ≠ Suspension of All Liability by default.
Resolution Pathway
LRSIM should identify the anticipated Resolution pathway where known.
Possible pathways may include:
Satisfaction, performance, Settlement, Discharge, Extinguishment, release, waiver, or another legitimate mechanism.
Pathway vs Outcome
Identification of a Resolution pathway does not establish that the pathway will succeed.
Therefore:
Resolution Pathway ≠ Resolution Outcome.
Satisfaction Pathway
Where Resolution is expected through fulfillment of an active requirement, LRSIM should route the matter toward Satisfaction governance.
Settlement Pathway
Where Resolution is expected through negotiated or otherwise governed Settlement, the Settlement pathway should remain explicit.
Discharge Pathway
Where a Liability requirement may cease through Discharge or Extinguishment rather than direct Satisfaction, the relevant pathway should remain explicit.
Multiple Resolution Pathways
A Liability requirement may involve more than one Resolution pathway.
Example:
payment plus corrective performance, Settlement plus later Satisfaction, or partial Satisfaction followed by Discharge.
Therefore:
One Liability Requirement ≠ One Resolution Pathway by default.
Resolution Conditions
Initiation may depend upon conditions.
These may concern:
payment, performance, authority, agreement, verification, timing, documentation, another Relationship, or another governed requirement.
Condition State
A Resolution Initiation condition may be:
Satisfied, Unsatisfied, Partially Satisfied, Pending, Unknown, Uncertain, or Disputed.
Conditional Initiation
A Resolution process may be initiated conditionally.
Therefore:
Conditional Resolution Initiation ≠ Conditional Resolution Completion.
Resolution Dependency
A Resolution process may depend upon another event, Subject, Relationship, authority, or governance state.
Dependencies should remain explicit.
Dependency vs Resolution
Existence of a dependency does not establish that the dependency has been satisfied.
Therefore:
Resolution Dependency ≠ Resolution Condition Satisfaction.
Resolution Authority
Where Resolution Initiation requires authority, LRSIM should identify:
the authority, its source, its Scope, affected Subjects, affected Relationships, and relevant limitations.
Authority Sufficiency
A Subject authorized to initiate one Resolution pathway may not possess authority to complete another.
Therefore:
Resolution Initiation Authority ≠ Resolution Completion Authority by default.
Local Authority
Authority concerning one Liability Relationship should not be projected onto an entire Liability Network.
Therefore:
Local Resolution Authority ≠ Universal Liability Resolution Authority.
Authority Conflict
Where competing authorities claim incompatible Resolution roles, the conflict should remain explicit.
Payment as Initiation Event
Payment may trigger Resolution governance.
It should not automatically establish Satisfaction or Resolution.
Therefore:
Payment ≠ Liability Resolution by default.
Partial Payment
Partial payment may initiate partial Satisfaction governance while other requirements remain active.
Therefore:
Partial Payment ≠ Complete Resolution.
Third-Party Payment
Payment by a third party may create Resolution relevance without changing primary Liability identity.
Therefore:
Third-Party Payment ≠ Liability Transfer by default.
Performance as Initiation Event
Performance may trigger Satisfaction assessment.
Performance should be evaluated against the actual Liability requirement.
Therefore:
Performance ≠ Satisfaction by default.
Partial Performance
Partial performance may initiate Resolution governance for a bounded component.
It should not be represented as complete Satisfaction.
Settlement Proposal
A Settlement proposal may initiate a Resolution pathway.
A proposal is not a Settlement.
Therefore:
Settlement Proposal ≠ Settlement.
Settlement Agreement
A Settlement agreement may create Resolution relevance and future performance requirements.
Its existence does not necessarily establish completed Resolution.
Therefore:
Settlement Agreement ≠ Liability Resolution by default.
Settlement and Admission
Settlement Initiation should not be interpreted automatically as admission of Liability.
Therefore:
Settlement Initiation ≠ Admission of Liability.
Discharge-Relevant Event
An event may indicate that Discharge should be assessed.
The event itself does not establish Discharge.
Therefore:
Discharge-Relevant Event ≠ Liability Discharge.
Release-Relevant Event
A release proposal or act may create Resolution relevance.
Its actual effect must remain bounded to its governed Scope and authority.
Waiver-Relevant Event
A waiver may create Resolution relevance where applicable.
Waiver of one right or requirement should not automatically erase the underlying Liability structure.
Extinguishment-Relevant Event
An event capable of extinguishing an active Liability requirement may initiate Resolution governance.
The Extinguishment state remains subject to subsequent governance and verification.
Claim Event
Claim payment, closure, rejection, or withdrawal may create Resolution relevance.
It does not independently determine Liability Resolution.
Therefore:
Claim Closure ≠ Liability Resolution.
Harm Resolution Event
Harm Recovery or Harm Resolution may create relevant context.
It does not establish Liability Resolution.
Therefore:
Harm Resolution ≠ Liability Resolution.
Operational Termination Event
Termination of an operational mechanism or relationship may create relevant context.
It does not establish Liability Resolution.
Therefore:
Operational Termination ≠ Liability Resolution.
Contract Termination Event
Contract termination may affect Resolution conditions without automatically resolving existing Liability.
Therefore:
Contract Termination ≠ Liability Resolution.
Administrative Closure Event
A system may mark a matter as closed.
That signal may initiate verification but cannot establish Resolution by itself.
Therefore:
Administrative Closure ≠ Verified Liability Resolution.
Initiation State
LRSIM may represent initiation states such as:
Not Initiated, Proposed, Pending, Conditionally Initiated, Initiated, Partially Initiated, Unknown, Uncertain, Disputed, Rejected, Superseded, or another explicitly governed state.
These are methodological states, not universal legal classifications.
Proposed Initiation
A proposal to resolve Liability does not mean Resolution governance has fully commenced.
Therefore:
Resolution Proposal ≠ Resolution Initiation by default.
Pending Initiation
Initiation may remain Pending while authority, conditions, Subject participation, or other required elements remain unresolved.
Unknown Initiation
Where available information cannot establish whether Resolution governance has legitimately begun, the state should remain Unknown.
Therefore:
Unknown Resolution Initiation ≠ No Resolution Initiation.
Uncertain Initiation
Where multiple plausible interpretations exist, uncertainty should remain explicit.
Therefore:
Uncertain Initiation ≠ Authority to Select a Preferred Resolution Pathway.
Disputed Initiation
Subjects may dispute whether a Resolution process has legitimately commenced.
The dispute should remain explicit.
Therefore:
Disputed Initiation ≠ Governed Resolution Initiation.
Initiation Effective Time
LRSIM should identify when Resolution Initiation becomes effective.
Trigger Time vs Initiation Time
The triggering event and effective initiation may occur at different times.
Therefore:
Resolution Trigger Time ≠ Resolution Initiation Effective Time by default.
Proposal Time vs Initiation Time
A proposal may precede actual initiation.
Therefore:
Resolution Proposal Time ≠ Resolution Initiation Time by default.
Recording Time vs Initiation Time
The process may be recorded after it began.
Therefore:
Resolution Recording Time ≠ Resolution Initiation Effective Time by default.
Retrospective Initiation Identification
A process may be identified retrospectively as having entered Resolution governance earlier.
The later identification should not overwrite the actual effective time.
Resolution Initiation Evidence
Evidence may support:
the Trigger, Resolution Object, Subject participation, Basis, Scope, conditions, authority, or effective time.
Evidence does not itself establish Resolution.
Evidence vs Initiation
Evidence that payment or performance occurred does not automatically prove that a complete Resolution process was initiated.
Therefore:
Evidence of Resolution-Relevant Event ≠ Resolution Initiation by default.
Initiation Rationale
LRSIM should preserve why the active Liability has been routed into Resolution governance.
The rationale should identify the relevant Trigger, Object, Basis, Scope, and pathway.
Rationale vs Outcome
The rationale for initiation does not establish the final Resolution outcome.
Therefore:
Resolution Initiation Rationale ≠ Liability Resolution Determination.
Initiation Provenance
The module should preserve sufficient provenance to reconstruct:
the active Liability structure, Trigger, Resolution Object, Subjects, Relationship, Basis, Scope, Boundary, conditions, authority, time, and supporting inputs.
Multiple Initiation Events
One Liability Relationship may receive multiple Resolution-Relevant Events.
Those events should not automatically create multiple Resolution processes.
Therefore:
Multiple Resolution-Relevant Events ≠ Multiple Resolution Processes by default.
Duplicate Initiation Records
Different systems may record the same initiation.
Duplicate records should not create artificial Resolution processes.
Therefore:
Multiple Initiation Records ≠ Multiple Resolution Initiations by default.
Conflicting Initiation Records
Where records disagree on whether, when, or how Resolution began, the conflict should remain explicit.
Therefore:
Conflicting Initiation Records ≠ One Governed Initiation by default.
Initiation Change
A Resolution Initiation Structure may change before subsequent Resolution governance is complete.
Changes may concern:
Scope, Subjects, Object, pathway, conditions, authority, or dependencies.
Initiation Expansion
A Resolution process may legitimately expand to additional Liability requirements.
The expansion should be explicit and historically preserved.
Therefore:
Resolution Scope Expansion ≠ Original Resolution Scope.
Initiation Contraction
A Resolution process may be narrowed.
Excluded Liability requirements should remain active unless independently resolved.
Initiation Withdrawal
A Resolution process may be withdrawn or cease before Resolution.
Withdrawal should not be represented as Resolution.
Therefore:
Resolution Initiation Withdrawal ≠ Liability Resolution.
Initiation Supersession
A later Resolution process may supersede an earlier initiation structure.
The earlier structure should remain historically reconstructable.
Therefore:
Initiation Supersession ≠ Historical Deletion.
Primary Liability Preservation
Entering Resolution governance should not alter the underlying Liability merely because Resolution has begun.
Therefore:
Resolution Initiation ≠ Primary Liability Redetermination.
Liability Scope Preservation
Resolution Initiation should not silently alter established Liability Scope.
Therefore:
Resolution Scope ≠ Revised Liability Scope.
Liability Allocation Preservation
Initiation should not silently reallocate Liability among Subjects.
Therefore:
Resolution Initiation ≠ Liability Reallocation.
Transfer & Recourse Preservation
Where Transfer, Sharing, or Recourse structures exist, LRSIM should preserve them unless the Resolution process explicitly and legitimately affects them.
No Automatic Network Resolution
Initiating Resolution for one Relationship should not alter unrelated network Relationships.
Therefore:
Local Resolution Initiation ≠ Liability Network Resolution.
Historical Integrity
The pre-initiation Liability state should remain reconstructable after Resolution governance begins.
Therefore:
Resolution Initiation ≠ Historical Rewrite.
Upstream Re-Entry
If initiation reveals a material defect in an earlier LIGA™ governance space, governance should return to the earliest materially affected space.
The canonical rule is:
Re-enter the earliest materially affected governance space.
Targeted Reassessment
The governing principle is:
Reassess what materially changed. Preserve what remains valid.
Re-Entry Integrity
Re-entry should preserve the fact that Resolution Initiation occurred and why reassessment became necessary.
Therefore:
Re-entry must not rewrite history.
Automated Resolution Initiation
AI or automated systems may assist with:
detecting payment, detecting performance, identifying Settlement proposals, mapping Resolution Objects, identifying affected Relationships, classifying pathways, tracking conditions, and detecting conflicts.
Automation should not independently convert a Resolution-Relevant Event into authoritative Resolution.
Therefore:
Automated Resolution Initiation Classification ≠ Authoritative Liability Resolution.
Governed Liability Resolution Initiation Structure
The principal output of LRSIM is:
Governed Liability Resolution Initiation Structure
It should identify, where applicable:
Liability Origin, active Liability Relationship, Resolution Initiation identity, Resolution-Relevant Event, Resolution Trigger, Resolution Object, affected Subjects, Subject roles, affected Relationships, preliminary Resolution Basis, Resolution Scope, Resolution Boundary, remaining active Liability, Resolution pathway, conditions, dependencies, authority, initiation State, effective time, payment association, performance association, Settlement association, Discharge relevance, release or waiver relevance, Extinguishment relevance, uncertainty, disputes, conflicts, rationale, provenance, and initiation history.
Meaning of the Output
A Governed Liability Resolution Initiation Structure means that an active Liability requirement has been sufficiently identified and bounded for Resolution governance to proceed.
It does not mean that Liability has been satisfied, settled, discharged, resolved, or finalized.
Therefore:
Governed Liability Resolution Initiation Structure ≠ Governed Liability Resolution & Discharge State.
Downstream Handoff
Depending on the applicable pathway, the Governed Liability Resolution Initiation Structure may proceed through:
LSATM — Liability Satisfaction Module
LSETM — Liability Settlement Module
and subsequently:
LDCHM — Liability Discharge Module
before final LRDS verification under:
LRVFM — Liability Resolution Verification Module
The exact pathway depends on the governed Resolution structure.
Minimum Implementation Framework
A conforming implementation of LRSIM must provide exactly the following eight capabilities:
Active Liability & Resolution-Relevant Event Association
Capability to associate Resolution Initiation with an established active Liability structure and identify the event, process, condition, proposal, or mechanism creating Resolution relevance.
Resolution Object, Subject & Relationship Identification
Capability to identify exactly what Liability requirement enters Resolution governance, which Subjects participate, their relevant roles, and which Liability Relationships are affected.
Resolution Basis, Scope & Boundary Governance
Capability to establish the preliminary Resolution Basis, define complete or partial Resolution Scope, distinguish affected from unaffected Liability, and prevent unbounded Resolution interpretation.
Resolution Pathway, Condition & Dependency Governance
Capability to identify Satisfaction, Settlement, Discharge, Extinguishment, release, waiver, or other applicable pathways and represent their conditions and dependencies without treating pathway identification as Resolution.
Authority, State & Temporal Governance
Capability to identify Resolution Initiation authority, authority boundaries, initiation State, Trigger time, effective time, proposal time, recording time, and relevant uncertainty or dispute.
Payment, Performance, Settlement & External-Event Distinction Governance
Capability to distinguish Resolution Initiation from payment, performance, Settlement proposal, Claim closure, Harm Resolution, operational termination, administrative closure, and other Resolution-relevant events.
Historical Integrity, Provenance, Change & Re-Entry Governance
Capability to preserve pre-initiation Liability state, initiation rationale, provenance, expansion, contraction, withdrawal, supersession, conflict, and targeted upstream re-entry without rewriting history.
LRDS Resolution Pathway Handoff Governance
Capability to produce a Governed Liability Resolution Initiation Structure sufficiently explicit, bounded, traceable, and historically preserved for subsequent Satisfaction, Settlement, Discharge, and Resolution Verification governance.
Governance Logic
The canonical LRSIM governance logic is:
Active Liability Structure
↓
Identify Resolution-Relevant Event
↓
Identify Resolution Trigger
↓
Identify Resolution Object
↓
Identify Affected Liability Relationship
↓
Identify Subjects & Roles
↓
Identify Preliminary Resolution Basis
↓
Establish Resolution Scope
↓
Establish Resolution Boundary
↓
Identify Remaining Active Liability
↓
Identify Resolution Pathway
↓
Identify Conditions & Dependencies
↓ Identify Authority where required ↓
Establish Initiation State & Effective Time
↓
Distinguish Payment / Performance / Settlement / Closure from Resolution
↓
Preserve Uncertainty / Dispute / Conflict
↓
Preserve Rationale / Provenance / History
↓
Governed Liability Resolution Initiation Structure
↓
Handoff to Subsequent LRDS Governance
Governance Outputs
LRSIM may produce:
Resolution Initiation Identity
Resolution-Relevant Event Record
Resolution Trigger
Resolution Object
Affected Liability Relationship
Affected Subject Structure
Subject Role Structure
Preliminary Resolution Basis
Resolution Scope
Resolution Boundary
Remaining Active Liability Record
Resolution Pathway
Resolution Condition Structure
Resolution Dependency Structure
Resolution Authority Association
Resolution Initiation State
Resolution Initiation Effective Time
Payment Association
Performance Association
Settlement Association
Discharge-Relevance Record
Extinguishment-Relevance Record
Release / Waiver Relevance Record
Initiation Conflict Record
Initiation Rationale
Initiation Provenance
Initiation History
The principal output is:
Governed Liability Resolution Initiation Structure
Critical Distinctions
LRSIM preserves the following distinctions:
Resolution-Relevant Event ≠ Liability Resolution Resolution Initiation ≠ Liability Resolution Resolution Trigger ≠ Resolution Completion Liability Basis ≠ Resolution Initiation Basis by default Resolution Object ≠ Liability Object by default Partial Resolution Object ≠ Complete Liability Relationship One Resolution Process ≠ One Resolution Object by default Liability-Bearing Subject ≠ Resolution-Performing Subject by default Paying Subject ≠ Liability-Bearing Subject by default Performing Subject ≠ Liability-Bearing Subject by default Multi-Subject Resolution Initiation ≠ Uniform Subject Resolution Resolution Initiation for Relationship A ≠ Resolution Initiation for Relationship B Primary Liability Resolution Initiation ≠ Recourse Resolution Initiation Local Resolution Initiation ≠ Liability Network Resolution Initiation Resolution Scope ≠ Liability Scope by default Resolution Initiation ≠ Authority to Resolve Unbounded Liability Resolution Initiation ≠ Suspension of All Liability by default Resolution Pathway ≠ Resolution Outcome One Liability Requirement ≠ One Resolution Pathway by default Conditional Resolution Initiation ≠ Conditional Resolution Completion Resolution Dependency ≠ Resolution Condition Satisfaction Resolution Initiation Authority ≠ Resolution Completion Authority by default Local Resolution Authority ≠ Universal Liability Resolution Authority Payment ≠ Liability Resolution by default Partial Payment ≠ Complete Resolution Third-Party Payment ≠ Liability Transfer by default Performance ≠ Satisfaction by default Settlement Proposal ≠ Settlement Settlement Agreement ≠ Liability Resolution by default Settlement Initiation ≠ Admission of Liability Discharge-Relevant Event ≠ Liability Discharge Claim Closure ≠ Liability Resolution Harm Resolution ≠ Liability Resolution Operational Termination ≠ Liability Resolution Contract Termination ≠ Liability Resolution Administrative Closure ≠ Verified Liability Resolution Resolution Proposal ≠ Resolution Initiation by default Unknown Resolution Initiation ≠ No Resolution Initiation Uncertain Initiation ≠ Authority to Select a Preferred Resolution Pathway Disputed Initiation ≠ Governed Resolution Initiation Resolution Trigger Time ≠ Resolution Initiation Effective Time by default Resolution Proposal Time ≠ Resolution Initiation Time by default Resolution Recording Time ≠ Resolution Initiation Effective Time by default Evidence of Resolution-Relevant Event ≠ Resolution Initiation by default Resolution Initiation Rationale ≠ Liability Resolution Determination Multiple Resolution-Relevant Events ≠ Multiple Resolution Processes by default Multiple Initiation Records ≠ Multiple Resolution Initiations by default Conflicting Initiation Records ≠ One Governed Initiation by default Resolution Scope Expansion ≠ Original Resolution Scope Resolution Initiation Withdrawal ≠ Liability Resolution Initiation Supersession ≠ Historical Deletion Resolution Initiation ≠ Primary Liability Redetermination Resolution Scope ≠ Revised Liability Scope Resolution Initiation ≠ Liability Reallocation Local Resolution Initiation ≠ Liability Network Resolution Resolution Initiation ≠ Historical Rewrite Automated Resolution Initiation Classification ≠ Authoritative Liability Resolution Governed Liability Resolution Initiation Structure ≠ Governed Liability Resolution & Discharge State
Cross-Architecture Boundary
LRSIM may receive Resolution-relevant inputs from adjacent OOF® architectures.
ORA™ may establish payment, performance, termination, or other Operational Reality.
HAGA™ may establish Harm Recovery or Harm Resolution.
AGA™ may establish Responsibility, Accountability, Authority, or completion of a responsibility.
ADIT® may provide evidence and auditability.
VALIDOS™ may validate Resolution-relevant inputs.
OBIDENITY® may provide identity, authority, succession, and provenance.
VFM® may establish economic or Value Flow events.
AIG® and ASGA™ may establish AI or autonomous-system operational events.
These inputs may create Resolution relevance.
They do not establish Liability Resolution.
The canonical interoperability principle is:
An external event may trigger Liability Resolution governance, but LRSIM governs whether an active Liability requirement has legitimately entered that governance process and what exactly the process concerns.
Canonical Boundary
LRSIM begins when an active Liability structure encounters an event, process, proposal, condition, agreement, performance, payment, authoritative action, or other mechanism capable of creating Resolution relevance.
LRSIM governs:
Resolution-Relevant Events, Resolution Triggers, Resolution Objects, affected Subjects, Subject roles, affected Liability Relationships, preliminary Resolution Basis, Scope, Boundary, remaining active Liability, Resolution pathways, conditions, dependencies, authority, initiation States, effective time, payment relevance, performance relevance, Settlement relevance, Discharge relevance, Extinguishment relevance, release or waiver relevance, uncertainty, disputes, conflicts, rationale, provenance, history, and downstream routing.
LRSIM does not independently determine:
Satisfaction, Settlement completion, Discharge, complete Resolution, or Finality.
LRSIM ends when the Resolution process is sufficiently represented as a:
Governed Liability Resolution Initiation Structure
for subsequent LRDS governance.
Use Case 1 — Payment Initiates Partial Resolution
Governance
An established Liability Relationship contains a monetary requirement and a separate corrective performance requirement.
The monetary amount is paid.
LRSIM identifies the payment as a Resolution-Relevant Event and establishes the monetary requirement as the Resolution Object.
The corrective performance requirement remains outside the Resolution Boundary and continues as active Liability.
The payment therefore initiates Resolution governance for one component without treating the complete Liability Relationship as resolved.
Use Case 2 — Settlement Proposal Across Multiple Liability
Relationships
Two Subjects participate in several Liability Relationships arising from the same wider matter.
A Settlement proposal is made concerning only one of those Relationships.
LRSIM identifies:
the proposal, the exact affected Liability Relationship, the participating Subjects, the proposed Resolution Scope, the preliminary Settlement pathway, and the Relationships remaining outside the process.
The Settlement proposal does not initiate network-wide Resolution and does not constitute an admission of Liability.
Canonical Closing Statement
Resolution must begin somewhere, but beginning Resolution is not the same as achieving it.
A payment may trigger the process.
Performance may trigger the process.
A Settlement proposal may trigger the process.
A Discharge mechanism may trigger the process.
But the Liability remains governed until the applicable Resolution requirements are actually satisfied.
LRSIM establishes the boundary between active Liability and the process intended to resolve it without confusing that boundary with the outcome.
Resolution-Relevant Event ≠ Liability Resolution.
Define what enters Resolution governance before deciding whether anything has actually been resolved.