LODM — Liability Object Distinction Module
LODM — Liability Object Distinction Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Object Standard (LOS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Object Distinction
Module ID: LIGA-LOS-LODM-001
Origin ID: OOF.CM.LIGA.02.03.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 20 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 Object Distinction Module (LODM) governs how a Bounded Liability Object is methodologically distinguished from adjacent, related, overlapping, derived, asserted, or externally governed matters so that the object retains a unique governed meaning throughout subsequent Liability governance without being conflated with the occurrence, Harm, Loss, Damage, Claim, obligation, Liability Subject, Liability Basis, Liability Relationship, operational mechanism, evidence, consequence, or another Liability Object.
LODM governs the transition:
Bounded Liability Object → Distinction Analysis → Conceptual & Structural Separation → Distinguished Liability
Object
Its foundational distinction is:
Relationship to a Liability Object ≠ Identity with the Liability Object.
Operational Role
The operational role of LODM is:
to establish what the Liability Object is not, which adjacent governed concepts must remain separate from it, and how those distinctions must be preserved before the object is formally represented.
LOIM identifies the candidate.
LOBM determines its boundary.
LODM establishes its methodological distinction.
Its central operational question is:
What must this Liability Object remain distinct from so that its governed meaning is not altered or collapsed during later Liability governance?
Position in the Parent Standard Flow
The internal LOS progression is:
Object Identification → Object Boundary → Object Distinction → Object Representation → Object Continuity LODM governs:
Object Distinction
Its principal input is:
Bounded Liability Object
Its principal output is:
Distinguished Liability Object
The canonical transition is:
Bounded Liability Object → Object Distinction Governance → Distinguished Liability Object → Object
Representation Governance
Governed Space
LODM governs Liability Object Distinction.
Its governed space includes distinction between the Liability Object and:
Liability Context, occurrence, event, action, omission, operational mechanism, Harm, Loss, Damage, consequence, Claim, obligation, Liability Subject, Liability Basis, Liability Conditions, Liability Relationship, Liability-Relevant Connection, evidence, system, product, environment, and other Liability Objects.
LODM also governs:
conceptual overlap, functional overlap, shared components, semantic ambiguity, object substitution, object conflation, and distinction uncertainty.
Why Object Distinction Is Necessary
A Liability Object may be correctly identified and bounded while still being misunderstood.
For example, a bounded matter may be treated interchangeably as:
the incident, the Harm, the Claim, the defective product, the responsible organization, the alleged breach, or the resulting Loss.
These concepts may interact.
They are not methodologically identical.
Without explicit distinction, later Liability governance may change the meaning of the object without changing its identifier.
LODM prevents that semantic drift.
Object Identity and Conceptual Identity
A Liability Object has a governed Object Identity.
It also requires a stable conceptual meaning.
Two records may refer to the same Object Identity while describing fundamentally different governed concepts.
LODM therefore tests whether the meaning attached to the object remains consistent.
The governing principle is:
Stable Identifier ≠ Stable Meaning by itself.
Object identity must be accompanied by conceptual distinction.
Liability Context and Liability Object
The Liability Context contains the contextual environment necessary to understand the matter.
The Liability Object is the specific matter against which potential Liability is structured.
Therefore:
Liability Context ≠ Liability Object.
A Context may contain multiple Liability Objects.
A Liability Object may depend on Context without becoming identical to it.
Occurrence and Liability Object
An occurrence is something that happened.
A Liability Object is the governed matter in relation to which potential Liability is being considered.
These may coincide in some cases.
They must not be presumed identical.
Therefore:
Occurrence ≠ Liability Object by default.
One occurrence may contain multiple Liability Objects.
One Liability Object may also span multiple occurrences.
Event and Liability Object
An event may provide the operational trigger for Liability governance.
However:
Event ≠ Liability Object by default.
The Object may concern:
an action within the event, a sequence surrounding the event, a product state, an omission, a decision, a service performance, or another matter.
The most visible event must not automatically replace Object Governance.
Action and Liability Object
An action may itself form a Liability Object.
It may also be only one component of a broader object.
Therefore:
Action ≠ Liability Object by default.
Where an action is the object, that identity must be established through LOS governance rather than assumed merely because the action is operationally important.
Omission and Liability Object
An omission may become the governed object.
However, describing a matter as an omission may already imply that some action was expected.
LODM must distinguish:
Observed Absence of Action
from:
Governed Omission
and from:
Liability Object.
Therefore:
Absence of Action ≠ Omission ≠ Liability Object by default.
Whether a duty or requirement existed belongs to later Liability governance where appropriate.
Operational Mechanism and Liability Object
An operational mechanism may produce, enable, or transmit a Liability-relevant matter.
Examples include:
physical contact, mechanical movement, software execution, autonomous action, data transfer, communication, payment, or infrastructure operation.
The mechanism does not automatically become the Liability Object.
Therefore:
Operational Mechanism ≠ Liability Object by default.
This preserves the Cross-Architecture Mechanism Principle.
Harm and Liability Object
Harm is governed by HAGA™.
Liability Object is governed by LOS.
Harm may:
trigger Liability governance, form part of the context, be related to the Object, or contribute to later Liability evaluation.
However:
Harm ≠ Liability Object by default.
and:
Harm Boundary ≠ Liability Object Boundary.
A Harm state may change without changing the Liability Object.
A Liability Object may exist without established Harm.
Loss and Liability Object
Loss may be economically, operationally, strategically, or otherwise relevant.
It may become part of later Liability governance.
But:
Loss ≠ Liability Object by default.
The object may concern the matter from which the Loss allegedly arose rather than the Loss itself.
Loss must not replace Object Identity merely because it becomes the most measurable consequence.
Damage and Liability Object
Damage may be a consequence, state, or other governed matter.
It does not automatically define the Liability Object.
Therefore:
Damage ≠ Liability Object by default.
Where Damage itself is legitimately the Object, that identity must be established explicitly.
Consequence and Liability Object
A consequence may occur downstream from the matter constituting the Liability Object.
Therefore:
Consequence ≠ Liability Object by default.
The fact that a consequence is significant does not make it the object automatically.
Likewise:
Object ≠ Consequence by default.
LODM preserves directionality between the governed matter and its potential consequences without determining causation.
Claim and Liability Object
A Claim is an assertion, demand, or other claim-governed object.
It may refer to a Liability Object.
It does not define that Object automatically.
Therefore:
Claim ≠ Liability Object.
and:
Claimed Object ≠ Canonical Liability Object by default.
A Claim may change while the Liability Object remains the same.
A Claim may close while the Object remains relevant.
A Claim may also combine several Liability Objects.
Obligation and Liability Object
An obligation may provide part of the basis under which Liability may potentially arise.
It may also be relevant to Conditions.
It does not automatically constitute the Liability Object.
Therefore:
Obligation ≠ Liability Object by default.
The object may concern:
performance, non-performance, an action, an omission, a transaction, or another matter related to the obligation.
Liability Subject and Liability Object
A Liability Subject is a participant potentially involved in a Liability Relationship.
The Liability Object is the matter to which that relationship may relate.
Therefore:
Liability Subject ≠ Liability Object.
The distinction prevents an organization, person, or other participant from being treated as the object merely because Liability is being considered in relation to them.
Liability Basis and Liability Object
The Liability Object answers:
What is being governed?
The Liability Basis answers:
On what governed basis can Liability potentially exist?
Therefore:
Liability Object ≠ Liability Basis.
The object must remain stable even where several possible Liability Bases are later considered.
Liability Conditions and Liability Object
Liability Conditions determine what conditions must exist, fail, change, or be satisfied under the applicable Liability Basis.
Those Conditions are not the Object itself.
Therefore:
Liability Conditions ≠ Liability Object.
A change in Conditions does not automatically change Object Identity.
Liability Relationship and Liability Object
A Liability Relationship connects relevant Liability Subjects and other governed elements within a potential Liability structure.
The Object may participate in several such relationships.
Therefore:
Liability Relationship ≠ Liability Object.
and:
One Liability Object ≠ One Liability Relationship.
This distinction is essential for Liability Network governance.
Liability-Relevant Connection and Liability Object
Later LIGA™ governance determines whether a sufficiently governed Liability-Relevant Connection exists.
That connection does not become the Liability Object.
Therefore:
Liability-Relevant Connection ≠ Liability Object.
The Object exists as the governed matter before the Connection question is determined.
Evidence and Liability Object
Evidence may describe, support, contradict, reconstruct, or challenge the Liability Object.
It is not the Object itself.
Therefore:
Evidence ≠ Liability Object.
and:
Evidence Record ≠ Object Reality.
ADIT® governs evidence and auditability.
LOS governs the Liability Object.
System and Liability Object
A system may be involved in the matter without being the Liability Object.
This includes:
AI systems, autonomous systems, software systems, industrial systems, financial systems, and infrastructure systems.
Therefore:
System ≠ Liability Object by default.
The Object may instead concern a specific action, configuration, execution, transaction, state, or another system-related matter.
Product and Liability Object
A product may be the Object.
But it may also merely contain or relate to the Object.
The relevant Object might instead be:
a component, a product state, a modification, an installation, a maintenance intervention, or another product-related matter.
Therefore:
Product ≠ Liability Object by default.
Environment and Liability Object
An environment establishes where the matter exists or operates.
It does not automatically become the Liability Object.
Therefore:
Environment ≠ Liability Object by default.
An Object may span several environments.
One environment may contain several Objects.
Environmental relevance must not collapse into Object Identity.
Liability Object and Another Liability Object
Two Liability Objects may:
overlap, interact, share components, share participants, share evidence, share environments, or arise from the same occurrence.
They remain distinct where their governed meanings differ.
Therefore:
Shared Context ≠ Shared Object Identity.
Shared Component ≠ Shared Object Identity.
Object Interaction ≠ Object Identity.
Similarity and Identity
Two objects may look similar without being the same governed object.
They may involve:
the same product type, the same system, the same process, the same organization, or the same operational pattern.
Therefore:
Object Similarity ≠ Object Identity.
LODM must preserve distinct identities where the underlying governed matters differ.
Shared Origin and Identity
Several Liability Objects may arise from one common origin.
For example, one operational incident may produce several separately governable matters.
Therefore:
Shared Origin ≠ Single Liability Object.
A common origin may create contextual or operational relationships without eliminating object distinction.
Shared Consequence and Identity
Several different Liability Objects may contribute to or relate to the same consequence.
Therefore:
Shared Consequence ≠ Single Liability Object.
Likewise, one Liability Object may relate to several consequences.
Consequence structure must not replace Object structure.
Shared Subject and Identity
Two objects may involve the same potential Liability Subject.
That does not make them one Object.
Therefore:
Shared Liability Subject ≠ Shared Liability Object.
This distinction prevents party-centric governance from collapsing distinct matters into one inquiry.
Shared Evidence and Identity
The same evidence may be relevant to several Liability Objects.
Therefore:
Shared Evidence ≠ Shared Object Identity.
Evidence association does not define Object Identity.
ADIT® may preserve the evidential relationship while LOS preserves the Object distinction.
Semantic Conflation
Semantic conflation occurs where different governed concepts are treated as interchangeable because their ordinarylanguage meanings overlap.
Examples include:
incident = object, damage = object, claim = liability, responsible party = liable party, failure = breach, Harm = Liability.
LODM must identify and prevent such conflation.
The governing principle is:
Terminological Similarity ≠ Methodological Identity.
Object Substitution
Object substitution occurs when the original Liability Object is silently replaced by another matter during later governance.
For example:
a product-related Object may gradually become represented as the resulting Harm, or an action-related Object may become represented as the Claim asserting it.
LODM requires that such changes be explicit.
Therefore:
Related Matter ≠ Permissible Object Substitute.
If the governed object genuinely changes, Object Change governance must occur.
Object Drift
Object Drift occurs when the meaning of a Liability Object changes incrementally without explicit governance.
Object Drift may result from:
new evidence, new terminology, Claim evolution, party arguments, system updates, new consequences, or later interpretations.
LODM must detect and prevent silent Object Drift.
The canonical principle is:
Object Meaning Must Not Change Silently.
Distinction Under Uncertainty
It may initially be uncertain whether two matters are:
the same Object, different Objects, components of one Composite Object, or one Object and one contextual element.
LODM must permit explicit uncertainty.
Possible states may include:
Distinct
Potentially Distinct
Overlapping
Potentially Composite
Distinction Uncertain
Distinction Disputed
Uncertainty must not be hidden through forced classification.
Distinction Reassessment
New information may change how an Object should be distinguished from adjacent matters.
Reassessment may determine that:
two matters previously treated as one should be separated, two matters previously distinguished should form a Composite Object, an alleged Object is actually contextual, or an external governed object should remain separate.
Reassessment must preserve earlier distinction states.
Therefore:
Distinction Reassessment ≠ Historical Erasure.
Distinction Sufficiency
LODM does not require every possible conceptual relationship to be resolved.
The relevant threshold is whether the Liability Object is sufficiently distinguished for stable Object Representation.
A sufficient distinction should establish:
what the Object is, what it is not, which adjacent concepts remain separate, which overlaps exist, and which distinctions remain uncertain.
Therefore:
Distinction Sufficiency ≠ Universal Conceptual Separation.
Minimum Implementation Framework
A conforming implementation of LODM must provide at least the following eight capabilities:
Core Object Distinction
Capability to distinguish the Liability Object from Liability Context, occurrence, event, action, omission, and other surrounding matters.
Consequence & Harm Distinction
Capability to distinguish the Liability Object from Harm, Loss, Damage, consequence, and other downstream states without preventing those states from remaining relevant.
Claim, Obligation & Liability Concept Distinction
Capability to distinguish the Object from Claims, obligations, Liability Basis, Liability Conditions, Liability Relationships, and Liability-Relevant Connection.
Subject, Mechanism & Environment Distinction
Capability to distinguish the Object from Liability Subjects, operational mechanisms, systems, products, and environments unless any of those are explicitly established as the Object.
Multi-Object Distinction
Capability to distinguish multiple Liability Objects that overlap, interact, share origins, components, Subjects, consequences, evidence, or environments.
Semantic Conflation & Object Drift Control
Capability to detect conceptual conflation, silent Object substitution, terminological ambiguity, and gradual Object Drift during Liability governance.
Distinction Uncertainty & Reassessment
Capability to represent uncertain, disputed, overlapping, or potentially composite distinctions and reassess them while preserving prior distinction states.
Distinction Sufficiency Determination
Capability to determine when the Object is sufficiently differentiated from adjacent governed concepts for Object Representation governance.
Governance Logic
The canonical LODM governance logic is:
Bounded Liability Object
↓
Identify Adjacent and Potentially Confusable Matters
↓
Distinguish Object From Context / Occurrence / Event
↓
Distinguish Object From Action / Omission / Mechanism
↓
Distinguish Object From Harm / Loss / Damage / Consequence
↓
Distinguish Object From Claim / Obligation
↓
Distinguish Object From Subject / Basis / Conditions / Relationship / Connection
↓
Distinguish Object From Evidence / System / Product / Environment
↓
Distinguish Object From Other Liability Objects
↓
Evaluate Shared Origins / Components / Subjects / Consequences / Evidence
↓
Detect Semantic Conflation / Object Substitution / Object Drift
↓
Identify Distinction Uncertainty
↓
Assess Distinction Sufficiency
If insufficient:
Clarify / Separate / Reclassify / Reassess Distinction
If sufficient:
↓
Distinguished Liability Object
↓
Handoff to Object Representation Governance
Governance Outputs
LODM may produce:
Object Distinction Map
Context–Object Distinction State
Occurrence–Object Distinction State
Harm–Object Distinction State
Loss–Object Distinction State
Damage–Object Distinction State
Claim–Object Distinction State
Obligation–Object Distinction State
Subject–Object Distinction State
Basis–Object Distinction State
Relationship–Object Distinction State
Mechanism–Object Distinction State
Evidence–Object Distinction State
Multi-Object Distinction Map
Semantic Conflation Alert
Object Substitution Alert
Object Drift State
Distinction Uncertainty State
Distinction Reassessment Record
Distinction Sufficiency State
The principal output is:
Distinguished Liability Object
The canonical handoff is:
Distinguished Liability Object → Object Representation Governance
Critical Distinctions
LODM preserves the following distinctions:
Relationship to a Liability Object ≠ Identity with the Liability Object Stable Identifier ≠ Stable Meaning by itself Liability Context ≠ Liability Object Occurrence ≠ Liability Object by default Event ≠ Liability Object by default Action ≠ Liability Object by default Absence of Action ≠ Omission ≠ Liability Object by default Operational Mechanism ≠ Liability Object by default Harm ≠ Liability Object by default Harm Boundary ≠ Liability Object Boundary Loss ≠ Liability Object by default Damage ≠ Liability Object by default Consequence ≠ Liability Object by default Claim ≠ Liability Object Claimed Object ≠ Canonical Liability Object by default Obligation ≠ Liability Object by default Liability Subject ≠ Liability Object Liability Object ≠ Liability Basis Liability Conditions ≠ Liability Object Liability Relationship ≠ Liability Object One Liability Object ≠ One Liability Relationship Liability-Relevant Connection ≠ Liability Object Evidence ≠ Liability Object Evidence Record ≠ Object Reality System ≠ Liability Object by default Product ≠ Liability Object by default Environment ≠ Liability Object by default Shared Context ≠ Shared Object Identity Shared Component ≠ Shared Object Identity Object Interaction ≠ Object Identity Object Similarity ≠ Object Identity Shared Origin ≠ Single Liability Object Shared Consequence ≠ Single Liability Object Shared Liability Subject ≠ Shared Liability Object Shared Evidence ≠ Shared Object Identity Terminological Similarity ≠ Methodological Identity Related Matter ≠ Permissible Object Substitute Distinction Reassessment ≠ Historical Erasure
Cross-Architecture Boundary
LODM may compare the Liability Object with governed objects from other OOF® architectures in order to preserve methodological separation.
LCS governs Liability Context.
ORA™ governs Operational Reality, including occurrences, actions, mechanisms, and operational states.
HAGA™ governs Harm.
AGA™ governs Authority, Responsibility, Accountability, and related structures.
ADIT® governs Evidence and Auditability.
VALIDOS™ governs Validation.
OBIDENITY® governs Origin-Bound Identity, Ownership, Authority, Permission, Provenance, Transfer, and Continuity.
AIG® governs AI behavior.
ASGA™ governs autonomous-system operation.
SIMULOS® governs Simulation.
PGA™ governs Prediction.
VFM® governs Value Flow.
An externally governed object may become relevant to the Liability Object.
That relevance does not transfer ownership of the external object to LOS.
The governing principle is:
Cross-Architecture Relevance ≠ Cross-Architecture Object Identity.
Canonical Boundary
LODM begins with a:
Bounded Liability Object
and governs the methodological distinction necessary to prevent that Object from being confused with adjacent, related, overlapping, asserted, consequential, or externally governed matters.
LODM governs:
Object–Context Distinction, Object–Occurrence Distinction, Object–Mechanism Distinction, Object–Harm Distinction, Object–Loss Distinction, Object–Damage Distinction, Object–Claim Distinction, Object–Obligation Distinction, Object–Subject Distinction, Object–Basis Distinction, Object–Condition Distinction, Object–Relationship Distinction, Object–Connection Distinction, Object–Evidence Distinction, Multi-Object Distinction, Semantic Conflation, Object Substitution, Object Drift, Distinction Uncertainty, and Distinction Reassessment.
LODM does not establish:
the complete Object Representation, Object Continuity, Liability Basis, Liability Relationships, Liability Conditions, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Transfer, Recourse, Resolution, or Finality.
LODM ends when the Liability Object is sufficiently distinguished for Object Representation governance.
Use Case 1 — AI System, Action, and Harm
An AI-enabled system performs an operational action followed by Harm.
The same matter is subsequently described by different participants as:
“the AI incident,” “the harmful output,” “the system failure,” and “the AI system.” LOBM has already established the Liability Object Boundary around a specific execution sequence.
LODM prevents later governance from silently replacing that Object with:
the AI system itself, the resulting Harm, the wider incident, or the Claim describing the event.
The system, action, Harm, and Liability Object remain related but methodologically distinct.
Use Case 2 — Product Failure and Claim
A product component fails during operation.
A Claim later describes the matter broadly as a defective product.
The Governed Liability Object, however, concerns a specific component state and related operational sequence.
LODM distinguishes:
the product, the failed component, the operational occurrence, the resulting Damage, the Claim, and the Liability Object.
The Claim may continue to refer to all of these matters.
That does not permit the canonical Liability Object to change silently.
Canonical Closing Statement
A Liability Object does not remain stable merely because it has a name and an identifier.
During a Liability lifecycle, the object may become surrounded by Harm, Claims, evidence, consequences, participants, legal assertions, operational mechanisms, and competing descriptions. Without explicit distinction, one of those adjacent concepts can silently replace the matter originally being governed.
LODM prevents that substitution.
It preserves the Liability Object as a distinct methodological object while allowing it to remain connected to the wider Liability system.
Related does not mean identical. Overlapping does not mean the same.
A Liability Object remains governable only while its meaning remains distinct.