LCHIM — Liability Change Identification Module
LCHIM — Liability Change Identification Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability State & Change Standard (LSCS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Change Identification
Module ID: LIGA-LSCS-LCHIM-001
Origin ID: OOF.CM.LIGA.09.03.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 24 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 Change Identification Module (LCHIM) governs how a potential or observed change affecting established Liability is identified, bounded, associated with the correct Liability structure, distinguished from surrounding operational or external change, and represented as an explicit Liability Change candidate for subsequent assessment.
LCHIM determines what changed, which Liability component may be affected, when the change occurred or became relevant, where within the Liability structure the change belongs, and whether the change is sufficiently material to require Liability Change Assessment.
It distinguishes change in underlying reality from change in Liability itself.
It also distinguishes a State Transition from the broader change that may have produced, accompanied, or followed that transition.
LCHIM does not determine the final effect of the identified change on Liability.
It does not independently modify Liability Determination, Scope, Allocation, or current State.
It governs the transition:
Governed Liability State / Governed Liability State Transition / Change-Relevant Input → Change Detection → Change Object Identification → Change Boundary → Affected Liability Structure Identification → Materiality Screening → Identified Liability Change Its foundational distinction is:
Change in Underlying Reality ≠ Liability Change by default.
Operational Role
The operational role of LCHIM is:
to determine what materially changed, where that change belongs within the governed Liability structure, and what must be assessed before the Liability itself may legitimately be treated as changed.
LSTIM identifies the current Liability State.
LSTTM governs State Transition.
LCHIM identifies the underlying or surrounding Liability Change requiring substantive assessment.
LCHAM subsequently determines what that identified change means for the governed Liability.
Position in the LSCS Internal Flow
The internal LSCS progression is:
Liability State Identification → Liability State Transition → Liability Change Identification → Liability Change Assessment → Liability State History LCHIM governs:
Liability Change Identification
Its principal inputs may include:
Governed Liability State
Governed Liability State Transition
and:
Change-Relevant Governed Inputs
Its principal output is:
Identified Liability Change
Its handoff is:
Identified Liability Change → LCHAM — Liability Change Assessment Module
Central Operational Question
What materially changed in or around the governed Liability structure, which Liability components may be affected, and does the identified change require formal Liability Change Assessment?
Change Identification Object
Every Change Identification should begin by identifying the matter that appears to have changed.
The Change Identification Object may concern:
a Liability State, Liability Subject, Liability Relationship, Liability Object, Liability Basis, Liability Condition, Liability-Relevant Connection, Liability Determination, Liability Scope, Liability Allocation, obligation, dependency, authority, time, or another Liability-relevant structure.
Change Identity
Every material identified change should possess sufficient identity to distinguish it from:
the underlying Liability, another change, another Liability component, another event, another time period, and another lifecycle.
Therefore:
Liability Change ≠ Liability itself.
Change Source
LCHIM should identify where the potential change originated.
A change may originate from:
new Operational Reality, new governed information, changed conditions, changed relationships, changed obligations, authority action, new evidence, Scope developments, Allocation developments, system behavior, time, external governance, correction, reassessment, or another materially relevant source.
Change Signal
A Change Signal is an indication that something potentially relevant to Liability may have changed.
A signal does not establish Liability Change.
Therefore:
Change Signal ≠ Identified Liability Change.
Change Detection
Change Detection identifies a difference between relevant prior and current information, states, conditions, or circumstances.
Detection alone does not establish material Liability relevance.
Therefore:
Detected Difference ≠ Material Liability Change by default.
Baseline
A change can be meaningfully identified only against a relevant baseline.
The baseline may be:
a prior Liability State, prior Scope, prior Allocation, prior Condition state, prior Relationship structure, prior obligation state, prior governed fact, or another valid earlier reference.
Baseline Integrity
The baseline used for Change Identification should itself be identifiable and historically valid for the comparison being performed.
Therefore:
Current Record vs Arbitrary Prior Record ≠ Governed Change Identification.
Prior State vs Current Observation
LCHIM should distinguish:
what was previously governed, from:
what is currently observed or reported.
The difference between them becomes a Change candidate, not automatically a Liability Change.
Change Object
The Change Object identifies exactly what changed.
Examples may include:
a condition, a relationship, a Scope component, an allocated portion, an obligation, a dependency, an authority state, or a temporal fact.
A change should not remain represented merely as “something changed.”
Change Boundary
Every identified change should have a boundary.
The boundary should determine:
what changed, what did not change, which Liability structure may be affected, and which surrounding structures remain outside the identified change.
Local Change
A Local Change affects a defined component of the Liability structure.
Therefore:
Local Liability Change ≠ Complete Liability Change.
Structural Change
A Structural Change affects the organization, relationship, Scope, Allocation, dependency, or another material structural element of Liability.
Structural Change may require upstream re-entry.
State-Only Change
A change may affect only the operative Liability State while leaving Determination, Scope, Allocation, and other upstream structures unchanged.
Therefore:
Liability State Change ≠ Liability Structure Change by default.
Upstream-Relevant Change
A change may reveal that an earlier LIGA™ governance space requires reassessment.
LCHIM should identify that possibility without performing the upstream reassessment itself.
Downstream-Relevant Change
A change may create conditions relevant to:
Transfer, Recourse, Resolution, Discharge, or later Finality governance.
LCHIM should identify the relevance without performing those downstream processes.
Change in Operational Reality
Operational Reality may change without changing Liability.
Therefore:
Operational Change ≠ Liability Change by default.
Operational change becomes a Liability Change candidate only where a legitimate Liability relationship exists.
Change in Harm
Harm may increase, decrease, persist, recover, or reach Finality independently of Liability.
Therefore:
Harm Change ≠ Liability Change by default.
Where Harm change affects Liability Scope, obligation, condition, or another governed Liability component, the relationship should be explicitly identified.
Change in Responsibility
Responsibility may change without automatically changing Liability.
Therefore:
Responsibility Change ≠ Liability Change.
Change in Accountability
Accountability or attribution may change without automatically changing Liability.
Therefore:
Accountability Change ≠ Liability Change.
Change in Claim
A Claim may be amended, accepted, rejected, reopened, paid, or closed.
Therefore:
Claim Change ≠ Liability Change by default.
Change in Payment
A payment may affect performance or downstream Resolution governance.
It does not automatically alter substantive Liability.
Therefore:
Payment Change ≠ Liability Change by default.
Change in Insurance
Insurance coverage, payment, denial, or policy state may change.
The underlying Liability does not automatically change with it.
Therefore:
Insurance Change ≠ Liability Change by default.
Change in Settlement
Settlement negotiations or settlement state may change independently of substantive Liability.
Therefore:
Settlement Change ≠ Liability Change by default.
Change in Operational Mechanism
The mechanism associated with a Liability-relevant occurrence may:
stop, restart, change, be repaired, be replaced, or disappear.
That does not automatically change Liability.
Therefore:
Mechanism Change ≠ Liability Change by default.
Change in Subject
A change involving a Liability Subject may include:
identity correction, role change, organizational succession, death, merger, replacement, delegation, or another relevant change.
LCHIM should identify whether the change affects the Liability structure.
Subject Identity Change vs Subject Replacement
A change in Subject information does not necessarily mean the Liability Subject itself changed.
Therefore:
Subject Data Change ≠ Liability Subject Replacement.
Change in Relationship
A Liability Relationship may materially change.
The change may affect:
direction, role, dependency, authority, scope, status, or another relational property.
Therefore:
Relationship Change ≠ New Liability Relationship by default.
Change in Liability Object
A change in the underlying governed matter may affect the Liability Object.
LCHIM should identify whether:
the existing Object changed, the Object representation changed, or a new Liability Object has emerged.
These states should remain distinct.
Object Change vs New Object
Therefore:
Liability Object Change ≠ New Liability Object by default.
A new Origin should not be created merely because an existing Object evolved.
Change in Liability Basis
A Liability Basis may become:
newly relevant, inapplicable, modified, superseded, disputed, or otherwise changed.
Where the Basis itself requires governance reassessment, the matter should be routed to LBS.
Change in Liability Conditions
A Liability Condition may become:
satisfied, unsatisfied, failed, expired, waived where applicable, unknown, uncertain, or disputed.
Condition change may materially affect Liability without automatically determining the result.
Therefore:
Condition Change ≠ Liability Change Outcome.
Change in Liability-Relevant Connection
New governed information may affect the relationship between Subjects, Objects, conditions, conduct, events, and other Liability-relevant inputs.
Where the Connection itself requires reassessment, the matter should return to LCNS.
Change in Liability Determination
A change may call the underlying Liability Determination into question.
LCHIM identifies this as Determination-relevant change.
It does not redetermine Liability.
Therefore:
Determination-Relevant Change ≠ New Liability Determination.
Change in Liability Scope
Scope may expand, contract, become partially unresolved, or otherwise require reassessment.
LCHIM identifies the Scope-relevant change.
LSAS governs the actual Scope reassessment.
Change in Liability Allocation
Allocation may require modification because:
Subjects changed, Relationships changed, Scope changed, an allocation dependency changed, or earlier Allocation was incorrect.
LCHIM identifies the Allocation-relevant change.
It does not perform reallocation.
Therefore:
Allocation-Relevant Change ≠ Liability Reallocation.
Change in Obligation
An obligation may:
activate, become conditional, be suspended, be modified, be performed, fail, expire, or otherwise change.
The obligation change should remain associated with the correct Liability Relationship and Scope.
Change in Dependency
A Liability structure may depend upon another governed condition, event, relationship, or state.
A dependency change should identify:
the dependency, the prior dependency state, the new observed state, and the potentially affected Liability component.
Change in Authority
Authority may change because of:
delegation, revocation, succession, jurisdictional shift, institutional change, or another legitimate mechanism.
Authority change does not automatically change Liability.
Therefore:
Authority Change ≠ Liability Change by default.
Temporal Change
Time itself may create a materially relevant change where the applicable Liability structure depends upon:
duration, deadline, expiry, review period, activation date, or another temporal condition.
Therefore:
Passage of Time ≠ Liability Change by default.
New Information
New information may reveal:
a previously unknown fact, a correction, a changed circumstance, a new dependency, or another Liability-relevant matter.
New information should be distinguished from new reality.
New Information vs New Event
A newly discovered historical fact is not the same as a newly occurring event.
Therefore:
Newly Known ≠ Newly Occurred.
This distinction may materially affect effective time and re-entry.
Change Discovery Time
Change Discovery Time identifies when the change became known to the governance system.
Change Occurrence Time
Change Occurrence Time identifies when the underlying change actually occurred, where this can be established.
Therefore:
Change Discovery Time ≠ Change Occurrence Time by default.
Change Effective Time
The time at which a change affects Liability may differ from both occurrence and discovery time.
Therefore:
Change Occurrence Time ≠ Liability Change Effective Time by default.
Retrospectively Identified Change
A change may be identified after the period in which it became relevant.
The governance system should preserve:
occurrence time, discovery time, assessment time, and eventual effective time where materially relevant.
Prospective Change
A future change may already be known or scheduled.
It should remain prospective until the applicable effective conditions occur.
Therefore:
Known Future Change ≠ Current Liability Change.
Change Scope
Change Scope defines how much of the Liability structure may be affected.
It may be:
local, partial, multi-component, Relationship-wide, Subject-wide, network-wide, or otherwise explicitly bounded.
Subject-Specific Change
A change affecting one Subject should not automatically be attributed to all Liability Subjects.
Therefore:
Subject A Change ≠ Subject B Change by default.
Relationship-Specific Change
A change affecting one Liability Relationship should remain separate from other Relationships unless propagation is established.
Therefore:
Relationship A Change ≠ Relationship B Change by default.
Scope-Specific Change
A change may affect only one Scope portion.
The remaining Governed Liability Scope may remain unchanged.
Allocation-Specific Change
A change may affect one Allocation without affecting the entire Allocation structure.
Obligation-Specific Change
A change may affect one obligation without changing every obligation within the Liability Relationship.
Multi-Dimensional Change
A single change may affect multiple Liability dimensions simultaneously.
LCHIM should preserve each materially affected dimension.
Change Propagation Candidate
A local change may potentially propagate to other Liability structures.
LCHIM identifies the possible propagation path.
It does not assume propagation.
Therefore:
Change Propagation Candidate ≠ Propagated Liability Change.
Liability Network Change
A change may affect multiple Liability Relationships within a Liability Network.
LCHIM should identify whether the change is:
local, cross-Relationship, or potentially network-wide.
Local Change vs Network Change
Therefore:
Local Liability Change ≠ Liability Network Change by default.
A network-level effect requires explicit governance.
Change Materiality
Not every difference requires formal Liability Change Assessment.
LCHIM should determine whether the identified change is sufficiently material to proceed.
Material Change
A Material Liability Change candidate is one capable of affecting:
Liability State, Determination, Scope, Allocation, Subject, Relationship, Basis, Conditions, Connection, obligation, Transfer or Recourse relevance, Resolution relevance, or another material Liability lifecycle element.
Non-Material Change
A change may be classified as non-material where it does not alter or reasonably require reassessment of the governed Liability structure.
The basis for non-material classification should remain traceable where relevant.
Materiality ≠ Outcome
Determining that a change is material does not establish how Liability should change.
Therefore:
Material Change ≠ Determined Liability Change Effect.
The effect belongs to LCHAM.
Change Threshold
Where an implementation uses thresholds to identify material change, the threshold should be explicit and appropriate to the governed Liability structure.
Quantitative Threshold
A quantitative difference may become material where it exceeds an applicable governed threshold.
Magnitude alone does not always determine materiality.
Qualitative Materiality
A change may be material even where no large quantitative difference exists.
Examples include:
Subject identity change, authority change, Relationship change, new obligation, Scope category change, or a change in the applicable Liability Basis.
Cumulative Change
Several individually minor changes may become material in combination.
Therefore:
Individually Non-Material Changes ≠ Collectively Non-Material by default.
Repeated Change
Repeated changes may indicate a materially different Liability environment even where each individual change is limited.
LCHIM should preserve relevant patterns where necessary.
Change Conflict
Different sources may identify incompatible changes.
LCHIM should preserve the conflict rather than forcing one version.
Unknown Change
Where a change appears to have occurred but its nature cannot be established, it should remain explicitly Unknown.
Therefore:
Unknown Change ≠ No Change.
Uncertain Change
Where the nature, extent, timing, or Liability relevance of a change remains uncertain, the uncertainty should remain explicit.
Disputed Change
Where materially competing governed positions exist concerning whether or what changed, the dispute should be represented.
Therefore:
Disputed Change ≠ Authority to Select a Preferred Change.
Duplicate Change Detection
The same underlying change may be reported through multiple systems or records.
LCHIM should prevent duplicate reports from becoming multiple independent Liability Changes.
Therefore:
Multiple Change Records ≠ Multiple Liability Changes by default.
Related Changes
Several distinct changes may share a common source.
LCHIM should preserve their relationship without collapsing them into one change where their Liability effects may differ.
Composite Change
Where several interdependent changes form one materially inseparable Liability Change, they may be represented as a Composite Change.
The constituent changes should remain traceable.
Change Sequence
Multiple changes may occur sequentially.
The sequence may materially affect Liability assessment.
Therefore:
Same Changes in Different Sequence ≠ Same Liability Change Structure by default.
Parallel Changes
Multiple changes may occur simultaneously or independently.
Temporal coincidence does not establish that they form one Liability Change.
Change Dependency
One change may depend upon another.
Dependencies should remain explicit before subsequent assessment.
Change Authority Association
Where an identified change arises from or depends upon an authority action, the authority should remain associated with the Change Object.
Authority does not automatically determine Liability effect.
Change Evidence Association
Evidence may support identification of a change.
Evidence does not itself become the Liability Change.
Therefore:
Evidence of Change ≠ Liability Change.
Change Rationale
LCHIM should preserve why the identified difference is treated as:
material, non-material, unknown, uncertain, disputed, or requiring assessment.
Therefore:
Change Classification ≠ Change Rationale.
Change Provenance
The identified change should remain traceable to:
its source, baseline, observed difference, affected Liability structure, time, authority where relevant, and supporting governed inputs.
Change Traceability
A qualified reviewer should be able to reconstruct:
Prior Governed Structure → Change Signal → Detected Difference → Change Object → Change Boundary → Materiality Screening → Identified Liability Change without reconstructing the entire matter from raw information.
Change Identification Integrity
LCHIM should not:
create Liability, redetermine Liability, expand Scope, redistribute Allocation, invent a State Transition, resolve disputes, or erase historical states.
Its function is identification and bounding.
No Determination Shortcut
A detected change cannot itself establish that Liability now attaches or no longer attaches.
Therefore:
Identified Change ≠ Liability Determination.
No Scope Shortcut
A change affecting Scope does not itself modify the Governed Liability Scope.
Therefore:
Scope-Relevant Change ≠ Changed Liability Scope.
No Allocation Shortcut
A change affecting Allocation does not itself redistribute Liability.
Therefore:
Allocation-Relevant Change ≠ Changed Liability Allocation.
No State Shortcut
An identified Liability Change does not automatically establish a new Liability State.
Therefore:
Identified Liability Change ≠ New Liability State.
No Resolution Shortcut
A change that appears to satisfy an obligation does not automatically establish Liability Resolution or Discharge.
Therefore:
Performance-Relevant Change ≠ Liability Resolution.
Automated Change Identification
AI or automated systems may assist with:
change detection, baseline comparison, materiality screening, dependency mapping, change classification, and affected-structure identification.
Automation should preserve methodology, source, uncertainty, time, and traceability.
Therefore:
Automated Change Detection ≠ Authoritative Liability Change Identification by default.
Re-Entry Identification
LCHIM should identify where an observed change may require upstream re-entry.
Possible routes include:
LCS for Context, LOS for Liability Object, LBS for Liability Basis, LRS for Liability Relationships, LCOS for Liability Conditions, LCNS for Liability Connection, LDS for Liability Determination, LSAS for Liability Scope & Allocation, or LSTIM where the current State itself was incorrectly identified.
Earliest Materially Affected Space
Where several governance spaces appear affected, the governing rule is:
Re-enter the earliest materially affected governance space.
This prevents downstream correction from masking an upstream governance defect.
Re-Entry Does Not Rewrite History
An identified change may require reassessment of an earlier governance space.
That does not erase the state that existed before reassessment.
Therefore:
Re-Entry ≠ Historical Rewrite.
Change Origin Continuity
A changed Liability structure should remain linked to the existing Liability Origin unless the change legitimately creates a distinct Liability Object or Liability Relationship requiring separate origin governance.
Therefore:
Liability Change ≠ New Liability Origin by default.
Identified Liability Change
The principal output of LCHIM is:
Identified Liability Change
It should identify, where applicable:
Change Identity, Change Source, Change Signal, Baseline, Change Object, Change Boundary, Change Type, affected Liability Subject, affected Liability Relationship, affected Liability Object, affected Liability Basis, affected Conditions, affected Connection, affected Determination, affected Scope, affected Allocation, affected obligation, affected State, Change Occurrence Time, Change Discovery Time, potential Effective Time, Change Scope, materiality state, dependencies, possible propagation, network relevance, authority association, evidence association, uncertainty, conflict, rationale, provenance, and potential re-entry route.
Meaning of the Output
An Identified Liability Change means that a potentially material difference affecting the governed Liability lifecycle has been sufficiently identified and bounded for formal Change Assessment.
It does not mean the Liability has already changed.
Therefore:
Identified Liability Change ≠ Assessed Liability Change.
Handoff to Liability Change Assessment
LCHIM hands the:
Identified Liability Change
to:
LCHAM — Liability Change Assessment Module
The next governance question becomes:
What effect does this identified change legitimately have on the governed Liability structure, and what governance action follows?
The boundary is explicit:
LCHIM identifies and bounds the Liability Change.
LCHAM assesses its effect on Liability.
Minimum Implementation Framework
A conforming implementation of LCHIM must provide exactly the following eight capabilities:
Change Signal, Baseline & Change Object Identification
Capability to identify Change Signals, establish the relevant governed baseline, detect differences, and define the exact Change Object without treating every difference as a Liability Change.
Change Source, Type, Boundary & Temporal Governance
Capability to identify the source and type of change, establish its boundary, and distinguish Change Occurrence Time, Discovery Time, prospective change, retrospective discovery, and potential Liability effective time.
Affected Liability Structure Identification
Capability to identify affected Subjects, Relationships, Objects, Bases, Conditions, Connections, Determinations, Scope portions, Allocations, obligations, States, dependencies, and other materially relevant Liability components.
Local, Partial, Multi-Dimensional, Propagation & Network Change Governance
Capability to distinguish local, partial, structural, multi-dimensional, cross-Relationship, propagation-relevant, and potentially network-wide Liability Changes.
Change Materiality & Cumulative Change Governance
Capability to distinguish material and non-material change, govern quantitative and qualitative materiality, and identify cumulative or repeated changes that become material in combination.
Unknown, Uncertain, Disputed, Duplicate, Composite & Conflicting Change
Governance
Capability to preserve unresolved Change states, distinguish duplicate reports from distinct Changes, represent Composite Changes, and maintain conflicts without forced resolution.
Change Integrity, Provenance, Traceability & Re-Entry Identification
Capability to preserve Change rationale, source, evidence association, authority association, historical integrity, Origin continuity, and identify the earliest materially affected governance space where re-entry may be required.
Liability Change Assessment Handoff Governance
Capability to produce an Identified Liability Change sufficiently explicit, bounded, materially screened, temporally situated, traceable, and historically connected for Liability Change Assessment.
Governance Logic
The canonical LCHIM governance logic is:
Governed Liability State / Governed Liability State Transition / Change-Relevant Input
↓
Detect Change Signal
↓
Establish Baseline
↓
Identify Difference
↓
Identify Change Object
↓
Identify Change Source & Type
↓
Establish Change Boundary
↓
Identify Affected Liability Structure
↓
Establish Temporal Context
↓
Assess Preliminary Materiality
↓
Identify Local / Partial / Network Relevance
↓
Identify Dependencies & Potential Propagation
↓
Preserve Unknown / Uncertain / Disputed / Conflict States
↓
Identify Potential Re-Entry Route
↓
Preserve Rationale / Provenance / History
↓
Identified Liability Change
↓
Handoff to Liability Change Assessment
Governance Outputs
LCHIM may produce:
Change Identity
Change Signal Record
Change Baseline
Detected Difference Record
Change Source
Change Object
Change Type
Change Boundary
Affected Subject Record
Affected Relationship Record
Affected Object Record
Affected Basis Record
Affected Condition Record
Affected Connection Record
Affected Determination Record
Affected Scope Record
Affected Allocation Record
Affected Obligation Record
Affected State Record
Change Occurrence Time
Change Discovery Time
Prospective Change Record
Retrospective Change Record
Change Scope
Material Change Candidate
Non-Material Change Record
Cumulative Change Record
Change Dependency Record
Propagation Candidate
Network Change Candidate
Unknown Change Record
Uncertain Change Record
Disputed Change Record
Duplicate Change Record
Composite Change Record
Change Conflict Record
Change Authority Association
Change Evidence Association
Change Rationale
Change Provenance Record
Potential Re-Entry Route
The principal output is:
Identified Liability Change
Critical Distinctions
LCHIM preserves the following distinctions:
Change in Underlying Reality ≠ Liability Change by default Liability Change ≠ Liability itself Change Signal ≠ Identified Liability Change Detected Difference ≠ Material Liability Change by default Current Record vs Arbitrary Prior Record ≠ Governed Change Identification Local Liability Change ≠ Complete Liability Change Liability State Change ≠ Liability Structure Change by default Operational Change ≠ Liability Change by default Harm Change ≠ Liability Change by default Responsibility Change ≠ Liability Change Accountability Change ≠ Liability Change Claim Change ≠ Liability Change by default Payment Change ≠ Liability Change by default Insurance Change ≠ Liability Change by default Settlement Change ≠ Liability Change by default Mechanism Change ≠ Liability Change by default Subject Data Change ≠ Liability Subject Replacement Relationship Change ≠ New Liability Relationship by default Liability Object Change ≠ New Liability Object by default Condition Change ≠ Liability Change Outcome Determination-Relevant Change ≠ New Liability Determination Allocation-Relevant Change ≠ Liability Reallocation Authority Change ≠ Liability Change by default Passage of Time ≠ Liability Change by default Newly Known ≠ Newly Occurred Change Discovery Time ≠ Change Occurrence Time by default Change Occurrence Time ≠ Liability Change Effective Time by default Known Future Change ≠ Current Liability Change Subject A Change ≠ Subject B Change by default Relationship A Change ≠ Relationship B Change by default Change Propagation Candidate ≠ Propagated Liability Change Local Liability Change ≠ Liability Network Change by default Material Change ≠ Determined Liability Change Effect Individually Non-Material Changes ≠ Collectively Non-Material by default Unknown Change ≠ No Change Disputed Change ≠ Authority to Select a Preferred Change Multiple Change Records ≠ Multiple Liability Changes by default Same Changes in Different Sequence ≠ Same Liability Change Structure by default Evidence of Change ≠ Liability Change Change Classification ≠ Change Rationale Identified Change ≠ Liability Determination Scope-Relevant Change ≠ Changed Liability Scope Allocation-Relevant Change ≠ Changed Liability Allocation Identified Liability Change ≠ New Liability State Performance-Relevant Change ≠ Liability Resolution Automated Change Detection ≠ Authoritative Liability Change Identification by default Re-Entry ≠ Historical Rewrite Liability Change ≠ New Liability Origin by default Identified Liability Change ≠ Assessed Liability Change
Cross-Architecture Boundary
LCHIM may receive Change-Relevant inputs from other OOF® architectures.
ORA™ may identify Operational Reality changes.
HAGA™ may identify Harm changes.
AGA™ may identify Responsibility, Accountability, Authority, or Attribution changes.
ADIT® may provide evidence of change.
VALIDOS™ may validate Change-Relevant information.
OBIDENITY® may identify changes in identity, ownership, authority, provenance, transfer, or continuity.
AIG® and ASGA™ may identify AI or autonomous-system changes.
VFM® may identify Value Flow changes.
PGA™ may identify Prediction changes.
SIMULOS® may model possible changes.
Those changes remain governed within their original domains.
LCHIM governs only whether they constitute or indicate a Liability-relevant Change.
The canonical interoperability principle is:
An external governed change may become an input to Liability Change Identification without becoming a Liability Change merely because it occurred.
Canonical Boundary
LCHIM begins with:
Governed Liability State, Governed Liability State Transition, or another Change-Relevant Governed Input and governs identification of potentially material Liability Change.
LCHIM governs:
Change Signals, Baselines, Detected Differences, Change Objects, Change Sources, Change Types, Change Boundaries, Affected Liability Structures, Temporal Change, Local Change, Partial Change, Structural Change, State-only Change, Multi-Dimensional Change, Materiality, Cumulative Change, Dependencies, Propagation Candidates, Network Change candidates, Unknown Change, Uncertain Change, Disputed Change, Duplicate Change, Composite Change, Change Conflict, Authority association, Evidence association, Rationale, Provenance, Origin continuity, and potential re-entry routing.
LCHIM does not govern:
final Change effect, new Liability Determination, new Scope, new Allocation, final State modification, Transfer, Recourse, Resolution, Discharge, or Finality.
LCHIM ends when an:
Identified Liability Change
is sufficiently explicit and bounded for Liability Change Assessment.
Use Case 1 — Industrial Liability Change Identification
An industrial Liability structure contains an Active repair obligation and an allocated production-loss component.
New technical information shows that a previously identified equipment dependency changed several weeks earlier.
LCHIM distinguishes the newly discovered information from the time the underlying change actually occurred.
It identifies the affected obligation, Relationship, Scope portion, and possible Allocation relevance.
The change is classified as materially relevant because it may affect more than the current Liability State.
LCHIM does not modify the Liability.
It produces an Identified Liability Change for formal assessment by LCHAM.
Use Case 2 — Autonomous System Liability Change
Identification
An autonomous system involved in an established Liability structure receives a major software update and its operational role changes.
LCHIM does not treat the software update itself as a Liability Change.
It compares the new Operational Reality with the governed Liability baseline and identifies whether the update affects any Liability Subject, Relationship, Condition, Scope, Allocation, obligation, or current State.
Only the materially Liability-relevant differences become part of the Identified Liability Change.
The module therefore preserves the distinction:
Operational Change ≠ Liability Change by default.
Canonical Closing Statement
Liability should not be treated as changed merely because the world around it changed.
A new event, fact, payment, Claim state, Harm state, system state, or operational condition may matter.
But relevance must be identified before effect is determined.
LCHIM establishes what changed, where the change belongs, what Liability structures may be affected, and whether formal assessment is required.
It does not decide the outcome before the change has been governed.
Detect the difference. Identify the Liability relevance. Bound the change before assessing its effect.
A change becomes a governed Liability Change only when its relationship to Liability is made explicit.