LOIM — Liability Object Identification Module
LOIM — Liability Object Identification 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 Identification
Module ID: LIGA-LOS-LOIM-001
Origin ID: OOF.CM.LIGA.02.01.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 Identification Module (LOIM) governs how one or more matters within a Governed Liability Context are recognized, differentiated, and identified as candidates for formal Liability Object governance without prematurely establishing the complete Object Boundary, determining a Liability Basis, identifying Liability Subjects or Relationships, evaluating Liability Conditions or Connection, or determining Liability.
LOIM governs the transition:
Governed Liability Context → Liability-Relevant Matter Recognition → Object Candidate Identification →
Identified Liability Object Candidate
Its foundational distinction is:
Liability-Relevant Matter ≠ Identified Liability Object Candidate by default.
Operational Role
The operational role of LOIM is:
to identify the specific matter or matters within a Governed Liability Context that require further governance as potential Liability Objects.
LCS establishes the context in which Liability may meaningfully be considered.
LOIM begins the transformation from:
context containing Liability-relevant information to:
explicitly identified Object Candidate.
Its central operational question is:
What specific matter within this Governed Liability Context requires formal Liability Object governance?
Position in the Parent Standard Flow
The internal LOS progression is:
Object Identification → Object Boundary → Object Distinction → Object Representation → Object Continuity LOIM governs:
Object Identification
Its principal input is:
Governed Liability Context
Its principal output is:
Identified Liability Object Candidate
The canonical transition is:
Governed Liability Context → Object Candidate Identification → Identified Liability Object Candidate → Object
Boundary Governance
Governed Space
LOIM governs Liability Object Identification.
Its governed space includes:
Object Candidate recognition, candidate identification, candidate differentiation, candidate multiplicity, candidate composition, candidate relevance, candidate uncertainty, candidate relationship to Context, candidate relationship to externally governed objects, candidate identification traceability, and identification sufficiency.
LOIM does not establish the final Object Boundary.
It identifies the matter that requires that boundary to be governed.
Starting Point
LOIM begins with a Governed Liability Context.
That Context may contain:
occurrences, actions, omissions, systems, products, services, transactions, decisions, conditions, obligations, Harm, Loss, Damage, Claims, organizations, persons, contracts, operational mechanisms, and other Liability-relevant information.
LOIM must determine which matter or matters require formal Object Governance.
Not everything inside the Context becomes an Object Candidate.
Liability-Relevant Matter Recognition
The first function of LOIM is to recognize matters that may require Liability Object governance.
A matter may be Liability-relevant where subsequent Liability reasoning would require it to be treated as a stable and separately identifiable governed matter.
Recognition does not establish:
Liability, wrongdoing, fault, breach, responsibility, or legal significance.
It establishes only that the matter may need to become a governed Liability Object.
Therefore:
Liability Relevance ≠ Liability.
Object Candidate Identification
A matter becomes an Identified Liability Object Candidate when LOIM determines that it is sufficiently relevant and distinguishable to require further Object Governance.
Possible candidates may include:
an action, an omission, a transaction, a decision, a product-related matter, a service-related matter, a system operation, a system state, a contractual performance matter, an operational condition, a continuing process, a sequence of events, or another sufficiently distinguishable matter.
The candidate remains provisional until subsequent LOS governance establishes its full structure.
Candidate Identification Does Not Establish the Final Object
LOIM identifies the candidate.
It does not yet establish the complete Governed Liability Object.
Therefore:
Object Candidate ≠ Governed Liability Object.
Subsequent LOS modules may:
refine the candidate, change its boundary, distinguish it from adjacent matters, represent it differently, separate it, consolidate it, or determine that it should not proceed as initially identified.
Identification is the beginning of Object Governance, not its completion.
Candidate Identity
Each sufficiently distinct Object Candidate should receive a stable provisional identity.
This identity allows subsequent governance to refer consistently to the same candidate while its boundary and meaning are refined.
Candidate Identity should remain distinguishable from:
candidate description, candidate classification, candidate boundary, and any later Liability conclusion.
Therefore:
Candidate Identity ≠ Candidate Description.
A description may change without necessarily changing which candidate is being governed.
Identification From Context
LOIM must derive Object Candidates from the Governed Liability Context without treating the entire Context as the object automatically.
The Context answers:
Within what governed environment does the Liability-relevant matter exist?
LOIM asks:
What matter within that environment requires Object Governance?
Therefore:
Liability Context ≠ Liability Object Candidate.
The Context may contain several candidates.
Occurrence-Derived Candidates
An occurrence may generate one or more Object Candidates.
For example, one occurrence may contain:
an operational action, a failed control, a maintenance intervention, a product condition, and a later response.
LOIM must not assume that the occurrence itself is the single correct candidate.
Therefore:
Occurrence ≠ Object Candidate by default.
The occurrence may be:
the candidate, part of the candidate, the source of several candidates, or merely contextual to another candidate.
Action-Derived Candidates
An action may become an Object Candidate where the action itself requires Liability Object governance.
Examples may include:
a decision, a transaction, a system execution, a physical intervention, a communication, a deployment, or another operational action.
However:
Action ≠ Liability Object Candidate by default.
The action must be sufficiently relevant and distinguishable within the governed context.
Omission-Derived Candidates
An alleged or observed omission may also become an Object Candidate.
However, LOIM must avoid defining the candidate in language that already assumes:
a duty existed, the duty was breached, the omission was wrongful, or Liability resulted.
Therefore:
Absence of Action ≠ Governed Omission by default.
and:
Omission Candidate ≠ Established Breach.
Whether a relevant obligation or condition existed belongs to later governance.
Product-Derived Candidates
A product-related context may generate Object Candidates concerning:
the product as a whole, a component, a product state, a modification, an installation, a maintenance condition, an instruction, or a specific product-related event.
LOIM must identify what requires Object Governance without assuming:
Product = Liability Object.
Therefore:
Product Presence ≠ Product Object Candidate by default.
System-Derived Candidates
A digital, AI, automated, or autonomous system may appear in the Liability Context.
The relevant Object Candidate may be:
a system action, a system output, a deployment state, a configuration, a decision sequence, a tool interaction, a permission-dependent execution, or another matter.
The system itself is not automatically the candidate.
Therefore:
System Presence ≠ System as Liability Object Candidate.
Transaction-Derived Candidates
A transaction may generate one or several Object Candidates.
Relevant matters may include:
the transaction itself, its execution, its authorization, its failure, its reversal, its settlement, or another distinct transactional matter.
LOIM identifies which matter requires formal Object Governance.
It does not determine contractual, financial, or legal Liability.
Condition-Derived Candidates
A persistent or temporary condition may itself require Object Governance.
Examples may include:
a system configuration, an infrastructure state, a continuing exposure condition, a product condition, or another operational state.
However:
Contextual Condition ≠ Liability Object Candidate by default.
A condition becomes a candidate only where it requires stable treatment as the matter against which potential Liability may later be structured.
Harm-Derived Candidates
Harm may reveal that a matter requires Liability Object governance.
However:
Harm ≠ Liability Object Candidate by default.
For example, a Harm state may direct attention toward:
a product-related matter, an action, an omission, a system operation, or another candidate.
HAGA™ continues to govern Harm.
LOIM governs only identification of the Liability Object Candidate.
Loss and Damage as Candidate Signals
Loss or Damage may signal the existence of a matter requiring Object Governance.
They do not automatically define that matter.
Therefore:
Loss ≠ Object Candidate by default.
Damage ≠ Object Candidate by default.
The candidate may instead concern the action, product, transaction, condition, or another matter related to that Loss or Damage.
Claim-Derived Candidates
A Claim may identify one or more alleged Liability matters.
LOIM may use those assertions as inputs.
It must not adopt the Claim structure automatically.
Therefore:
Claimed Object ≠ Identified Liability Object Candidate by default.
The Claim may:
combine several candidates, exclude relevant candidates, misidentify the matter, or describe the candidate through language that presupposes Liability.
LOIM performs independent methodological identification.
Obligation-Derived Candidates
An obligation may indicate that a matter requires Liability Object governance.
However, the obligation itself may belong primarily to later Liability Basis or Conditions governance.
LOIM must distinguish:
the matter being evaluated from:
the basis or condition under which Liability might later exist.
Therefore:
Obligation ≠ Object Candidate by default.
Subject-Derived Identification
A person or organization may draw attention to a Liability-relevant matter.
However:
Potential Liability Subject ≠ Liability Object Candidate.
LOIM must avoid converting the identity of a potentially involved party into the governed object.
The object is the matter.
The subject is a participant in a later Liability Relationship.
Mechanism-Derived Identification
An operational mechanism may reveal an Object Candidate.
Examples include:
physical contact, mechanical movement, software execution, data transfer, communication, payment, or autonomous action.
However:
Operational Mechanism ≠ Liability Object Candidate by default.
The mechanism remains governed by its appropriate architecture or operational governance domain.
LOIM identifies only the Liability-relevant matter requiring Object Governance.
Multiple Candidate Identification
A single Governed Liability Context may produce multiple Object Candidates.
LOIM must permit:
Context → Candidate A + Candidate B + Candidate C without prematurely deciding whether those candidates ultimately remain separate.
Subsequent LOS governance may determine that they should be:
separate objects, components of one Composite Liability Object, or consolidated.
Therefore:
Multiple Candidates ≠ Multiple Final Liability Objects.
Candidate Overlap
Object Candidates may overlap.
Candidate A and Candidate B may share:
events, systems, participants, time periods, conditions, or evidence.
Overlap does not establish identity.
Therefore:
Candidate Overlap ≠ Candidate Identity.
LOIM should preserve the overlap for later Object Boundary and Distinction governance.
Candidate Dependency
One Object Candidate may depend operationally or contextually on another.
For example:
one system action may depend on an earlier configuration, or one transaction may depend on an earlier authorization.
Dependency does not establish that the candidates are one object.
Therefore:
Candidate Dependency ≠ Object Unity by default.
Nor does dependency establish Liability.
Composite Candidate Recognition
LOIM may identify that several elements appear to form a potentially composite matter.
The module may mark:
Composite Object Candidate
where separating the elements immediately would risk losing the meaning of the Liability-relevant matter.
However, LOIM does not finalize Composite Object structure.
That structure is refined through later LOS governance.
Therefore:
Composite Candidate ≠ Final Composite Liability Object.
Candidate Granularity
Object Candidate identification requires sufficient granularity.
A candidate that is too broad may obscure several different governed matters.
A candidate that is too narrow may fragment one coherent matter artificially.
LOIM should identify the candidate at a level sufficient for Object Boundary governance.
It does not need to finalize exact Object Granularity.
Therefore:
Identification Granularity ≠ Final Object Granularity.
Neutral Identification
Candidate identification must remain methodologically neutral.
The candidate should not be named or described using terminology that prematurely assumes:
fault, negligence, breach, wrongdoing, responsibility, causation, or Liability.
For example, an unresolved matter should not automatically be identified as:
“the negligent action” or:
“the liable failure.” The governing principle is:
Object Identification Must Not Predetermine Liability.
Candidate Classification
LOIM may classify candidates provisionally to support later governance.
Possible identification classes may include:
action-related, omission-related, product-related, service-related, system-related, transaction-related, decision-related, condition-related, contract-related, composite, or other appropriate classes.
Classification assists routing.
It does not determine final Object meaning or Liability.
Therefore:
Candidate Classification ≠ Liability Classification.
Candidate Uncertainty
Candidate identity may initially be uncertain.
LOIM must permit states such as:
Identified
Partially Identified
Uncertain
Disputed
Competing Candidate
Composite Candidate
Insufficiently Identified
where appropriate.
Uncertainty must remain visible.
Uncertain Object Candidate ≠ No Object Candidate.
Competing Object Candidates
Different interpretations may identify different possible objects.
For example:
one interpretation may identify a system action as the candidate, another may identify the broader deployment process, and another may identify a sequence involving both human and automated actions.
LOIM should preserve competing candidates where the evidence does not yet support one definitive identification.
It must not force premature convergence.
Candidate Identification Across Time
A candidate may become identifiable only after later information emerges.
This does not mean the underlying matter originated when it was identified.
Therefore:
Candidate Identification Time ≠ Candidate Matter Origin Time.
LCTM may provide the temporal structure necessary to preserve that distinction.
Candidate Identification Across Environments
A candidate may span:
physical and digital environments, test and production environments, multiple organizations, multiple systems, or multiple operational domains.
LOIM may identify the cross-environment matter as a candidate without deciding its final boundary.
LCEM provides the governed environmental structure.
LOIM uses that structure for candidate identification.
Candidate Identification and Evidence
Evidence may support recognition of an Object Candidate.
However:
Evidence Item ≠ Liability Object Candidate.
and:
Evidence Availability ≠ Object Validity by itself.
ADIT® governs evidence and auditability.
LOIM governs the methodological identification of the candidate.
Candidate Identification and Validation
Candidate-related inputs may require validation.
VALIDOS™ may govern whether those inputs are sufficiently validated.
LOIM must preserve the difference between:
Identified Candidate
and:
Validated Input Supporting Candidate Identification.
A candidate may remain uncertain while validation is incomplete.
Identification Reassessment
New information may require LOIM to reassess candidate identification.
Reassessment may:
confirm the candidate, modify its description, identify an additional candidate, remove an unsupported candidate, separate a previously combined candidate, or identify a potential composite structure.
Reassessment must preserve the earlier identification state.
Therefore:
Candidate Reassessment ≠ Historical Identification Erasure.
Candidate Traceability
Each identified candidate should be traceable to:
the Governed Liability Context, the contextual elements supporting its identification, the time of identification, material assumptions, material uncertainty, and subsequent identification changes.
Traceability enables later LOS governance to understand why the candidate entered Object Governance.
Identification Sufficiency
LOIM does not require complete Object formation.
Its output is sufficient when the candidate is clear enough for Object Boundary governance to ask:
What belongs inside this Liability Object and what remains outside it?
The threshold is therefore:
Sufficient Identification for Boundary Governance
not:
Complete Liability Object Formation.
Minimum Implementation Framework
A conforming implementation of LOIM must provide at least the following eight capabilities:
Liability-Relevant Matter Recognition
Capability to identify matters within a Governed Liability Context that may require formal Liability Object governance without treating relevance as Liability.
Object Candidate Identification
Capability to create a stable provisional identity for each sufficiently distinguishable matter requiring further Object Governance.
Candidate Source Differentiation
Capability to distinguish candidates arising from occurrences, actions, omissions, products, systems, transactions, conditions, Harm, Claims, obligations, operational mechanisms, or other contextual sources without automatically equating those sources with the candidate.
Multiple, Overlapping & Composite Candidate Recognition
Capability to identify multiple, overlapping, dependent, competing, or potentially composite candidates without prematurely determining their final Object structure.
Neutral Candidate Representation
Capability to identify and describe candidates without embedding ungoverned conclusions concerning fault, breach, wrongdoing, responsibility, causation, or Liability.
Candidate Uncertainty & Competing Interpretation Governance
Capability to preserve partial identification, uncertainty, disputes, and competing candidate interpretations without forcing premature convergence.
Candidate Traceability & Reassessment
Capability to trace candidate identification to its governed context, supporting information, assumptions, uncertainty, and later identification changes while preserving historical states.
Identification Sufficiency Determination
Capability to determine when an Object Candidate is sufficiently identified for Object Boundary governance.
Governance Logic
The canonical LOIM governance logic is:
Governed Liability Context
↓
Identify Liability-Relevant Matters
↓ Which matters require stable Object Governance?
↓ Identify Object Candidate(s) ↓
Assign Provisional Candidate Identity
↓ Differentiate Candidate From Context / Occurrence / Harm / Claim / Obligation / Subject / Mechanism ↓
Identify Multiple / Overlapping / Competing / Composite Candidates
↓
Represent Candidate Neutrally
↓
Identify Uncertainty and Assumptions
↓
Establish Candidate Traceability
↓
Assess Identification Sufficiency
If insufficient:
Clarify / Investigate / Preserve Uncertainty / Reassess Candidate Identification
If sufficient:
↓
Identified Liability Object Candidate
↓
Handoff to Object Boundary Governance
Materially new information may trigger:
Candidate Reassessment → Revised Candidate Identification without erasing prior identification history.
Governance Outputs
LOIM may produce:
Liability Object Candidate Identity
Candidate Description
Candidate Source State
Candidate Classification
Multiple Candidate Structure
Candidate Overlap State
Candidate Dependency State
Composite Candidate State
Competing Candidate State
Candidate Uncertainty State
Candidate Assumption Record
Candidate Traceability Record
Candidate Reassessment Record
Identification Sufficiency State
The principal output is:
Identified Liability Object Candidate
The canonical handoff is:
Identified Liability Object Candidate → Object Boundary Governance
Critical Distinctions
LOIM preserves the following distinctions:
Liability-Relevant Matter ≠ Identified Liability Object Candidate by default Liability Relevance ≠ Liability Object Candidate ≠ Governed Liability Object Candidate Identity ≠ Candidate Description Liability Context ≠ Liability Object Candidate Occurrence ≠ Object Candidate by default Action ≠ Liability Object Candidate by default Omission Candidate ≠ Established Breach Product Presence ≠ Product Object Candidate by default System Presence ≠ System as Liability Object Candidate Contextual Condition ≠ Liability Object Candidate by default Harm ≠ Liability Object Candidate by default Loss ≠ Object Candidate by default Damage ≠ Object Candidate by default Claimed Object ≠ Identified Liability Object Candidate by default Obligation ≠ Object Candidate by default Potential Liability Subject ≠ Liability Object Candidate Operational Mechanism ≠ Liability Object Candidate by default Multiple Candidates ≠ Multiple Final Liability Objects Candidate Overlap ≠ Candidate Identity Candidate Dependency ≠ Object Unity by default Composite Candidate ≠ Final Composite Liability Object Identification Granularity ≠ Final Object Granularity Candidate Classification ≠ Liability Classification Uncertain Object Candidate ≠ No Object Candidate Candidate Identification Time ≠ Candidate Matter Origin Time Evidence Item ≠ Liability Object Candidate Candidate Reassessment ≠ Historical Identification Erasure
Cross-Architecture Boundary
LOIM may consume governed outputs from other OOF® architectures to identify Liability Object Candidates without taking ownership of those external governed objects.
LCS provides the Governed Liability Context.
ORA™ may provide an occurrence, action, condition, or Operational Reality that signals an Object Candidate.
HAGA™ may provide a governed Harm state that reveals a Liability-relevant matter.
AGA™ may provide Authority, Responsibility, Accountability, or Attribution states relevant to candidate identification.
ADIT® may provide governed evidence supporting candidate recognition.
VALIDOS™ may validate candidate-relevant inputs.
OBIDENITY® may provide identity, origin, ownership, provenance, or other governed states necessary to distinguish matters.
AIG® may provide AI behavior relevant to candidate identification.
ASGA™ may provide autonomous actions or operational states.
SIMULOS® may provide Simulation states.
PGA™ may provide Prediction objects or lifecycle states.
VFM® may provide Value-related objects or states.
The Cross-Architecture Mechanism Principle applies:
An operational mechanism may produce inputs for Liability Object Identification without becoming owned by LIGA™ merely because it becomes Liability-relevant.
Canonical Boundary
LOIM begins when a Governed Liability Context contains one or more matters that may require explicit Liability Object governance.
It governs:
Liability-Relevant Matter Recognition, Object Candidate Identification, Candidate Identity, Candidate Differentiation, Multiple Candidate Recognition, Candidate Overlap, Candidate Dependency, Composite Candidate Recognition, Candidate Classification, Candidate Uncertainty, Competing Candidates, Candidate Traceability, Candidate Reassessment, and Identification Sufficiency.
LOIM does not establish:
the complete Object Boundary, final Object Distinction, complete Object Representation, Object Continuity, Liability Basis, Liability Subjects, Liability Relationships, Liability Conditions, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Transfer, Recourse, Resolution, or Finality.
LOIM ends when the matter is sufficiently identified for Object Boundary governance.
Use Case 1 — Autonomous System Incident
An autonomous system performs an action that produces an unexpected operational consequence.
The Governed Liability Context contains:
the system, its configuration, the autonomous action, a human supervisory process, an external service, the operational environment, and the resulting consequence.
LOIM does not automatically identify the AI system or consequence as the Liability Object.
It identifies possible Object Candidates such as:
the specific autonomous execution, a deployment-related action sequence, or another materially distinguishable matter.
Those candidates can then proceed to Object Boundary governance without LOIM deciding whether Liability exists.
Use Case 2 — Industrial Failure With Several Candidate
Matters
An industrial incident involves:
equipment failure, a previous maintenance intervention, a component replacement, and an operational action immediately before the incident.
LOIM identifies that the context may contain several Object Candidates rather than treating the entire incident automatically as one Liability Object.
It preserves the candidates and their relationships without prematurely deciding whether they ultimately become:
separate Liability Objects, one Composite Liability Object, or another governed structure.
That determination can proceed through later LOS governance.
Canonical Closing Statement
Liability Object governance cannot begin reliably by assuming that the most visible event, Harm, Claim, system, product, or participant is automatically the matter against which Liability should be evaluated.
LOIM creates the first explicit transition from contextual relevance to Object Governance.
It identifies the matter that requires governance without deciding its final boundary, its Liability Basis, its Liability Relationships, or whether Liability ultimately exists.
The event that reveals a Liability question is not necessarily the object of that question.
Identify the matter first. Define its boundary next.