LORM — Liability Object Representation Module
LORM — Liability Object Representation 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 Representation
Module ID: LIGA-LOS-LORM-001
Origin ID: OOF.CM.LIGA.02.04.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 Representation Module (LORM) governs how a Distinguished Liability Object is formally represented, described, structured, referenced, classified, and made consistently interpretable so that the same governed matter can be used across subsequent Liability governance without semantic drift, hidden assumptions, premature Liability conclusions, or loss of distinction from adjacent governed concepts.
LORM governs the transition:
Distinguished Liability Object → Representation Formation → Semantic Structuring → Representation Validation → Represented Liability Object Its foundational distinction is:
Representation of the Liability Object ≠ Liability Determination about the Liability Object.
Operational Role
The operational role of LORM is:
to convert a sufficiently identified, bounded, and distinguished Liability Object into a stable governed representation that can be consistently understood and referenced throughout the remaining LIGA™ lifecycle.
LOIM identifies the Object Candidate.
LOBM establishes its boundary.
LODM establishes its distinction.
LORM establishes its formal representation.
Its central operational question is:
How must this Liability Object be represented so that every later governance stage refers to the same governed matter without embedding an ungoverned Liability conclusion?
Position in the Parent Standard Flow
The internal LOS progression is:
Object Identification → Object Boundary → Object Distinction → Object Representation → Object Continuity LORM governs:
Object Representation
Its principal input is:
Distinguished Liability Object
Its principal output is:
Represented Liability Object
The canonical transition is:
Distinguished Liability Object → Object Representation Governance → Represented Liability Object → Object
Continuity Governance
Governed Space
LORM governs Liability Object Representation.
Its governed space includes:
Object Naming, Object Description, Object Identity Reference, Object Type, Object Classification, Object Boundary Representation, Object Component Representation, Object State, Object Context Association, Object Distinction References, Object Uncertainty Representation, Object Assumption Representation, Composite Object Representation, Multi-Object Representation, representation granularity, semantic neutrality, machine interpretability, representation consistency, representation correction, and representation readiness.
LORM represents the Object.
It does not determine Liability.
Representation Formation
A Distinguished Liability Object must be transformed into an explicit governed representation.
The representation should make the Object understandable without requiring later governance stages to reconstruct its meaning independently.
The canonical progression is:
Distinguished Liability Object
↓
Representation Elements Identified
↓
Canonical Object Description Formed
↓
Boundary & Distinction References Attached
↓
State / Uncertainty / Assumptions Represented
↓
Representation Consistency Tested
↓
Represented Liability Object
Representation Purpose
The purpose of Object Representation is not merely documentation.
It provides a stable semantic reference for later LIGA™ governance.
A sufficiently governed representation should allow later stages to answer:
Which Object is being evaluated?
What constitutes it?
What does not constitute it?
How is it identified?
What type of matter is it?
Which Context does it belong to?
Which uncertainty remains?
Which assumptions affect its current representation?
Without this stability, later Liability governance may unintentionally operate on different interpretations of the same Object.
Canonical Object Representation
A Canonical Object Representation should provide a single authoritative governed representation of the Liability Object for the relevant governance state.
It may contain:
Object Identity
Canonical Object Name or Reference
Canonical Object Description
Object Type
Object Classification
Object Boundary Reference
Material Components
Relevant Context Reference
Object Distinction References
Object State
Uncertainty State
Material Assumptions
Representation Version
where applicable.
The canonical representation does not eliminate underlying evidence or source records.
It provides the governed methodological representation of the Object.
Object Naming
A Liability Object may require a human-readable name.
The name should:
identify the matter clearly, remain sufficiently neutral, avoid ungoverned conclusions, and remain distinguishable from adjacent Objects.
Names such as:
“negligent maintenance failure,” “illegal system action,” or “liable product defect” may improperly encode conclusions not yet established.
Therefore:
Object Name ≠ Liability Conclusion.
Object Description
The Object Description should explain what the governed matter is.
It should be:
specific, bounded, neutral, traceable, and consistent with prior LOS governance.
The description must not silently expand or contract the Object Boundary.
Therefore:
Object Description ≠ Authority to Redefine the Object.
Where the description reveals a boundary problem, the matter should return to LOBM rather than changing the Object silently through wording.
Object Identity Reference
The representation must maintain a stable reference to Object Identity.
The reference may remain constant even where:
the description changes, the representation is corrected, new information emerges, or the Object state changes.
Therefore:
Object Identity ≠ Object Representation Version.
One Object may have multiple representation states while maintaining one continuous Object Identity.
Object Type
LORM may represent an Object Type to support interpretation and governance.
Possible types may include:
action, omission, transaction, decision, product-related matter, service-related matter, system operation, system state, contract-related matter, condition, process, sequence, composite matter, or another appropriate type.
Object Type describes the nature of the governed matter.
It does not determine Liability.
Therefore:
Object Type ≠ Liability Type.
Object Classification
An Object may require one or more methodological classifications.
Classification may assist:
routing, comparison, interoperability, analytics, automation, or later governance.
However:
Object Classification ≠ Liability Classification.
Classification must not be used to infer automatically:
Liability Basis, Liability Attachment, Liability Scope, or Liability Allocation.
Object Boundary Representation
The Canonical Object Representation should reference the established Object Boundary.
Where useful, it may represent:
included elements, excluded but related elements, open boundaries, boundary uncertainty, shared components, cross-environment extent, and temporal extent.
The representation must not silently alter those states.
Therefore:
Boundary Representation ≠ Boundary Governance.
LOBM owns the Object Boundary.
LORM represents its governed output.
Component Representation
Composite Liability Objects may contain multiple components.
LORM must permit explicit representation of:
component identities, component roles, component relationships, shared components, and component status.
A component must not be mistaken for the complete Object.
Therefore:
Object Component ≠ Complete Liability Object by default.
Composite Object Representation
A Composite Liability Object should be represented in a way that preserves both:
the identity of the composite whole, and the identities of materially relevant components.
The canonical structure may be:
Composite Object
→ Component A → Component B → Component C The representation should make clear why the components belong to one Object without treating their aggregation as proof of Liability.
Multiple Object Representation
One Liability Context may contain multiple Liability Objects.
LORM must ensure that each Object remains separately representable.
The representation should prevent:
Object A attributes being assigned to Object B, Object B evidence being treated automatically as Object A evidence, or shared context being interpreted as shared Object Identity.
Therefore:
Shared Context ≠ Shared Object Representation.
Object State Representation
LORM should represent the current Object Governance State.
Possible states may include:
Identified
Bounded
Distinguished
Represented
Uncertain
Disputed
Under Reassessment
Superseded
or another controlled state.
Object State describes the state of Object Governance.
It does not describe whether Liability exists.
Therefore:
Object State ≠ Liability State.
Context Association
Every represented Liability Object should remain traceably associated with its Governed Liability Context.
The representation should identify the relevant Context without collapsing Object and Context.
Therefore:
Context Association ≠ Context Identity.
The Object remains a distinct governed object within or in relation to its Context.
Distinction References
Where materially useful, the representation should preserve explicit distinction references showing that the Object is not identical to adjacent governed concepts.
Examples may include:
Object ≠ Harm Object ≠ Claim Object ≠ Liability Subject Object ≠ Operational Mechanism Object ≠ Liability Basis These references can prevent downstream semantic drift.
Neutral Representation
The Liability Object must be represented neutrally.
The representation must not presume:
fault, breach, negligence, wrongdoing, causation, responsibility, accountability, Liability, or legal outcome unless such states have already been independently governed and are legitimately required as contextual references.
The canonical principle is:
Representation Must Not Predetermine Liability.
Descriptive Fact and Evaluative Conclusion
LORM must distinguish descriptive representation from evaluative conclusion.
For example:
“System executed transaction X at T1” is structurally different from:
“System wrongfully executed transaction X.” The second formulation contains an evaluative conclusion.
Therefore:
Description of Object ≠ Evaluation of Object.
This distinction is especially important before Liability Basis and Determination governance.
Assertion and Representation
A Claim, participant, authority, organization, or other source may assert a description of the Object.
That assertion may be relevant.
It does not automatically become the Canonical Object Representation.
Therefore:
Asserted Description ≠ Canonical Object Representation.
Where assertions are retained, they should remain attributable to their source.
Evidence and Representation
Evidence may support the Object Representation.
However:
Evidence ≠ Object Representation.
Evidence describes or supports aspects of the Object.
LORM structures the governed representation.
ADIT® governs evidence integrity, provenance, and auditability.
LORM should preserve references to relevant governed evidence where needed without absorbing evidence governance.
Representation and Operational Reality
ORA™ may establish the Operational Reality underlying the Object.
LORM may represent relevant ORA™ outputs.
However:
Operational Reality Representation ≠ Liability Object Representation by default.
The Liability Object is represented specifically for Liability governance while preserving the original governed meaning of external objects.
Representation and Harm
Where Harm is relevant, LORM may reference a governed HAGA™ Harm object or state.
It must not silently represent the Harm as the Liability Object unless LOS has explicitly established that relationship.
Therefore:
Harm Representation ≠ Liability Object Representation by default.
Representation and Claims
A Claim may contain its own representation of the matter.
LORM must preserve the distinction between:
Claim Representation
and:
Canonical Liability Object Representation.
A Claim may change without requiring the Liability Object Representation to change.
Likewise, the Object Representation may be corrected without altering the Claim itself.
Representation Across Systems
The same Liability Object may need to be represented across:
governance platforms, databases, AI systems, audit systems, claims systems, organizational systems, or external interfaces.
Interoperability requires preservation of Object Identity and meaning across those representations.
Therefore:
Representation Transfer ≠ Object Transformation.
A change in technical format must not silently change the governed meaning of the Object.
Human-Readable Representation
The Object should be understandable to authorized human users.
Human-readable representation should clearly communicate:
what the Object is, its relevant boundary, its principal components, its state, and material uncertainty.
Clarity must not be achieved by replacing methodological precision with simplified but misleading terminology.
Machine-Readable Representation
Where machine processing is used, the representation should support structured interpretation of:
Object Identity, Object Type, Object Boundary references, Context references, component relationships, Object State, uncertainty, assumptions, and representation version.
Machine readability must preserve the same governed meaning as the human-readable representation.
Therefore:
Machine-Readable Representation ≠ Separate Object Meaning.
Representation Consistency
Different representations of the same Liability Object must remain semantically consistent.
A database record, human-readable report, API object, AI-readable structure, or audit record may use different formats.
Those formats must not create different Object meanings.
Therefore:
Format Difference ≠ Meaning Difference.
Where representations conflict materially, reconciliation is required.
Representation Granularity
Representation should provide enough detail for downstream governance without reproducing the entire Liability Context.
Too little detail may create ambiguity.
Too much detail may obscure the Object by importing unrelated context.
Therefore:
More Representation Detail ≠ Better Representation by default.
The correct level is:
Sufficient Semantic Granularity.
Representation of Uncertainty
Where Object meaning, boundary, classification, or another representation element remains uncertain, the uncertainty must be explicit.
Possible states may include:
Established
Partially Established
Uncertain
Disputed
Inferred
Under Reassessment
The representation must not convert uncertainty into certainty merely for technical convenience.
Therefore:
Structured Representation ≠ Established Certainty.
Representation of Assumptions
Material assumptions affecting Object Representation must remain visible.
Examples may include:
assumed component identity, assumed sequence membership, assumed system state, or assumed relationship between object elements.
Therefore:
Represented Assumption ≠ Established Fact.
Assumptions should remain distinguishable from verified representation elements.
Representation Conflict
Two systems, participants, or records may contain materially different representations of the same Object.
LORM should identify such conflict.
The system should not resolve the conflict merely by selecting the latest or most convenient description.
Possible responses include:
reconciliation, validation, return to Object Distinction, return to Object Boundary, or preservation of competing representations.
Therefore:
Representation Conflict ≠ Automatic Canonical Replacement.
Representation Drift
Representation Drift occurs when the description or structured representation of an Object changes incrementally while the change is not explicitly governed.
This may alter:
scope, meaning, components, classification, or implied Liability interpretation.
LORM must detect and prevent silent Representation Drift.
Therefore:
Representation Change Must Be Governed.
Representation Correction
A representation may later be shown to be inaccurate.
LORM must permit correction.
The canonical pattern is:
Representation V1 → Error Identification → Corrected Representation V2 The correction should preserve:
the earlier representation, the reason for correction, the corrected element, and the relationship between versions.
Therefore:
Representation Correction ≠ Historical Erasure.
Representation Reassessment
New information may require reassessment of the representation.
Reassessment may:
change the description, change classification, change represented components, change uncertainty, or reveal that Boundary or Distinction governance must be reopened.
LORM must route such issues appropriately.
It must not solve a Boundary or Distinction problem merely by rewriting the representation.
Therefore:
Representation Reassessment ≠ Authority to Redefine the Object.
Representation Sufficiency
The Object Representation is sufficient when later governance can reliably determine:
which Object is being referenced, what it means, what constitutes it, what remains outside it, which Context it belongs to, which material uncertainty remains, and which representation state is current.
Perfect descriptive completeness is not required.
Therefore:
Representation Sufficiency ≠ Exhaustive Description.
Representation Readiness
A Represented Liability Object is ready for Object Continuity governance when:
Object Identity is stable, the Object is neutrally described, its Boundary is represented, its distinctions are preserved, its relevant components are represented, uncertainty and assumptions are visible, and representation conflicts are sufficiently controlled.
Readiness does not establish Liability.
Minimum Implementation Framework
A conforming implementation of LORM must provide at least the following eight capabilities:
Canonical Object Representation
Capability to create a stable governed representation containing Object Identity, description, type, classification, state, Context association, and other materially necessary representation elements.
Boundary & Component Representation
Capability to represent Object Boundary, included components, excluded-but-related elements, Composite Object structure, and multiple Object relationships without silently changing the governed boundary.
Semantic Neutrality & Distinction Preservation
Capability to represent the Object without embedding ungoverned conclusions and to preserve its distinction from Harm, Claims, Subjects, Basis, mechanisms, consequences, and other adjacent concepts.
Uncertainty & Assumption Representation
Capability to represent uncertainty, disputes, inference, assumptions, and incomplete states without converting them into false certainty.
Human & Machine Interpretability
Capability to provide semantically consistent human-readable and machine-readable representations suitable for interoperable governance use.
Cross-System Representation Consistency
Capability to preserve Object Identity and meaning across different systems, formats, interfaces, and technical representations and to detect material representation conflicts.
Representation Change, Correction & Reassessment
Capability to govern representation changes, corrections, conflicts, and reassessment while preserving prior states and routing Boundary or Distinction issues back to the appropriate governance function.
Representation Sufficiency & Readiness Determination
Capability to determine when the Object Representation is sufficiently stable, neutral, interpretable, and traceable for Object Continuity governance.
Governance Logic
The canonical LORM governance logic is:
Distinguished Liability Object
↓
Establish Canonical Object Identity Reference
↓
Create Neutral Object Name and Description
↓
Represent Object Type / Classification / State
↓
Represent Object Boundary
↓ Represent Components / Composite Structure where applicable ↓
Associate Governed Liability Context
↓
Preserve Critical Object Distinctions
↓
Represent Uncertainty and Assumptions
↓
Establish Human-Readable and Machine-Readable Forms
↓
Test Cross-System Semantic Consistency
↓
Detect Representation Conflict / Drift
↓
Assess Representation Sufficiency
If insufficient:
Clarify / Reconcile / Correct / Reassess / Return to Boundary or Distinction Governance
If sufficient:
↓
Represented Liability Object
↓
Handoff to Object Continuity Governance
Materially new information may trigger:
Representation Reassessment → Corrected or Revised Representation without silently redefining the Object.
Governance Outputs
LORM may produce:
Canonical Liability Object Representation
Object Identity Reference
Canonical Object Name
Canonical Object Description
Object Type
Object Classification
Object State Representation
Object Boundary Reference
Object Component Representation
Composite Object Representation
Context Association Record
Object Distinction Reference Set
Object Uncertainty State
Object Assumption Record
Human-Readable Object Representation
Machine-Readable Object Representation
Representation Conflict State
Representation Change Record
Representation Correction Record
Representation Version
Representation Sufficiency State
The principal output is:
Represented Liability Object
The canonical handoff is:
Represented Liability Object → Object Continuity Governance
Critical Distinctions
LORM preserves the following distinctions:
Representation of the Liability Object ≠ Liability Determination about the Liability Object Object Name ≠ Liability Conclusion Object Description ≠ Authority to Redefine the Object Object Identity ≠ Object Representation Version Object Type ≠ Liability Type Object Classification ≠ Liability Classification Boundary Representation ≠ Boundary Governance Object Component ≠ Complete Liability Object by default Shared Context ≠ Shared Object Representation Object State ≠ Liability State Context Association ≠ Context Identity Description of Object ≠ Evaluation of Object Asserted Description ≠ Canonical Object Representation Evidence ≠ Object Representation Operational Reality Representation ≠ Liability Object Representation by default Harm Representation ≠ Liability Object Representation by default Claim Representation ≠ Canonical Liability Object Representation Representation Transfer ≠ Object Transformation Machine-Readable Representation ≠ Separate Object Meaning Format Difference ≠ Meaning Difference More Representation Detail ≠ Better Representation by default Structured Representation ≠ Established Certainty Represented Assumption ≠ Established Fact Representation Conflict ≠ Automatic Canonical Replacement Representation Correction ≠ Historical Erasure Representation Reassessment ≠ Authority to Redefine the Object Representation Sufficiency ≠ Exhaustive Description
Cross-Architecture Boundary
LORM may represent references to governed outputs from other OOF® architectures without absorbing their governed meaning.
LCS provides the Governed Liability Context.
ORA™ may provide Operational Reality objects and states relevant to the Object.
HAGA™ may provide governed Harm references.
AGA™ may provide Authority, Responsibility, Accountability, or Attribution references.
ADIT® governs evidence supporting or documenting the representation.
VALIDOS™ governs Validation of relevant inputs.
OBIDENITY® may provide persistent Identity, Origin, Ownership, Provenance, Authority, Permission, Transfer, or Continuity references.
AIG® may provide AI behavior objects or states.
ASGA™ may provide autonomous-system objects or states.
SIMULOS® may provide Simulation objects or states.
PGA™ may provide Prediction objects.
VFM® may provide Value objects or states.
LORM may reference these objects.
It does not redefine them.
The governing principle is:
Representation for Liability Governance does not transfer ownership of the represented object from its original governed domain.
Canonical Boundary
LORM begins with a:
Distinguished Liability Object
and governs its formal representation for continued LIGA™ use.
LORM governs:
Object Naming, Object Description, Object Identity Reference, Object Type, Object Classification, Object Boundary Representation, Object Component Representation, Composite Object Representation, Object State Representation, Context Association, Distinction References, Uncertainty Representation, Assumption Representation, human readability, machine readability, cross-system consistency, Representation Conflict, Representation Drift, Representation Correction, Representation Reassessment, and Representation Sufficiency.
LORM does not establish or redefine:
Object Boundary, Object Distinction, 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.
LORM ends when the Liability Object is sufficiently represented for Object Continuity governance.
Use Case 1 — AI-Generated Operational Action
An AI-enabled system executes an operational action that becomes the subject of Liability Object governance.
LOIM identifies the relevant Object Candidate.
LOBM establishes the Object Boundary.
LODM distinguishes the Object from:
the AI system, the resulting Harm, the wider incident, the Claim, and the potential Liability Subjects.
LORM then creates a neutral representation of the governed Object.
Instead of describing it as:
“the AI system's negligent action,” the representation records the specific execution sequence, relevant Object Boundary, Context reference, system state, uncertainty, and Object Identity without assuming negligence or Liability.
Later LIGA™ standards can therefore evaluate the same Object without inheriting a premature conclusion.
Use Case 2 — Industrial Equipment Matter
A Liability Object concerns a specific equipment state and maintenance-related sequence.
Several systems refer to the matter differently:
the maintenance system uses a work-order number, the operational system uses an incident identifier, the supplier uses a component reference, and a Claim describes the matter as a product defect.
LORM establishes one Canonical Liability Object Representation linking those references while preserving their distinct meanings.
The technical identifiers may differ.
The governed Object meaning does not.
This allows later Liability governance to operate on one consistently represented matter.
Canonical Closing Statement
A Liability Object that cannot be represented consistently cannot remain stable across a complex Liability lifecycle.
Different people, systems, organizations, Claims, evidence records, and AI processes may describe the same matter differently. Those representations may vary in format, terminology, granularity, certainty, and purpose.
LORM creates a governed semantic anchor.
It allows the Liability Object to be represented across systems and stages without allowing description to become determination, formatting to become meaning, or assertion to become fact.
A representation may describe the object. It must not decide the Liability attached to it.
Represent the same object consistently before asking different governance systems to reason about it.