LCBM — Liability Context Boundary Module
LCBM — Liability Context Boundary Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Context Standard (LCS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Context Boundary
Module ID: LIGA-LCS-LCBM-001
Origin ID: OOF.CM.LIGA.01.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 Context Boundary Module (LCBM) governs how the boundary of an identified Liability Context is established, represented, tested, adjusted, and preserved so that materially relevant circumstances remain inside the governed context while unrelated, insufficiently relevant, or separately governed matters remain outside it.
LCBM governs the transition:
Identified Liability Context → Boundary Candidate → Boundary Evaluation → Boundary Establishment →
Bounded Liability Context
Its foundational distinction is:
Context Boundary ≠ Liability Scope.
The Context Boundary determines what belongs to the contextual environment requiring Liability governance.
It does not determine what established Liability ultimately covers.
Operational Role
The operational role of LCBM is:
to determine where the identified Liability Context begins and ends without prematurely determining Liability, Liability Scope, Liability Allocation, or the boundaries of other governed objects.
LCIM identifies what context may require governance.
LCBM determines what materially belongs within that context.
Its principal operational question is:
What belongs inside this Liability Context, what remains outside it, and where must the boundary remain open, conditional, or subject to reassessment?
Position in the Parent Standard Flow
The internal LCS progression is:
Context Identification → Context Boundary → Context Environment → Temporal Context → Context Continuity LCBM governs:
Context Boundary
Its principal input is:
Identified Liability Context
Its principal output is:
Bounded Liability Context
The canonical transition is:
Identified Liability Context → Boundary Establishment → Bounded Liability Context → Context Environment
Governance
Governed Space
LCBM governs the methodological boundary of Liability Context.
Its governed space includes:
boundary candidate identification, context inclusion, context exclusion, boundary criteria, boundary uncertainty, boundary permeability, boundary interaction, boundary expansion, boundary contraction, boundary separation, boundary consolidation, cross-boundary relevance, boundary reassessment, and boundary traceability.
LCBM determines contextual membership.
It does not determine Liability.
Context Boundary
A Context Boundary defines which circumstances belong to the governed Liability Context for the purposes of subsequent LIGA™ governance.
The boundary may distinguish:
Inside Context
Outside Context
Adjacent Context
Conditionally Relevant Context
Boundary-Uncertain Context
and
Separately Governed Context
where such distinctions are materially necessary.
A Context Boundary is not required to be purely physical or geographical.
It may be:
organizational, operational, digital, contractual, relational, functional, systemic, temporal, jurisdictional, physical, or composite.
The relevant boundary form depends on the governed matter.
Boundary Establishment Principle
The boundary must be based on material contextual relevance.
It must not be defined merely by:
technical accessibility, physical proximity, organizational membership, data availability, contractual proximity, shared infrastructure, shared ownership, shared participants, or chronological proximity.
These characteristics may be relevant.
None universally defines the Context Boundary.
The governing principle is:
Contextual Proximity ≠ Contextual Membership.
A matter belongs inside the Liability Context because it is materially relevant to the governed context, not merely because it is nearby, connected, available, or visible.
Boundary Inclusion
LCBM must determine which contextual elements require inclusion.
An element should be included where excluding it could materially distort subsequent Liability governance.
Possible inclusion considerations may involve whether the element materially affects:
the meaning of the contextual matter, the relevant environment, the applicable temporal state, the relationships among contextual elements, the formation of the later Liability Object, the potential Liability Basis, the identification of later Liability Subjects or Relationships, the evaluation of Liability Conditions, or the interpretation of Liability-Relevant Connections.
Inclusion does not establish Liability relevance under a jurisdiction-specific legal test.
It establishes contextual relevance within LIGA™.
Boundary Exclusion
LCBM must also determine what should remain outside the Governed Liability Context.
Information or circumstances should not be included merely because they are available.
Exclusion may be appropriate where a matter is:
materially unrelated, duplicative without additional contextual value, outside the relevant contextual lineage, part of a separate Liability Context, governed independently without material contextual effect, or insufficiently connected to affect subsequent Liability governance.
The exclusion of an element from one Liability Context does not establish that the element is irrelevant everywhere.
It may belong to another context or another governance architecture.
Therefore:
Outside This Context ≠ Globally Irrelevant.
Boundary Sufficiency
A Context Boundary must be sufficiently complete to support subsequent governance.
A boundary is insufficient where it materially omits circumstances required to understand the context.
A boundary may also be methodologically weak where it includes excessive unrelated information that obscures the governed matter.
LCBM therefore requires:
Sufficient Boundary Coverage
rather than:
Maximum Boundary Expansion.
The objective is a boundary broad enough to preserve material context and narrow enough to remain governable.
Boundary Granularity
Context boundaries may exist at different levels of granularity.
For example, a matter may involve:
a specific machine, a production line, a facility, an organization, a supplier network, or a wider operational ecosystem.
The widest available boundary is not automatically the correct boundary.
Nor is the narrowest technically identifiable unit.
Boundary granularity must correspond to the material contextual requirements of the Liability matter.
Therefore:
Largest Possible Boundary ≠ Correct Boundary and:
Smallest Possible Boundary ≠ Correct Boundary.
The appropriate boundary is the one that preserves the context necessary for legitimate downstream governance.
Composite Boundaries
Some Liability Contexts cannot be represented through one boundary dimension.
A matter may simultaneously require:
a physical boundary, an organizational boundary, a system boundary, a contractual boundary, and a temporal boundary.
LCBM must permit a Composite Context Boundary where multiple dimensions jointly define the governed context.
A composite boundary does not require all dimensions to align.
For example, an operational process may remain within one organization while crossing several digital systems, physical locations, or contractual relationships.
LCBM must preserve those differences.
Nested Context Boundaries
A Liability Context may contain smaller contextual structures.
For example:
Enterprise Context
may contain:
Facility Context
which may contain:
Operational Process Context
which may contain:
Specific Event Context
where each level remains materially relevant.
LCBM may represent nested contexts without assuming that each nested context constitutes a separate Liability lifecycle.
Therefore:
Nested Context ≠ Separate Liability by default.
Nested boundaries are contextual structures.
Later LIGA™ stages determine whether distinct Liability Objects or Relationships emerge.
Overlapping Context Boundaries
Two Liability Contexts may overlap.
An occurrence may simultaneously be relevant to:
an organizational context, a contractual context, a product context, and an operational context.
Overlap does not require those contexts to be merged.
Nor does it automatically require them to remain separate.
LCBM must preserve the possibility that:
Context A ∩ Context B ≠ Context A = Context B Shared contextual elements may belong legitimately to more than one governed context where their relevance differs.
Boundary Separation
Where identified contextual elements represent materially distinct matters, LCBM must support Context Separation.
Separation may be appropriate where the matters have materially different:
contextual origins, operational environments, time periods, relationship structures, system states, object candidates, or contextual purposes.
The separation decision must remain traceable.
However:
Different Circumstances ≠ Separate Contexts by default.
Separation requires material contextual distinction.
Boundary Consolidation
Apparently separate contextual matters may form one materially continuous Liability Context.
LCBM may consolidate them where their separation would distort the governed context.
Potential indicators include:
a common contextual origin, continuing operational state, shared contextual lineage, continuous system behavior, one evolving condition, or a materially inseparable sequence of events.
However:
Shared Feature ≠ Common Context by default.
Consolidation must be justified by material contextual continuity.
Boundary Permeability
Context Boundaries need not be treated as impermeable walls.
External matters may influence the governed context without becoming fully internal to it.
LCBM may therefore represent:
Internal Context
External Influence
Cross-Boundary Input
Cross-Boundary Output
or
Boundary Interaction
where materially relevant.
This distinction is important where supply chains, platforms, external systems, third parties, environmental conditions, or interconnected infrastructure influence the context.
External Influence ≠ Internal Context Membership.
Cross-Boundary Relationships
A relationship may cross the Context Boundary.
For example:
an external supplier may affect an internal production process, an external AI service may influence an organizational decision, an external system may send information into a controlled environment, or an internal action may produce effects outside the organization.
LCBM must preserve the existence of the cross-boundary relationship without automatically expanding the Context Boundary to include everything connected through it.
Therefore:
Connection Across Boundary ≠ Boundary Expansion by default.
Environment Boundaries
A Context Boundary may correspond partly to an environment boundary.
Examples include:
simulation → operational reality, test → production, private → public, internal network → external network, controlled physical area → uncontrolled area, organization A → organization B.
However:
Environment Boundary ≠ Liability Context Boundary by default.
An environment transition may justify Context Boundary reassessment.
It does not automatically determine the final Liability Context Boundary.
Context Environment is governed separately within LCS.
Authority Across Boundaries
Authority may change when an operational or organizational boundary is crossed.
LCBM may preserve the contextual relevance of that transition.
However, it does not determine whether authority remains valid.
The governing distinction is:
Context Boundary ≠ Authority Boundary although the two may materially interact.
Where relevant:
Capability to cross a boundary ≠ Authority to act beyond that boundary.
Authority governance remains outside LCBM.
LCBM preserves the contextual boundary necessary for the relevant architecture to evaluate it.
Temporal Boundary Interaction
A Context Boundary may change over time.
The context relevant at T1 may not have the same boundary at T2.
For example:
a new organization may enter the process, a system may become connected, a contract may begin or end, an operational area may expand, or an external dependency may become internal.
LCBM must permit boundary states to change.
However, detailed Temporal Context governance belongs to LCTM.
LCBM governs the boundary change itself insofar as it affects contextual membership.
Boundary Expansion
A Context Boundary may require expansion when materially relevant circumstances previously outside the context become necessary for reliable Liability governance.
Expansion may be triggered by:
new information, newly identified relationships, new environmental interactions, previously unknown system dependencies, new evidence, or reassessment of contextual relevance.
Boundary expansion must be justified.
New Information ≠ Automatic Boundary Expansion.
Only material contextual relevance justifies inclusion.
Boundary Contraction
A Context Boundary may require contraction where previously included elements are determined not to belong materially to the governed context.
Contraction may occur where:
an assumed relationship is disproven, information is found to concern another matter, a system believed to participate did not participate, an environmental condition is shown to be unrelated, or earlier contextual inclusion was excessively broad.
Contraction must preserve the historical record of the previous boundary state.
Boundary Contraction ≠ Historical Deletion.
Boundary Uncertainty
The correct Context Boundary may initially be uncertain.
LCBM must allow uncertain boundary states rather than forcing premature inclusion or exclusion.
Possible states may include:
Included
Excluded
Conditionally Included
Boundary-Uncertain
Adjacent
Separate Context Candidate
or another controlled state.
Uncertainty must remain explicit until sufficiently resolved.
Boundary Uncertainty ≠ Boundary Absence.
Boundary Conflict
Different evidence, systems, organizations, or governance processes may propose different Context Boundaries.
LCBM must preserve and evaluate such conflicts.
A boundary conflict may concern:
what event belongs to the context, which period is relevant, which organization participates, which system state matters, whether two occurrences form one context, or whether an external condition should be included.
The existence of competing boundaries must not be hidden by selecting one without traceable rationale.
Boundary Reassessment
Context Boundaries must remain capable of reassessment.
Reassessment may result in:
boundary confirmation, boundary expansion, boundary contraction, boundary separation, boundary consolidation, boundary reclassification, or continued uncertainty.
A reassessment must preserve:
the prior boundary, the reason for reassessment, the changed information, and the resulting boundary state.
Therefore:
Boundary Reassessment ≠ Historical Rewrite.
Boundary Traceability
A Context Boundary must remain explainable.
The system should be capable of reconstructing:
why the boundary was established, which criteria supported inclusion, which criteria supported exclusion, which elements remained uncertain, which changes occurred, and why later boundary states differ from earlier ones.
Boundary traceability supports later Liability governance by preventing contextual membership from becoming an unexplained assumption.
Boundary and Liability Object
LCBM must not prematurely define the Liability Object.
The Context Boundary may contain:
multiple possible Liability Objects, no ultimately valid Liability Object, or contextual elements that support formation of one later Liability Object.
Therefore:
Context Boundary ≠ Liability Object Boundary.
The Liability Object Standard determines the boundary of the Liability Object.
LCBM determines the boundary of the environment within which that object will be considered.
Boundary and Liability Scope
The distinction between Context Boundary and Liability Scope is foundational.
Context Boundary asks:
What belongs to the environment within which Liability is being governed?
Liability Scope asks later:
For what, and to what extent, does established Liability apply?
Therefore:
Context Boundary ≠ Liability Scope.
A broad Liability Context may ultimately produce narrow Liability Scope.
A complex Context may ultimately produce no established Liability.
No inference from contextual breadth to Liability breadth is permitted.
Boundary and Liability Relationships
LCBM may identify that persons, organizations, systems, objects, or other entities exist inside or across the Context Boundary.
It does not establish formal Liability Relationships between them.
Therefore:
Contextual Relationship ≠ Liability Relationship.
Liability Relationship governance occurs later under LRS.
Contextual inclusion merely establishes that the relationship may need consideration.
Boundary and Operational Reality
ORA™ may establish operational states relevant to determining the Liability Context Boundary.
LCBM may use those governed states to determine contextual membership.
However:
Operational Boundary ≠ Liability Context Boundary by default.
An operational process may extend beyond the contextual matter relevant to Liability.
Likewise, a Liability Context may require consideration of circumstances outside the immediate operational process.
LCBM governs only the Liability Context Boundary.
Boundary and Harm
HAGA™ may establish the boundary of Harm or Harm-relevant states.
That boundary does not automatically define the Liability Context Boundary.
Therefore:
Harm Boundary ≠ Liability Context Boundary.
A Liability Context may be broader or narrower than the governed Harm space depending on the matter.
LIGA™ consumes only the Harm-relevant contextual information required for Liability governance.
Boundary and Claims
A Claim may define its own asserted factual, contractual, compensatory, procedural, or other scope.
That scope does not automatically define the Liability Context Boundary.
Therefore:
Claim Scope ≠ Liability Context Boundary.
A Claim may omit materially relevant circumstances.
It may also include allegations or information outside the context ultimately required for Liability governance.
LCBM determines contextual membership independently of the mere existence of a Claim.
Boundary and Evidence
Evidence may support boundary decisions.
Evidence may indicate:
that a system participated, that an environment was connected, that an event occurred within a period, that an organization was involved, or that two matters were related.
However:
Evidence Coverage ≠ Context Boundary.
The boundary must not be limited solely to what has already been evidenced.
Nor should the existence of evidence automatically place its subject inside the Context Boundary.
ADIT® governs evidence.
LCBM governs contextual membership.
Boundary and Jurisdiction
Jurisdictional boundaries may be contextually relevant.
However:
Jurisdiction Boundary ≠ Liability Context Boundary by default.
A Liability Context may cross multiple jurisdictions.
A single jurisdiction may contain multiple distinct Liability Contexts.
LCBM may preserve jurisdictional structure where materially relevant without determining jurisdiction-specific legal authority or Liability.
Boundary Integrity
A Context Boundary must resist both inappropriate expansion and inappropriate contraction.
Boundary integrity is weakened where the boundary is manipulated to:
exclude materially relevant circumstances, include irrelevant information to obscure the matter, fragment one continuous context artificially, merge distinct contexts improperly, or create the appearance of a predetermined Liability conclusion.
LCBM therefore requires boundary formation to remain independent from the desired outcome of later Liability Determination.
Boundary Design Must Not Predetermine Liability.
Minimum Implementation Framework
A conforming implementation of LCBM must provide at least the following eight capabilities:
Boundary Candidate Formation
Capability to derive a candidate Context Boundary from an Identified Liability Context.
Context Inclusion & Exclusion
Capability to determine which contextual elements are included, excluded, adjacent, conditional, uncertain, or separately governed according to material contextual relevance.
Boundary Structure & Granularity
Capability to represent physical, digital, organizational, operational, contractual, relational, systemic, jurisdictional, composite, nested, or overlapping boundaries at appropriate granularity.
Cross-Boundary Interaction Governance
Capability to represent external influences, cross-boundary inputs, outputs, relationships, and environment transitions without automatically expanding contextual membership.
Boundary Separation & Consolidation
Capability to identify when contextual structures should be separated or consolidated without equating those decisions with creation or elimination of Liability.
Boundary Uncertainty & Conflict
Capability to represent uncertain, disputed, conditional, or competing boundary states without forcing premature resolution.
Boundary Change, Reassessment & Traceability
Capability to expand, contract, reassess, version, and reconstruct Context Boundaries while preserving historical boundary states and rationale.
Boundary Sufficiency Determination
Capability to determine when the Context Boundary is sufficiently explicit and materially complete for Context Environment governance to begin.
Governance Logic
The canonical LCBM governance logic is:
Identified Liability Context
↓
Form Candidate Context Boundary
↓
Identify Potential Internal Context
↓
Identify External / Adjacent / Uncertain Context
↓
Evaluate Material Contextual Relevance
↓
Determine Inclusion / Exclusion / Conditional Status
↓
Evaluate Cross-Boundary Relationships
↓
Evaluate Separation / Consolidation Requirements
↓
Assess Boundary Uncertainty or Conflict
↓
Test Boundary Integrity
↓
Assess Boundary Sufficiency
If insufficient:
Expand / Contract / Separate / Consolidate / Clarify / Reassess Boundary
If sufficient:
↓
Bounded Liability Context
↓
Handoff to Context Environment Governance
Materially new information may trigger:
Boundary Reassessment → Revised Boundary State without erasing previous boundary history.
Governance Outputs
LCBM may produce:
Liability Context Boundary
Context Inclusion State
Context Exclusion State
Adjacent Context State
Conditional Context State
Boundary-Uncertain State
Separate Context Candidate
Composite Boundary Structure
Nested Boundary Structure
Overlapping Boundary Structure
Cross-Boundary Interaction Record
Boundary Expansion State
Boundary Contraction State
Boundary Separation State
Boundary Consolidation State
Boundary Conflict State
Boundary Reassessment Record
Boundary Traceability Record
Boundary Sufficiency State
The principal output is:
Bounded Liability Context
The canonical handoff is:
Bounded Liability Context → Context Environment Governance
Critical Distinctions
LCBM preserves the following distinctions:
Context Boundary ≠ Liability Scope Context Boundary ≠ Liability Object Boundary Context Boundary ≠ Authority Boundary Context Boundary ≠ Environment Boundary by default Context Boundary ≠ Jurisdiction Boundary by default Contextual Proximity ≠ Contextual Membership Physical Proximity ≠ Contextual Membership Technical Accessibility ≠ Contextual Membership Organizational Membership ≠ Contextual Membership Available Information ≠ Contextual Membership Outside This Context ≠ Globally Irrelevant Largest Possible Boundary ≠ Correct Boundary Smallest Possible Boundary ≠ Correct Boundary Nested Context ≠ Separate Liability Overlapping Context ≠ Identical Context External Influence ≠ Internal Context Membership Connection Across Boundary ≠ Boundary Expansion by default Environment Transition ≠ New Liability Context by default Boundary Expansion ≠ New Liability Boundary Contraction ≠ Historical Deletion Boundary Uncertainty ≠ Boundary Absence Boundary Reassessment ≠ Historical Rewrite Contextual Relationship ≠ Liability Relationship Operational Boundary ≠ Liability Context Boundary Harm Boundary ≠ Liability Context Boundary Claim Scope ≠ Liability Context Boundary Evidence Coverage ≠ Context Boundary Jurisdiction Boundary ≠ Liability Context Boundary Boundary Breadth ≠ Liability Breadth
Cross-Architecture Boundary
LCBM may consume governed boundary-relevant inputs from other OOF® architectures.
ORA™ may establish relevant Operational Reality and operational boundaries.
HAGA™ may establish Harm boundaries.
AGA™ may establish authority, responsibility, or accountability structures.
ADIT® may provide evidence supporting boundary decisions.
VALIDOS™ may validate boundary-relevant inputs.
OBIDENITY® may establish identity, ownership, authority, permission, provenance, transfer, or continuity relevant to contextual membership.
AIG® may establish AI behavioral states.
ASGA™ may establish autonomous-system operational boundaries.
SIMULOS® may establish simulation boundaries.
PGA™ may establish Prediction-related governed objects.
VFM® may establish relevant Value states.
LCBM does not absorb any of those boundaries as its own merely because they are relevant.
The governing rule is:
A boundary in one governance architecture does not automatically become the boundary of another governed object.
LCBM determines only the Liability Context Boundary.
Canonical Boundary
LCBM begins when LCIM has identified a Liability Context requiring formal boundary governance.
It governs what materially belongs inside that context, what remains outside it, what remains uncertain or adjacent, how cross-boundary relationships are represented, and how the boundary may change without losing historical integrity.
LCBM does not determine:
Liability, Liability Object boundaries, Liability Basis, Liability Relationships, Liability Conditions, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, or jurisdiction-specific legal boundaries.
Within LCS, it does not own detailed Context Environment, Temporal Context, or Context Continuity governance.
LCBM ends when the Liability Context Boundary is sufficiently explicit, materially justified, traceable, and stable enough for Context Environment governance.
Use Case 1 — AI Service Connected to an External
Production System
An organization operates an AI service inside an internal environment, but the service also interacts with an external production platform operated by another organization.
A Liability-relevant incident occurs.
The existence of technical connectivity does not establish that the entire external platform belongs inside the same Liability Context.
LCBM determines which internal systems, external interactions, cross-boundary data flows, organizational relationships, and surrounding circumstances materially belong to the governed context.
It may represent parts of the external platform as an external influence or cross-boundary interaction rather than absorbing the entire external environment.
The resulting Bounded Liability Context can then proceed to Context Environment governance.
Use Case 2 — Industrial Incident Across Supplier and
Operator Boundaries
An industrial incident involves equipment operated at one facility but containing components supplied, configured, and maintained by several external organizations.
The physical incident occurs at one location, but relevant contextual circumstances may extend beyond that site.
LCBM determines whether supplier activity, maintenance history, remote configuration, external technical support, or other circumstances belong inside the Liability Context, remain adjacent to it, or form separate contextual structures.
The module does not determine which organization bears Liability.
It establishes the contextual boundary within which that question can later be governed.
Canonical Closing Statement
A Liability Context becomes unreliable when its boundary is assumed rather than governed.
A boundary drawn too narrowly can remove circumstances necessary to understand the matter. A boundary drawn too broadly can bury the matter inside unrelated information. A technical connection can be mistaken for contextual membership. A physical location can be mistaken for the complete context. A Claim, Harm boundary, operational boundary, organizational boundary, or jurisdictional boundary can be incorrectly substituted for the Liability Context Boundary.
LCBM prevents those substitutions.
It establishes what belongs to the context without determining what Liability ultimately covers.
The boundary of the context determines what must be considered. It does not determine what is liable.