LBAM — Liability Basis Association Module
LBAM — Liability Basis Association Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Basis Standard (LBS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Basis Association
Module ID: LIGA-LBS-LBAM-001
Origin ID: OOF.CM.LIGA.03.04.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 21 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 Basis Association Module (LBAM) governs how one or more Qualified Liability Bases are formally associated with the Governed Liability Object to which they may apply, including the identity, structure, multiplicity, dependency, temporal state, uncertainty, and lifecycle status of each Object–Basis association, so that subsequent Liability governance proceeds through explicit governed relationships between the matter being evaluated and the foundations under which Liability may potentially exist.
LBAM governs the transition:
Qualified Liability Basis + Governed Liability Object → Association Evaluation → Object–Basis Relationship Formation → Association Structuring → Governed Object–Basis Association Its foundational distinction is:
Liability Basis Association ≠ Liability Attachment.
Operational Role
The operational role of LBAM is:
to establish exactly which Qualified Liability Basis is associated with which Governed Liability Object, in what governed manner, and with what limitations, dependencies, temporal relevance, and uncertainty.
A Basis may be:
identifiable, classified, and qualified without yet being formally associated with the specific Liability Object.
LBAM establishes that association.
Position in the Parent Standard Flow
The internal LBS progression is:
Basis Identification → Basis Classification → Basis Qualification → Basis Association → Basis Continuity LBAM governs:
Basis Association
Its principal inputs are:
Qualified Liability Basis
and:
Governed Liability Object
Its principal output is:
Governed Object–Basis Association
Its canonical handoff is:
Governed Object–Basis Association → Liability Basis Continuity
Central Operational Question
How does this Qualified Liability Basis relate to this Governed Liability Object, and what exactly is the governed structure of that association?
The question concerns Basis association.
It does not ask whether Liability attaches.
Governed Space
LBAM governs:
Object–Basis Association Identification, Association Formation, Association Identity, Association Scope, Association Boundary, Association Type, Association State, Association Multiplicity, Multiple Basis Associations, Multiple Object Associations, Alternative Associations, Concurrent Associations, Dependent Associations, Conditional Associations, Association Hierarchy, Association Network, Temporal Association, Association Uncertainty, Association Conflict, Association Change, Association Correction, Association Reassessment, and Association Sufficiency.
LBAM does not determine Liability itself.
Association Inputs
LBAM requires two principal governed inputs:
Governed Liability Object
and:
Qualified Liability Basis
The Object identifies what matter is being governed.
The Basis identifies the qualified foundation under which Liability may potentially exist.
LBAM governs the relationship between them.
The canonical structure is:
Governed Liability Object ↔ Qualified Liability Basis
Why Association Is Necessary
A Liability Basis may exist and be qualified without applying to every Liability Object.
Likewise, a Liability Object may exist without every qualified Basis being relevant to it.
Therefore:
Qualified Liability Basis ≠ Object-Associated Liability Basis by default.
Formal association prevents general Liability foundations from being applied indiscriminately to unrelated governed matters.
Object–Basis Association Formation
Association is formed when governance establishes that a Qualified Liability Basis has sufficient governed relevance to a specific Governed Liability Object to proceed into subsequent Liability governance.
The resulting structure is:
Object A ↔ Basis A
This does not establish Liability.
It establishes the governed foundation through which Liability may subsequently be evaluated in relation to Object A.
Association Identity
Every materially distinct Object–Basis association should be independently identifiable.
Association Identity should preserve:
the Object Identity, the Basis Identity, the association state, the association origin, and material association history.
Therefore:
Object Identity + Basis Identity ≠ Association Identity by itself.
The association is a distinct governance relationship.
Association Origin
LBAM should preserve when and why the Object–Basis association entered formal governance.
Association Origin may arise from:
Basis qualification, new Object information, new Basis information, reassessment, a newly discovered dependency, or another governed trigger.
Association Origin must remain distinguishable from Object Origin and Basis Origin.
Therefore:
Object Origin ≠ Basis Origin ≠ Association Origin.
Association Relevance
Association requires more than conceptual similarity.
The Basis must have sufficient governed relevance to the specific Object.
Therefore:
Basis Similarity ≠ Object–Basis Association.
and:
General Basis Relevance ≠ Object-Specific Association.
Association Scope
An Object–Basis association may concern:
the entire Liability Object, a defined component, a defined state, a defined period, or another explicitly bounded part of the Object.
Association Scope determines which part of the governed Object the Basis association concerns.
Therefore:
Association Scope ≠ Liability Scope.
Liability Scope is governed later by LSAS.
Association Boundary
The Association Boundary identifies where the Object–Basis association applies and where it does not.
This boundary must remain distinguishable from:
Liability Object Boundary, Liability Context Boundary, Liability Basis identity, and later Liability Scope.
Therefore:
Association Boundary ≠ Object Boundary.
and:
Association Boundary ≠ Liability Scope.
Whole-Object Association
A Basis may be associated with the entire Governed Liability Object.
The structure is:
Object A ↔ Basis A / Whole Object
Whole-Object Association should only be used where the Basis is materially relevant across the complete governed Object.
It must not be assumed merely because the Basis relates to one Object component.
Partial-Object Association
A Basis may apply only to a defined part of the Liability Object.
The structure may be:
Object A / Component 2 ↔ Basis A
The remaining Object components may require:
another Basis, no Basis, or later evaluation.
Therefore:
Partial Object Association ≠ Whole Object Association.
Component-Level Association
A Composite Liability Object may contain several components with different Basis relationships.
LBAM should permit:
Component A → Basis 1 Component B → Basis 2 Component C → Basis 1 + Basis 3 without forcing all components into one uniform Basis structure.
Therefore:
Shared Liability Object ≠ Shared Basis Association by default.
One Object and Multiple Bases
One Liability Object may be associated with multiple Qualified Liability Bases.
The structure may be:
Object A → Basis 1 + Basis 2 + Basis 3 Each association should remain separately identifiable.
Therefore:
One Liability Object ≠ One Liability Basis Association.
One Basis and Multiple Objects
One Qualified Liability Basis may be associated with several Liability Objects.
The structure may be:
Basis A → Object 1 + Object 2 + Object 3 Each association must be evaluated independently where the Objects differ materially.
Therefore:
Basis Association with Object A ≠ Basis Association with Object B.
Multiple Object–Basis Associations
Complex Liability matters may produce many Object–Basis associations.
For example:
Object A ↔ Basis 1
Object A ↔ Basis 2
Object B ↔ Basis 1
Object C ↔ Basis 3
LBAM should preserve these as a structured association network rather than collapsing them into one generalized Liability foundation.
Alternative Basis Associations
Alternative Bases may each be associated with the same Object.
The structure may be:
Object A ↔ Basis 1 OR Basis 2
The alternatives remain distinct.
Therefore:
Alternative Association ≠ Basis Selection.
LBAM records the association structure without deciding which Basis will ultimately support Liability.
Concurrent Basis Associations
Several Bases may be concurrently associated with the same Object.
The structure may be:
Object A ↔ Basis 1 + Basis 2
Each Basis retains independent identity.
Therefore:
Concurrent Association ≠ Basis Merger.
Dependent Basis Associations
A Basis association may depend on another Basis association.
For example:
Object A ↔ Basis 1
may enable:
Object A ↔ Basis 2
where Basis 2 derives from or depends on Basis 1.
The dependency must remain explicit.
Therefore:
Association Dependency ≠ Association Identity.
Conditional Association
An Object–Basis association may be established conditionally where a material association requirement remains unresolved.
Possible state:
Conditionally Associated
The unresolved condition must remain explicit.
This must not be confused with Liability Conditions governed by LCOS.
Therefore:
Conditional Basis Association ≠ Liability Condition Satisfaction.
Association Hierarchy
Object–Basis associations may form hierarchical structures.
A possible structure is:
Object → Foundational Basis → Derived Basis or:
Composite Object → Component → Specific Basis LBAM may represent such hierarchies where necessary.
Hierarchy does not establish Liability priority.
Therefore:
Association Hierarchy ≠ Liability Priority.
Association Network
Complex matters may require an Object–Basis Association Network.
Such a network may contain:
multiple Objects, multiple Bases, alternative associations, concurrent associations, dependent associations, partial associations, and conditional associations.
The network enables subsequent governance to determine which Basis relates to which governed matter.
Association Network and Liability Network
An Object–Basis Association Network is not the same as the later Liability Network.
The former maps:
Objects ↔ Bases
The latter may contain multiple Liability Subjects and Liability Relationships after subsequent governance.
Therefore:
Object–Basis Association Network ≠ Liability Network.
This distinction prevents early Basis structures from predetermining later Liability Relationships.
Association and Liability Subject
LBAM associates Bases with Liability Objects.
It does not yet establish complete Liability Subject structures.
Therefore:
Object–Basis Association ≠ Basis–Subject Attachment.
LRS governs Liability Subjects and Relationships.
A Basis associated with an Object does not automatically identify who bears Liability.
Association and Liability Relationship
An Object–Basis association may later participate in one or more Liability Relationships.
However:
Object–Basis Association ≠ Liability Relationship.
LRS must independently establish the relevant Subjects and Relationships.
Association and Liability Conditions
Association establishes that a qualified Basis is methodologically linked to the Object.
It does not establish that the Conditions required under that Basis are satisfied.
Therefore:
Basis Association ≠ Liability Condition Satisfaction.
LCOS owns Liability Conditions governance.
Association and Liability Connection
An Object–Basis association does not establish the required connection among:
Subject, Object, conditions, conduct, and other Liability-relevant inputs.
Therefore:
Basis Association ≠ Liability-Relevant Connection.
LCNS governs that later relationship.
Association and Liability Attachment
This is a critical LIGA™ distinction:
Liability Basis Association ≠ Liability Attachment.
A Basis may be correctly associated with the Object while Liability ultimately does not attach to any Subject.
Attachment belongs to Liability Determination governance.
Association and Liability Determination
A valid Object–Basis association means:
this qualified Basis is relevant to this governed Object for further Liability governance.
It does not mean:
Liability exists.
Therefore:
Governed Object–Basis Association ≠ Liability Determination.
Temporal Association
An association may be valid only during a particular period or lifecycle state.
LBAM should preserve:
association start, association end where applicable, relevant Basis version, relevant Object state, and material temporal changes.
Therefore:
Current Object–Basis Association ≠ Historical Object–Basis Association by default.
Historical Association
A Basis may have been associated with an Object historically even if that association no longer applies.
Historical associations may remain relevant to:
earlier Liability states, later reconstruction, audit, reassessment, or dispute.
Therefore:
Inactive Association ≠ Historically Irrelevant Association.
Association Change
An Object–Basis association may change because:
the Object changes, the Basis changes, the association scope changes, a dependency changes, new information emerges, or an earlier association is reassessed.
Therefore:
Association Change ≠ New Liability Object or New Liability Basis by default.
The identities of Object, Basis, and association must be evaluated separately.
Association Expansion
A Basis association may expand from part of an Object to a larger governed portion.
The expansion must be recorded.
Therefore:
Association Expansion ≠ Liability Scope Expansion.
The former concerns Basis relevance.
The latter concerns established Liability and belongs later in the architecture.
Association Contraction
A Basis association may contract when the Basis is determined to relate to a narrower portion of the Object.
The previous state must remain reconstructable.
Therefore:
Association Contraction ≠ Historical Association Erasure.
Association Removal
An association may later be removed where governance determines that the Basis is not sufficiently related to the Object.
Removal should preserve:
the prior association, the reason for removal, the effective state, and the relevant governance inputs.
Therefore:
Association Removal ≠ Association Never Existed.
Association Correction
An Object–Basis association may have been recorded incorrectly.
Correction should preserve:
the incorrect association state, the corrected state, the reason for correction, and the relationship between them.
Therefore:
Association Correction ≠ Historical Erasure.
Association Reassessment
Later information may require reassessment of:
whether the Basis remains associated, which part of the Object is affected, whether multiple associations should be separated, or whether previously separate associations should be consolidated.
Therefore:
Association Reassessment ≠ New Liability Basis by default.
Reassessment should preserve association lineage.
Association Uncertainty
An association may remain uncertain.
Possible states may include:
Associated
Provisionally Associated
Conditionally Associated
Association Uncertain
Association Disputed
Association Inactive
Association Removed
Material uncertainty must remain visible to downstream governance.
Association Conflict
Different governed inputs may support conflicting Object–Basis associations.
For example:
one interpretation may associate a Basis with the entire Object, while another associates it only with one component.
LBAM must preserve the conflict where it cannot yet be legitimately resolved.
Therefore:
Association Conflict ≠ Authority to Manufacture Association Certainty.
Association Assumptions
An association may depend on assumptions concerning:
Object state, Basis state, temporal relevance, component identity, dependency, or another governed input.
Material assumptions should be explicit.
Therefore:
Association Assumption ≠ Established Association Fact.
Cross-System Association
The same Object–Basis association may be represented across:
internal governance systems, legal systems, insurance systems, claims systems, AI systems, audit systems, or other environments.
Technical duplication does not create additional methodological associations by default.
Therefore:
Multiple Association Records ≠ Multiple Object–Basis Associations by default.
Association Traceability
Every material Object–Basis association should remain traceable to:
the Object Identity, Basis Identity, association origin, association state, association scope, relevant temporal state, dependencies, uncertainty, changes, and reassessment history.
Traceability allows later governance to reconstruct why a particular Basis was used in relation to a particular Object.
Association Sufficiency
Association is sufficiently governed when subsequent LIGA™ governance can determine:
which Object is involved, which Basis is involved, whether the association concerns the whole Object or part of it, whether the association is alternative, concurrent, dependent, or conditional, which temporal state applies, what uncertainty exists, and how the association originated and changed.
Therefore:
Association Sufficiency ≠ Liability Determination Readiness.
The next LBS function must still preserve Basis continuity before final handoff from the Parent Standard.
Minimum Implementation Framework
A conforming implementation of LBAM must provide at least the following eight capabilities:
Object–Basis Association Formation
Capability to establish an explicit governed association between a Qualified Liability Basis and a Governed Liability Object without converting association into Liability Attachment.
Association Scope & Boundary Governance
Capability to determine whether the Basis association concerns the whole Object, a component, a state, a period, or another bounded portion while preserving the distinction from Liability Scope.
Multiple & Cross-Object Association Governance
Capability to govern one Object associated with multiple Bases and one Basis associated with multiple Objects without collapsing distinct associations.
Alternative, Concurrent & Dependent Association Governance
Capability to preserve alternative, concurrent, dependent, hierarchical, and conditional Object–Basis associations as distinct governed structures.
Temporal & Historical Association Governance
Capability to preserve current and historical association states, relevant Basis versions, Object states, and material temporal changes.
Association Uncertainty, Assumption & Conflict Governance
Capability to represent provisional or conditional associations, material assumptions, uncertainty, competing association interpretations, and unresolved conflicts.
Association Change, Correction & Reassessment
Capability to govern association expansion, contraction, removal, correction, reassessment, and lineage without historical erasure.
Association Sufficiency Determination
Capability to determine whether the Object–Basis association is sufficiently governed for Liability Basis Continuity and subsequent handoff into Liability Relationship governance.
Governance Logic
The canonical LBAM governance logic is:
Governed Liability Object + Qualified Liability Basis
↓
Confirm Object Identity
↓
Confirm Basis Identity and Qualification State
↓
Evaluate Object-Specific Basis Relevance
↓
Form Object–Basis Association Candidate
↓
Determine Association Scope and Boundary
↓ Whole Object or Partial Object?
↓
Identify Multiple / Alternative / Concurrent / Dependent / Conditional Associations
↓
Determine Relevant Temporal Association State
↓
Identify Association Dependencies
↓
Identify Material Assumptions
↓
Identify Association Uncertainty or Conflict
↓ Can the Object–Basis relationship be sufficiently governed?
If no:
Clarify / Reassess / Preserve Uncertainty
If yes:
↓
Governed Object–Basis Association
↓
Preserve Association History and Traceability
↓
Handoff to Liability Basis Continuity
Governance Outputs
LBAM may produce:
Object–Basis Association Identity
Object–Basis Association Record
Association Origin Record
Association Scope
Association Boundary
Whole-Object Association
Partial-Object Association
Component-Level Association
Multiple Basis Association Structure
Multiple Object Association Structure
Alternative Association Structure
Concurrent Association Structure
Dependent Association Structure
Conditional Association State
Association Hierarchy
Object–Basis Association Network
Temporal Association State
Historical Association Record
Association Uncertainty State
Association Assumption Record
Association Conflict State
Association Expansion Record
Association Contraction Record
Association Removal Record
Association Correction Record
Association Reassessment Record
Association Traceability Record
Association Sufficiency State
The principal output is:
Governed Object–Basis Association
Critical Distinctions
LBAM preserves the following distinctions:
Liability Basis Association ≠ Liability Attachment Qualified Liability Basis ≠ Object-Associated Liability Basis by default Object Identity + Basis Identity ≠ Association Identity by itself Object Origin ≠ Basis Origin ≠ Association Origin Basis Similarity ≠ Object–Basis Association General Basis Relevance ≠ Object-Specific Association Association Scope ≠ Liability Scope Association Boundary ≠ Object Boundary Association Boundary ≠ Liability Scope Partial Object Association ≠ Whole Object Association Shared Liability Object ≠ Shared Basis Association by default One Liability Object ≠ One Liability Basis Association Basis Association with Object A ≠ Basis Association with Object B Alternative Association ≠ Basis Selection Concurrent Association ≠ Basis Merger Association Dependency ≠ Association Identity Conditional Basis Association ≠ Liability Condition Satisfaction Association Hierarchy ≠ Liability Priority Object–Basis Association Network ≠ Liability Network Object–Basis Association ≠ Basis–Subject Attachment Object–Basis Association ≠ Liability Relationship Basis Association ≠ Liability Condition Satisfaction Basis Association ≠ Liability-Relevant Connection Governed Object–Basis Association ≠ Liability Determination Current Object–Basis Association ≠ Historical Object–Basis Association by default Inactive Association ≠ Historically Irrelevant Association Association Change ≠ New Liability Object or New Liability Basis by default Association Expansion ≠ Liability Scope Expansion Association Contraction ≠ Historical Association Erasure Association Removal ≠ Association Never Existed Association Correction ≠ Historical Erasure Association Reassessment ≠ New Liability Basis by default Association Conflict ≠ Authority to Manufacture Association Certainty Association Assumption ≠ Established Association Fact Multiple Association Records ≠ Multiple Object–Basis Associations by default Association Sufficiency ≠ Liability Determination Readiness
Cross-Architecture Boundary
LBAM may use governed relationships from other OOF® architectures where they materially support Object–Basis association.
GOA™ may provide Authority, Scope, Delegation, or governance boundaries relevant to an association.
ORA™ may provide Operational Reality connecting the governed Object to the environment in which the Basis is relevant.
AGA™ may provide Responsibility, Accountability, Authority, or Attribution structures that inform association without establishing Liability.
HAGA™ may provide a governed Harm state where a particular Basis association depends upon Harm.
ADIT® may provide evidence supporting Object identity, Basis identity, association scope, temporal state, or association history.
VALIDOS™ may validate association-relevant inputs.
OBIDENITY® may provide Identity, Ownership, Authority, Permission, Provenance, Transfer, or Continuity structures relevant to association.
Other OOF® architectures may provide governed objects or states relevant to establishing an Object–Basis association.
The governing principle is:
A relationship governed elsewhere may support an Object–Basis association without becoming a Liability Relationship or transferring governance ownership to LIGA™.
Canonical Boundary
LBAM begins with:
Governed Liability Object + Qualified Liability Basis
and asks:
How does this Qualified Liability Basis relate to this Governed Liability Object?
LBAM governs:
Association Formation, Association Identity, Association Origin, Association Scope, Association Boundary, Whole-Object Association, Partial-Object Association, Component-Level Association, Multiple Associations, Cross-Object Associations, Alternative Associations, Concurrent Associations, Dependent Associations, Conditional Associations, Association Hierarchy, Association Network, Temporal Association, Historical Association, Association Uncertainty, Association Assumptions, Association Conflict, Association Change, Association Expansion, Association Contraction, Association Removal, Association Correction, Association Reassessment, Association Traceability, and Association Sufficiency.
LBAM does not determine:
Liability Subjects, complete Liability Relationships, Liability Conditions, Condition Satisfaction, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Liability State, Transfer, Recourse, Resolution, Discharge, or Finality.
LBAM ends when a:
Governed Object–Basis Association
is sufficiently established for Liability Basis Continuity.
Use Case 1 — AI Service with Multiple Liability Bases
A Governed Liability Object concerns a specific AI-enabled operational process.
Two Qualified Liability Bases exist:
a contractual Basis, and a regulatory Basis.
LBAM establishes separate Object–Basis associations for both.
The contractual Basis applies to the complete governed service interaction, while the regulatory Basis is associated only with a defined component of the Object.
The two associations remain separately identifiable and traceable.
Neither association determines whether the provider, deployer, operator, or another Subject is liable.
That requires later Liability Relationship, Conditions, Connection, and Determination governance.
Use Case 2 — Industrial Equipment with Component-Level
Association
A Governed Liability Object concerns an industrial equipment matter containing several governed components.
A Qualified maintenance-related Basis is relevant only to one component, while an ownership-related Basis is associated with the broader Object.
LBAM represents:
Component A ↔ Maintenance Basis
and:
Complete Object ↔ Ownership-Related Basis
without treating the two association scopes as identical.
Later Liability governance can therefore evaluate each foundation against the correct governed matter rather than applying every Basis indiscriminately to the entire Object.
Canonical Closing Statement
A qualified Liability Basis is not automatically a foundation for every governed matter.
The relationship between the Basis and the Liability Object must itself be explicit, bounded, traceable, and governable.
LBAM establishes that relationship without turning relevance into Liability.
Association establishes which Basis belongs to which Liability inquiry. It does not establish that Liability attaches.
Connect the Basis to the Object before connecting Liability to a Subject.