LCXRM — Liability Connection Relationship Module
LCXRM — Liability Connection Relationship Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Connection Standard (LCNS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Connection Relationships
Module ID: LIGA-LCNS-LCXRM-001
Origin ID: OOF.CM.LIGA.06.02.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 22 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 Connection Relationship Module (LCXRM) governs how the relationship between the identified elements of each Liability Connection Candidate is explicitly structured, distinguished, bounded, directed, typed, and represented before those relationships are assembled into complete Liability Connection Chains.
LCXRM transforms an Identified Liability Connection Set into a governed set of explicit Liability Connection Relationships by determining what elements are related, the nature of their relationship, the direction in which that relationship operates where relevant, the scope and boundaries of the relationship, and how multiple or overlapping relationships remain distinct.
LCXRM does not determine the complete Connection Chain, Connection Qualification, evidentiary sufficiency, Liability Attachment, or Liability.
It governs the transition:
Identified Liability Connection Set → Relationship Formation → Relationship Type → Direction & Boundary → Relationship Distinction → Governed Liability Connection Relationship Set Its foundational distinction is:
Connection Candidate ≠ Governed Connection Relationship.
Operational Role
The operational role of LCXRM is:
to convert identified potential Connections into explicit governed relationships whose meaning, endpoints, direction, type, scope, and boundaries are sufficiently structured for subsequent Connection Chain governance.
LCXIM asks:
Which potential Connections require governance?
LCXRM asks:
What exactly is the governed relationship between the identified elements of each Connection Candidate?
LCXCM subsequently asks:
How do those governed Connection Relationships combine into complete Connection Chains?
Position in the Parent Standard Flow
The internal LCNS progression is:
Liability Connection Identification → Liability Connection Relationship → Liability Connection Chain → Liability Connection Qualification → Liability Connection Evidence Association LCXRM governs:
Liability Connection Relationship
Its principal input is:
Identified Liability Connection Set
Its principal output is:
Governed Liability Connection Relationship Set
Its canonical handoff is:
Governed Liability Connection Relationship Set → Liability Connection Chain Governance
Central Operational Question
What is the governed relationship between the identified elements of each Liability Connection Candidate, and how must that relationship be structured so that it can form part of a Liability Connection Chain?
Governed Space
LCXRM governs:
Connection Relationship Formation, Connection Relationship Identity, Relationship Endpoints, Relationship Direction, Relationship Type, Relationship Role, Relationship Scope, Relationship Boundary, Relationship Basis Association, Relationship Subject Association, Relationship Object Association, Relationship Condition Association, Relationship Temporal State, Direct Relationship, Indirect Relationship Reference, Operational Relationship, Control Relationship, Authority Relationship, Dependency Relationship, Conduct Relationship, Event Relationship, State Relationship, Consequence Relationship, Contribution Relationship, Multi-Subject Relationship, Multiple Relationships, Parallel Relationships, Overlapping Relationships, Composite Relationships, Relationship Distinction, Relationship Conflict, Relationship Uncertainty, Relationship Change, Relationship Correction, and Relationship Sufficiency.
Connection Relationship
A Connection Relationship is an explicitly governed relationship between two or more identified elements within a potential Liability Connection structure.
It defines:
how the elements are related without determining:
what the complete Connection Chain establishes.
Therefore:
Connection Relationship ≠ Connection Chain.
Relationship Formation
Relationship Formation converts an identified Connection Candidate into an explicit relational structure.
The process should establish, where materially relevant:
the connected elements, relationship identity, relationship type, direction, scope, boundary, temporal relevance, and applicable associations.
Relationship Identity
Each materially distinct Connection Relationship should retain a stable governed identity.
Relationship Identity allows the same relationship to be:
referenced, combined into chains, qualified, corrected, reassessed, versioned, or historically reconstructed.
Therefore:
Connection Relationship Identity ≠ Endpoint Identity.
Relationship Identity and Candidate Identity
A Connection Candidate may become one governed Connection Relationship.
It may also reveal:
multiple relationships, a composite relationship, or no sufficiently governable relationship.
Therefore:
Connection Candidate Identity ≠ Connection Relationship Identity by default.
Relationship Endpoints
Each Connection Relationship should identify its materially relevant endpoints.
Canonical representation:
Endpoint A ↔ Endpoint B
or, where direction matters:
Endpoint A → Endpoint B Endpoints should reference governed objects rather than ambiguous descriptive labels wherever possible.
Endpoint Integrity
The identity of each endpoint should remain stable enough to prevent the Relationship from silently changing meaning.
Therefore:
Endpoint Change ≠ Same Relationship by default.
A materially changed endpoint may require a different Relationship identity.
Relationship Direction
Where direction affects Liability relevance, LCXRM should establish explicit Relationship direction.
Examples:
Subject → Action Authority → Decision Action → Object State Event → Consequence Condition → Subject Applicability Direction must not be assumed from presentation order alone.
Bidirectional Relationship
Some relationships may legitimately operate in both directions.
Where this is materially relevant, they may be represented as:
A ↔ B
A bidirectional representation should not be used merely because direction is unknown.
Therefore:
Bidirectional Relationship ≠ Unknown Direction.
Unknown Direction
Where a Relationship exists but its direction cannot yet be determined, direction should remain explicitly unknown.
Therefore:
Unknown Direction ≠ Bidirectional Relationship.
Relationship Type
Each Relationship should be typed where type materially affects Connection governance.
Potential types may include:
Operational, Control, Authority, Dependency, Conduct, Event, State, Temporal, Contribution, Identity, Ownership, Permission, Maintenance, Design, Production, Deployment, Supervision, Reliance, Communication, or another explicitly governed type.
Type Does Not Determine Liability
A Relationship type describes the Connection relationship.
It does not determine Liability.
Therefore:
Relationship Type ≠ Liability Type.
Operational Relationship
An Operational Relationship may connect elements through actual operational activity or state.
ORA™ may govern the underlying Operational Reality.
LCXRM governs only its Liability-specific relational representation.
Therefore:
Operational Relationship ≠ Liability.
Control Relationship
A Control Relationship may connect a Subject to:
Object, system, process, activity, or another Subject.
The existence of control may be materially relevant.
However:
Control Relationship ≠ Liability Determination.
Authority Relationship
An Authority Relationship may connect a Subject to:
decision, action, system, Object, or another Subject.
GOA™ may govern the underlying Authority state.
Therefore:
Authority Relationship ≠ Liability.
Responsibility Relationship
A Responsibility state may create a materially relevant Connection Relationship.
AGA™ governs Responsibility.
LCXRM governs its Liability-specific relational relevance.
Therefore:
Responsibility Relationship ≠ Liability.
Accountability Relationship
An Accountability structure may become relevant to the Connection.
However:
Accountability Relationship ≠ Liability Relationship Determination.
Accountability and Liability remain distinct governance objects.
Dependency Relationship
A Dependency Relationship exists where one element materially depends upon another.
Dependency may concern:
operation, state, authority, information, resource, decision, or another governed dependency.
Therefore:
Dependency Relationship ≠ Liability by itself.
Conduct Relationship
A Conduct Relationship connects a Subject or other relevant element to governed conduct.
The Relationship may concern:
performance, authorization, control, instruction, supervision, execution, or another materially relevant role.
Therefore:
Conduct Relationship ≠ Wrongdoing.
Action Relationship
An Action Relationship identifies how an action relates to another governed element.
Examples:
Subject → Action Action → Object Action → Event The Relationship does not establish the complete downstream chain.
Omission Relationship
An Omission Relationship may exist where governed non-action is materially connected to another element.
LCXRM must preserve the Requirement or Condition that makes the non-action relevant.
Therefore:
Non-Action ≠ Omission Relationship by default.
Event Relationship
An Event Relationship connects an event to another materially relevant element.
Examples:
Action → Event Event → State Event → Consequence Event Relationship does not establish causation by default.
State Relationship
A State Relationship connects a governed state to another relevant element.
The state may originate from:
ORA™, HAGA™, AGA™, GOA™, OBIDENITY®, AIG®, ASGA™, or another relevant architecture.
LCXRM governs only its Liability-specific relationship.
Consequence Relationship
A Consequence Relationship connects a governed consequence to another element.
The existence of a consequence does not establish how it arose or who bears Liability.
Therefore:
Consequence Relationship ≠ Liability.
Harm Relationship
A governed Harm state may participate in a Connection Relationship where Harm is relevant to the Liability Basis.
HAGA™ retains governance ownership of Harm.
Therefore:
Harm Relationship ≠ Liability Relationship.
Identity Relationship
Identity may establish that two records, actions, states, or representations relate to the same governed Subject or Object.
OBIDENITY® may govern that identity.
LCXRM may preserve the identity relationship where necessary for Liability Connection governance.
Therefore:
Identity Relationship ≠ Liability Connection by itself.
Ownership Relationship
Ownership may create a materially relevant relationship between Subject and Object.
Ownership does not automatically establish:
control, conduct, fault, or Liability.
Therefore:
Ownership Relationship ≠ Liability.
Permission Relationship
Permission may connect a Subject to an action, system, capability, or Object.
The existence of Permission does not establish execution.
Therefore:
Permission ≠ Action.
and:
Permission Relationship ≠ Liability.
Supervision Relationship
Supervision may connect one Subject to another Subject, process, system, or activity.
The existence of supervision does not determine whether the supervised conduct occurred or whether Liability attaches.
Maintenance Relationship
A Maintenance Relationship may connect:
maintenance provider, Object, maintenance action, Condition, or operational state.
LCXRM preserves the relevant relational structure without determining whether maintenance was adequate or Liability exists.
Design Relationship
A Design Relationship may connect a designer or design authority to an Object, component, system, or specification.
Therefore:
Design Relationship ≠ Design Defect.
Production Relationship
A Production Relationship may connect a producer to a product, component, process, or output.
Therefore:
Production Relationship ≠ Product Liability.
Deployment Relationship
A Deployment Relationship may connect a deploying Subject to:
system, configuration, environment, or operational activity.
Therefore:
Deployment Relationship ≠ Deployment Liability.
Reliance Relationship
Reliance may become materially relevant under certain Liability Bases.
A Reliance Relationship should identify:
the relying Subject, the relevant representation or state, and the direction of reliance.
Therefore:
Reliance Relationship ≠ Liability by itself.
Communication Relationship
A Communication Relationship may connect:
sender, message, recipient, decision, action, or consequence.
The existence of communication does not establish reliance or Liability.
Therefore:
Communication ≠ Reliance.
Contribution Relationship
A Contribution Relationship may represent that an element contributed to another state, event, or consequence.
Contribution should not be treated automatically as complete causation.
Therefore:
Contribution ≠ Complete Causation.
and:
Contribution ≠ Liability.
Relationship Scope
Each Connection Relationship should have a scope sufficient to determine what the Relationship includes.
Scope may be limited by:
Subject, Object, Condition, Basis, activity, time, location, system, event, or another relevant boundary.
Relationship Boundary
The Relationship Boundary determines where a Connection Relationship begins and ends as a governed relational object.
A boundary prevents adjacent relationships from being silently merged.
Therefore:
Relationship Proximity ≠ Relationship Identity.
Basis-Specific Relationship
A Connection Relationship may possess relevance only under a particular Liability Basis.
Therefore:
Relationship under Basis A ≠ Relationship under Basis B by default.
Basis association should remain explicit.
Condition-Specific Relationship
A Relationship may be relevant to one Liability Condition but not another.
Therefore:
Relationship relevant to Condition A ≠ Relationship relevant to Condition B by default.
Subject-Specific Relationship
Different Subjects may possess materially different Relationships to the same Object, Condition, event, or consequence.
Therefore:
Subject A Relationship ≠ Subject B Relationship.
Object-Specific Relationship
A Subject may possess different Connection Relationships to different Liability Objects.
Therefore:
Relationship to Object A ≠ Relationship to Object B.
Relationship-Specific Relationship
A Connection Relationship may itself depend upon an upstream Liability Relationship established under LRS.
The two remain distinct.
Therefore:
Liability Relationship ≠ Liability Connection Relationship.
The first defines relational participation in the potential Liability structure.
The second defines the Liability-specific Connection between relevant elements.
Direct Connection Relationship
A Direct Connection Relationship links two governed elements without requiring a materially necessary intermediate element for that specific relational step.
Canonical form:
A → B Directness applies to the individual Relationship.
It does not establish that the complete Connection is direct.
Indirect Connection Reference
Where the identified candidate depends upon intermediate elements, LCXRM should not falsely represent the endpoints as directly related.
Instead, it may preserve an indirect Connection reference for subsequent Chain governance.
Therefore:
Indirect Connection ≠ Direct Relationship.
Intermediate Relationship Requirement
Where A and C appear connected only through B:
A → B → C LCXRM should govern:
A → B and:
B → C as distinct Relationships where both are materially necessary.
LCXCM later governs their combination into a Chain.
Relationship Sequence
Individual Relationships may possess a preliminary sequence where order is known.
However, LCXRM does not own complete Connection Chain sequencing.
Therefore:
Relationship Sequence ≠ Complete Connection Chain.
Temporal Relationship
A Connection Relationship may be valid only during a defined period.
LCXRM should preserve materially relevant:
start, end, activation, suspension, expiration, or unknown temporal state.
Historical Relationship
A Connection Relationship may have existed historically but no longer exist.
Therefore:
Current Relationship Absence ≠ Historical Relationship Absence.
Relationship Continuity
A Relationship may change while retaining its governed identity.
Therefore:
Relationship Change ≠ New Relationship by default.
Continuity should preserve material historical states.
Relationship Activation
A Relationship may exist structurally before becoming operationally active.
Therefore:
Relationship Existence ≠ Relationship Activation.
Relationship Suspension
A Relationship may temporarily cease active operation without losing identity.
Therefore:
Relationship Suspension ≠ Relationship Termination.
Relationship Termination
A Relationship may terminate while remaining historically relevant.
Therefore:
Relationship Termination ≠ Historical Erasure.
Multiple Relationships Between Same Endpoints
The same two endpoints may possess several materially distinct Relationships.
Example:
Subject A → Object B: Ownership Subject A → Object B: Operational Control Subject A → Object B: Maintenance Responsibility These should not be collapsed merely because their endpoints are identical.
Therefore:
Same Endpoints ≠ Same Relationship.
Parallel Relationships
Multiple Relationships may operate in parallel.
Parallelism should preserve:
separate identities, types, scopes, and temporal states.
Therefore:
Parallel Relationships ≠ One Composite Relationship by default.
Overlapping Relationships
Relationships may partially overlap in:
scope, time, Subjects, Objects, or function.
Overlap does not establish equivalence.
Therefore:
Relationship Overlap ≠ Relationship Equivalence.
Composite Relationship
A Composite Relationship may be represented where several inseparable relational components must be governed together.
Its internal components should remain identifiable where materially relevant.
Therefore:
Composite Relationship ≠ Unstructured Relationship Aggregation.
Multi-Subject Relationship
A Connection Relationship may involve multiple Subjects.
Where individual Subject roles differ, those differences should remain explicit.
Therefore:
Multi-Subject Relationship ≠ Equal Subject Connection.
Multi-Object Relationship
A Connection Relationship may involve multiple Objects.
Object-specific distinctions should remain visible where they affect downstream Connection governance.
Relationship Network
LCXRM may produce multiple interconnected Relationships.
This does not yet constitute the complete governed Connection Network.
LCXCM determines how Relationships combine into Chains and network structures.
Therefore:
Relationship Set ≠ Complete Connection Network.
Relationship Distinction
LCXRM must distinguish materially different Relationships even where they appear similar.
Distinction may depend on:
identity, type, direction, scope, Basis, Condition, Subject, Object, time, or role.
Relationship Similarity
Two Relationships may appear similar without being equivalent.
Therefore:
Relationship Similarity ≠ Relationship Identity.
Relationship Equivalence
Relationships should be treated as equivalent only where the applicable methodology establishes that their materially relevant characteristics represent the same governed relationship.
Equivalence should not be inferred from shared labels alone.
Relationship Duplication
Multiple records may represent the same Connection Relationship.
Duplicate reconciliation should preserve provenance.
Therefore:
Multiple Relationship Records ≠ Multiple Relationships by default.
Relationship Conflict
Governed inputs may support conflicting descriptions of the same potential Relationship.
LCXRM should preserve the conflict.
Therefore:
Relationship Conflict ≠ Authority to Manufacture Relational Certainty.
Relationship Uncertainty
Uncertainty may concern:
Relationship existence, type, direction, scope, endpoint identity, temporal state, or Basis relevance.
Uncertainty should remain explicit.
Therefore:
Relationship Uncertainty ≠ Relationship Absence.
Unknown Relationship
Where a Connection Candidate is relevant but the nature of the Relationship cannot yet be established, it may remain:
Unknown Relationship
rather than being forced into an unsupported type.
Therefore:
Unknown Relationship ≠ No Relationship.
Disputed Relationship
A Relationship may remain disputed where competing governed sources support materially different representations.
Therefore:
Disputed Relationship ≠ Established Relationship.
Inferred Relationship
A Relationship may be inferred where methodology permits.
The inference should preserve:
inputs, logic, assumptions, and uncertainty.
Therefore:
Inferred Relationship ≠ Directly Established Relationship.
Assumed Relationship
An assumption may be recorded for analytical purposes.
It must not be represented as an established Relationship.
Therefore:
Assumed Relationship ≠ Governed Established Relationship.
Relationship Change
A Connection Relationship may change because:
underlying reality changes, Subject roles change, Object states change, Conditions change, authority changes, control changes, or new information becomes available.
Change should remain traceable.
Relationship Correction
An earlier Relationship representation may be found incorrect.
Correction should preserve:
the earlier representation, corrected representation, reason, effective relevance, and provenance.
Therefore:
Relationship Correction ≠ Historical Erasure.
Relationship Reassessment
New information may require reassessment of:
type, direction, scope, identity, or relevance.
Therefore:
Relationship Reassessment ≠ Historical Rewrite.
Relationship Versioning
Material Relationship changes may require versioning.
Therefore:
New Relationship Version ≠ New Relationship by default.
The distinction between continuity and new identity must be governed.
Relationship Re-Entry
Later LCNS stages may reveal that a Relationship was incorrectly structured.
LCXRM should support targeted re-entry.
Therefore:
Relationship Re-Entry ≠ New Liability Origin by default.
Upstream Re-Entry
Relationship governance may reveal that the problem lies in Connection Identification.
Where a relevant Connection Candidate is missing or incorrectly identified, governance should return to LCXIM.
Likewise, defective upstream LIGA™ structures should return to their owning Parent Standard.
No Liability Relationship Substitution
LCXRM must not substitute the Liability Relationship established by LRS for the Connection Relationship governed here.
For example:
a contractual relationship may establish that two Subjects participate in the Liability structure.
LCXRM must still determine how a relevant action, Condition, Object, event, or consequence connects within that structure.
Therefore:
Participation Relationship ≠ Connection Relationship.
No Causation Substitution
An operational causal relationship may become a Connection Relationship input.
It does not automatically become the complete Liability Connection Relationship.
Therefore:
Operational Causal Relationship ≠ Liability Connection Relationship by default.
No Harm Substitution
A relationship to Harm does not automatically establish the Liability-specific relationship required by LCNS.
Therefore:
Relationship to Harm ≠ Liability Connection Relationship by default.
No Accountability Substitution
An Accountability relationship does not automatically become a Liability Connection Relationship.
Therefore:
Accountability Relationship ≠ Liability Connection Relationship by default.
No Control Substitution
A Control Relationship may be materially relevant.
It must not be converted automatically into Liability.
Therefore:
Control Relationship ≠ Liability Connection Sufficiency.
No Ownership Substitution
Ownership may form one Relationship within the Connection structure.
It does not establish the complete Liability Connection.
Therefore:
Ownership Relationship ≠ Complete Liability Connection.
No Temporal Shortcut
Two events occurring close together may justify a Relationship inquiry.
Temporal proximity alone does not establish the Relationship type or meaning.
Therefore:
Temporal Proximity ≠ Governed Connection Relationship.
No Spatial Shortcut
Spatial proximity may be relevant but does not establish the governed Relationship.
Therefore:
Spatial Proximity ≠ Governed Connection Relationship.
No Label Shortcut
Two records carrying the same relationship label may represent materially different Relationships.
Therefore:
Same Label ≠ Same Relationship.
Governed characteristics determine identity.
Relationship Sufficiency
A Connection Relationship is sufficiently governed for Chain formation when materially relevant aspects of its:
identity, endpoints, type, direction, scope, boundary, Basis association, Condition association, Subject association, Object association, temporal state, and uncertainty are explicit enough for LCXCM to determine how it connects with other Relationships.
Relationship Sufficiency and Qualification
Relationship sufficiency does not mean the overall Connection has been qualified.
Therefore:
Relationship Sufficiency ≠ Connection Qualification.
LCXQM owns Qualification.
Relationship Sufficiency and Evidence
A Relationship may be structurally sufficient for Chain governance while its evidentiary support remains incomplete or disputed.
Therefore:
Relationship Structural Sufficiency ≠ Evidence Sufficiency.
LCXEAM governs Connection Evidence Association.
Governed Liability Connection Relationship Set
The principal output of LCXRM is:
Governed Liability Connection Relationship Set
It contains the materially relevant governed Relationships needed to construct Liability Connection Chains.
The set may contain:
direct Relationships, directional Relationships, bidirectional Relationships, unknown-direction Relationships, operational Relationships, control Relationships, authority Relationships, dependency Relationships, conduct Relationships, event Relationships, state Relationships, consequence Relationships, and other explicitly governed relational types.
Handoff to Connection Chain Governance
LCXRM hands the:
Governed Liability Connection Relationship Set
to:
LCXCM — Liability Connection Chain Module
The next governance question becomes:
How do the governed Liability Connection Relationships combine into complete, ordered, traceable, and materially sufficient Connection Chains?
LCXRM must not answer that question prematurely.
Minimum Implementation Framework
A conforming implementation of LCXRM must provide exactly the following eight capabilities:
Connection Relationship Formation & Identity
Capability to transform Connection Candidates into explicitly governed Connection Relationships with persistent identities sufficient for subsequent Chain governance.
Endpoint, Direction & Role Governance
Capability to establish Relationship endpoints, direction, bidirectionality, unknown direction, and the materially relevant roles of connected elements.
Relationship Type Governance
Capability to distinguish operational, control, authority, dependency, conduct, event, state, consequence, contribution, identity, ownership, permission, supervision, maintenance, design, production, deployment, reliance, communication, and other materially relevant Relationship types.
Scope, Boundary & Association Governance
Capability to govern Relationship scope and boundaries and preserve relevant Basis, Subject, Object, Condition, and upstream Liability Relationship associations.
Multiple, Parallel, Overlapping & Composite Relationship Governance
Capability to preserve materially distinct Relationships among the same or overlapping endpoints without inappropriate consolidation and to represent composite or multi-subject structures where justified.
Temporal, Uncertain, Disputed & Inferred Relationship Governance
Capability to preserve temporal states, historical Relationships, uncertainty, disputes, conflicts, assumptions, and governed inference without manufacturing certainty.
Relationship Change, Correction, Versioning & Re-Entry
Capability to preserve legitimate Relationship change, correction, reassessment, versioning, continuity, and targeted lifecycle re-entry without historical erasure.
Relationship Sufficiency & Handoff
Capability to determine whether the Governed Liability Connection Relationship Set is sufficiently structured for Connection Chain governance without prematurely determining Connection Qualification, evidentiary sufficiency, or Liability.
Governance Logic
The canonical LCXRM governance logic is:
Identified Liability Connection Set
↓
Select Connection Candidate
↓
Establish Connection Relationship Identity
↓
Confirm Governed Endpoints
↓
Determine Direction / Bidirectionality / Unknown Direction
↓
Determine Relationship Type
↓
Determine Relationship Role
↓
Establish Scope
↓
Establish Boundary
↓
Associate Liability Basis
↓
Associate Subjects / Objects / Conditions
↓
Associate Upstream Liability Relationships
↓
Preserve Temporal State
↓
Distinguish Direct / Indirect Relationship Structure
↓
Separate Multiple / Parallel / Overlapping Relationships
↓ Govern Composite Relationships where necessary ↓
Preserve Unknown / Uncertain / Disputed / Inferred Relationships
↓
Govern Change / Correction / Versioning / Re-Entry
↓
Assess Relationship Sufficiency
↓
Governed Liability Connection Relationship Set
↓
Handoff to Liability Connection Chain Governance
Governance Outputs
LCXRM may produce:
Connection Relationship Identity
Connection Relationship Endpoint Set
Directed Connection Relationship
Bidirectional Connection Relationship
Unknown-Direction Connection Relationship
Operational Connection Relationship
Control Connection Relationship
Authority Connection Relationship
Responsibility-Related Connection Relationship
Accountability-Related Connection Relationship
Dependency Connection Relationship
Conduct Connection Relationship
Action Connection Relationship
Omission Connection Relationship
Event Connection Relationship
State Connection Relationship
Consequence Connection Relationship
Harm-Related Connection Relationship
Identity-Related Connection Relationship
Ownership Connection Relationship
Permission Connection Relationship
Supervision Connection Relationship
Maintenance Connection Relationship
Design Connection Relationship
Production Connection Relationship
Deployment Connection Relationship
Reliance Connection Relationship
Communication Connection Relationship
Contribution Connection Relationship
Parallel Relationship Set
Overlapping Relationship Set
Composite Connection Relationship
Multi-Subject Connection Relationship
Relationship Temporal State
Unknown Connection Relationship
Uncertain Connection Relationship
Disputed Connection Relationship
Inferred Connection Relationship
Relationship Conflict
Relationship Correction Record
Relationship Reassessment Record
Relationship Version Record
Relationship Sufficiency State
The principal output is:
Governed Liability Connection Relationship Set
Critical Distinctions
LCXRM preserves the following distinctions:
Connection Candidate ≠ Governed Connection Relationship Connection Relationship ≠ Connection Chain Connection Relationship Identity ≠ Endpoint Identity Connection Candidate Identity ≠ Connection Relationship Identity by default Endpoint Change ≠ Same Relationship by default Bidirectional Relationship ≠ Unknown Direction Unknown Direction ≠ Bidirectional Relationship Relationship Type ≠ Liability Type Operational Relationship ≠ Liability Control Relationship ≠ Liability Determination Authority Relationship ≠ Liability Responsibility Relationship ≠ Liability Accountability Relationship ≠ Liability Relationship Determination Dependency Relationship ≠ Liability by itself Conduct Relationship ≠ Wrongdoing Non-Action ≠ Omission Relationship by default Consequence Relationship ≠ Liability Harm Relationship ≠ Liability Relationship Identity Relationship ≠ Liability Connection by itself Ownership Relationship ≠ Liability Permission ≠ Action Permission Relationship ≠ Liability Design Relationship ≠ Design Defect Production Relationship ≠ Product Liability Deployment Relationship ≠ Deployment Liability Reliance Relationship ≠ Liability by itself Communication ≠ Reliance Contribution ≠ Complete Causation Contribution ≠ Liability Relationship Proximity ≠ Relationship Identity Relationship under Basis A ≠ Relationship under Basis B by default Relationship relevant to Condition A ≠ Relationship relevant to Condition B by default Subject A Relationship ≠ Subject B Relationship Relationship to Object A ≠ Relationship to Object B Liability Relationship ≠ Liability Connection Relationship Indirect Connection ≠ Direct Relationship Relationship Sequence ≠ Complete Connection Chain Current Relationship Absence ≠ Historical Relationship Absence Relationship Change ≠ New Relationship by default Relationship Existence ≠ Relationship Activation Relationship Suspension ≠ Relationship Termination Relationship Termination ≠ Historical Erasure Same Endpoints ≠ Same Relationship Parallel Relationships ≠ One Composite Relationship by default Relationship Overlap ≠ Relationship Equivalence Composite Relationship ≠ Unstructured Relationship Aggregation Multi-Subject Relationship ≠ Equal Subject Connection Relationship Set ≠ Complete Connection Network Relationship Similarity ≠ Relationship Identity Multiple Relationship Records ≠ Multiple Relationships by default Relationship Conflict ≠ Authority to Manufacture Relational Certainty Relationship Uncertainty ≠ Relationship Absence Unknown Relationship ≠ No Relationship Disputed Relationship ≠ Established Relationship Inferred Relationship ≠ Directly Established Relationship Assumed Relationship ≠ Governed Established Relationship Relationship Correction ≠ Historical Erasure Relationship Reassessment ≠ Historical Rewrite New Relationship Version ≠ New Relationship by default Relationship Re-Entry ≠ New Liability Origin by default Participation Relationship ≠ Connection Relationship Operational Causal Relationship ≠ Liability Connection Relationship by default Relationship to Harm ≠ Liability Connection Relationship by default Accountability Relationship ≠ Liability Connection Relationship by default Control Relationship ≠ Liability Connection Sufficiency Ownership Relationship ≠ Complete Liability Connection Temporal Proximity ≠ Governed Connection Relationship Spatial Proximity ≠ Governed Connection Relationship Same Label ≠ Same Relationship Relationship Sufficiency ≠ Connection Qualification Relationship Structural Sufficiency ≠ Evidence Sufficiency
Cross-Architecture Boundary
LCXRM may use relational states governed by other OOF® architectures as inputs.
ORA™ governs Operational Reality and operational relationships.
GOA™ governs Authority, Scope, and Delegation.
AGA™ governs Responsibility, Accountability, and Attribution.
HAGA™ governs Harm and its lifecycle.
ADIT® governs evidence and auditability.
VALIDOS™ governs validation.
OBIDENITY® governs Identity, Ownership, Authority, Permission, Provenance, Transfer, and Continuity.
AIG® and ASGA™ govern AI and autonomous-system behavior and operational governance states.
LCXRM does not duplicate those governance domains.
It determines how their relevant governed states participate in a Liability Connection Relationship.
The canonical interoperability principle is:
An externally governed relationship may become a component of a Liability Connection Relationship without transferring governance ownership of its original domain to LIGA™.
Canonical Boundary
LCXRM begins with an:
Identified Liability Connection Set
and asks:
What exactly is the governed relationship between the identified elements of each Connection Candidate?
LCXRM governs:
Relationship Formation, Relationship Identity, Endpoints, Direction, Type, Role, Scope, Boundary, Basis Association, Subject Association, Object Association, Condition Association, upstream Liability Relationship Association, Temporal State, Direct Relationships, Indirect Relationship References, Multiple Relationships, Parallel Relationships, Overlapping Relationships, Composite Relationships, Multi-Subject Relationships, Relationship Distinction, Relationship Conflict, Relationship Uncertainty, Inference, Change, Correction, Reassessment, Versioning, Re-Entry, and Relationship Sufficiency.
LCXRM does not determine:
the complete Connection Chain, final Connection Network structure, Connection Qualification, Connection Evidence Sufficiency, Operational Causation itself, Harm, Accountability, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Liability State, Liability Transfer, Recourse, Resolution, Discharge, or Finality.
LCXRM ends when a:
Governed Liability Connection Relationship Set
is sufficiently structured for Liability Connection Chain governance.
Use Case 1 — Autonomous System Control Relationship
An autonomous industrial system performs an operational action involving a governed Liability Object.
LCXIM has identified potential Connections among:
the system operator, the autonomous system, the action, the Object, and an operational event.
LCXRM determines the distinct Relationships among those elements.
It may distinguish:
operator → system as an operational-control Relationship, system → action as an execution Relationship, and action → Object as an operational Relationship.
The module does not collapse those Relationships into one assumed causal or Liability chain.
It produces explicit governed Relationships that LCXCM can subsequently assemble and test as a Connection Chain.
Use Case 2 — Multi-Party Maintenance Relationships
A technical installation is owned by one organization, operated by another, and maintained by a third provider.
A later incident makes several Connection Candidates relevant.
LCXRM distinguishes:
owner → equipment as an Ownership Relationship, operator → equipment as an Operational-Control Relationship, maintenance provider → maintenance activity as a Conduct Relationship, and maintenance activity → equipment state as an Operational Relationship.
The shared Object does not make these Relationships equivalent.
Each Relationship retains its own identity, type, direction, scope, and temporal state.
LCXCM can then determine how the relevant Relationships combine into one or more Liability Connection Chains.
Canonical Closing Statement
Identifying the elements of a potential Liability Connection is not enough.
The relationship between those elements must itself be explicit: what is related, in what direction, through what role, within what scope, and under which governed context.
LCXRM converts potential Connections into governed relational structure without prematurely constructing the complete chain or determining Liability.
A Connection Candidate identifies what may be related. A Connection Relationship defines how those elements are related.
Define the relationship before constructing the chain.