LRIM — Liability Relationship Identification Module
LRIM — Liability Relationship Identification Module
(LRIM)
Architecture:
LIGA™ — Liability Governance Architecture
Parent Standard:
Liability Relationship Standard (LRS)
Category:
Governance & Enforcement
Subcategory:
Liability Governance
Type:
Core Module
Governed Space:
Liability Relationship Identification
Module ID:
LIGA-LRS-LRIM-001
Origin ID:
OOF.CM.LIGA.04.02.01
Version:
1.0 Status:
Canonical · Open Standard
Effective Date:
21 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 Relationship Identification Module (LRIM) governs how materially relevant relationships among Identified Liability Subjects, and between those Subjects, the Governed Liability Object, and the Governed Liability Basis, are recognized, identified, typed, bounded, referenced, and represented as distinct Liability Relationship Candidates for subsequent relationship mapping and governance.
LRIM determines which relationships must enter the Liability inquiry without converting relational relevance, contractual structure, ownership, control, authority, delegation, responsibility, accountability, operational participation, or other relationship characteristics into Liability.
LRIM governs the transition:
Identified Liability Subject Set → Potential Relationship Recognition → Relationship Candidate Identification → Relationship Identity → Relationship Type & Direction → Identified Liability Relationship Set Its foundational distinction is:
Liability Relationship ≠ Liability.
Operational Role
The operational role of LRIM is:
to determine which relationships among the identified Subjects and relevant Liability structures must be explicitly represented for subsequent Liability governance.
LSUIM establishes:
Who or what must be examined?
LRIM establishes:
What Liability-relevant relationships involving those Subjects must be examined?
LRIM does not determine whether any identified relationship produces Liability.
Position in the Parent Standard Flow
The internal LRS progression is:
Liability Subject Identification → Liability Relationship Identification → Relationship Mapping → Relationship Distinction → Relationship Continuity LRIM governs:
Liability Relationship Identification
Its principal input is:
Identified Liability Subject Set
Its principal output is:
Identified Liability Relationship Set
Its canonical handoff is:
Identified Liability Relationship Set → Liability Relationship Mapping
Central Operational Question
What materially relevant relationships exist or may exist among the identified Liability Subjects and between those Subjects, the Governed Liability Object, and the Governed Liability Basis?
The question concerns relationship identification.
It does not ask whether those relationships establish Liability.
Governed Space
LRIM governs:
Potential Relationship Recognition, Relationship Candidate Identification, Relationship Identity, Relationship Origin, Relationship Type, Relationship Direction, Relationship Participants, Subject–Subject Relationships, Subject–Object Relationships, Subject–Basis Relationships, Direct Relationships, Indirect Relationships, Reciprocal Relationships, Multi-Subject Relationships, Multiple Relationships, Formal Relationships, Operational Relationships, Relationship Scope, Relationship Boundary, Relationship Relevance, Relationship Temporal State, Relationship Uncertainty, Relationship Conflict, Relationship Correction, Relationship Reassessment, and Relationship Identification Sufficiency.
Liability Relationship Candidate
A Liability Relationship Candidate is a potentially relevant governed relationship whose existence, identity, type, direction, scope, or participants require explicit representation within the Liability inquiry.
Candidate status does not establish a final relationship state.
Therefore:
Potential Relationship ≠ Identified Liability Relationship.
Relationship Recognition
A potential Liability Relationship may become visible through:
the Governed Liability Basis, the Governed Liability Object, Subject roles, contracts, ownership, control, authority, delegation, agency, service provision, manufacture, operation, maintenance, custody, insurance, guarantee, professional activity, organizational structure, Operational Reality, or another governed input.
Recognition means the relationship requires evaluation.
It does not establish Liability.
Relationship Recognition Trigger
A Relationship Recognition Trigger is a governed signal indicating that a relationship may materially affect later Liability governance.
The trigger may originate from:
upstream LIGA™ governance, another OOF® architecture, evidence, a formal record, Operational Reality, or lifecycle re-entry.
Therefore:
Relationship Recognition Trigger ≠ Established Liability Relationship.
Relationship Identification
A relationship becomes identified when its essential structure is sufficiently established for subsequent mapping.
Identification should determine, where materially required:
which Subjects participate, what relationship is involved, what type of relationship it is, which direction applies, which Object or Basis it concerns, what temporal state applies, and what uncertainty remains.
Relationship Identity
Every materially distinct Liability Relationship should possess a sufficiently stable identity.
Relationship Identity must remain distinguishable from the identities of its participating Subjects.
Therefore:
Subject Identity ≠ Relationship Identity.
Two known Subjects do not automatically establish a known relationship.
Same Subjects, Different Relationships
The same pair of Subjects may participate in several materially distinct relationships.
For example:
Subject A ↔ Subject B / Contractual Relationship
Subject A ↔ Subject B / Ownership Relationship
Subject A ↔ Subject B / Control Relationship
Therefore:
Same Subjects ≠ Same Liability Relationship.
Each materially distinct relationship should be separately identified.
Relationship Origin
Relationship Origin identifies how the relationship entered the governed structure.
Potential origins may include:
contract, ownership, authority, delegation, control, agency, service provision, operation, maintenance, custody, guarantee, insurance, professional status, or another governed foundation.
Therefore:
Relationship Origin ≠ Liability Origin.
Relationship Type
LRIM should identify the methodological type of each relationship where type materially affects subsequent governance.
Potential types may include:
Contractual Relationship, Ownership Relationship, Control Relationship, Authority Relationship, Delegation Relationship, Agency Relationship, Operational Relationship, Service Relationship, Manufacturing Relationship, Maintenance Relationship, Custodial Relationship, Professional Relationship, Insurance Relationship, Guarantee Relationship, or another relevant type.
Typing the relationship does not determine Liability.
Relationship Type and Liability
A relationship type describes the structure under examination.
It does not determine the Liability outcome.
Therefore:
Contractual Relationship ≠ Contractual Liability.
Ownership Relationship ≠ Owner Liability.
Control Relationship ≠ Controller Liability.
Agency Relationship ≠ Principal or Agent Liability.
Operational Relationship ≠ Operational Liability.
Relationship Participants
Each relationship should identify its participating Subjects to the extent possible.
A relationship may involve:
two Subjects, multiple Subjects, a Subject and Liability Object, a Subject and Liability Basis, or another governed relational structure.
Participants should remain independently identifiable.
Subject–Subject Relationship
A Subject–Subject Relationship connects two or more Liability Subjects.
Examples may include:
provider ↔ customer, principal ↔ agent, owner ↔ operator, manufacturer ↔ distributor, contractor ↔ subcontractor, organization ↔ employee, insurer ↔ insured.
The relationship establishes structure.
It does not establish Liability.
Subject–Object Relationship
A Subject may have a Liability-relevant relationship to the Governed Liability Object.
Examples may include:
ownership, control, operation, manufacture, maintenance, custody, use, possession, or another relevant relation.
Therefore:
Subject–Object Relationship ≠ Liability.
Subject–Basis Relationship
A Subject may have a relevant relationship to the Governed Liability Basis.
The Subject may be:
bound by, benefited by, authorized under, obligated under, protected under, or otherwise referenced by the Basis.
Therefore:
Subject–Basis Relationship ≠ Liability Attachment.
Direct Relationship
A Direct Relationship exists where the relevant relational structure connects participating Subjects without requiring an intermediate Subject.
Example:
Subject A ↔ Subject B
Directness is a structural property.
Therefore:
Direct Relationship ≠ Direct Liability.
Indirect Relationship
A potentially relevant relationship may operate through one or more intermediate Subjects.
Example:
Subject A → Subject B → Subject C LRIM should identify the relevant relational segments without assuming Liability propagation.
Therefore:
Indirect Relationship ≠ Indirect Liability.
Relationship Chain
Several identified relationships may form an apparent chain.
Example:
Manufacturer → Distributor → Operator → User LRIM identifies the individual relationships.
LRMM subsequently maps their complete structure.
Therefore:
Relationship Identification ≠ Relationship Network Mapping.
Reciprocal Relationship
A relationship may operate in both directions while containing different rights, duties, authorities, dependencies, or functions in each direction.
Therefore:
Reciprocal Relationship ≠ Symmetrical Liability Position.
LRIM should preserve direction-specific characteristics where materially relevant.
Relationship Direction
Direction should be identified where the relationship has directional meaning.
Examples:
Principal → delegates to → Agent Provider → supplies to → Customer Owner → authorizes → Operator Controller → directs → Operational Subject Direction describes the relationship.
Therefore:
Relationship Direction ≠ Liability Direction.
Bidirectional Relationship
Some relationships may legitimately require bidirectional representation.
Example:
Subject A ↔ Subject B
Bidirectionality does not imply equal authority, equal responsibility, or equal Liability.
Therefore:
Bidirectional Relationship ≠ Equal Liability.
Multi-Subject Relationship
A relationship may involve more than two Subjects as one coherent relational structure.
Example:
Subject A + Subject B + Subject C → Relationship R LRIM should preserve the multi-subject structure where decomposing it would distort the relationship.
Therefore:
Multi-Subject Relationship ≠ Multiple Bilateral Relationships by default.
Multiple Relationships
A Liability inquiry may contain multiple relationships simultaneously.
These should not be collapsed into a single generalized relationship merely because they concern the same Object or event.
Therefore:
Multiple Liability Relationships ≠ One Composite Relationship by default.
Composite Relationship
A Composite Relationship may exist where several relational elements form one inseparable governed relationship.
Composite status should be established explicitly.
Therefore:
Multiple Relationship Elements ≠ Composite Relationship by default.
Relationship Dependency
One relationship may depend upon another.
Example:
an agent relationship may depend on a valid delegation structure.
A subcontracting relationship may depend upon an upstream contractual structure.
Therefore:
Relationship Dependency ≠ Relationship Identity.
Dependency should remain explicit.
Relationship Hierarchy
Relationships may exist within hierarchical structures.
Example:
Principal → Contractor → Subcontractor → Operator Hierarchy may affect later governance.
However:
Relationship Hierarchy ≠ Liability Hierarchy.
LRIM identifies the relationships without ranking Liability.
Formal Relationship
A Formal Relationship may be established through:
contract, organizational record, legal instrument, delegation, appointment, ownership record, policy, or another formal structure.
Formal existence may be relevant.
It does not establish the complete operational relationship.
Operational Relationship
Operational Reality may reveal relationships that differ from formal structures.
Examples may include:
actual control, actual operation, actual supervision, actual decision authority, or actual coordination.
Therefore:
Formal Relationship ≠ Operational Relationship by default.
Both may require separate identification.
Nominal and Operational Relationship
A formally named relationship may not accurately represent the relationship that operated in practice.
Therefore:
Nominal Relationship ≠ Operational Relationship by default.
LRIM should preserve both where materially relevant rather than silently replacing one with the other.
Contractual Relationship
A contractual relationship may be relevant where a contract establishes a governed connection among Subjects.
LRIM identifies the contractual relationship.
It does not determine:
breach, Condition Satisfaction, Connection, Attachment, or Liability.
Therefore:
Contractual Relationship ≠ Contractual Liability.
Ownership Relationship
Ownership may create a relationship between:
Subject and Object, Subject and organization, or multiple Subjects.
LRIM identifies the ownership relationship where materially relevant.
Therefore:
Ownership Relationship ≠ Liability.
Control Relationship
A Control Relationship may involve:
formal control, operational control, technical control, organizational control, or another relevant control structure.
Control should be identified without assuming Liability.
Therefore:
Control Relationship ≠ Liability Determination.
Authority Relationship
An Authority Relationship may connect a Subject possessing authority with:
another Subject, an Object, a system, a process, or a decision domain.
Therefore:
Authority Relationship ≠ Liability Relationship Outcome.
Authority may become a later Liability input.
Delegation Relationship
A Delegation Relationship may exist where authority, responsibility, permission, or operational activity is delegated.
Delegation does not establish Liability Transfer.
Therefore:
Delegation Relationship ≠ Liability Transfer.
LTRS governs Liability Transfer later in the lifecycle.
Agency Relationship
A potential Agency Relationship may connect:
principal, agent, scope of authority, and relevant activity.
LRIM identifies the relationship without determining attribution or Liability.
Therefore:
Agency Relationship ≠ Liability Attribution.
Service Relationship
A Service Relationship may connect:
provider, recipient, operator, customer, or other relevant Subjects.
The relationship may become Liability-relevant where the Governed Liability Basis concerns service provision.
Therefore:
Service Relationship ≠ Provider Liability.
Manufacturing Relationship
A Manufacturing Relationship may connect:
manufacturer, component supplier, assembler, distributor, owner, operator, or another relevant Subject.
Identification does not establish product-related Liability.
Therefore:
Manufacturing Relationship ≠ Manufacturer Liability.
Maintenance Relationship
A Maintenance Relationship may connect:
equipment owner, maintenance provider, contractor, subcontractor, operator, or another Subject.
The existence of maintenance responsibility or participation does not establish Liability.
Therefore:
Maintenance Relationship ≠ Maintenance Liability.
Insurance Relationship
An Insurance Relationship may become relevant to later Liability Transfer, payment, sharing, or Recourse.
LRIM may identify:
insurer, insured, beneficiary, or other relevant participants.
However:
Insurance Relationship ≠ Underlying Liability.
Guarantee Relationship
A Guarantee Relationship may create a secondary relational structure.
The guarantor should remain distinct from the Subject whose underlying conduct or obligation is being evaluated.
Therefore:
Guarantee Relationship ≠ Primary Liability.
Human–AI Relationship
Liability governance may require relationships involving:
human users, AI providers, AI deployers, operators, AI systems, autonomous agents, and organizations.
Possible relationships may include:
provider → AI system, deployer → AI system, operator → AI system, AI system → operational process, user → AI system.
Identification of these relationships does not determine AI or human Liability.
Autonomous-System Relationship
An autonomous system may participate in relationships concerning:
authority, permission, delegation, operation, coordination, override, control, or execution.
ASGA™ may govern the original autonomous-system relationship.
LRIM identifies its Liability relevance where necessary.
Therefore:
Autonomous-System Relationship ≠ Liability.
Relationship Relevance
A relationship should enter LRIM where its existence, state, scope, direction, or type may materially affect later Liability governance.
The relevance threshold should avoid:
omitting material relationships, and:
including every remote connection.
Therefore:
Relational Existence ≠ Liability Relevance by default.
Relationship Relevance and Basis
A relationship may be relevant because the Governed Liability Basis makes that relationship material.
For example, a contractual Basis may make a contractual relationship relevant.
However:
Basis-Relevant Relationship ≠ Liability-Producing Relationship.
Relationship Relevance and Object
A relationship may be relevant because it connects a Subject to the Governed Liability Object.
However:
Object-Relevant Relationship ≠ Liability-Relevant Connection.
LCNS later determines the Liability-specific Connection required for Determination.
Relationship Scope
Relationship Scope defines the extent of the relationship itself.
It may concern:
an entire service, specific operation, defined Object component, particular authority, specific activity, or limited period.
Therefore:
Relationship Scope ≠ Liability Scope.
Relationship Boundary
Relationship Boundary establishes what belongs inside and outside the identified relationship.
It may define:
participating Subjects, relevant Object, relevant Basis, relationship type, scope, temporal period, and excluded structures.
Therefore:
Relationship Boundary ≠ Liability Boundary by default.
Temporal Relationship State
Relationships may:
begin, be active, change, be suspended, resume, terminate, or be superseded.
LRIM should identify the state relevant to the Liability inquiry.
Therefore:
Current Relationship State ≠ Historically Relevant Relationship State by default.
Historical Relationship
A relationship may no longer exist while remaining relevant to a historical Liability inquiry.
Therefore:
Inactive Relationship ≠ Historically Irrelevant Relationship.
Historical relevance must be preserved.
Relationship Uncertainty
Possible relationship states may include:
Identified
Provisionally Identified
Partially Identified
Relationship Uncertain
Relationship Disputed
Relationship Unknown
Uncertainty should remain explicit.
Unknown Relationship
The relevant Subjects may be known while the relationship between them remains unresolved.
The correct governance state may be:
Known Subjects / Relationship Unknown
Therefore:
Unknown Relationship ≠ No Relationship.
Partially Identified Relationship
A relationship may be known in part.
For example:
the existence of a relationship may be known, but its exact type, scope, direction, or temporal state may remain unresolved.
Therefore:
Partial Relationship Identification ≠ Complete Relationship Identification.
Relationship Assumption
A potential relationship may initially depend on an assumption.
The assumption should remain visible until established or rejected.
Therefore:
Relationship Assumption ≠ Established Relationship Fact.
Relationship Conflict
Different governed inputs may support conflicting relationship representations.
For example:
a contract may identify one operator, while Operational Reality identifies another.
LRIM should preserve the conflict.
Therefore:
Relationship Conflict ≠ Authority to Manufacture Relationship Certainty.
Duplicate Relationship Records
Several records may refer to the same underlying relationship.
Technical duplication should not create multiple methodological relationships.
Therefore:
Multiple Relationship Records ≠ Multiple Liability Relationships by default.
Similar Relationships
Relationships may appear similar because they involve:
the same Subjects, the same Object, the same Basis, or similar labels.
Similarity does not establish identity.
Therefore:
Relationship Similarity ≠ Relationship Identity.
Relationship Correction
An identified relationship may later be found incorrect.
Correction should preserve:
the earlier representation, the corrected representation, the reason for correction, and relevant supporting inputs.
Therefore:
Relationship Correction ≠ Historical Erasure.
Relationship Reassessment
New information may require reassessment of:
relationship existence, identity, type, participants, direction, scope, boundary, or temporal state.
Therefore:
Relationship Reassessment ≠ New Liability Origin.
The existing governance history should remain preserved.
Relationship Inclusion
A Relationship Candidate should be included in the Identified Liability Relationship Set where its structure may materially affect subsequent LRS governance.
Inclusion means:
this relationship requires further governance.
It does not mean:
this relationship creates Liability.
Therefore:
Relationship Inclusion ≠ Liability Determination.
Relationship Exclusion
A Relationship Candidate may be excluded where sufficient governance establishes that it is not materially relevant to the current Liability inquiry.
The exclusion reason should remain traceable where material.
Therefore:
Relationship Exclusion ≠ Proof that the relationship can never become Liability-relevant.
Later information may require re-entry.
Relationship Identification Sufficiency
Relationship identification is sufficient when subsequent mapping can determine:
which relationships exist or may exist, which Subjects participate, what type of relationship is involved, which direction applies, which Object and Basis are relevant, what scope and temporal state apply, and what uncertainty remains.
Identification sufficiency does not require complete network mapping.
Therefore:
Relationship Identification Sufficiency ≠ Relationship Mapping Completion.
Handoff to Relationship Mapping
Once materially relevant relationships are sufficiently identified, LRIM produces:
Identified Liability Relationship Set
The handoff should preserve:
Relationship Identity, participating Subject identities, Relationship Type, Relationship Origin, Relationship Direction, Object reference, Basis reference, Relationship Scope, Relationship Boundary, Temporal State, dependencies where already known, uncertainty, and identification history.
The next governance question becomes:
How do these identified Liability Relationships connect into the complete relational structure of the Liability matter?
That question belongs to LRMM.
Minimum Implementation Framework
A conforming implementation of LRIM must provide at least the following eight capabilities:
Potential Relationship Recognition
Capability to recognize materially relevant Subject–Subject, Subject–Object, Subject–Basis, formal, operational, and other relationship candidates without treating recognition as Liability.
Relationship Candidate Identification
Capability to establish distinct Liability Relationship Candidates and preserve why each relationship entered governance.
Relationship Identity, Type & Origin Governance
Capability to establish stable Relationship Identity and represent relationship type and origin independently of Subject identity and Liability outcome.
Participant, Direction, Scope & Boundary Governance
Capability to identify participating Subjects, relationship direction, scope, boundary, Object reference, and Basis reference where materially required.
Multiple, Direct, Indirect & Multi-Subject Relationship Governance
Capability to distinguish multiple relationships, direct and indirect structures, reciprocal relationships, multi-subject relationships, composite candidates, and relationship dependencies without inappropriate collapse.
Formal, Operational, Unknown & Conflicting Relationship Governance
Capability to preserve formal and operational relationships, unknown or partially identified relationships, assumptions, duplicate records, uncertainty, and conflicts without manufacturing certainty.
Temporal Change, Correction & Reassessment Governance
Capability to preserve historically relevant Relationship States and govern correction, reassessment, exclusion, and later re-entry without historical erasure.
Relationship Identification Sufficiency
Capability to determine whether the relevant relationship set is sufficiently identified for Relationship Mapping while preserving unresolved relational uncertainty.
Governance Logic
The canonical LRIM governance logic is:
Identified Liability Subject Set + Governed Liability Object + Governed Liability Basis
↓
Recognize Potential Liability-Relevant Relationships
↓
Create Relationship Candidates
↓
Identify Participating Subjects
↓
Establish Relationship Identity
↓
Determine Relationship Type and Origin
↓
Determine Relationship Direction
↓
Associate Relevant Object and Basis
↓
Determine Relationship Scope and Boundary
↓
Identify Direct / Indirect / Reciprocal / Multi-Subject Structures
↓
Distinguish Formal and Operational Relationships
↓
Determine Relevant Temporal State
↓
Identify Unknown / Partial / Assumed Relationships
↓
Identify Uncertainty or Conflict
↓
Include / Exclude / Preserve Candidate State
↓
Assess Relationship Identification Sufficiency
↓
Identified Liability Relationship Set
↓
Handoff to Liability Relationship Mapping
Governance Outputs
LRIM may produce:
Liability Relationship Candidate
Liability Relationship Identity
Relationship Origin
Relationship Type
Relationship Participant Record
Relationship Direction
Subject–Subject Relationship
Subject–Object Relationship
Subject–Basis Relationship
Direct Relationship
Indirect Relationship
Reciprocal Relationship
Multi-Subject Relationship
Multiple Relationship Set
Composite Relationship Candidate
Relationship Dependency Reference
Formal Relationship Record
Operational Relationship Record
Relationship Scope
Relationship Boundary
Relationship Temporal State
Historical Relationship Record
Unknown Relationship Record
Partial Relationship Record
Relationship Assumption Record
Relationship Uncertainty State
Relationship Conflict State
Duplicate Relationship Reconciliation
Relationship Correction Record
Relationship Reassessment Record
Relationship Inclusion State
Relationship Exclusion State
Relationship Identification Sufficiency State
The principal output is:
Identified Liability Relationship Set
Critical Distinctions
LRIM preserves the following distinctions:
Liability Relationship ≠ Liability Potential Relationship ≠ Identified Liability Relationship Relationship Recognition Trigger ≠ Established Liability Relationship Subject Identity ≠ Relationship Identity Same Subjects ≠ Same Liability Relationship Relationship Origin ≠ Liability Origin Relationship Type ≠ Liability Outcome Contractual Relationship ≠ Contractual Liability Ownership Relationship ≠ Owner Liability Control Relationship ≠ Controller Liability Agency Relationship ≠ Principal or Agent Liability Operational Relationship ≠ Operational Liability Subject–Object Relationship ≠ Liability Subject–Basis Relationship ≠ Liability Attachment Direct Relationship ≠ Direct Liability Indirect Relationship ≠ Indirect Liability Relationship Identification ≠ Relationship Network Mapping Reciprocal Relationship ≠ Symmetrical Liability Position Relationship Direction ≠ Liability Direction Bidirectional Relationship ≠ Equal Liability Multi-Subject Relationship ≠ Multiple Bilateral Relationships by default Multiple Liability Relationships ≠ One Composite Relationship by default Multiple Relationship Elements ≠ Composite Relationship by default Relationship Dependency ≠ Relationship Identity Relationship Hierarchy ≠ Liability Hierarchy Formal Relationship ≠ Operational Relationship by default Nominal Relationship ≠ Operational Relationship by default Delegation Relationship ≠ Liability Transfer Agency Relationship ≠ Liability Attribution Service Relationship ≠ Provider Liability Manufacturing Relationship ≠ Manufacturer Liability Maintenance Relationship ≠ Maintenance Liability Insurance Relationship ≠ Underlying Liability Guarantee Relationship ≠ Primary Liability Autonomous-System Relationship ≠ Liability Relational Existence ≠ Liability Relevance by default Basis-Relevant Relationship ≠ Liability-Producing Relationship Object-Relevant Relationship ≠ Liability-Relevant Connection Relationship Scope ≠ Liability Scope Current Relationship State ≠ Historically Relevant Relationship State by default Inactive Relationship ≠ Historically Irrelevant Relationship Unknown Relationship ≠ No Relationship Partial Relationship Identification ≠ Complete Relationship Identification Relationship Assumption ≠ Established Relationship Fact Relationship Conflict ≠ Authority to Manufacture Relationship Certainty Multiple Relationship Records ≠ Multiple Liability Relationships by default Relationship Similarity ≠ Relationship Identity Relationship Correction ≠ Historical Erasure Relationship Reassessment ≠ New Liability Origin Relationship Inclusion ≠ Liability Determination Relationship Identification Sufficiency ≠ Relationship Mapping Completion
Cross-Architecture Boundary
LRIM may receive governed relationship inputs from other OOF® architectures.
GOA™ may provide Authority, Scope, Delegation, and governance relationships.
ORA™ may provide actual operational relationships.
AGA™ may provide Responsibility, Accountability, Authority, and Attribution relationships.
HAGA™ may provide Harm-relevant actor relationships.
ADIT® may provide evidence concerning relationship existence, participants, type, scope, and historical state.
VALIDOS™ may validate relationship-relevant information.
OBIDENITY® may provide Identity, Ownership, Authority, Permission, Provenance, Transfer, and Continuity relationships.
AIG® may provide AI governance relationships.
ASGA™ may provide autonomous-system Authority, Permission, Delegation, Coordination, Override, and operational relationships.
Other OOF® architectures may provide governed relationships relevant to Liability.
The governing principle is:
A relationship governed elsewhere may become Liability-relevant without becoming a Liability Relationship merely because it enters LIGA™ analysis.
LRIM governs only its Liability-specific representation.
Canonical Boundary
LRIM begins with an:
Identified Liability Subject Set
together with the relevant Governed Liability Object and Governed Liability Basis.
LRIM governs:
Potential Relationship Recognition, Relationship Candidate Identification, Relationship Identity, Relationship Origin, Relationship Type, Relationship Participants, Relationship Direction, Subject–Subject Relationships, Subject–Object Relationships, Subject–Basis Relationships, Direct Relationships, Indirect Relationships, Reciprocal Relationships, Multi-Subject Relationships, Multiple Relationships, Composite Relationship Candidates, Relationship Dependencies, Formal Relationships, Operational Relationships, Relationship Scope, Relationship Boundary, Temporal State, Unknown Relationships, Partial Relationships, Assumptions, Uncertainty, Conflict, Correction, Reassessment, Inclusion, Exclusion, and Identification Sufficiency.
LRIM does not govern:
complete Relationship Network Mapping, final Relationship Distinction, Relationship Continuity, Liability Conditions, Condition Satisfaction, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Transfer, Recourse, Resolution, Discharge, or Finality.
LRIM ends when an:
Identified Liability Relationship Set
is sufficiently established for Liability Relationship Mapping.
Use Case 1 — AI-Enabled Service Relationships
An AI-enabled service involves an AI provider, deploying organization, operator, customer, and AI system already identified by LSUIM.
LRIM identifies several potentially relevant relationships:
Provider ↔ Deployer
Deployer ↔ Operator
Deployer ↔ Customer
Provider ↔ AI System
Deployer ↔ AI System
Operator ↔ AI System
The relationships may include contractual, operational, control, service, or authority structures.
LRIM identifies each relationship independently without determining whether any Subject bears Liability.
LRMM can subsequently map how the relationships interact across the complete Liability structure.
Use Case 2 — Industrial Equipment Relationships
An industrial equipment matter includes an owner, operating company, manufacturer, maintenance provider, subcontractor, operator, and insurer.
LRIM identifies potentially relevant:
ownership, operational, manufacturing, maintenance, contractual, subcontracting, and insurance relationships.
A formal maintenance agreement identifies one organization, while Operational Reality indicates that another Subject performed the relevant maintenance activity.
LRIM preserves both relationships rather than choosing one prematurely.
The resulting Identified Liability Relationship Set can then be mapped by LRMM without converting maintenance participation, ownership, operation, or insurance into Liability.
Canonical Closing Statement
Knowing who participates in a Liability inquiry is not enough.
Governance must also identify the distinct relationships through which those Subjects interact with one another, the Liability Object, and the Liability Basis.
Those relationships create the structure that later Liability governance must evaluate, but they do not create Liability merely by existing.
A relationship can make Liability governable without making Liability established.
Identify the relationships before mapping the Liability structure.