LOBM — Liability Object Boundary Module
LOBM — Liability Object Boundary 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 Boundary
Module ID: LIGA-LOS-LOBM-001
Origin ID: OOF.CM.LIGA.02.02.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 Boundary Module (LOBM) governs how the boundary of an Identified Liability Object Candidate is established, tested, refined, and maintained so that the matter constituting the Liability Object is explicitly separated from surrounding context, adjacent matters, external mechanisms, related consequences, and other Object Candidates without prematurely determining Liability Basis, Liability Relationships, Liability Conditions, Liability Connection, Liability Scope, or Liability itself.
LOBM governs the transition:
Identified Liability Object Candidate → Boundary Candidate → Inclusion & Exclusion Evaluation → Object Boundary Establishment → Bounded Liability Object Its foundational distinction is:
Liability Object Boundary ≠ Liability Scope.
Operational Role
The operational role of LOBM is:
to determine what belongs inside the Liability Object and what remains outside it so that subsequent Liability governance evaluates a stable and explicitly bounded matter.
LOIM identifies the candidate.
LOBM establishes its boundary.
Its central operational question is:
What constitutes this Liability Object, and where does the object end?
Position in the Parent Standard Flow
The internal LOS progression is:
Object Identification → Object Boundary → Object Distinction → Object Representation → Object Continuity LOBM governs:
Object Boundary
Its principal input is:
Identified Liability Object Candidate
Its principal output is:
Bounded Liability Object
The canonical transition is:
Identified Liability Object Candidate → Object Boundary Governance → Bounded Liability Object → Object
Distinction Governance
Governed Space
LOBM governs Liability Object Boundary.
Its governed space includes:
Boundary Candidate formation, Object inclusion, Object exclusion, boundary granularity, component membership, adjacent matter separation, composite boundary formation, multi-object boundary separation, boundary overlap, boundary dependency, cross-environment boundaries, temporal object boundaries, boundary uncertainty, boundary conflict, boundary change, boundary correction, boundary reassessment, and boundary sufficiency.
LOBM determines the extent of the governed object.
It does not determine the extent of Liability.
Boundary Candidate Formation
An Identified Liability Object Candidate requires a provisional Boundary Candidate.
The Boundary Candidate represents an initial proposition concerning what constitutes the object.
It may be based on:
the candidate identity, the Governed Liability Context, material actions, material omissions, relevant states, object components, temporal relationships, environmental relationships, or other governed information.
The Boundary Candidate remains subject to evaluation.
Therefore:
Boundary Candidate ≠ Established Object Boundary.
Object Inclusion
LOBM determines which elements belong inside the Liability Object.
An element should be included where it is materially constitutive of the object being governed.
The governing question is:
Would exclusion of this element materially change what the Liability Object is?
Possible included elements may involve:
actions, omissions, transactions, decisions, system operations, product states, service performances, operational conditions, or materially inseparable sequences.
Inclusion establishes Object Membership.
It does not establish Liability relevance beyond the object itself.
Object Exclusion
LOBM must also explicitly determine what remains outside the Liability Object.
An element may be:
contextually relevant, evidentially relevant, temporally related, operationally connected, or associated with a potential Liability Subject without being part of the object itself.
Therefore:
Object Relevance ≠ Object Membership.
Exclusion from the object does not mean global irrelevance.
It means only that the matter does not constitute this Liability Object.
Context Boundary and Object Boundary
The Liability Context may be substantially broader than the Liability Object.
The Context Boundary answers:
What circumstances belong within the relevant Liability Context?
The Object Boundary answers:
What constitutes the specific matter against which potential Liability will be structured?
Therefore:
Liability Context Boundary ≠ Liability Object Boundary.
A matter may remain inside the Context while remaining outside the Object.
Object Boundary and Liability Scope
Liability Scope is governed later under LSAS.
Object Boundary must not be used to determine Liability Scope prematurely.
The Object Boundary establishes:
what the governed matter is.
Liability Scope later establishes:
for what and to what extent established Liability applies.
Therefore:
Liability Object Boundary ≠ Liability Scope.
A broad Object does not establish broad Liability.
A narrow Object does not establish narrow Liability.
Object Boundary and Liability Basis
LOBM must not expand or contract the object merely to make a particular Liability Basis easier to apply.
The object should be bounded according to its governed identity.
Therefore:
Object Boundary ≠ Liability Basis Boundary.
A possible Basis may later apply to all, part, or none of the Object.
The Object Boundary must remain independently governed.
Object Boundary and Liability Relationship
The existence of several potentially involved parties does not determine the Object Boundary.
Likewise, an Object Boundary must not be expanded merely because additional Liability Subjects or Relationships may later become relevant.
Therefore:
Object Boundary ≠ Liability Relationship Boundary.
One Object may participate in several Liability Relationships.
Object Boundary and Harm
Harm may exist within, outside, or downstream from the Liability Object depending on the matter.
LOBM must not assume:
Harm Boundary = Liability Object Boundary.
HAGA™ governs Harm Boundary.
LOS governs Liability Object Boundary.
Therefore:
Harm Boundary ≠ Liability Object Boundary.
The two may overlap without becoming identical.
Object Boundary and Occurrence
An occurrence may contain more material than the Liability Object.
Alternatively, the Liability Object may span several occurrences.
Therefore:
Occurrence Boundary ≠ Liability Object Boundary by default.
LOBM must determine the object independently from the mere start and end of an occurrence.
Object Boundary and Claim
A Claim may define its own asserted scope.
LOBM must not adopt that scope automatically.
Therefore:
Claim Scope ≠ Liability Object Boundary.
A Claim may:
combine several objects, omit part of an object, include contextual information outside the object, or define the matter according to procedural rather than methodological needs.
Object Boundary and Operational Mechanism
An operational mechanism may be related to the Liability Object without forming part of the object itself.
For example:
physical contact, software execution, data transfer, mechanical movement, communication, payment, or autonomous action may be a mechanism relevant to the matter.
Therefore:
Mechanism Boundary ≠ Liability Object Boundary by default.
The architecture governing the mechanism retains ownership of that governed space.
Boundary Granularity
The Object Boundary must be sufficiently granular to preserve the identity of the matter.
Too broad a boundary may combine distinct Liability Objects.
Too narrow a boundary may fragment one coherent Object.
Therefore:
Largest Possible Boundary ≠ Correct Object Boundary.
and:
Smallest Possible Boundary ≠ Correct Object Boundary.
The correct boundary is the one that preserves the governed meaning of the Liability Object.
Materiality of Membership
Object membership should depend on materiality to Object Identity.
An element should not be included merely because it is:
nearby, related, available, documented, temporally close, or connected through a participant.
The relevant test is whether the element is materially constitutive of the governed matter.
Therefore:
Association ≠ Object Membership.
Temporal Object Boundary
A Liability Object may require a temporal boundary.
For example, an object concerning a continuing system operation may need a defined start and end period.
However:
Temporal Proximity ≠ Object Membership.
An event occurring immediately before or after the object is not automatically part of it.
LCTM provides relevant temporal context.
LOBM determines whether temporal elements form part of the Object Boundary.
Open-Ended Temporal Objects
Some Liability Objects may not have a known terminal moment when initially bounded.
Examples may include:
continuing conduct, ongoing system behavior, persistent conditions, repeated service performance, or unresolved operational processes.
LOBM may therefore establish an:
Open Temporal Boundary
where appropriate.
Open does not mean undefined.
The boundary must specify why and where it remains open.
Cross-Environment Object Boundary
A Liability Object may span multiple environments.
For example:
a digital action may produce a physical consequence, a test environment may interact with production, or an organizational process may span several companies.
Therefore:
One Liability Object ≠ One Environment by default.
LCEM governs the environmental structure.
LOBM determines which environmental elements constitute the object.
Environment Membership and Object Membership
An element may exist in a relevant environment without forming part of the Liability Object.
Therefore:
Environment Membership ≠ Object Membership.
Likewise, an object may span several environments without those environments becoming one environment.
LOBM preserves Object Membership independently from Environment Identity.
Composite Object Boundary
Where a candidate appears composite, LOBM must determine whether its components belong within one Object Boundary.
A Composite Liability Object may contain several materially inseparable components.
The canonical structure may be:
Component A + Component B + Component C → Composite Object Boundary However:
Multiple Components ≠ Multiple Liability Objects by default.
The components must be evaluated according to their contribution to Object Identity.
Multiple Object Boundaries
Where several candidates remain distinct, each requires its own Object Boundary.
The structure may be:
Context
→ Object A Boundary → Object B Boundary → Object C Boundary These boundaries may:
overlap, interact, share contextual elements, or depend on common mechanisms.
That does not eliminate their separate Object Identities.
Boundary Overlap
Two Liability Objects may share one or more elements.
Therefore:
Object Boundary Overlap ≠ Object Identity.
For example, two objects may share:
a system, a transaction, a participant, a time period, or an operational condition.
LOBM must preserve the overlap without automatically consolidating the objects.
Shared Component
A component may participate in more than one Liability Object.
This may occur where one system action forms part of several separately governed matters.
Therefore:
Shared Component ≠ Single Liability Object by default.
The component may be represented in multiple Object Boundaries while retaining traceability to the same underlying operational element.
Object Dependency
One Liability Object may depend upon another.
For example:
Object B may exist only because Object A occurred earlier.
Dependency does not automatically merge their boundaries.
Therefore:
Object Dependency ≠ Object Unity.
Dependency may later become relevant to Liability Connection or other governance stages.
LOBM governs only whether the objects remain structurally separate.
Boundary Interaction
Separate Object Boundaries may interact.
Interaction may involve:
shared components, shared environments, shared time periods, shared operational mechanisms, or direct object-to-object dependencies.
LOBM must represent such interactions without automatically expanding either boundary.
Therefore:
Object Interaction ≠ Boundary Merger by default.
Boundary Expansion
New information may establish that the existing Object Boundary is too narrow.
LOBM may expand the boundary where additional elements are shown to be materially constitutive of the same Liability Object.
The canonical pattern is:
Object Boundary V1 → New Material Information → Boundary Expansion → Object Boundary V2 However:
Boundary Expansion ≠ New Liability Object by default.
Object Continuity must be preserved.
Boundary Contraction
New information may establish that the Object Boundary is too broad.
LOBM may remove elements that are contextual or related but not constitutive of the object.
The canonical pattern is:
Object Boundary V1 → Boundary Reassessment → Boundary Contraction → Object Boundary V2 However:
Boundary Contraction ≠ Historical Deletion.
The earlier boundary state must remain reconstructable.
Boundary Separation
An Object Boundary may initially contain matters that later require separation.
The canonical pattern may be:
Object A → Boundary Reassessment → Object A1 + Object A2 Separation is appropriate where continued aggregation would distort the governed meaning of the objects.
However:
Boundary Complexity ≠ Automatic Separation.
The separation must be methodologically justified.
Boundary Consolidation
Separate Object Candidates may later be shown to form one materially coherent Object.
The canonical pattern may be:
Object A + Object B → Boundary Consolidation → Composite Object C Consolidation must preserve the prior Object and Boundary history.
Therefore:
Boundary Consolidation ≠ Historical Identity.
Boundary Uncertainty
The correct Object Boundary may initially be uncertain.
LOBM must permit states such as:
Established
Partially Established
Open
Uncertain
Disputed
Competing Boundary
Under Reassessment
where appropriate.
Therefore:
Boundary Uncertainty ≠ Boundary Absence.
A partially governed boundary may still support continued governance if uncertainty is explicitly represented.
Competing Boundaries
Different plausible interpretations may produce different Boundary Candidates.
For example:
one boundary may include an entire deployment process, while another may include only a specific execution sequence.
LOBM should preserve competing boundaries where available information does not yet justify convergence.
Competing Boundary ≠ Governance Failure.
Premature certainty may create greater methodological error than explicit uncertainty.
Boundary Assumptions
Boundary formation may depend on assumptions.
Such assumptions must remain visible.
Examples may include:
assumed sequence membership, assumed component integration, assumed continuity, or assumed object dependency.
Therefore:
Boundary Assumption ≠ Established Object Membership.
A change in an assumption may trigger Boundary Reassessment.
Evidence and Object Boundary
Evidence may support the inclusion or exclusion of elements.
However:
Evidence Coverage ≠ Object Boundary.
A lack of evidence concerning one component does not automatically establish that the component lies outside the Object Boundary.
Likewise, abundant evidence concerning an element does not automatically make it part of the object.
ADIT® governs evidence.
LOBM governs Object Boundary.
Boundary Correction
An established Object Boundary may later be shown to be incorrect.
LOBM must permit correction while preserving the earlier state.
The canonical structure is:
Previous Boundary → Error Identification → Corrected Boundary Therefore:
Boundary Correction ≠ Boundary History Erasure.
The reason for correction should remain traceable.
Boundary Reassessment
Materially new information may trigger Boundary Reassessment.
Reassessment may:
confirm the existing boundary, expand it, contract it, separate the object, consolidate objects, change an open boundary, or resolve boundary uncertainty.
Reassessment must preserve prior states.
Therefore:
Boundary Reassessment ≠ New Liability Object by default.
Boundary Stability
An Object Boundary must become sufficiently stable before Object Distinction governance can proceed reliably.
Stability does not require permanent immutability.
It means the boundary is sufficiently established for later governance to understand what matter is being distinguished from adjacent objects and concepts.
Therefore:
Boundary Stability ≠ Boundary Permanence.
Boundary Sufficiency
LOBM does not require absolute certainty.
The relevant threshold is whether the Object Boundary is sufficiently governed for Object Distinction.
A sufficient boundary should identify:
what is included, what is excluded, which elements remain uncertain, which overlaps exist, which components are shared, and whether any boundary remains open.
Therefore:
Boundary Sufficiency ≠ Boundary Completeness.
Minimum Implementation Framework
A conforming implementation of LOBM must provide at least the following eight capabilities:
Boundary Candidate Formation
Capability to form a provisional Object Boundary from an Identified Liability Object Candidate and its Governed Liability Context.
Object Inclusion & Exclusion Governance
Capability to determine which elements materially constitute the Liability Object and which related or contextual elements remain outside it.
Boundary Granularity & Component Governance
Capability to establish appropriate Object Boundary granularity and govern component membership without artificial fragmentation or aggregation.
Composite, Multiple & Overlapping Boundary Governance
Capability to represent Composite Objects, multiple Object Boundaries, overlapping boundaries, shared components, and object dependencies without automatically merging distinct objects.
Temporal & Cross-Environment Boundary Governance
Capability to establish temporal and cross-environment Object Boundaries while distinguishing Object Membership from temporal proximity or Environment Membership.
Boundary Uncertainty, Conflict & Assumption Governance
Capability to preserve open, uncertain, disputed, competing, and assumption-dependent Object Boundaries without forcing premature certainty.
Boundary Change, Correction & Reassessment
Capability to expand, contract, separate, consolidate, correct, and reassess Object Boundaries while preserving prior states and Object Continuity.
Boundary Sufficiency Determination
Capability to determine when the Object Boundary is sufficiently established and stable for Object Distinction governance.
Governance Logic
The canonical LOBM governance logic is:
Identified Liability Object Candidate
↓
Form Boundary Candidate
↓ What materially constitutes this Liability Object?
↓
Identify Included Elements
↓ Identify Excluded but Related Elements ↓
Evaluate Boundary Granularity
↓
Evaluate Components
↓
Evaluate Composite / Multiple Object Structure
↓
Evaluate Boundary Overlap and Shared Components
↓
Evaluate Temporal and Cross-Environment Extent
↓
Identify Boundary Uncertainty / Assumptions / Competing Boundaries
↓
Test Boundary Against Context / Harm / Claim / Mechanism / Liability Scope Distinctions
↓
Assess Boundary Stability
↓
Assess Boundary Sufficiency
If insufficient:
Clarify / Expand / Contract / Separate / Consolidate / Correct / Reassess Boundary
If sufficient:
↓
Bounded Liability Object
↓
Handoff to Object Distinction Governance
Materially new information may trigger:
Boundary Reassessment → Revised Object Boundary without erasing prior Boundary history.
Governance Outputs
LOBM may produce:
Object Boundary Candidate
Object Inclusion Set
Object Exclusion Set
Object Component Structure
Object Boundary Map
Temporal Object Boundary
Cross-Environment Object Boundary
Composite Object Boundary
Multiple Object Boundary Structure
Boundary Overlap State
Shared Component State
Object Dependency State
Boundary Uncertainty State
Competing Boundary State
Boundary Assumption Record
Boundary Change Record
Boundary Correction Record
Boundary Reassessment Record
Boundary Sufficiency State
The principal output is:
Bounded Liability Object
The canonical handoff is:
Bounded Liability Object → Object Distinction Governance
Critical Distinctions
LOBM preserves the following distinctions:
Boundary Candidate ≠ Established Object Boundary Object Relevance ≠ Object Membership Liability Context Boundary ≠ Liability Object Boundary Liability Object Boundary ≠ Liability Scope Object Boundary ≠ Liability Basis Boundary Object Boundary ≠ Liability Relationship Boundary Harm Boundary ≠ Liability Object Boundary Occurrence Boundary ≠ Liability Object Boundary by default Claim Scope ≠ Liability Object Boundary Mechanism Boundary ≠ Liability Object Boundary by default Largest Possible Boundary ≠ Correct Object Boundary Smallest Possible Boundary ≠ Correct Object Boundary Association ≠ Object Membership Temporal Proximity ≠ Object Membership One Liability Object ≠ One Environment by default Environment Membership ≠ Object Membership Multiple Components ≠ Multiple Liability Objects by default Object Boundary Overlap ≠ Object Identity Shared Component ≠ Single Liability Object by default Object Dependency ≠ Object Unity Object Interaction ≠ Boundary Merger by default Boundary Expansion ≠ New Liability Object by default Boundary Contraction ≠ Historical Deletion Boundary Complexity ≠ Automatic Separation Boundary Consolidation ≠ Historical Identity Boundary Uncertainty ≠ Boundary Absence Boundary Assumption ≠ Established Object Membership Evidence Coverage ≠ Object Boundary Boundary Correction ≠ Boundary History Erasure Boundary Reassessment ≠ New Liability Object by default Boundary Stability ≠ Boundary Permanence Boundary Sufficiency ≠ Boundary Completeness
Cross-Architecture Boundary
LOBM may use governed outputs from other OOF® architectures to determine the extent of a Liability Object without taking ownership of those external governed spaces.
LCS provides the Governed Liability Context and Context Boundary.
ORA™ may establish operational actions, occurrences, mechanisms, states, and boundaries relevant to Object formation.
HAGA™ may provide Harm Boundaries relevant to understanding the matter while remaining distinct from the Liability Object Boundary.
AGA™ may provide Authority, Responsibility, Accountability, or Attribution structures relevant to the context.
ADIT® may provide evidence supporting Object inclusion, exclusion, and boundary reconstruction.
VALIDOS™ may validate boundary-relevant inputs.
OBIDENITY® may provide identity, origin, ownership, provenance, or continuity states useful for distinguishing object components.
AIG® and ASGA™ may provide AI or autonomous-system states and operational boundaries.
SIMULOS® may provide Simulation boundaries.
PGA™ may provide Prediction Object boundaries.
VFM® may provide Value Object structures.
These governed boundaries may inform LOBM.
They do not become Liability Object Boundaries automatically.
A boundary in one governed domain does not become the Liability Object Boundary merely because the domains interact.
Canonical Boundary
LOBM begins with an:
Identified Liability Object Candidate
and governs the establishment of the boundary that defines what constitutes that candidate as a Liability Object.
LOBM governs:
Boundary Candidate Formation, Object Inclusion, Object Exclusion, Boundary Granularity, Component Membership, Composite Object Boundaries, Multiple Object Boundaries, Boundary Overlap, Shared Components, Object Dependency, Temporal Object Boundaries, Cross-Environment Object Boundaries, Boundary Uncertainty, Boundary Assumptions, Boundary Change, Boundary Correction, Boundary Reassessment, and Boundary Sufficiency.
LOBM does not determine:
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.
LOBM ends when the Liability Object Boundary is sufficiently established for Object Distinction governance.
Use Case 1 — AI Action Across Connected Systems
An AI agent performs a task through several connected systems.
The Governed Liability Context includes:
the AI agent, its initiating instruction, a tool call, an external platform, a production database, a human approval step, and a resulting operational action.
LOIM identifies a possible Object Candidate concerning the execution sequence.
LOBM then determines which elements actually constitute that Liability Object.
The existence of the external platform or database within the Context does not automatically place the entire external environment inside the Object Boundary.
Likewise, the resulting consequence is not automatically part of the Object merely because it followed the action.
LOBM establishes a sufficiently precise Object Boundary before later Liability governance begins.
Use Case 2 — Industrial Incident With Maintenance History
An industrial incident occurs after equipment has undergone several maintenance interventions.
The Context contains:
the equipment, historical maintenance, a recent component replacement, operator actions, supplier information, and the resulting incident.
LOIM identifies an Object Candidate concerning the relevant equipment-related matter.
LOBM determines whether the Liability Object includes:
only the recent component replacement, the wider maintenance sequence, the equipment state at the time of the incident, or a materially inseparable combination.
Earlier maintenance may remain contextually relevant without belonging inside the Object Boundary.
The resulting Bounded Liability Object can then proceed to Object Distinction governance without predetermining Liability.
Canonical Closing Statement
A Liability Object is not defined by everything that is connected to it.
Context may be broader than the object. Harm may extend beyond it. Claims may describe it differently. Operational mechanisms may cross it. Evidence may cover only part of it. Multiple objects may overlap without becoming one.
LOBM establishes the boundary that preserves the governed identity of the matter without allowing that boundary to predetermine Liability.
What surrounds the object may explain it. What belongs to the object defines it.
Define the object boundary before determining what the object means for Liability.