LSATM — Liability Satisfaction Module
LSATM — Liability Satisfaction 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 Satisfaction
Module ID: LIGA-LRDS-LSATM-001
Origin ID: OOF.CM.LIGA.11.02.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 Satisfaction Module (LSATM) governs whether, to what extent, and under what conditions an identified Liability requirement has been fulfilled through payment, performance, delivery, correction, restoration, reimbursement, transfer of an agreed object, completion of a required act, or another applicable form of performance.
LSATM begins with a Governed Liability Resolution Initiation Structure containing a Liability requirement for which Satisfaction is relevant.
It identifies the Satisfaction Object, applicable Satisfaction Requirements, responsible and performing Subjects, required and actual performance, Satisfaction Scope, conditions, timing, dependencies, deficiencies, excesses, disputes, and remaining unsatisfied Liability.
It determines the governed Satisfaction State of the defined requirement without automatically treating payment or performance as Satisfaction and without treating Satisfaction as complete Liability Resolution.
Its principal output is:
Governed Liability Satisfaction Structure
Its foundational distinction is:
Performance ≠ Satisfaction by default.
Operational Role
The operational role of LSATM is:
to determine whether actual payment, performance, or another governed act fulfills the specific Liability requirement to which it relates, to what extent that requirement has been satisfied, and what remains unsatisfied.
LSATM governs fulfillment.
It does not independently establish Settlement, Discharge, Finality, or complete Liability Resolution.
Position in the LRDS Internal Flow
The internal LRDS progression is:
Liability Resolution Initiation → Liability Satisfaction → Liability Settlement → Liability Discharge → Liability
Resolution Verification
LSATM governs:
Liability Satisfaction
Its principal input is:
Governed Liability Resolution Initiation Structure
Its principal output is:
Governed Liability Satisfaction Structure
Where Settlement is applicable, the structure may proceed to:
LSETM — Liability Settlement Module
Where the relevant requirements are otherwise ready for Discharge assessment, the structure may proceed toward:
LDCHM — Liability Discharge Module
Central Operational Question
Has the defined Liability requirement actually been fulfilled, by whom, through what performance, to what extent, under which conditions, and what part of the requirement remains unsatisfied?
Satisfaction Object
Every Satisfaction assessment requires an explicit Satisfaction Object.
The Satisfaction Object is the defined Liability requirement whose fulfillment is being assessed.
It may concern:
payment, performance, delivery, correction, repair, replacement, restoration, reimbursement, return, transfer, completion of a required act, or another defined obligation.
Satisfaction Object vs Liability Object
The Satisfaction Object is not necessarily the original Liability Object.
Therefore:
Satisfaction Object ≠ Liability Object by default.
Satisfaction Object vs Resolution Object
A Resolution Object may contain several Satisfaction Objects.
Therefore:
Resolution Object ≠ Satisfaction Object by default.
Satisfaction Requirement
A Satisfaction Requirement defines what must be fulfilled for the relevant Liability requirement to be considered satisfied.
The requirement should be sufficiently explicit to evaluate actual performance against it.
Required Performance
Required Performance describes what the applicable Liability structure requires.
It should identify, where relevant:
required act, required amount, required quality, required quantity, required recipient, required timing, required location, required method, and required conditions.
Actual Performance
Actual Performance represents what occurred in Operational Reality.
It should remain distinct from Required Performance.
Therefore:
Required Performance ≠ Actual Performance.
Performance Comparison
Satisfaction requires comparison between:
Required Performance
and
Actual Performance
rather than merely confirming that some action occurred.
Performance ≠ Satisfaction
Performance alone does not establish that the applicable requirement has been fulfilled.
Therefore:
Performance ≠ Satisfaction by default.
Payment as Performance
Payment is one form of performance where a monetary requirement exists.
It should be evaluated against the actual monetary requirement.
Therefore:
Payment ≠ Satisfaction by default.
Payment Amount
LSATM should distinguish:
required amount, paid amount, credited amount, accepted amount, remaining amount, and disputed amount where relevant.
Full Payment
Payment of the complete required amount may support complete monetary Satisfaction where all applicable conditions are fulfilled.
It does not automatically resolve other Liability requirements.
Therefore:
Full Payment ≠ Complete Liability Resolution by default.
Partial Payment
A partial payment may satisfy part of a monetary requirement.
Therefore:
Partial Payment ≠ Complete Satisfaction.
Excess Payment
Payment exceeding the required amount should not automatically enlarge the Satisfaction Scope.
Therefore:
Excess Payment ≠ Additional Liability Satisfaction by default.
Excess payment may create separate reimbursement or Recourse relevance.
Third-Party Payment
A third party may perform a payment.
LSATM should distinguish:
who owed the requirement, who paid, whose requirement was satisfied, and whether any secondary Relationship arises.
Therefore:
Paying Party ≠ Liability-Bearing Party by default.
Payment Acceptance
Receipt of payment and Satisfaction of the underlying requirement are related but distinct.
Therefore:
Payment Receipt ≠ Satisfaction by default.
Non-Monetary Performance
Liability Satisfaction may occur through non-monetary performance.
Examples may include:
repair, replacement, delivery, restoration, return, corrective action, completion of a defined service, or another required act.
Performance Quality
Where quality is part of the Satisfaction Requirement, mere completion of an act is insufficient.
Therefore:
Performance Completion ≠ Satisfactory Performance by default.
Performance Quantity
Where quantity matters, LSATM should compare required and actual quantities.
Performance Method
Where a particular method is required, performance through another method should not automatically be treated as Satisfaction.
Performance Recipient
Performance should reach the required recipient or governed destination where that is part of the requirement.
Therefore:
Performance Occurrence ≠ Required Delivery by default.
Performance Location
Where location materially affects fulfillment, it should be included in the Satisfaction assessment.
Performance Timing
Where timing forms part of the requirement, performance should be assessed against the applicable time condition.
Late Performance
Late performance may still satisfy all or part of the underlying requirement depending on the governed structure.
Lateness should remain explicit.
Therefore:
Late Performance ≠ No Satisfaction by default.
Early Performance
Early performance may require acceptance or other conditions before it constitutes Satisfaction.
Therefore:
Early Performance ≠ Satisfaction by default.
Conditional Performance
Performance may depend upon conditions before it becomes Satisfaction.
Therefore:
Conditional Performance ≠ Completed Satisfaction.
Satisfaction Conditions
Satisfaction Conditions may concern:
amount, quality, quantity, timing, recipient, method, authority, acceptance, verification, dependency, or another applicable requirement.
Condition State
A Satisfaction Condition may be:
Satisfied, Unsatisfied, Partially Satisfied, Pending, Unknown, Uncertain, or Disputed.
Satisfaction Scope
LSATM should establish the exact Scope of Satisfaction.
Satisfaction may be:
complete, partial, Subject-specific, requirement-specific, Relationship-specific, conditional, or otherwise bounded.
Satisfaction Scope vs Liability Scope
Satisfaction of a bounded requirement does not necessarily satisfy the complete Liability Scope.
Therefore:
Satisfaction Scope ≠ Liability Scope by default.
Complete Satisfaction
Complete Satisfaction means the entire defined Satisfaction Object has been fulfilled under the applicable requirements and conditions.
It does not automatically establish complete Liability Resolution.
Therefore:
Complete Satisfaction ≠ Liability Resolution by default.
Partial Satisfaction
Partial Satisfaction means only part of the Satisfaction Object has been fulfilled.
The satisfied and remaining portions should be explicit.
Unsatisfied Portion
Any requirement not fulfilled should remain represented as an Unsatisfied Portion.
Therefore:
Partial Satisfaction ≠ Elimination of Remaining Liability.
Multiple Satisfaction Objects
One Liability Relationship may contain multiple independently satisfiable requirements.
Each should retain separate identity.
Therefore:
One Liability Relationship ≠ One Satisfaction Object by default.
Mixed Satisfaction State
A Liability Relationship may simultaneously contain:
Satisfied requirements, Partially Satisfied requirements, Unsatisfied requirements, Pending requirements, and Disputed requirements.
Therefore:
One Liability Relationship ≠ One Uniform Satisfaction State.
Satisfaction Subject
LSATM should identify the Subject whose Liability requirement is being satisfied.
Performing Subject
The Subject actually performing the requirement may differ from the Satisfaction Subject.
Therefore:
Performing Subject ≠ Satisfaction Subject by default.
Receiving Subject
Where applicable, the Subject receiving performance should be explicit.
Multi-Subject Satisfaction
A single performance may affect requirements associated with several Subjects.
The effect on each Subject should remain separately governed.
Therefore:
One Performance ≠ Uniform Satisfaction Across Subjects.
Shared Liability Satisfaction
Where Liability is shared, each Subject may satisfy its applicable requirement independently.
Therefore:
Shared Liability ≠ Shared Satisfaction State.
Satisfaction and Liability Allocation
LSATM should preserve upstream Liability Allocation.
Satisfaction does not itself rewrite the allocation.
Therefore:
Satisfaction ≠ Liability Reallocation.
Satisfaction and Liability Sharing
Actual performance may differ from the governed Sharing structure.
The difference may create Recourse relevance but should not rewrite Sharing history.
Therefore:
Performance Distribution ≠ Liability Sharing by default.
Satisfaction and Transfer
A transferred requirement may be satisfied by the Transferee or another Subject.
Satisfaction should remain linked to the applicable Transfer structure.
Satisfaction and Recourse
Performance by one Subject may create Recourse relevance against another Subject.
Satisfaction and Recourse remain separate.
Therefore:
Satisfaction ≠ Recourse.
Excess Performance and Recourse
Where a Subject performs beyond its governed requirement, excess performance may create Recourse relevance.
Therefore:
Excess Performance ≠ Established Recourse.
Satisfaction Basis
The Satisfaction assessment should remain connected to the governed requirement defining what constitutes fulfillment.
Satisfaction Authority
Where acceptance or confirmation requires authority, LSATM should identify the relevant authority and its Scope.
Acceptance
Some Satisfaction structures may require acceptance by an authorized Subject or mechanism.
Acceptance should remain distinct from performance itself.
Therefore:
Performance ≠ Acceptance.
Acceptance vs Satisfaction
Acceptance may support Satisfaction but does not automatically establish it where other requirements remain unmet.
Therefore:
Acceptance ≠ Satisfaction by default.
Acceptance Authority
The authority to accept one performance should not automatically extend to unrelated Liability requirements.
Therefore:
Local Acceptance Authority ≠ Universal Satisfaction Authority.
Satisfaction State
LSATM may represent Satisfaction States such as:
Not Performed, Performance Initiated, Partially Performed, Performed, Partially Satisfied, Satisfied, Conditionally Satisfied, Pending Verification, Rejected, Unknown, Uncertain, Disputed, Superseded, or another explicitly governed state.
These are methodological states, not universal legal classifications.
Performed vs Satisfied State
A requirement may be marked Performed while Satisfaction remains Pending Verification.
Therefore:
Performed ≠ Satisfied by default.
Conditionally Satisfied State
A requirement may be fulfilled subject to an unresolved condition.
Therefore:
Conditionally Satisfied ≠ Unconditionally Satisfied.
Unknown Satisfaction
Where available information cannot establish whether the requirement was fulfilled, the state should remain Unknown.
Therefore:
Unknown Satisfaction ≠ Unsatisfied by assumption.
Uncertain Satisfaction
Where several materially plausible interpretations remain, uncertainty should be preserved.
Therefore:
Uncertain Satisfaction ≠ Authority to Select a Preferred Satisfaction State.
Disputed Satisfaction
Subjects may dispute whether performance satisfied the requirement.
The dispute should remain explicit.
Therefore:
Disputed Satisfaction ≠ Governed Satisfaction.
Satisfaction Effective Time
LSATM should identify when Satisfaction becomes effective where materially relevant.
Performance Time vs Satisfaction Time
Performance may occur before Satisfaction becomes effective.
Therefore:
Performance Time ≠ Satisfaction Effective Time by default.
Payment Time vs Satisfaction Time
Payment execution, receipt, clearance, acceptance, and Satisfaction may occur at different times.
Therefore:
Payment Time ≠ Satisfaction Effective Time by default.
Recording Time vs Satisfaction Time
Satisfaction may be recorded after it became effective.
Therefore:
Satisfaction Recording Time ≠ Satisfaction Effective Time by default.
Retrospective Satisfaction Identification
A Satisfaction state may be identified retrospectively.
The later identification should not overwrite the actual governed effective time.
Satisfaction Dependency
Satisfaction may depend upon:
another performance, payment clearance, acceptance, verification, another Subject, another Liability Relationship, or another governed condition.
Dependencies should remain explicit.
Dependency Failure
Failure of a required dependency may prevent complete Satisfaction.
Therefore:
Performance Completion + Failed Required Dependency ≠ Complete Satisfaction.
Satisfaction Verification
LSATM should verify Actual Performance against Required Performance and applicable Satisfaction Conditions.
Verification Object
Verification should identify exactly which requirement and performance are being compared.
Verification Sufficiency
Generic evidence that “something was done” is insufficient where the Satisfaction Requirement is more specific.
Therefore:
Evidence of Performance ≠ Evidence of Complete Satisfaction by default.
Payment Verification
Payment verification may consider:
amount, recipient, currency or value unit where relevant, timing, status, reversal, conditions, and applicable reference.
Performance Verification
Non-monetary performance verification may consider:
completion, quality, quantity, recipient, method, location, timing, and conditions.
Satisfaction Evidence
Evidence supports Satisfaction assessment.
Evidence does not itself create Satisfaction.
Therefore:
Evidence of Performance ≠ Satisfaction.
Satisfaction Rationale
The rationale for a Satisfaction State should explain how Actual Performance compares with the applicable Satisfaction Requirement.
Therefore:
Satisfaction State ≠ Satisfaction Rationale.
Satisfaction Provenance
LSATM should preserve sufficient provenance to reconstruct:
the Liability requirement, Satisfaction Object, Required Performance, Actual Performance, Subjects, conditions, Scope, authority, evidence, State, effective time, and rationale.
Performance Failure
Where performance does not meet the Satisfaction Requirement, the deficiency should remain explicit.
Performance Deficiency
A deficiency may concern:
amount, quality, quantity, timing, recipient, method, location, condition, or another requirement.
Deficient Performance
Deficient performance may produce Partial Satisfaction, Unsatisfied status, dispute, or another governed State.
It should not be forced into a binary satisfied/unsatisfied representation where the structure is more complex.
Performance Rejection
Where performance is legitimately rejected, the rejection Basis and authority should remain explicit.
Therefore:
Performance Rejection ≠ Absence of Performance.
Corrective Performance
A deficient performance may be followed by corrective performance.
Both the original and corrective performance should remain historically preserved.
Repeated Performance
Multiple attempts to satisfy the same requirement should remain distinguishable.
Therefore:
Multiple Performance Events ≠ Multiple Liability Requirements by default.
Duplicate Performance Records
Multiple records may represent the same performance.
Therefore:
Multiple Performance Records ≠ Multiple Performances by default.
Conflicting Performance Records
Where records conflict concerning whether or how performance occurred, the conflict should remain explicit.
Therefore:
Conflicting Performance Records ≠ Governed Satisfaction by default.
Reversed Payment
A payment may later be reversed, cancelled, recalled, or otherwise cease to provide the expected performance.
The Satisfaction State should be reassessed where materially affected.
Therefore:
Recorded Payment ≠ Permanent Satisfaction.
Reversed Performance Effect
Where an earlier performance loses its operative effect, the historical performance should remain recorded while the current Satisfaction State changes.
Satisfaction Change
A Satisfaction State may change through:
additional performance, corrective performance, payment reversal, condition failure, new evidence, verification, or another materially relevant event.
Satisfaction Correction
An incorrectly recorded Satisfaction State may be corrected.
The prior record and correction should remain reconstructable.
Therefore:
Satisfaction Correction ≠ Historical Erasure.
Satisfaction Reassessment
A previously valid Satisfaction assessment may require reassessment when circumstances materially change.
Therefore:
Satisfaction Reassessment ≠ Satisfaction Correction.
Satisfaction Supersession
A later Satisfaction assessment may supersede an earlier one.
The earlier assessment should remain historically preserved.
Therefore:
Satisfaction Supersession ≠ Historical Deletion.
Satisfaction History
LSATM should preserve:
required performance, performance attempts, payments, partial fulfillment, deficiencies, corrections, verification, State changes, and final Satisfaction assessment.
Therefore:
Current Satisfaction State ≠ Complete Satisfaction History.
Satisfaction vs Settlement
Satisfaction may occur independently of Settlement.
Settlement may also define future Satisfaction requirements.
Therefore:
Satisfaction ≠ Settlement.
Settlement Performance
Where Settlement creates performance requirements, LSATM may govern whether those requirements have actually been satisfied.
Therefore:
Settlement Agreement ≠ Settlement Satisfaction.
Satisfaction vs Discharge
Satisfaction may support Discharge.
It does not automatically establish Discharge.
Therefore:
Satisfaction ≠ Discharge by default.
Satisfaction vs Resolution
Satisfaction of the relevant requirement may support Liability Resolution.
It does not automatically establish Resolution of the complete Liability Relationship.
Therefore:
Satisfaction ≠ Liability Resolution by default.
Satisfaction vs Finality
Even complete Satisfaction does not establish Liability Finality.
Therefore:
Complete Satisfaction ≠ Liability Finality.
Local Satisfaction
Satisfaction of one Liability requirement should not automatically satisfy another.
Therefore:
Local Satisfaction ≠ Network-Wide Satisfaction.
Primary Liability Satisfaction
A primary Liability requirement may be satisfied while a Recourse Relationship remains active.
Therefore:
Primary Liability Satisfaction ≠ Recourse Satisfaction.
Recourse Satisfaction
A Recourse requirement may be satisfied independently of primary Liability.
Its Satisfaction State should remain Relationship-specific.
Network Satisfaction
A Liability Network may contain multiple Satisfaction States simultaneously.
Therefore:
One Liability Network ≠ One Uniform Satisfaction State.
Claim Payment vs Satisfaction
A Claim payment may satisfy a Liability-related requirement where the applicable structure establishes that relationship.
It should not be assumed automatically.
Therefore:
Claim Payment ≠ Liability Satisfaction by default.
Harm Recovery vs Satisfaction
Recovery from Harm does not itself satisfy Liability.
Therefore:
Harm Recovery ≠ Liability Satisfaction.
Responsibility Performance vs Satisfaction
Completion of a Responsibility under another governance architecture may provide relevant performance evidence.
It does not automatically establish Liability Satisfaction.
Therefore:
Responsibility Performance ≠ Liability Satisfaction by default.
Operational Completion vs Satisfaction
Completion of an operational task may not fulfill the relevant Liability requirement.
Therefore:
Operational Completion ≠ Liability Satisfaction.
Automated Satisfaction Assessment
AI or automated systems may assist with:
payment reconciliation, performance comparison, condition tracking, deficiency detection, timing analysis, duplicate detection, and Satisfaction classification.
Automation must preserve uncertainty and authority boundaries.
Therefore:
Automated Satisfaction Assessment ≠ Authoritative Liability Satisfaction by default.
Upstream Re-Entry
Where Satisfaction governance reveals a material defect in an earlier Liability governance space, the matter should reenter 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.
Historical Integrity of Re-Entry
Re-entry should preserve prior Satisfaction assessments and the information available at the time.
Therefore:
Re-entry must not rewrite history.
Governed Liability Satisfaction Structure
The principal output of LSATM is:
Governed Liability Satisfaction Structure
It should identify, where applicable:
Liability Origin, Liability Relationship, Resolution Object, Satisfaction Object, Satisfaction Requirement, Required Performance, Actual Performance, Satisfaction Subject, Performing Subject, Paying Subject, Receiving Subject, payment amount, performance characteristics, Satisfaction Scope, satisfied portion, unsatisfied portion, conditions, dependencies, acceptance, authority, Satisfaction State, effective time, verification status, deficiencies, excess performance, Transfer association, Sharing association, Recourse relevance, uncertainty, disputes, conflicts, rationale, provenance, and Satisfaction history.
Meaning of the Output
A Governed Liability Satisfaction Structure means that the relevant Liability requirement has been sufficiently assessed to determine whether and to what extent actual performance fulfills the governed Satisfaction Requirement.
It does not establish Settlement.
It does not automatically establish Discharge.
It does not establish complete Liability Resolution.
It does not establish Finality.
Minimum Implementation Framework
A conforming implementation of LSATM must provide exactly the following eight capabilities:
Satisfaction Object & Requirement Identification
Capability to identify the exact Liability requirement being assessed, distinguish the Satisfaction Object from the wider Liability and Resolution Objects, and define Required Performance.
Subject, Role & Actual Performance Governance
Capability to identify Satisfaction Subjects, performing, paying, and receiving Subjects, distinguish their roles, and represent Actual Performance without assuming performance equals Satisfaction.
Payment, Performance Quality, Quantity, Method, Timing & Recipient Governance
Capability to compare Required and Actual Performance across monetary and non-monetary requirements, including amount, quality, quantity, method, recipient, location, timing, and other applicable characteristics.
Satisfaction Scope, Condition, Dependency & State Governance
Capability to establish complete or partial Satisfaction Scope, represent conditions and dependencies, distinguish satisfied and unsatisfied portions, and maintain explicit Satisfaction States.
Acceptance, Verification, Deficiency, Excess & Reversal Governance
Capability to govern acceptance where required, verify performance, identify deficiencies, excess performance, payment or performance reversal, corrective performance, and repeated performance attempts.
Sharing, Transfer, Recourse, Settlement & Network Distinction Governance
Capability to distinguish Satisfaction from Liability Allocation, Sharing, Transfer, Recourse, Settlement, Discharge, and network-wide Resolution while identifying relevant secondary effects.
Historical Integrity, Provenance, Change & Re-Entry Governance
Capability to preserve Satisfaction history, evidence association, rationale, provenance, corrections, reassessments, supersessions, disputes, conflicts, and targeted upstream re-entry without rewriting history.
LRDS Downstream Handoff Governance
Capability to produce a Governed Liability Satisfaction Structure sufficiently explicit, bounded, verified, traceable, and historically preserved for Settlement, Discharge, and Resolution Verification governance.
Governance Logic
The canonical LSATM governance logic is:
Governed Liability Resolution Initiation Structure
↓
Identify Satisfaction Object
↓
Identify Satisfaction Requirement
↓
Identify Required Performance
↓
Identify Satisfaction / Performing / Paying / Receiving Subjects
↓
Observe Actual Performance
↓
Compare Required Performance with Actual Performance
↓
Assess Amount / Quality / Quantity / Method / Recipient / Timing
↓
Assess Conditions & Dependencies
↓ Assess Acceptance where required ↓
Identify Deficiencies / Excess / Reversal
↓
Establish Satisfaction Scope
↓
Identify Satisfied & Unsatisfied Portions
↓
Establish Satisfaction State
↓
Verify Satisfaction
↓
Preserve Uncertainty / Dispute / Conflict
↓
Preserve Rationale / Provenance / History
↓
Governed Liability Satisfaction Structure
↓
Handoff to Subsequent LRDS Governance
Governance Outputs
LSATM may produce:
Satisfaction Object
Satisfaction Requirement
Required Performance Record
Actual Performance Record
Satisfaction Subject Record
Performing Subject Record
Paying Subject Record
Receiving Subject Record
Payment Association
Performance Comparison
Satisfaction Scope
Satisfied Portion
Unsatisfied Portion
Satisfaction Condition Structure
Satisfaction Dependency Structure
Acceptance Record
Performance Deficiency Record
Excess Performance Record
Corrective Performance Record
Payment Reversal Record
Satisfaction State
Satisfaction Effective Time
Satisfaction Verification Record
Recourse-Relevance Record
Satisfaction Conflict Record
Satisfaction Rationale
Satisfaction Provenance
Satisfaction History
The principal output is:
Governed Liability Satisfaction Structure
Critical Distinctions
LSATM preserves the following distinctions:
Performance ≠ Satisfaction by default Satisfaction Object ≠ Liability Object by default Resolution Object ≠ Satisfaction Object by default Required Performance ≠ Actual Performance Payment ≠ Satisfaction by default Full Payment ≠ Complete Liability Resolution by default Partial Payment ≠ Complete Satisfaction Excess Payment ≠ Additional Liability Satisfaction by default Paying Party ≠ Liability-Bearing Party by default Payment Receipt ≠ Satisfaction by default Performance Completion ≠ Satisfactory Performance by default Performance Occurrence ≠ Required Delivery by default Late Performance ≠ No Satisfaction by default Early Performance ≠ Satisfaction by default Conditional Performance ≠ Completed Satisfaction Satisfaction Scope ≠ Liability Scope by default Complete Satisfaction ≠ Liability Resolution by default Partial Satisfaction ≠ Elimination of Remaining Liability One Liability Relationship ≠ One Satisfaction Object by default One Liability Relationship ≠ One Uniform Satisfaction State Performing Subject ≠ Satisfaction Subject by default One Performance ≠ Uniform Satisfaction Across Subjects Shared Liability ≠ Shared Satisfaction State Satisfaction ≠ Liability Reallocation Performance Distribution ≠ Liability Sharing by default Satisfaction ≠ Recourse Excess Performance ≠ Established Recourse Performance ≠ Acceptance Acceptance ≠ Satisfaction by default Local Acceptance Authority ≠ Universal Satisfaction Authority Performed ≠ Satisfied by default Conditionally Satisfied ≠ Unconditionally Satisfied Unknown Satisfaction ≠ Unsatisfied by assumption Uncertain Satisfaction ≠ Authority to Select a Preferred Satisfaction State Disputed Satisfaction ≠ Governed Satisfaction Performance Time ≠ Satisfaction Effective Time by default Payment Time ≠ Satisfaction Effective Time by default Satisfaction Recording Time ≠ Satisfaction Effective Time by default Performance Completion + Failed Required Dependency ≠ Complete Satisfaction Evidence of Performance ≠ Evidence of Complete Satisfaction by default Evidence of Performance ≠ Satisfaction Satisfaction State ≠ Satisfaction Rationale Performance Rejection ≠ Absence of Performance Multiple Performance Events ≠ Multiple Liability Requirements by default Multiple Performance Records ≠ Multiple Performances by default Conflicting Performance Records ≠ Governed Satisfaction by default Recorded Payment ≠ Permanent Satisfaction Satisfaction Correction ≠ Historical Erasure Satisfaction Reassessment ≠ Satisfaction Correction Satisfaction Supersession ≠ Historical Deletion Current Satisfaction State ≠ Complete Satisfaction History Satisfaction ≠ Settlement Settlement Agreement ≠ Settlement Satisfaction Satisfaction ≠ Discharge by default Satisfaction ≠ Liability Resolution by default Complete Satisfaction ≠ Liability Finality Local Satisfaction ≠ Network-Wide Satisfaction Primary Liability Satisfaction ≠ Recourse Satisfaction One Liability Network ≠ One Uniform Satisfaction State Claim Payment ≠ Liability Satisfaction by default Harm Recovery ≠ Liability Satisfaction Responsibility Performance ≠ Liability Satisfaction by default Operational Completion ≠ Liability Satisfaction Automated Satisfaction Assessment ≠ Authoritative Liability Satisfaction by default
Cross-Architecture Boundary
LSATM may use governed inputs from adjacent OOF® architectures.
ORA™ may establish actual payment, delivery, performance, repair, correction, or another Operational Reality.
HAGA™ may establish Harm Recovery without determining Liability Satisfaction.
AGA™ may establish Responsibility performance or Accountability structures.
ADIT® may provide evidence and auditability.
VALIDOS™ may validate Satisfaction-relevant inputs.
OBIDENITY® may establish Subject identity, authority, ownership, provenance, Transfer, or succession.
VFM® may govern economic or Value Flow.
AIG® and ASGA™ may provide AI or autonomous-system performance events.
These inputs may demonstrate that performance occurred.
They do not determine whether the applicable Liability requirement has been satisfied.
The canonical interoperability principle is:
An external system may establish that payment, performance, delivery, correction, or another act occurred; LSATM governs whether that act satisfies the defined Liability requirement.
Canonical Boundary
LSATM begins when a Governed Liability Resolution Initiation Structure contains a Liability requirement for which Satisfaction through payment, performance, delivery, correction, restoration, reimbursement, or another applicable act must be assessed.
LSATM governs:
Satisfaction Objects, Satisfaction Requirements, Required Performance, Actual Performance, Subjects and roles, payment, non-monetary performance, quality, quantity, method, recipient, location, timing, conditions, dependencies, Scope, partial Satisfaction, remaining unsatisfied Liability, acceptance, verification, deficiencies, excess performance, reversal, corrective performance, Satisfaction States, effective time, Transfer and Sharing associations, Recourse relevance, uncertainty, disputes, conflicts, rationale, provenance, history, and downstream handoff.
LSATM does not independently govern:
Settlement formation, Discharge, complete Liability Resolution, or Finality.
LSATM ends when the applicable Satisfaction structure is sufficiently represented as a:
Governed Liability Satisfaction Structure
for continued LRDS governance.
Use Case 1 — Partial Monetary Satisfaction
An established Liability requirement requires payment of a defined monetary amount.
The liable Subject pays only part of that amount.
LSATM compares the Required Performance with the Actual Performance and records:
the required amount, the amount paid, the satisfied portion, the remaining amount, the relevant payment time, and the current Satisfaction State.
The payment therefore creates Partial Satisfaction without representing the complete Liability requirement as satisfied or resolved.
Use Case 2 — Corrective Performance by a Third Party
A Liability requirement requires a defined corrective action.
A third party performs the corrective work on behalf of the Liability-bearing Subject.
LSATM distinguishes:
the Liability-bearing Subject, the Performing Subject, the required corrective action, the Actual Performance, the applicable quality and completion requirements, and whether those requirements were actually fulfilled.
The third party's performance may satisfy the Liability requirement without transferring the underlying Liability to that third party.
Canonical Closing Statement
Liability is not satisfied merely because something was paid or something was done.
The relevant question is whether the required thing was actually fulfilled.
The amount matters.
The quality may matter.
The timing may matter.
The recipient may matter.
The conditions may matter.
And partial fulfillment must remain distinguishable from complete fulfillment.
Performance ≠ Satisfaction by default.
Measure what was required against what was actually fulfilled before treating a Liability requirement as satisfied.