LBIM — Liability Basis Identification Module
LBIM — Liability Basis Identification 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 Identification
Module ID: LIGA-LBS-LBIM-001
Origin ID: OOF.CM.LIGA.03.01.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 Identification Module (LBIM) governs how one or more potential foundations under which Liability may exist in relation to a Governed Liability Object are recognized, identified, differentiated, sourced, and recorded as Liability Basis Candidates without prematurely classifying or qualifying the Basis, determining its complete applicability, evaluating Liability Conditions, establishing Liability-Relevant Connection, attaching Liability, or determining Liability.
LBIM governs the transition:
Governed Liability Object → Potential Basis Recognition → Basis Candidate Identification → Basis Source Association → Identified Liability Basis Candidate Its foundational distinction is:
A reason to consider Liability ≠ an identified Liability Basis by default.
Operational Role
The operational role of LBIM is:
to identify the explicit foundation or foundations under which Liability may potentially exist before those foundations are classified, qualified, or used in subsequent Liability governance.
The Governed Liability Object establishes:
What is the matter?
LBIM begins the next question:
What potential foundation makes Liability relevant to that matter?
LBIM does not answer whether the proposed Basis is ultimately valid or applicable.
It establishes what Basis is being proposed for governance.
Position in the Parent Standard Flow
The internal LBS progression is:
Basis Identification → Basis Classification → Basis Qualification → Basis Association → Basis Continuity LBIM governs:
Basis Identification
Its principal input is:
Governed Liability Object
Its principal output is:
Identified Liability Basis Candidate
Its canonical handoff is:
Identified Liability Basis Candidate → Liability Basis Classification
Central Operational Question
What identifiable foundation could potentially support Liability in relation to this Governed Liability Object?
This question must be answered without converting the identified foundation into an established Liability conclusion.
Governed Space
LBIM governs the identification layer of Liability Basis governance.
Its governed space includes:
Potential Basis Recognition, Basis Candidate Identification, Basis Origin Identification, Basis Source Identification, Basis Reference, Basis Candidate Differentiation, Multiple Basis Candidate Identification, Basis Assertion Identification, Basis Uncertainty, Basis Identification Conflict, Basis Candidate Traceability, and Identification Sufficiency.
LBIM does not determine whether a Basis is legally valid, fully applicable, satisfied, or sufficient for Liability Attachment.
Input Governance
The canonical LBIM input is:
Governed Liability Object
The Object should already be sufficiently:
identified, bounded, distinguished, represented, and continuous.
LBIM uses that Object as the reference matter against which potential Liability foundations are identified.
A defect in Object governance should not be hidden by creating a Basis around an unstable Object.
Where material Object uncertainty affects Basis identification, that dependency should remain explicit.
Potential Basis Recognition
A Liability Basis Candidate begins when a foundation is recognized as potentially relevant to Liability.
Potential foundations may arise from:
legal rules, statutory structures, regulatory requirements, contractual arrangements, governed obligations, ownership structures, control structures, undertakings, warranties, guarantees, status-based structures, or other recognized Liability-relevant foundations.
Recognition establishes relevance for examination.
It does not establish validity.
Therefore:
Potential Basis Recognition ≠ Governed Liability Basis.
Basis Candidate Identification
Once a potential foundation is recognized, it must be represented as an identifiable Basis Candidate.
The candidate should be sufficiently distinguishable from other possible Bases.
Identification should establish, where available:
a Basis Candidate reference, the proposed foundation, its known source, its apparent origin, its relationship to the Governed Liability Object, its current identification state, and material uncertainty.
The purpose is to make the candidate governable.
Basis Candidate Identity
Each materially distinct Basis Candidate should possess a distinguishable governance identity.
This prevents:
different Bases being treated as one, one Basis being duplicated under several labels, and later changes being mistaken for entirely different Bases.
Basis Candidate Identity is methodological.
It does not establish legal validity.
Therefore:
Basis Candidate Identity ≠ Valid Liability Basis.
Basis Origin Identification
LBIM should identify where the proposed Basis originates.
Basis Origin may involve:
an authoritative rule, a contractual undertaking, a governed obligation, an ownership state, a control structure, a guarantee, a warranty, a status, or another identifiable foundation.
The origin should be distinguished from the person or system asserting that the Basis exists.
Therefore:
Basis Origin ≠ Basis Assertion.
Basis Source Identification
Where possible, LBIM should identify the source from which the Basis Candidate derives.
The source may be represented through an appropriate:
document, rule, agreement, record, governed relationship, authoritative instrument, system state, or other source reference.
LBIM identifies the source.
It does not independently prove every fact contained within it.
Source and Evidence
A source may provide evidence concerning a Basis Candidate.
The two concepts must remain distinct.
Therefore:
Basis Source ≠ Evidence by default.
and:
Evidence of a Basis ≠ Liability Basis itself.
ADIT® may govern evidence supporting the source or its interpretation.
LBIM governs identification of the Basis Candidate.
Basis Assertion
A Basis may first enter governance because a:
person, organization, Claim, system, authority, insurer, contractual participant, or another actor asserts that a particular Liability Basis exists.
The assertion should be recorded where material.
But:
Basis Assertion ≠ Basis Identification Completion.
and:
Basis Assertion ≠ Governed Liability Basis.
An assertion triggers examination.
It does not substitute for governance.
Basis Assertion Source and Basis Source
The source of the assertion and the source of the Basis may be different.
For example:
a party may assert a contractual Basis, while the actual Basis source is the contract itself.
Therefore:
Assertion Source ≠ Basis Source.
This distinction prevents a claim about a Basis from being confused with the foundation from which the Basis is supposed to derive.
Object–Basis Candidate Relevance
A potential Basis should be identified in relation to a specific Governed Liability Object.
The initial relationship is:
Governed Liability Object ↔ Liability Basis Candidate
At LBIM stage, this relationship establishes potential relevance only.
It does not establish full applicability.
Therefore:
Basis Candidate Relevance ≠ Basis Applicability.
Object–Basis Candidate Association
LBIM may record a preliminary association between the Object and Basis Candidate so that the candidate remains traceable to the matter that triggered its identification.
However, formal Basis Association is governed later within LBS after classification and qualification.
Therefore:
Preliminary Basis Reference ≠ Governed Object–Basis Association.
Liability-Relevant Fact and Liability Basis
A fact may explain why a Basis should be investigated.
The fact is not necessarily the Basis.
For example:
an injury, system failure, missed action, financial Loss, product defect, or operational event may trigger Basis identification.
Therefore:
Liability-Relevant Fact ≠ Liability Basis by default.
Occurrence and Liability Basis
An occurrence may trigger the Liability inquiry.
It does not itself establish the foundation under which Liability could arise.
Therefore:
Occurrence ≠ Liability Basis.
The occurrence belongs to the relevant Operational Reality.
The Basis explains why Liability may potentially arise in relation to the governed matter.
Harm and Liability Basis
Harm may trigger investigation of a Liability Basis.
But Harm does not itself define the Basis.
Therefore:
Harm ≠ Liability Basis.
A single Harm may be relevant to several different Basis Candidates.
A Basis may also exist in a matter where Harm has not been established.
Loss and Damage
Loss or Damage may be relevant to Basis identification.
They must not automatically be converted into the Basis itself.
Therefore:
Loss ≠ Liability Basis.
Damage ≠ Liability Basis.
Their methodological role depends on the specific Basis and subsequent governance.
Responsibility and Basis Identification
A governed Responsibility structure may indicate that a Liability Basis should be examined.
However:
Responsibility ≠ Liability Basis by default.
Responsibility may be an input.
LBIM must still identify the actual foundation under which Liability could potentially arise.
Accountability and Basis Identification
Accountability may similarly indicate a relevant governance relationship.
But:
Accountability ≠ Liability Basis by default.
A system may be accountable for explaining an action without that accountability itself establishing Liability.
AGA™ governs Accountability.
LIGA™ governs Liability.
Obligation and Basis Identification
An obligation may become a Liability Basis Candidate where the obligation is potentially relevant to the Governed Liability Object.
However:
Obligation ≠ Liability Basis by default.
LBIM identifies the potential relationship.
Later LBS governance determines how the Basis should be classified, qualified, and associated.
Breach and Basis Identification
An alleged breach may cause a Basis Candidate to be identified.
However, breach and Basis remain different concepts.
The Basis may explain why a particular breach would matter for Liability.
Therefore:
Alleged Breach ≠ Liability Basis.
and:
Breach Assertion ≠ Basis Validation.
Fault and Basis Identification
Fault may be relevant under some potential Liability Bases.
It may be irrelevant under others.
LBIM must not assume that every Liability inquiry requires a fault-based foundation.
Therefore:
Fault ≠ Liability Basis.
and:
Absence of Alleged Fault ≠ Absence of a Potential Liability Basis.
Claim and Basis Identification
A Claim may identify or assert one or more proposed Liability Bases.
LBIM may use that assertion as an identification input.
But:
Claimed Basis ≠ Governed Liability Basis.
A Claim may:
misidentify the Basis, omit another Basis, combine several Bases, or assert a Basis that later proves inapplicable.
Liability Basis governance must therefore remain independent from Claim wording.
Multiple Basis Candidates
A Governed Liability Object may generate several Basis Candidates.
The structure may be:
Governed Liability Object → Basis Candidate A + Basis Candidate B + Basis Candidate C LBIM must preserve them separately where their governed meanings differ.
Therefore:
Multiple Basis Candidates ≠ One Basis by default.
Similar Basis Candidates
Two Basis Candidates may initially appear similar.
Similarity may arise from:
shared source, similar wording, related obligations, shared parties, similar consequences, or overlapping governance structures.
Similarity does not establish identity.
Therefore:
Basis Similarity ≠ Basis Identity.
Classification and qualification may later clarify the relationship.
Duplicate Basis Candidates
Different systems or participants may identify the same potential Basis under different references.
LBIM should detect possible duplication.
However, duplicate detection must not merge candidates prematurely.
The relevant question is whether they represent the same governed foundation.
Therefore:
Different Basis Labels ≠ Different Bases by default.
and:
Same Basis Label ≠ Same Basis by default.
Alternative Basis Candidates
A matter may contain alternative potential foundations.
At identification stage, LBIM does not need to determine which alternative will ultimately govern.
It should preserve each materially credible candidate for later classification and qualification.
Therefore:
Alternative Basis Identification ≠ Alternative Basis Selection.
Competing Basis Candidates
Different participants or systems may propose competing explanations of the Liability foundation.
LBIM must preserve those candidates without prematurely selecting one.
A disagreement about the Basis is itself a governance state.
Therefore:
Basis Candidate Conflict ≠ Authority to Select a Basis without further governance.
Basis Candidate Dependency
A Basis Candidate may appear to depend on another foundation.
For example:
a specific obligation may derive from a broader contractual or regulatory structure.
LBIM should preserve the dependency where visible.
However:
Basis Dependency ≠ Basis Identity.
The candidates may require separate governance.
Basis Candidate Hierarchy
Potential Bases may form an initial hierarchy:
Foundational Source → Derived Basis Candidate → Object-Relevant Basis Candidate LBIM may identify this structure where necessary.
It should not treat hierarchy as proof of applicability.
Therefore:
Basis Hierarchy ≠ Basis Applicability.
Temporal Identification
A Basis Candidate must be identifiable in the relevant temporal context where time materially affects the foundation.
LBIM may need to distinguish:
the current Basis source, the Basis source existing at the relevant event, an earlier version, a later amendment, or a superseded structure.
Therefore:
Current Basis Source ≠ Historically Relevant Basis Source by default.
Basis Candidate Status
A Basis Candidate may carry an identification state such as:
Potential
Identified
Uncertain
Disputed
Duplicate Candidate
Competing Candidate
Source Uncertain
Temporally Uncertain
These states describe identification status.
They do not establish Liability.
Basis Identification Uncertainty
Uncertainty may concern:
whether a Basis exists, which source creates it, whether two candidates are identical, which historical version matters, or how the candidate relates to the Object.
LBIM must preserve uncertainty explicitly.
Therefore:
Basis Identification Uncertainty ≠ Basis Absence.
Unknown Basis
A Liability-relevant matter may exist even when the Basis has not yet been identified.
The correct state may therefore be:
Liability-Relevant Object / Basis Not Yet Identified
rather than:
No Liability Basis Exists.
Therefore:
Unidentified Basis ≠ Nonexistent Basis.
This distinction prevents premature closure of the Liability inquiry.
Basis Identification Assumptions
Identification may initially depend on assumptions.
Material assumptions should be recorded.
Examples may concern:
the identity of a source, the applicable version, the existence of an obligation, the authority of an instrument, or the relationship between the Basis Candidate and the Object.
Therefore:
Basis Identification Assumption ≠ Established Basis Fact.
Basis Candidate Traceability
Every materially relevant Basis Candidate should remain traceable to:
the Governed Liability Object, the reason it was identified, its proposed origin, its known source, the asserting participant or system where relevant, its identification time, and its current identification state.
Traceability allows later governance to understand why the Basis entered the lifecycle.
Basis Candidate Change
Information concerning a Basis Candidate may change before classification or qualification is completed.
LBIM should preserve material changes to:
source reference, description, origin, Object relevance, or identification status.
Therefore:
Basis Candidate Change ≠ New Basis Candidate by default.
A new candidate is required only where the governed foundation is materially different.
Candidate Correction
An identified Basis Candidate may contain an error.
Correction should preserve:
the earlier representation, the corrected representation, the reason for correction, and the relationship between them.
Therefore:
Basis Candidate Correction ≠ Historical Erasure.
Identification Reassessment
Later information may require Basis identification to be reassessed.
Reassessment may:
confirm the candidate, correct it, separate one candidate into several, consolidate duplicates, identify an additional candidate, or determine that the candidate was misidentified.
The earlier governance state should remain reconstructable.
Therefore:
Basis Identification Reassessment ≠ Historical Rewrite.
Identification Sufficiency
A Basis Candidate is sufficiently identified when later LBS governance can determine:
what potential foundation is being examined, where it appears to originate, what source supports its identification, which Governed Liability Object it concerns, how it differs from other candidates, and what material uncertainty remains.
Identification sufficiency does not require complete classification or qualification.
Therefore:
Identification Sufficiency ≠ Basis Qualification.
Handoff to Basis Classification
When identification is sufficient, LBIM produces:
Identified Liability Basis Candidate
The candidate then proceeds to Liability Basis Classification.
The handoff must preserve:
Basis Candidate Identity, proposed origin, source reference, Object reference, known dependencies, uncertainty, conflicts, and relevant identification history.
The next governance question becomes:
What kind of Liability Basis is this?
Minimum Implementation Framework
A conforming implementation of LBIM must provide at least the following eight capabilities:
Potential Basis Recognition
Capability to recognize when a Governed Liability Object contains or relates to one or more potential foundations requiring Liability Basis governance.
Basis Candidate Identification
Capability to create a distinguishable Liability Basis Candidate without prematurely establishing validity, applicability, Attachment, or Liability.
Basis Origin & Source Identification
Capability to identify and separately represent the proposed origin and source of each Basis Candidate.
Object–Basis Candidate Referencing
Capability to maintain an explicit preliminary relationship between each Basis Candidate and the Governed Liability Object that triggered its identification.
Multiple, Alternative & Competing Candidate Governance
Capability to identify and preserve multiple, alternative, overlapping, dependent, duplicate, or competing Basis Candidates without premature consolidation or selection.
Uncertainty & Assumption Governance
Capability to represent source uncertainty, identity uncertainty, temporal uncertainty, disputed identification, and material assumptions explicitly.
Candidate Traceability, Correction & Reassessment
Capability to preserve candidate origin, identification history, material corrections, changes, and later reassessment without historical erasure.
Identification Sufficiency Determination
Capability to determine whether a Basis Candidate is sufficiently identified for handoff to Liability Basis Classification while preserving unresolved material uncertainty.
Governance Logic
The canonical LBIM governance logic is:
Governed Liability Object
↓ Is there an identifiable potential foundation under which Liability could arise?
If no foundation is yet identifiable:
Preserve Basis-Not-Yet-Identified State
If one or more potential foundations are recognizable:
↓
Recognize Potential Basis
↓
Identify Basis Candidate
↓
Identify Proposed Basis Origin
↓
Identify Basis Source
↓
Associate Candidate with Governed Liability Object
↓ Distinguish Basis Candidate from Harm / Loss / Damage / Claim / Responsibility / Accountability / Obligation /
Breach / Fault / Evidence
↓
Identify Multiple / Alternative / Competing / Dependent / Duplicate Candidates
↓
Record Material Uncertainty and Assumptions
↓
Preserve Candidate Traceability
↓
Assess Identification Sufficiency
If insufficient:
Clarify / Correct / Reassess / Preserve Uncertainty
If sufficient:
↓
Identified Liability Basis Candidate
↓
Handoff to Liability Basis Classification
Governance Outputs
LBIM may produce:
Potential Basis Recognition Record
Liability Basis Candidate
Basis Candidate Identity
Basis Origin Reference
Basis Source Reference
Basis Assertion Reference
Object–Basis Candidate Reference
Multiple Basis Candidate Structure
Alternative Basis Candidate Structure
Competing Basis Candidate Structure
Dependent Basis Candidate Reference
Potential Duplicate Basis Reference
Basis Candidate Temporal Reference
Basis Identification Uncertainty State
Basis Identification Assumption Record
Basis Identification Conflict State
Basis Candidate Change Record
Basis Candidate Correction Record
Basis Identification Reassessment Record
Basis Identification Sufficiency State
The principal output is:
Identified Liability Basis Candidate
Critical Distinctions
LBIM preserves the following distinctions:
A reason to consider Liability ≠ an identified Liability Basis by default Potential Basis Recognition ≠ Governed Liability Basis Basis Candidate Identity ≠ Valid Liability Basis Basis Origin ≠ Basis Assertion Basis Source ≠ Evidence by default Evidence of a Basis ≠ Liability Basis itself Assertion Source ≠ Basis Source Basis Candidate Relevance ≠ Basis Applicability Preliminary Basis Reference ≠ Governed Object–Basis Association Liability-Relevant Fact ≠ Liability Basis by default Occurrence ≠ Liability Basis Harm ≠ Liability Basis Loss ≠ Liability Basis Damage ≠ Liability Basis Responsibility ≠ Liability Basis by default Accountability ≠ Liability Basis by default Obligation ≠ Liability Basis by default Alleged Breach ≠ Liability Basis Fault ≠ Liability Basis Claimed Basis ≠ Governed Liability Basis Multiple Basis Candidates ≠ One Basis by default Basis Similarity ≠ Basis Identity Different Basis Labels ≠ Different Bases by default Same Basis Label ≠ Same Basis by default Alternative Basis Identification ≠ Alternative Basis Selection Basis Dependency ≠ Basis Identity Basis Hierarchy ≠ Basis Applicability Current Basis Source ≠ Historically Relevant Basis Source by default Basis Identification Uncertainty ≠ Basis Absence Unidentified Basis ≠ Nonexistent Basis Basis Identification Assumption ≠ Established Basis Fact Basis Candidate Change ≠ New Basis Candidate by default Basis Candidate Correction ≠ Historical Erasure Basis Identification Reassessment ≠ Historical Rewrite Identification Sufficiency ≠ Basis Qualification
Cross-Architecture Boundary
LBIM may receive information from other OOF® architectures when that information reveals a potential Liability Basis.
GOA™ may expose Authority, Delegation, Scope, or governance structures that require Basis examination.
ORA™ may expose Operational Reality that triggers Basis identification.
AGA™ may expose Responsibility, Accountability, Authority, or Attribution structures relevant to a potential Basis.
HAGA™ may expose Harm that causes one or more Liability Bases to be examined.
ADIT® may provide evidence relevant to Basis Origin or Source.
VALIDOS™ may validate Basis-relevant information.
OBIDENITY® may provide Identity, Ownership, Authority, Permission, Provenance, or Transfer states relevant to Basis identification.
Other OOF® architectures may likewise supply governed states that reveal a potential Liability foundation.
The canonical boundary is:
An external governed state may trigger Liability Basis identification without becoming the Liability Basis itself.
Governance ownership of the external state remains with its originating architecture.
Canonical Boundary
LBIM begins with a:
Governed Liability Object
and the question:
What identifiable foundation could potentially support Liability in relation to this Object?
LBIM governs:
Potential Basis Recognition, Basis Candidate Identification, Basis Origin Identification, Basis Source Identification, Basis Candidate Identity, Basis Candidate Differentiation, preliminary Object–Basis referencing, Multiple Basis Candidates, Alternative Basis Candidates, Competing Basis Candidates, Basis Identification Uncertainty, Basis Identification Assumptions, Candidate Traceability, Correction, Reassessment, and Identification Sufficiency.
LBIM does not determine:
complete Basis Classification, Basis Qualification, final Basis Applicability, formal Object–Basis Association, Liability Relationships, Liability Conditions, Condition Satisfaction, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Liability State, Resolution, Discharge, or Finality.
LBIM ends when an:
Identified Liability Basis Candidate
is sufficiently established for Liability Basis Classification.
Use Case 1 — AI-Enabled Operational Matter
A Governed Liability Object concerns a specific AI-enabled operational action.
The action produced an outcome that creates Liability relevance.
Several potential foundations are identified:
a contractual obligation, a regulatory requirement, and an organizational undertaking.
LBIM records each as a separate Liability Basis Candidate, identifies its proposed source, links it to the Governed Liability Object, and preserves uncertainty concerning whether each candidate is actually applicable.
The operational outcome itself is not treated as the Liability Basis.
The candidates proceed separately to Basis Classification.
Use Case 2 — Industrial Equipment Matter
A Governed Liability Object concerns an industrial equipment matter following an operational failure.
A maintenance agreement, an ownership-related obligation, and a separate governed requirement are identified as possible foundations for Liability.
LBIM distinguishes the three Basis Candidates and preserves their respective sources and Object references.
The existence of equipment Damage does not become a substitute for identifying the Liability Basis.
Likewise, an allegation that maintenance was inadequate does not establish the Basis.
Each identified candidate proceeds to subsequent LBS governance independently.
Canonical Closing Statement
Liability Basis governance cannot begin with an unnamed assumption that some reason for Liability must exist.
The potential foundation must first become an identifiable governed object of analysis.
LBIM makes that foundation explicit without deciding whether it will ultimately support Liability.
A consequence may trigger the question of Liability. It does not identify the Basis by itself.
Identify the foundation before qualifying what it can support.