LCIM — Liability Context Identification Module
LCIM — Liability Context Identification 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 Identification
Module ID: LIGA-LCS-LCIM-001
Origin ID: OOF.CM.LIGA.01.01.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 20 September 2026
Compatibility: OOF® Methodology OS™ · Modular OOF® Architecture Ecosystem
AI-Readable: Yes
Authority: OOF® — OriginOpen® Foundation
Protection: MIP® — Methodological Intellectual Property
Canonical Language: English (UCL™)
Canonical Definition
The Liability Context Identification Module (LCIM) governs how a matter that may require Liability governance is recognized as sufficiently Liability-relevant to require contextual governance and how the materially relevant contextual dimensions of that matter are identified without prematurely establishing Liability, defining the complete Context Boundary, determining Liability, or importing unrelated information into the governed context.
LCIM governs the transition:
Observed Matter → Liability-Relevance Recognition → Contextual Dimension Identification → Identified Liability
Context
Its foundational distinction is:
Identification of Liability Context ≠ Establishment of Liability.
Operational Role
The operational role of LCIM is:
to identify that a Liability-relevant context exists and determine which contextual dimensions require governance before the context is formally bounded, environmentally structured, temporally positioned, and maintained through continuity.
LCIM is the entry module of the Liability Context Standard.
It answers the first operational question of LCS:
What context needs to be governed?
It does not yet answer:
Where exactly does that context end?
How should its environment be structured?
Which temporal states apply?
How does the context remain continuous through change?
Those functions occur after Context Identification.
Position in the Parent Standard Flow
The internal LCS progression is:
Context Identification → Context Boundary → Context Environment → Temporal Context → Context Continuity LCIM governs:
Context Identification
Its principal input is:
Potentially Liability-Relevant Matter
Its principal output is:
Identified Liability Context
The canonical transition is:
Potentially Liability-Relevant Matter → Liability-Relevance Assessment → Context Identification → Identified Liability Context → Context Boundary Governance
Governed Space
LCIM governs Liability Context Identification.
Its governed space includes:
recognition of potential Liability relevance, identification of the matter requiring contextual governance, identification of materially relevant contextual dimensions, initial differentiation of relevant and apparently irrelevant contextual information, recognition of multi-context characteristics, identification of contextual uncertainty, identification of contextual assumptions, recognition of potential environment transitions, and preparation of the identified context for formal Context Boundary governance.
LCIM does not establish the complete Context Boundary.
It identifies what requires boundary governance.
Liability-Relevance Recognition
A matter enters LCIM when circumstances indicate that Liability may be sufficiently relevant to justify methodological contextual governance.
This threshold does not require established Liability.
Possible initiating matters may include:
an occurrence, decision, omission, interaction, relationship, obligation, system action, product state, operational condition, contractual matter, Harm, Loss, Damage, failure, environmental change, AI behavior, autonomous action, or another materially relevant circumstance.
The governing distinction is:
Liability Relevance ≠ Liability.
A matter may legitimately enter LCIM and later produce no established Liability.
Identification therefore must not be conditioned on a predetermined Liability conclusion.
Identification Threshold
Not every event, fact, relationship, or condition requires formation of a Liability Context.
LCIM requires a threshold of material Liability relevance.
A matter should enter contextual governance where failure to establish its context could materially impair later evaluation of potential Liability.
The threshold may be met where context could materially affect:
formation of the Liability Object, identification of a Liability Basis, identification of relevant Liability Subjects or Relationships, applicable Liability Conditions, Liability-Relevant Connection, Liability Determination, or later Liability lifecycle governance.
The threshold is therefore methodological rather than jurisdiction-specific.
LCIM does not determine whether a legal cause of action, legal duty, legal breach, or legally enforceable Liability exists.
Identification of the Contextual Matter
LCIM must establish what matter requires contextual governance.
The identified matter must be sufficiently specific to distinguish it from the broader universe of surrounding activity.
For example, contextual identification may begin with:
a particular operational occurrence, a product condition, a system interaction, a contractual event, an autonomous-system action, a sequence of decisions, a continuing condition, or a materially connected set of circumstances.
However, LCIM must avoid prematurely converting that matter into a Liability Object.
Therefore:
Contextual Matter ≠ Liability Object.
The Liability Object is governed later in LIGA™ after the Liability Context has been sufficiently established.
Material Contextual Dimensions
LCIM identifies contextual dimensions that may materially affect later Liability governance.
Depending on the matter, these may include:
physical circumstances, digital circumstances, organizational circumstances, operational circumstances, contractual circumstances, technological circumstances, financial circumstances, product circumstances, infrastructure circumstances, human interaction circumstances, system circumstances, AI-related circumstances, autonomous-system circumstances, environmental circumstances, multi-party circumstances, cross-system circumstances, or other materially relevant dimensions.
LCIM does not require every dimension to be present.
Only materially relevant dimensions should enter contextual governance.
Materiality Principle
Context Identification must remain proportional to the Liability-relevant matter.
The objective is not:
Identify Everything
The objective is:
Identify What May Materially Affect Liability Governance
Accordingly:
Available Information ≠ Relevant Context and:
More Context ≠ Better Context by default.
Information should not become part of the identified context merely because it is technically available.
Its inclusion requires a reasonable methodological relationship to the Liability matter being governed.
Contextual Relevance
A contextual element is materially relevant where its presence, absence, state, relationship, or change could reasonably affect a later LIGA™ governance question.
This may include whether it could affect:
what the Liability Object is, which Liability Basis may apply, which Subjects or Relationships are relevant, which Conditions must be evaluated, which Connections require governance, or how subsequent Liability states must be interpreted.
Contextual relevance does not establish substantive Liability relevance under any particular jurisdiction.
It establishes methodological relevance to the LIGA™ lifecycle.
Relevant and Non-Relevant Information
LCIM must support an initial distinction between:
Materially Relevant Context
Potentially Relevant Context
Apparently Non-Relevant Information
and
Undetermined Contextual Relevance
Information should not be permanently excluded merely because its relevance is not immediately visible.
Likewise, potentially relevant information should not automatically be treated as established context.
This allows contextual identification to remain adaptable without becoming unlimited.
Contextual Assumption Identification
Some contextual elements may initially be available only as assumptions.
LCIM must identify those assumptions explicitly.
Examples may include assumptions concerning:
which system was active, which party controlled an activity, which environment was being used, which product version existed, which contractual relationship applied, or which operational state was present.
LCIM must preserve the distinction:
Contextual Assumption ≠ Established Contextual Fact.
An assumption may justify further contextual governance.
It must not silently become an established fact because later governance depends upon it.
Contextual Uncertainty Identification
LCIM must identify material uncertainty surrounding the context.
Uncertainty may concern:
the identity of relevant circumstances, the relationship between events, the environment in which an action occurred, the timing of a condition, the completeness of available information, or whether a contextual dimension is materially relevant.
Possible identification states may include:
Established
Potential
Uncertain
Disputed
Incomplete
Unknown
or another controlled state.
Uncertainty is itself a governance state.
It must not automatically terminate Context Identification.
Multi-Context Recognition
LCIM must recognize when a matter may involve more than one relevant context.
A matter may span:
multiple organizations, multiple systems, multiple physical locations, multiple digital environments, multiple contractual structures, multiple operational environments, or multiple periods.
LCIM identifies the existence of potential multi-context structure.
It does not yet determine the final boundary or internal structure of each context.
Therefore:
Multi-Context Recognition ≠ Context Boundary Determination.
and:
Multiple Contexts ≠ Multiple Liabilities.
Environment Transition Recognition
A matter may involve movement from one environment to another.
Examples include:
test → production, simulation → operational reality, private system → external system, controlled physical space → public space, organization A → organization B, or one technical infrastructure environment → another.
LCIM must identify a potential environment transition where it may materially affect Liability governance.
It does not determine the authority, permission, accountability, or Liability consequence of that transition.
The governing principle is:
Environment Transition Recognition ≠ Environment Transition Determination.
The transition becomes an identified contextual dimension for subsequent governance.
Actor and System Participation
LCIM may identify persons, organizations, systems, autonomous agents, products, services, infrastructure components, or other entities that appear contextually relevant.
However, participation does not establish Liability.
Therefore:
Participation ≠ Liability Presence ≠ Responsibility Responsibility ≠ Liability System Involvement ≠ Liability Attachment At this stage, LCIM identifies contextual participation only.
Formal Liability Subject and Relationship governance belongs later in LIGA™.
Harm, Loss, and Damage as Contextual Inputs
Harm, Loss, or Damage may contribute to identification of a Liability-relevant context.
However:
Harm ≠ Liability Loss ≠ Liability Damage ≠ Liability and:
Harm Identification ≠ Liability Context Identification HAGA™ governs Harm.
Other appropriate architectures may govern other underlying objects.
LCIM consumes only the contextual relevance required for Liability governance.
A Liability Context may also exist where no governed Harm has been established.
Operational Mechanism Identification
LCIM may identify an operational mechanism where that mechanism forms part of the context.
Such mechanisms may include:
physical contact, mechanical action, human action, software execution, AI behavior, autonomous action, communication, transaction, prediction, simulation, or another operational process.
The mechanism does not thereby become governed by LIGA™.
Mechanism Identification ≠ Mechanism Governance.
LCIM records only its potential contextual relevance to Liability.
Claim-Originated Context
A Claim may cause a previously ungoverned Liability-relevant matter to become visible.
LCIM may therefore begin after:
a complaint, insurance claim, contractual demand, compensation request, dispute, legal filing, or another external assertion.
However:
Claim ≠ Liability and:
Claim Assertion ≠ Established Contextual Fact.
Information contained within a Claim must remain distinguishable from independently governed contextual facts.
LCIM governs the context, not the Claim lifecycle.
Evidence-Originated Context
Evidence may reveal circumstances requiring Liability Context governance.
An audit record, sensor log, document, transaction record, system trace, communication, image, testimony, or other evidence may expose a Liability-relevant matter.
However:
Evidence ≠ Context and:
Evidence Discovery ≠ Liability.
ADIT® governs evidence and auditability.
LCIM identifies the contextual significance of sufficiently governed evidence without taking ownership of evidence integrity itself.
Context Identification Across Time
The context visible when LCIM begins may not be the context that existed when the Liability-relevant matter arose.
LCIM must therefore identify whether historical contextual reconstruction may be necessary.
For example:
Observed Context at T2
may differ from:
Relevant Context at T1
LCIM identifies this temporal relevance.
Detailed Temporal Context governance belongs later within LCS.
Therefore:
Current Observation ≠ Historical Context by default.
Context Identification Under Change
A matter may become Liability-relevant only after later information or consequences emerge.
LCIM must therefore support delayed Context Identification.
The absence of earlier identification does not establish that the relevant context did not exist.
Accordingly:
Unidentified Context ≠ Non-Existing Context.
Where later information reveals earlier Liability relevance, the relevant context may require retrospective identification while preserving the distinction between:
when the context existed, and when the context was identified.
Context Separation Signals
LCIM must identify signals that may indicate more than one distinct Liability Context.
Possible signals include materially different:
occurrences, object candidates, environments, time periods, relationships, operational states, contractual structures, or causal sequences.
LCIM does not perform final Context Separation.
It identifies that separation may be necessary during subsequent Context Boundary governance.
Therefore:
Separation Signal ≠ Separate Liability Context.
Context Consolidation Signals
Conversely, apparently separate matters may form part of one materially continuous context.
LCIM must identify potential contextual continuity where multiple observations may relate to the same underlying Liabilityrelevant matter.
Examples may include:
repeated manifestations of one continuing condition, multiple system outputs from one underlying process, multiple consequences arising from one continuing operational state, or multiple observations of the same contextual environment.
Again:
Consolidation Signal ≠ Final Context Consolidation.
Formal boundary governance follows.
Identification Traceability
LCIM must preserve sufficient traceability to explain why a matter entered Liability Context governance.
The identification record should be capable of showing:
what matter was observed, why it was considered potentially Liability-relevant, which contextual dimensions were identified, which elements remained uncertain, which assumptions were present, and which information triggered contextual governance.
Traceability is required so that later LIGA™ stages do not treat Context Identification as an unexplained starting assumption.
Identification Reassessment
Context Identification may require reassessment when materially new information emerges.
Reassessment may:
confirm the identified context, add a previously unidentified contextual dimension, remove an element found to be irrelevant, identify a potential separate context, identify a previously unknown environment transition, or change the status of an assumption or uncertainty.
Reassessment must not silently rewrite earlier identification states.
Identification Reassessment ≠ Historical Erasure.
Identification Sufficiency
LCIM reaches sufficient completion when the matter and its materially relevant contextual dimensions are identified well enough for formal Context Boundary governance to begin.
This does not require:
complete evidence, complete environmental mapping, complete temporal reconstruction, complete party identification, or complete Liability analysis.
The threshold is:
Sufficient Identification for Boundary Governance
not:
Complete Knowledge of the Liability Matter.
Minimum Implementation Framework
A conforming implementation of LCIM must provide at least the following eight capabilities:
Liability-Relevance Recognition
Capability to recognize when a matter is sufficiently Liability-relevant to require contextual governance without treating that recognition as establishment of Liability.
Contextual Matter Identification
Capability to identify the matter requiring Liability Context governance while keeping it distinct from the later Liability Object.
Material Context Dimension Identification
Capability to identify physical, digital, organizational, operational, contractual, technological, temporal, relational, or other contextual dimensions where materially relevant.
Contextual Relevance Classification
Capability to distinguish materially relevant, potentially relevant, apparently non-relevant, and undetermined contextual information.
Assumption & Uncertainty Identification
Capability to identify contextual assumptions, uncertainties, disputes, incomplete information, and unknown states without converting them into established facts.
Multi-Context & Transition Recognition
Capability to recognize potential multi-context matters and materially relevant transitions between environments without prematurely determining their final boundaries.
Identification Traceability & Reassessment
Capability to preserve why a context was identified and to reassess that identification when materially new information emerges without erasing historical identification states.
Identification Sufficiency Determination
Capability to determine when Context Identification is sufficiently complete for formal Context Boundary governance to begin.
Governance Logic
The canonical LCIM governance logic is:
Observed Matter
↓ Could the matter be materially Liability-relevant?
If no:
No LIGA™ Context Identification Required at Present
If yes or materially uncertain:
↓
Identify the Contextual Matter
↓
Identify Material Contextual Dimensions
↓ Identify Relevant Participants, Systems, Environments, Conditions, and Relationships at Context Level ↓
Identify Assumptions and Uncertainty
↓
Identify Potential Multi-Context Structure
↓
Identify Potential Environment Transitions
↓
Classify Contextual Relevance
↓
Assess Identification Sufficiency
If insufficient:
Expand / Clarify / Reassess Identification
If sufficient:
↓
Identified Liability Context
↓
Handoff to Context Boundary Governance
Governance Outputs
LCIM may produce:
Liability-Relevance Identification State
Identified Contextual Matter
Material Context Dimension Set
Contextual Relevance Classification
Contextual Assumption Set
Contextual Uncertainty State
Multi-Context Recognition State
Environment Transition Recognition State
Context Separation Signal
Context Consolidation Signal
Context Identification Trace
Context Identification Sufficiency State
The principal output is:
Identified Liability Context
The canonical handoff is:
Identified Liability Context → Context Boundary Governance
Critical Distinctions
LCIM preserves the following distinctions:
Liability Relevance ≠ Liability Context Identification ≠ Liability Determination Contextual Matter ≠ Liability Object Context Identification ≠ Context Boundary Determination Available Information ≠ Relevant Context More Context ≠ Better Context by default Contextual Assumption ≠ Established Contextual Fact Uncertainty ≠ Absence of Context Multi-Context Recognition ≠ Multiple Liabilities Environment Transition Recognition ≠ Authority Determination Participation ≠ Liability Presence ≠ Responsibility Responsibility ≠ Liability System Involvement ≠ Liability Attachment Harm ≠ Liability Loss ≠ Liability Damage ≠ Liability Mechanism Identification ≠ Mechanism Governance Claim Assertion ≠ Established Contextual Fact Evidence ≠ Context Current Observation ≠ Historical Context by default Unidentified Context ≠ Non-Existing Context Separation Signal ≠ Separate Liability Context Consolidation Signal ≠ Final Context Consolidation Identification Reassessment ≠ Historical Erasure Sufficient Identification ≠ Complete Knowledge
Cross-Architecture Boundary
LCIM may receive relevant governed inputs from other OOF® architectures.
ORA™ may establish Operational Reality relevant to Context Identification.
HAGA™ may establish Harm relevant to a potential Liability matter.
AGA™ may provide relevant authority, responsibility, or accountability structures.
ADIT® may provide governed evidence.
VALIDOS™ may provide validated inputs.
OBIDENITY® may provide relevant identity, origin, ownership, authority, permission, provenance, or continuity states.
AIG® may provide AI behavior states.
ASGA™ may provide autonomous-system states.
SIMULOS® may provide simulation environment states.
PGA™ may provide Prediction states.
VFM® may provide Value-related states.
LCIM does not absorb those governed objects.
It identifies only their material relevance to the Liability Context.
Cross-Architecture Relevance ≠ Cross-Architecture Ownership.
Canonical Boundary
LCIM begins when an observed or known matter may be sufficiently Liability-relevant to justify contextual governance.
It governs recognition of that relevance and identification of the contextual dimensions that may materially affect later Liability governance.
LCIM does not:
establish Liability, form the Liability Object, determine the Liability Basis, identify formal Liability Relationships, evaluate Liability Conditions, establish Liability-Relevant Connection, determine Liability Attachment, determine Liability, define Liability Scope, allocate Liability, or establish Liability Finality.
Within LCS, it also does not complete:
Context Boundary governance, Context Environment governance, Temporal Context governance, or Context Continuity governance.
LCIM ends when the relevant contextual matter and its materially relevant contextual dimensions are sufficiently identified for formal Context Boundary governance.
Use Case 1 — AI System Action Creates Potential Liability
Relevance
An AI-enabled operational system performs an action that produces an unexpected real-world consequence.
At the time of discovery, it is unclear whether the relevant context involves:
the AI output, human approval, system configuration, deployment environment, organizational procedure, external data, or a combination of several factors.
LCIM does not determine Liability.
It identifies that the matter is sufficiently Liability-relevant to require contextual governance and identifies the contextual dimensions requiring further structuring.
The output is an Identified Liability Context ready for Context Boundary governance.
Use Case 2 — Industrial Failure With Unclear Contextual
Scope
A component fails during an industrial operation involving a manufacturer, supplier, operator, maintenance provider, and several connected systems.
Initial information does not establish whether the relevant context is limited to the component failure or includes maintenance history, operating conditions, system modifications, installation state, supplier relationships, or other surrounding circumstances.
LCIM identifies the materially relevant contextual dimensions without deciding which party bears Liability or where the final Context Boundary lies.
The resulting identified context can then proceed to formal boundary governance.
Canonical Closing Statement
Liability governance cannot begin reliably from an undefined collection of facts.
Before context can be bounded, structured, temporally positioned, or maintained, the system must first identify what context actually requires governance and why it is materially relevant to Liability.
LCIM performs that first operational function.
It recognizes Liability relevance without converting relevance into Liability, identifies context without prematurely forming the Liability Object, captures uncertainty without converting uncertainty into fact, and identifies complexity without prematurely determining boundaries.
What is not identified cannot be governed as context. What is identified as context must not be mistaken for Liability.