Liability Object Standard (LOS)
Liability Object Standard (LOS)
Architecture: LIGA™ — Liability Governance Architecture
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Parent Standard
Governed Space: Liability Object Governance
Standard ID: LIGA-LOS-001
Origin ID: OOF.PS.LIGA.02.00.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 Standard (LOS) governs how the specific matter in relation to which Liability is being considered is identified, formed, bounded, distinguished, represented, and maintained as a stable governed Liability Object before any Liability Basis, Liability Relationship, Liability Condition, Liability Connection, or Liability Determination is established.
A Liability Object is the governed matter against which potential Liability is structured and evaluated.
It is not necessarily the Harm, occurrence, subject, Claim, obligation, Loss, Damage, operational mechanism, product, action, or event from which Liability relevance arose.
Its foundational distinction is:
Liability-Relevant Matter ≠ Liability Object by default.
Operational Role
The operational role of LOS is:
to transform a sufficiently governed Liability Context into an explicit Liability Object that defines what the subsequent Liability lifecycle is actually about.
LCS establishes the context.
LOS establishes the governed matter within that context against which potential Liability will subsequently be structured.
Without an explicit Liability Object, later Liability governance may accidentally evaluate different matters as though they were the same object.
LOS prevents that ambiguity.
Core Question
What exactly is the governed matter in relation to which Liability is being considered?
Position in the LIGA™ Governance Flow
The complete LIGA™ Governance Flow is:
Liability Context → Liability Object → Liability Basis → Liability Relationships → Liability Conditions → Liability Connection → Liability Determination → Liability Scope & Allocation → Liability State & Change → Liability Transfer & Recourse → Liability Resolution & Discharge → Liability Continuity & Finality LOS governs:
Liability Object
Its canonical transition is:
Governed Liability Context → Liability Object Formation → Governed Liability Object → Liability Basis
Governance
Governed Space
LOS governs Liability Object Governance.
Its governed space begins when a Liability Context contains a matter requiring explicit formation as a Liability Object.
It ends when that object is sufficiently:
identified, formed, bounded, distinguished, represented, and continuous for Liability Basis governance.
LOS does not determine whether Liability exists.
Why a Liability Object Is Necessary
A Liability Context may contain many relevant elements:
events, persons, organizations, systems, actions, omissions, products, contracts, Harm, Loss, Damage, decisions, conditions, relationships, and operational mechanisms.
Not all of these are necessarily the matter against which Liability should be evaluated.
The Liability Object provides an explicit answer to:
What is this Liability inquiry actually about?
Without that answer, later governance may attach a Liability Basis to one matter, evaluate Conditions against another, and determine Liability against a third.
LOS prevents that object drift.
Liability Object Formation
A Liability Object is formed from a Governed Liability Context when a sufficiently specific matter requires subsequent Liability governance.
The canonical progression is:
Governed Liability Context
↓
Liability Object Candidate
↓
Object Identification
↓
Object Formation
↓
Object Boundary
↓
Object Distinction
↓
Object Representation
↓
Governed Liability Object
Object formation does not establish Liability.
It establishes the governed object against which potential Liability may subsequently be evaluated.
Liability Object Candidate
A Governed Liability Context may contain one or more possible Liability Object candidates.
Possible candidates may arise from:
an occurrence, action, omission, decision, product, service, system state, contractual matter, obligation, transaction, operational condition, Harm-related matter, Loss-related matter, Damage-related matter, or another sufficiently defined matter.
A candidate becomes a Governed Liability Object only after LOS governance establishes that it is the appropriate object for subsequent Liability governance.
Therefore:
Object Candidate ≠ Governed Liability Object.
Liability Object Identification
LOS must identify the specific matter requiring Liability governance.
Identification must be sufficiently precise to distinguish the object from surrounding contextual information.
The object should be capable of being referenced consistently throughout subsequent LIGA™ stages.
Object Identification must not depend upon a predetermined Liability conclusion.
A matter can remain a valid Liability Object even if subsequent governance determines that no Liability attaches.
Therefore:
Valid Liability Object ≠ Established Liability.
Object Identity
Each Liability Object requires a stable governed identity.
The object may later:
be described differently, receive additional information, have its boundary refined, be reclassified, be corrected, or become associated with additional Liability Relationships.
Those changes do not automatically create a new Liability Object.
Therefore:
Object Change ≠ New Liability Object by default.
Object identity must remain distinguishable from its descriptive attributes.
Liability Object Boundary
The Liability Object requires a boundary defining what constitutes the object itself.
This boundary is distinct from the Liability Context Boundary.
The Context Boundary answers:
What belongs within the relevant contextual environment?
The Object Boundary answers:
What specifically constitutes the matter being governed as the Liability Object?
Therefore:
Liability Context Boundary ≠ Liability Object Boundary.
A broad Context may contain a narrowly defined Liability Object.
Object Inclusion
An element should form part of the Liability Object where removing it would materially alter the identity or meaning of the matter being evaluated for potential Liability.
Object inclusion may concern:
a particular action, a sequence of actions, an omission, a defined product state, a transaction, a contractual performance matter, a system operation, a continuing condition, or a materially inseparable combination of elements.
Object inclusion must remain methodologically justified.
Object Exclusion
Contextually relevant information does not automatically form part of the Liability Object.
Information may remain part of the Liability Context while being outside the Object Boundary.
Therefore:
Contextual Relevance ≠ Object Membership.
For example, an organizational relationship may be necessary to understand the context without becoming part of the Liability Object itself.
LOS must preserve this distinction.
Object Granularity
A Liability Object may be represented at different levels of granularity.
An object may concern:
one action, one transaction, one product, one system state, one continuing condition, a sequence of related actions, or a composite matter.
The appropriate granularity is the level required to preserve the meaning of the Liability inquiry without artificially fragmenting or aggregating the governed matter.
Therefore:
Smallest Identifiable Matter ≠ Correct Liability Object by default.
and:
Largest Connected Matter ≠ Correct Liability Object by default.
Composite Liability Objects
Some Liability matters cannot be represented accurately as a single isolated event or element.
A Liability Object may therefore be composite.
A Composite Liability Object may contain:
multiple actions, multiple omissions, multiple system states, multiple operational stages, or several materially inseparable components.
However:
Multiple Components ≠ Multiple Liability Objects by default.
A composite object is legitimate where the components form one coherent governed matter for subsequent Liability evaluation.
Multiple Liability Objects
One Liability Context may contain multiple distinct Liability Objects.
For example, one complex incident may generate separate governed matters involving:
a product defect, a maintenance action, a contractual performance issue, and a later response.
These objects may share the same context while requiring separate Liability governance.
Therefore:
One Liability Context ≠ One Liability Object.
and:
One Occurrence ≠ One Liability Object by default.
Occurrence and Liability Object
An occurrence may trigger Liability governance.
It does not automatically define the Liability Object.
An occurrence may:
contain several Liability Objects, form part of a broader Liability Object, provide context for another Liability Object, or ultimately produce no Liability Object requiring further governance.
Therefore:
Occurrence ≠ Liability Object.
This distinction prevents an event from being treated automatically as the complete governed matter.
Harm and Liability Object
Harm may be relevant to a Liability Object.
Harm may also become one component of the matter being evaluated.
However:
Harm ≠ Liability Object by default.
HAGA™ governs Harm itself.
LOS governs the Liability Object.
A Liability Object may exist:
with Harm, without established Harm, before Harm is determined, or after Harm has been resolved.
Therefore:
Harm Determination ≠ Liability Object Formation.
Loss and Damage
Loss or Damage may contribute to formation of a Liability Object.
They do not automatically define it.
Therefore:
Loss ≠ Liability Object by default.
Damage ≠ Liability Object by default.
The Liability Object may concern the action, obligation, product, transaction, condition, or another matter in relation to which Loss or Damage later becomes relevant.
Claim and Liability Object
A Claim may describe or assert a matter against which Liability is alleged.
That asserted matter does not automatically become the canonical Liability Object.
Therefore:
Claim Object ≠ Liability Object by default.
A Claim may:
define the object too narrowly, define it too broadly, combine several objects, omit a relevant object, or assert an object that later governance does not support.
LOS forms the Liability Object independently of the Claim's procedural or asserted structure.
Obligation and Liability Object
An obligation may be relevant to Liability.
However:
Obligation ≠ Liability Object by default.
An obligation may later form part of the Liability Basis or Conditions.
The Liability Object may instead be:
the performance, non-performance, transaction, action, omission, service, or another governed matter to which the obligation relates.
LOS must avoid collapsing the object into the basis for potential Liability.
Liability Object and Liability Basis
The Liability Object answers:
What is being governed?
The Liability Basis answers:
On what governed basis can Liability potentially exist in relation to that object?
Therefore:
Liability Object ≠ Liability Basis.
The object must be sufficiently established before a Liability Basis is attached to the inquiry.
Liability Object and Liability Subject
A Liability Object is not the person or entity that may bear Liability.
Therefore:
Liability Object ≠ Liability Subject.
For example, an organization may be a Liability Subject in relation to an object concerning:
a product, a contractual performance, an operational action, a system decision, or another governed matter.
Confusing object and subject would collapse two separate governance questions.
Liability Object and Liability Relationship
A Liability Object may participate in multiple Liability Relationships.
Therefore:
Liability Object ≠ Liability Relationship.
The same object may be relevant to:
multiple parties, multiple Liability Bases, multiple conditions, and potentially multiple Liability Relationships.
This becomes particularly important in Liability Network governance.
Liability Object and Operational Mechanism
The mechanism producing a Liability-relevant matter is not automatically the Liability Object.
For example:
physical contact, software execution, autonomous action, mechanical failure, communication, payment, data transfer, or another mechanism may produce or contribute to the matter.
Therefore:
Operational Mechanism ≠ Liability Object by default.
The relevant operational architecture continues to own the mechanism itself.
Liability Object and Product
A product may be the Liability Object in some matters.
In others, the object may instead be:
a specific product state, a defect, an installation, a maintenance intervention, a product-related decision, a transaction, or an operational use.
Therefore:
Product ≠ Liability Object by default.
Object formation must determine what precisely is being governed.
Liability Object and AI Systems
The presence of an AI system does not automatically make the AI system the Liability Object.
The relevant object may instead be:
an AI-generated decision, an autonomous action, a deployment configuration, a human-AI interaction, a system output, a failed control, or another matter.
Therefore:
AI System ≠ Liability Object by default.
AIG® and ASGA™ continue to govern their respective AI and autonomous-system domains.
LOS governs only the Liability Object formed from the relevant context.
Object Representation
A Liability Object must be represented sufficiently for later LIGA™ stages to refer to the same governed matter consistently.
A representation should identify, where applicable:
the object identity, the object description, the object boundary, the object type, the relevant context, material components, related but excluded contextual elements, object state, and uncertainty affecting the representation.
Representation must describe the object without embedding an ungoverned Liability conclusion.
Neutral Object Representation
The representation of a Liability Object must remain methodologically neutral.
Terms that presuppose Liability should not be embedded into the object merely because Liability is alleged.
For example, where Liability has not yet been determined, the object should not be represented in a way that assumes:
fault, breach, wrongdoing, negligence, responsibility, Liability, or unlawful conduct unless that state has already been independently established and is legitimately relevant.
The governing principle is:
Object Representation Must Not Predetermine Liability.
Object Classification
A Liability Object may be classified to support governance.
Possible classes may include:
action-related, omission-related, product-related, service-related, transaction-related, contract-related, system-related, operational, decision-related, condition-related, composite, or another useful class.
Classification supports structure.
It does not determine Liability.
Therefore:
Object Classification ≠ Liability Classification.
Object State
A Liability Object may have different governance states.
Possible states may include:
Candidate
Identified
Bounded
Represented
Disputed
Uncertain
Superseded
Separated
Consolidated
Governed
or another controlled state.
The object state describes the maturity or condition of Object Governance.
It does not describe whether Liability exists.
Object Uncertainty
The exact Liability Object may initially be uncertain.
Several object candidates may exist.
The boundary may be disputed.
It may be unclear whether several matters form one object or multiple objects.
LOS must preserve that uncertainty explicitly.
Therefore:
Object Uncertainty ≠ Absence of Liability-Relevant Matter.
Governance may continue until the object becomes sufficiently defined.
Object Separation
A Liability Object may need to be separated into multiple objects where continued aggregation would distort subsequent Liability governance.
The canonical pattern may be:
Object A → Governed Separation → Object A1 + Object A2 Separation may be required where components have materially different:
Bases, Subjects, Relationships, Conditions, Connections, or lifecycle paths.
However:
Object Complexity ≠ Requirement for Object Separation.
Separation must be methodologically justified.
Object Consolidation
Apparently separate Object Candidates may need to be consolidated where they form one materially inseparable governed matter.
The canonical pattern may be:
Object A + Object B → Governed Consolidation → Object C Consolidation must preserve the history of the original candidates.
Therefore:
Object Consolidation ≠ Historical Identity.
The fact that objects are later consolidated does not mean they were always governed as one.
Object Change
The Liability Object may change as new information becomes available.
Changes may involve:
description, boundary, classification, component structure, representation, or relationship to the context.
LOS must distinguish:
Object Change
from:
New Object Formation.
A changed object remains the same governed object where methodological continuity remains intact.
Object Continuity
A Liability Object must remain traceable across changes.
Object Continuity should preserve:
original formation, prior boundaries, prior representations, material changes, corrections, separation or consolidation events, and the current Object State.
Therefore:
Current Liability Object ≠ Complete Liability Object History.
Continuity allows later Liability governance to reconstruct what object was being evaluated at each relevant lifecycle stage.
Object Correction
An Object Representation may later be found to be inaccurate.
LOS must permit correction without historical erasure.
The canonical pattern is:
Prior Object Representation → Error Identification → Correction → Corrected Object Representation Therefore:
Object Correction ≠ Object History Deletion.
The system should preserve what changed and why.
Object Reassessment
Materially new Context information may require the Liability Object to be reassessed.
Reassessment may:
confirm the object, refine its boundary, change its representation, separate it, consolidate it, or determine that a previously assumed Object Candidate should not proceed.
Reassessment does not automatically create a new object.
Object Reassessment ≠ New Liability Object by default.
Object and Liability Networks
One Liability Object may participate in multiple Liability Relationships.
Multiple Liability Objects may also participate in one wider Liability Network.
Therefore:
One Liability Object ≠ One Liability Relationship.
and:
One Liability Object ≠ Complete Liability Network.
LOS establishes the object.
LRS and later LIGA™ standards govern the relationships and resulting Liability Network structure.
Object Readiness
A Liability Object is ready for Liability Basis governance when it is sufficiently:
identified, bounded, distinguished, represented, traceable, and stable to permit the question:
On what governed basis can Liability potentially exist in relation to this object?
Perfect information is not required.
The threshold is methodological sufficiency.
Object Readiness ≠ Liability Determination Readiness.
Several later governance stages remain before Liability can be determined.
Governance Requirements
A conforming implementation of LOS should be capable of:
receiving a Governed Liability Context;
identifying one or more Liability Object candidates;
determining whether an Object Candidate requires formal Liability Object governance;
assigning stable Object Identity;
establishing an explicit Object Boundary;
distinguishing Object Boundary from Context Boundary;
distinguishing Object from Harm, occurrence, Claim, Loss, Damage, obligation, subject, relationship, and
mechanism;
supporting appropriate Object Granularity;
representing Composite Liability Objects;
supporting multiple Liability Objects within one Context;
preserving Object Uncertainty;
maintaining neutral Object Representation;
preventing object terminology from predetermining Liability;
supporting Object Classification and State;
supporting Object Separation and Consolidation;
preserving Object Change and Correction history;
maintaining Object Continuity;
assessing readiness for Liability Basis governance.
Governance Logic
The canonical LOS governance logic is:
Governed Liability Context
↓ Identify Potential Liability Object Candidate(s) ↓ What specific matter requires Liability governance?
↓
Establish Object Identity
↓
Establish Object Boundary
↓ Differentiate Object From Context / Harm / Occurrence / Claim / Obligation / Subject / Mechanism ↓
Determine Appropriate Object Granularity
↓
Evaluate Composite / Multiple Object Structure
↓
Represent Object Neutrally
↓
Identify Object Uncertainty
↓ Evaluate Separation / Consolidation where necessary ↓
Establish Object Continuity
↓
Assess Object Readiness
If insufficient:
Clarify / Refine / Separate / Consolidate / Correct / Reassess Object
If sufficient:
↓
Governed Liability Object
↓
Handoff to Liability Basis Governance
Materially new contextual information may trigger:
Object Reassessment → Revised Object State without automatically creating a new Liability Object.
Governance Outputs
LOS may produce:
Liability Object Identity
Liability Object Representation
Liability Object Boundary
Liability Object Classification
Liability Object State
Liability Object Component Structure
Composite Object State
Multiple Object Structure
Object Uncertainty State
Object Separation Record
Object Consolidation Record
Object Change Record
Object Correction Record
Object Continuity Record
Object Readiness State
The principal output is:
Governed Liability Object
The canonical handoff is:
Governed Liability Object → Liability Basis Governance
Critical Distinctions
LOS preserves the following distinctions:
Liability-Relevant Matter ≠ Liability Object by default Object Candidate ≠ Governed Liability Object Valid Liability Object ≠ Established Liability Context Boundary ≠ Liability Object Boundary Contextual Relevance ≠ Object Membership One Liability Context ≠ One Liability Object One Occurrence ≠ One Liability Object by default Occurrence ≠ Liability Object Harm ≠ Liability Object by default Harm Determination ≠ Liability Object Formation Loss ≠ Liability Object by default Damage ≠ Liability Object by default Claim Object ≠ Liability Object by default Obligation ≠ Liability Object by default Liability Object ≠ Liability Basis Liability Object ≠ Liability Subject Liability Object ≠ Liability Relationship Operational Mechanism ≠ Liability Object by default Product ≠ Liability Object by default AI System ≠ Liability Object by default Object Representation ≠ Liability Determination Object Classification ≠ Liability Classification Object Complexity ≠ Requirement for Object Separation Object Consolidation ≠ Historical Identity Object Change ≠ New Liability Object by default Current Liability Object ≠ Complete Liability Object History Object Correction ≠ Object History Deletion Object Reassessment ≠ New Liability Object by default One Liability Object ≠ Complete Liability Network Object Readiness ≠ Liability Determination Readiness
Cross-Architecture Boundary
LOS may consume governed outputs from other OOF® architectures where those outputs help identify or distinguish the Liability Object.
LCS provides the Governed Liability Context within which the object is formed.
ORA™ may establish an occurrence, action, system state, or other Operational Reality relevant to the Object.
HAGA™ may establish Harm that becomes relevant to Object formation without making Harm automatically identical to the Liability Object.
AGA™ may establish authority, responsibility, accountability, or attribution states relevant to the object without determining Liability.
ADIT® may provide governed evidence supporting Object Identification or representation.
VALIDOS™ may validate Object-relevant inputs.
OBIDENITY® may establish identity, origin, ownership, provenance, or other states relevant to distinguishing objects.
AIG® and ASGA™ may establish AI or autonomous-system behavior relevant to an Object.
SIMULOS® may establish Simulation states relevant to an Object.
PGA™ may establish Prediction objects or states relevant to the Liability matter.
VFM® may establish Value-related objects or states.
LOS does not absorb those governed objects merely because they become Liability-relevant.
The governing principle is:
An object governed elsewhere may become relevant to a Liability Object without becoming owned by LIGA™ in its original governed meaning.
Canonical Boundary
LOS begins when a Governed Liability Context contains a matter requiring explicit formation as a Liability Object.
LOS governs:
Object Identification, Object Formation, Object Identity, Object Boundary, Object Granularity, Object Distinction, Object Representation, Object Classification, Object State, Object Uncertainty, Object Separation, Object Consolidation, Object Change, Object Correction, Object Reassessment, and Object Continuity.
LOS does not determine:
Liability Basis, Liability Subjects, Liability Relationships, Liability Conditions, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Liability Transfer, Liability Recourse, Liability Resolution, or Liability Finality.
It does not replace governance of the underlying occurrence, Harm, operational mechanism, Claim, AI behavior, autonomous action, evidence, or other externally governed object.
LOS ends when the Liability Object is sufficiently identified, bounded, distinguished, represented, and continuous for Liability Basis governance.
Canonical Closing Statement
Liability cannot be governed reliably when the matter to which Liability is supposed to relate remains undefined.
An occurrence may contain several governed matters. Harm may exist without being the Liability Object. A Claim may describe an object differently from the object established through governance. A product, action, omission, system, obligation, or operational mechanism may be relevant without itself constituting the complete object against which Liability should be evaluated.
LOS resolves that ambiguity before Liability Basis, Relationships, Conditions, Connection, or Determination are formed.
It establishes what the Liability inquiry is about without deciding whether Liability exists.
Occurrence ≠ Harm ≠ Liability Object ≠ Liability Relationship.
Define the object before determining Liability in relation to it.