LRMM — Liability Relationship Mapping Module
LRMM — Liability Relationship Mapping Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Relationship Standard (LRS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Relationship Mapping
Module ID: LIGA-LRS-LRMM-001
Origin ID: OOF.CM.LIGA.04.03.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 Mapping Module (LRMM) governs how an Identified Liability Relationship Set is organized into an explicit, traceable, and reconstructable relational topology showing how Liability Subjects, Governed Liability Objects, Governed Liability Bases, and Liability-relevant Relationships connect across direct, indirect, reciprocal, multi-subject, layered, dependent, hierarchical, and networked structures.
LRMM transforms individually identified relationships into a governed representation of the complete relational structure relevant to the Liability inquiry without converting relational topology into Liability Connection, Liability Attachment, Liability Determination, Liability Scope, or Liability Allocation.
LRMM governs the transition:
Identified Liability Relationship Set → Relationship Node & Edge Structuring → Relationship Path Mapping → Dependency & Layer Mapping → Network Formation → Governed Liability Relationship Map Its foundational distinction is:
Liability Relationship Map ≠ Liability Determination.
Operational Role
The operational role of LRMM is:
to show how individually identified Liability Relationships connect into the wider relational structure of the Liability matter.
LRIM answers:
What Liability-relevant relationships exist or may exist?
LRMM asks:
How are those relationships structurally connected?
A set of individually correct relationships may still provide an incomplete or misleading understanding if the topology connecting them remains unknown.
LRMM makes that topology governable.
Position in the Parent Standard Flow
The internal LRS progression is:
Liability Subject Identification → Liability Relationship Identification → Relationship Mapping → Relationship Distinction → Relationship Continuity LRMM governs:
Relationship Mapping
Its principal input is:
Identified Liability Relationship Set
Its principal output is:
Governed Liability Relationship Map
Its canonical handoff is:
Governed Liability Relationship Map → Liability Relationship Distinction
Central Operational Question
How do the identified Liability Subjects and Liability Relationships connect into the complete relational structure relevant to the Liability inquiry?
The question concerns relational topology.
It does not ask:
who is liable, whether Liability attaches, or how Liability should be allocated.
Governed Space
LRMM governs:
Relationship Nodes, Relationship Edges, Relationship Paths, Relationship Chains, Relationship Direction, Reciprocal Structures, Subject–Subject Mapping, Subject–Object Mapping, Subject–Basis Mapping, Direct Relationship Mapping, Indirect Relationship Mapping, Multi-Subject Mapping, Multiple Relationship Mapping, Relationship Dependencies, Relationship Hierarchies, Relationship Layers, Relationship Branches, Relationship Convergence, Relationship Divergence, Parallel Relationships, Formal and Operational Relationship Mapping, Relationship Network Formation, Subnetwork Formation, Cross-Object Relationships, Cross-Basis Relationships, Temporal Relationship Maps, Relationship Map Uncertainty, Relationship Map Conflict, Relationship Map Change, and Mapping Sufficiency.
Mapping Input
LRMM receives an:
Identified Liability Relationship Set
The input should preserve, where materially available:
Relationship Identity, participating Subject identities, Relationship Type, Relationship Origin, Relationship Direction, Object reference, Basis reference, Relationship Scope, Relationship Boundary, Temporal State, dependencies, uncertainty, and identification history.
LRMM should not silently repair missing relationship identification by inventing relational structure.
Mapping Purpose
Relationship identification produces individual relational units.
Liability governance may nevertheless fail if those units remain isolated.
For example:
Subject A may relate to Subject B.
Subject B may relate to Subject C.
Subject C may relate to the Governed Liability Object.
Subject A may separately relate to the Governed Liability Basis.
Without mapping, these relationships may appear unrelated.
LRMM reveals their governed topology.
Relationship Node
A Relationship Node is a governed point within the relational map.
A node may represent:
a Liability Subject, a Governed Liability Object, a Governed Liability Basis, or another explicitly governed relational reference where necessary.
Node representation must preserve the identity of the underlying governed object.
Therefore:
Map Node ≠ New Governance Object.
Subject Node
Each materially relevant Liability Subject may be represented as a Subject Node.
A Subject Node should preserve the Subject Identity established upstream.
Mapping must not create a different Subject merely because the Subject appears in multiple relational positions.
Therefore:
Multiple Map Positions ≠ Multiple Subjects by default.
Object Node
The Governed Liability Object may function as a central relational reference.
Several Subjects may connect to the same Object through different relationships.
For example:
owner → Object, operator → Object, manufacturer → Object, maintenance provider → Object.
These relationships should remain distinct.
Therefore:
Shared Object ≠ Shared Liability.
Basis Node
A Governed Liability Basis may be represented where relationships depend upon or derive relevance from that Basis.
Several relationships may connect to the same Basis.
Likewise, one relationship may be relevant to multiple Bases.
Therefore:
Shared Liability Basis ≠ Shared Liability Outcome.
Relationship Edge
A Relationship Edge represents an identified relationship connecting governed nodes.
The edge should preserve:
Relationship Identity, Relationship Type, Direction, Scope, Boundary, Temporal State, and uncertainty where relevant.
Therefore:
Relationship Edge ≠ Liability Connection.
A map edge represents relational structure, not the Liability-specific Connection governed by LCNS.
Directed Edge
Where a relationship possesses directional meaning, the map should preserve that direction.
Example:
Principal → delegates to → Agent Direction may later become important.
However:
Directed Relationship Edge ≠ Direction of Liability.
Reciprocal Edge Structure
A reciprocal relationship may require representation in both directions.
Example:
Subject A ↔ Subject B
Where each direction carries different meaning, the map should preserve separate directional characteristics.
Therefore:
Reciprocal Mapping ≠ Symmetrical Liability.
Parallel Edges
Two Subjects may share several relationships simultaneously.
The map may therefore contain parallel edges:
Subject A → Contractual Relationship → Subject B Subject A → Control Relationship → Subject B Subject A → Service Relationship → Subject B These edges must not be collapsed merely because their endpoints are identical.
Therefore:
Same Nodes ≠ Same Relationship Edge.
Relationship Path
A Relationship Path is a connected sequence of identified relationships across the map.
Example:
Subject A → Subject B → Subject C → Object A path shows relational connectivity.
It does not establish Liability propagation.
Therefore:
Relationship Path ≠ Liability Path.
Relationship Chain
A Relationship Chain is a structured sequence where one relationship follows or depends upon another.
Example:
Principal → Contractor → Subcontractor → Operator LRMM preserves the chain.
It does not assume that Liability travels through the chain.
Therefore:
Relationship Chain ≠ Liability Chain.
Path Length
A relationship path may contain one or many intermediate Subjects.
Path length may be relevant to understanding the relational structure.
It does not determine Liability relevance or strength by itself.
Therefore:
Shorter Relationship Path ≠ Stronger Liability.
Direct Mapping
Direct mapping represents relationships where no intermediate Subject is required.
Example:
Subject A → Subject B Directness should remain visible.
However:
Direct Mapping ≠ Direct Liability.
Indirect Mapping
Indirect mapping represents relational structures containing intermediate Subjects or relationships.
Example:
Subject A → Subject B → Subject C The intermediate structure should remain explicit.
Therefore:
Indirect Mapping ≠ Indirect Liability.
Subject–Subject Mapping
LRMM maps relevant relationships among Liability Subjects.
The map may reveal:
bilateral relationships, multi-party structures, hierarchies, dependencies, parallel relationships, or network clusters.
Subject–Subject mapping remains relational.
It does not determine Liability.
Subject–Object Mapping
LRMM may map multiple Subject relationships to the Governed Liability Object.
Example:
Owner → Object Operator → Object Manufacturer → Object Maintenance Provider → Object These relationships may later support different Liability inquiries.
They must remain separate.
Subject–Basis Mapping
LRMM may represent which Subjects are connected to which Governed Liability Bases.
Example:
Basis A → Subject A Basis A → Subject B Basis B → Subject C This representation supports later governance without attaching Liability.
Therefore:
Subject–Basis Mapping ≠ Liability Attachment Mapping.
Object–Basis Context
The Governed Liability Object and Governed Liability Basis already possess an upstream governed association.
LRMM may represent that association as contextual infrastructure for the relationship map.
It must not redefine it.
Therefore:
Relationship Mapping ≠ Basis Association Governance.
LBAM retains ownership of Object–Basis Association.
Multi-Subject Mapping
A coherent relationship may involve more than two Subjects.
LRMM should preserve a multi-subject structure where reducing it to bilateral edges would distort its meaning.
Therefore:
Multi-Subject Mapping ≠ Mandatory Bilateral Decomposition.
Multiple Relationship Mapping
A Liability matter may contain many distinct relationships.
LRMM should preserve their separate identities while representing how they coexist.
Therefore:
Multiple Relationships ≠ One Generalized Relationship.
Relationship Dependency Mapping
One relationship may depend upon another.
Example:
Delegation Relationship B depends on Authority Relationship A.
The map should preserve the dependency separately from the relationship identities.
Therefore:
Relationship Dependency ≠ Relationship Identity.
Dependency Direction
Dependency may itself be directional.
Example:
Relationship B → depends upon → Relationship A This does not imply that A and B have the same Subjects or the same Liability relevance.
Dependency direction should remain explicit.
Relationship Hierarchy Mapping
Relationships may form hierarchical structures.
Example:
Organization
↓
Contractor
↓
Subcontractor
↓
Operator
Hierarchy can clarify structural position.
It must not be converted into Liability ranking.
Therefore:
Relationship Hierarchy ≠ Liability Hierarchy.
Relationship Layer Mapping
A complex Liability matter may contain multiple relational layers.
Potential layers may include:
contractual, organizational, operational, ownership, control, authority, delegation, technical, insurance, guarantee, or other relevant structures.
Layers should remain distinguishable where their governance meaning differs.
Layer Separation
Different relationship layers may connect the same Subjects.
For example:
Subject A and Subject B may have both:
a contractual relationship, and an operational control relationship.
The map should preserve both.
Therefore:
Relationship Layer Overlap ≠ Relationship Identity.
Cross-Layer Mapping
Relationships in different layers may interact.
Example:
Contractual Layer → Delegation Layer → Operational Layer Cross-layer mapping may reveal governance dependencies that are invisible within one layer.
However:
Cross-Layer Relationship Path ≠ Liability Connection.
Relationship Branch
A relationship structure may branch from one Subject into several relationships.
Example:
Subject A → Subject B Subject A → Subject C Subject A → Subject D Branching shows relational distribution.
It does not establish distributed Liability.
Therefore:
Relationship Branching ≠ Liability Allocation.
Relationship Convergence
Several relationships may converge on one Subject or Object.
Example:
Subject A → Subject D Subject B → Subject D Subject C → Subject D Convergence may make the node structurally important.
It does not make the node liable.
Therefore:
Relationship Convergence ≠ Liability Concentration.
Relationship Divergence
One upstream relationship may produce several downstream relational branches.
Divergence should remain explicit where relevant.
Therefore:
Relationship Divergence ≠ Liability Distribution.
Parallel Relationship Paths
Two Subjects may be connected through multiple independent paths.
Example:
A → B → D and:
A → C → D Parallel paths may become important to later Connection governance.
However:
Multiple Relationship Paths ≠ Multiple Liability Connections by default.
Relationship Loop
A relational structure may contain a loop.
Example:
A → B → C → A Loops may arise through:
mutual control, cross-contracting, delegation, ownership, or other structures.
The map should preserve the loop without interpreting it as Liability.
Network Formation
Where multiple relationships interact, LRMM forms a:
Liability Relationship Network
This network represents the relational topology relevant to the Liability inquiry.
It is not yet an established Liability Network.
Therefore:
Liability Relationship Network ≠ Established Liability Network.
Network Identity
A materially distinct Relationship Network may require its own governed reference.
The network reference should not replace the identities of:
Subjects, Objects, Bases, or individual Relationships.
Therefore:
Network Identity ≠ Relationship Identity.
Relationship Subnetwork
A large Relationship Network may contain subnetworks.
Examples may include:
contractual subnetwork, operational subnetwork, insurance subnetwork, supply-chain subnetwork, or autonomous-system subnetwork.
Subnetworks support analysis.
They do not create separate Liability by default.
Network Boundary
The Relationship Network requires a sufficiently explicit boundary.
The boundary should determine:
which Subjects are included, which Relationships are included, which Object or Objects are relevant, which Bases are relevant, which temporal state applies, and what remains outside the map.
Therefore:
Relationship Network Boundary ≠ Liability Scope.
Network Expansion
New information may reveal:
new Subjects, new Relationships, new paths, new dependencies, or new layers.
The network may therefore expand.
Expansion should preserve the earlier map.
Therefore:
Network Expansion ≠ Historical Map Replacement.
Network Contraction
Later governance may determine that a relationship or Subject is no longer relevant to the current map.
The network may contract.
The earlier representation should remain traceable.
Therefore:
Network Contraction ≠ Historical Relationship Erasure.
Cross-Object Mapping
A Subject or Relationship may connect to several Governed Liability Objects.
LRMM should preserve Object-specific relationships.
Therefore:
One Subject Across Multiple Objects ≠ One Liability Structure by default.
Object boundaries remain important.
Cross-Basis Mapping
One Relationship may be relevant under several Governed Liability Bases.
Likewise, different Relationships may rely on different Bases.
LRMM should preserve these distinctions.
Therefore:
Multiple Bases ≠ One Relationship Basis by default.
Formal Relationship Map
LRMM may create a map of formally documented relationships.
The formal map may derive from:
contracts, organizational records, ownership records, delegations, appointments, policies, or other formal sources.
The formal map is not necessarily the complete relational reality.
Operational Relationship Map
ORA™ or other governed operational inputs may support an Operational Relationship Map showing how the relevant system actually functioned.
The operational map may differ from the formal map.
Therefore:
Formal Relationship Map ≠ Operational Relationship Map by default.
Formal–Operational Comparison
Where formal and operational maps differ materially, LRMM should preserve the difference.
Example:
formal documentation:
Organization A → Operator B Operational Reality:
Organization A → Contractor C → Operator D The difference may become relevant later.
LRMM maps it without determining Liability.
Map Conflict
Different governed inputs may support incompatible maps.
LRMM should preserve:
each supported structure, its source, the conflicting nodes or edges, and unresolved uncertainty.
Therefore:
Relationship Map Conflict ≠ Authority to Manufacture Topological Certainty.
Map Uncertainty
Mapping uncertainty may concern:
missing Subjects, missing Relationships, unknown direction, uncertain dependency, uncertain layer, unknown temporal state, or incomplete network boundary.
Possible states may include:
Mapped
Provisionally Mapped
Partially Mapped
Mapping Uncertain
Mapping Disputed
Mapping Incomplete
Uncertainty must remain visible downstream.
Missing Relationship
A map may reveal that a relational connection appears necessary to explain the topology but has not yet been identified.
LRMM should not invent the relationship.
It should create a mapping gap requiring re-entry into LRIM.
Therefore:
Mapping Gap ≠ Authority to Create Relationship.
Missing Subject
A map may reveal a structurally necessary but unidentified Subject.
The appropriate response is re-entry into LSUIM.
Therefore:
Unknown Network Node ≠ Invented Liability Subject.
Recursive governance preserves architectural boundaries.
Mapping Re-Entry
LRMM may trigger re-entry into:
LSUIM where a missing Subject is discovered, or:
LRIM where a missing Relationship is discovered.
Re-entry should occur at the earliest materially affected governance point.
Therefore:
Mapping Re-Entry ≠ Full LRS Restart by default.
Temporal Relationship Map
Relationships may change over time.
LRMM should support time-specific maps.
Example:
Map at T1
may differ from:
Map at T2
because Subjects, roles, Relationships, or dependencies changed.
Therefore:
Current Relationship Map ≠ Historical Relationship Map by default.
Map Snapshot
A Map Snapshot represents the governed relational topology at a defined lifecycle moment.
A snapshot should preserve:
time reference, included Subjects, included Relationships, relevant Objects, relevant Bases, and known uncertainty.
Snapshots support historical reconstruction.
Map Evolution
Relationship maps may evolve through:
Subject addition, Subject removal, Relationship addition, Relationship termination, dependency change, layer change, network expansion, network contraction, or correction.
Map evolution should preserve state lineage.
Therefore:
Map Change ≠ New Liability Matter by default.
Map Correction
A previous map may be found incorrect.
Correction should preserve:
the earlier map, the corrected map, the reason, the affected nodes or edges, and the supporting governed inputs.
Therefore:
Map Correction ≠ Historical Erasure.
Map Reassessment
New information may require reassessment of an existing Relationship Map.
Reassessment may:
confirm, expand, contract, restructure, or correct the map.
Therefore:
Map Reassessment ≠ Historical Rewrite.
Relationship Map and Liability Conditions
LRMM may show where later Liability Conditions must be evaluated.
It does not determine whether those Conditions are satisfied.
Therefore:
Relationship Map ≠ Liability Condition State.
LCOS owns Liability Conditions governance.
Relationship Map and Liability Connection
A mapped path may appear to connect a Subject to an Object or consequence.
This is not the same as a governed Liability-Relevant Connection.
Therefore:
Mapped Relationship Path ≠ Liability-Relevant Connection.
LCNS owns Liability Connection.
Relationship Map and Liability Attachment
A Subject may occupy a central position within the map.
Centrality does not attach Liability.
Therefore:
Relationship Centrality ≠ Liability Attachment.
LDS owns Liability Attachment and Determination.
Relationship Map and Liability Determination
The map establishes relational structure.
It does not determine whether Liability exists.
Therefore:
Governed Liability Relationship Map ≠ Liability Determination.
Even a complete map may ultimately support a negative Liability Determination.
Relationship Map and Liability Scope
The Relationship Map may be broad while established Liability is narrow.
Or the map may contain many Subjects while Liability applies only to a subset.
Therefore:
Relationship Map Boundary ≠ Liability Scope.
LSAS governs Liability Scope.
Relationship Map and Liability Allocation
Network structure does not determine allocation.
A Subject with many relationships is not automatically allocated more Liability.
Therefore:
Relationship Connectivity ≠ Liability Allocation.
and:
Relationship Centrality ≠ Liability Allocation.
Relationship Map and Liability Network
Later Liability Determination may establish Liability across one or more mapped Relationships.
Only then may parts of the Relationship Network become part of an established Liability Network.
Therefore:
Mapped Relationship Network ≠ Determined Liability Network.
Local Relationship and Complete Map
A single identified relationship may appear straightforward when viewed locally.
Its meaning may change when placed within the complete topology.
Therefore:
Local Relationship View ≠ Complete Relationship Structure.
LRMM exists to prevent isolated relational interpretation from replacing system-level mapping.
One Occurrence and Multiple Relationships
A single Liability-relevant occurrence may intersect with many Relationships.
Therefore:
One Occurrence ≠ One Liability Relationship.
The architecture should preserve relational plurality.
One Subject and Multiple Paths
One Subject may participate in several paths simultaneously.
Example:
a company may be:
an owner in one path, a contracting party in another, and a controller in another.
Therefore:
One Subject ≠ One Relationship Path.
One Relationship and Multiple Contexts
One Relationship may become relevant to several aspects of the same Liability inquiry.
LRMM should preserve a single Relationship Identity where the underlying relationship remains the same.
Therefore:
Multiple Map Uses ≠ Multiple Relationships by default.
Network Complexity
Relationship complexity may increase with:
number of Subjects, number of Relationships, number of layers, number of Objects, number of Bases, number of dependencies, and temporal changes.
Complexity itself does not imply Liability complexity.
Therefore:
Relationship Network Complexity ≠ Liability Severity.
Mapping Granularity
The map should be detailed enough to preserve materially relevant distinctions without fragmenting the network into meaningless detail.
Too little granularity may hide important relationships.
Too much granularity may obscure the governing structure.
Therefore:
Maximum Mapping Detail ≠ Maximum Governance Quality.
Granularity should follow governance relevance.
Mapping Completeness
Mapping completeness does not require every possible relationship in the surrounding world.
It requires the relationships materially necessary for the governed Liability inquiry.
Therefore:
Complete Liability Relationship Map ≠ Map of Every Existing Relationship.
The network boundary must remain purpose-specific.
Mapping Sufficiency
Mapping is sufficient when downstream governance can determine:
which Subjects participate, which Relationships connect them, how those Relationships are directed, which Objects and Bases are involved, which paths and dependencies exist, which layers exist, where branches or convergence occur, what network boundary applies, which temporal map is relevant, and what uncertainty remains.
Mapping sufficiency does not require Liability Determination.
Handoff to Relationship Distinction
Once the relational topology is sufficiently mapped, LRMM produces:
Governed Liability Relationship Map
The handoff should preserve:
Subject identities, Relationship identities, Object references, Basis references, node structure, edge structure, Relationship Types, directions, paths, chains, dependencies, hierarchies, layers, branches, convergence, subnetworks, network boundary, temporal state, formal–operational distinctions, uncertainty, conflicts, and map history.
The next governance question becomes:
Which mapped relationships must remain methodologically distinct, and where must apparently similar or overlapping relational structures be separated to prevent Liability governance errors?
That question belongs to LRDM.
Minimum Implementation Framework
A conforming implementation of LRMM must provide at least the following eight capabilities:
Node & Relationship Edge Mapping
Capability to represent Liability Subjects, Governed Liability Objects, Governed Liability Bases, and identified Relationships as explicit nodes and relational edges while preserving upstream identities.
Path, Chain & Direction Mapping
Capability to represent direct, indirect, reciprocal, directional, chained, and parallel relationship paths without converting relational paths into Liability paths.
Multi-Subject & Multiple Relationship Mapping
Capability to map multi-subject structures, multiple relationships between the same Subjects, composite structures where justified, branches, convergence, and divergence.
Dependency, Hierarchy & Layer Mapping
Capability to represent relationship dependencies, hierarchies, relational layers, cross-layer interactions, and relevant structural ordering without treating them as Liability ranking.
Network, Subnetwork & Boundary Governance
Capability to form governed Liability Relationship Networks and subnetworks, establish their boundaries, and preserve cross-Object and cross-Basis structures.
Formal, Operational, Temporal & Uncertain Mapping
Capability to preserve formal and operational maps, historical snapshots, temporal states, incomplete maps, uncertainty, conflicts, and missing-node or missing-relationship gaps.
Map Change, Correction, Reassessment & Re-Entry
Capability to govern network expansion, contraction, map evolution, correction, reassessment, and recursive re-entry into Subject or Relationship Identification without historical erasure.
Mapping Sufficiency & Downstream Handoff
Capability to determine whether the relational topology is sufficiently mapped for Relationship Distinction while preserving unresolved material limitations.
Governance Logic
The canonical LRMM governance logic is:
Identified Liability Relationship Set
↓
Establish Map Nodes
↓
Establish Relationship Edges
↓
Preserve Relationship Direction
↓
Map Subject–Subject Relationships
↓
Map Subject–Object Relationships
↓
Map Subject–Basis Relationships
↓
Map Direct and Indirect Paths
↓
Map Relationship Chains
↓
Map Reciprocal and Parallel Relationships
↓
Map Multi-Subject Structures
↓
Map Dependencies and Hierarchies
↓
Map Relationship Layers
↓
Identify Branches / Convergence / Divergence
↓
Form Relationship Network and Subnetworks
↓
Establish Network Boundary
↓ Compare Formal and Operational Maps where relevant ↓
Establish Relevant Temporal Map
↓
Identify Mapping Gaps / Uncertainty / Conflict
↓ Re-enter LSUIM or LRIM where required ↓
Assess Mapping Sufficiency
↓
Governed Liability Relationship Map
↓
Handoff to Liability Relationship Distinction
Governance Outputs
LRMM may produce:
Liability Relationship Node Map
Liability Relationship Edge Map
Subject–Subject Map
Subject–Object Map
Subject–Basis Map
Direct Relationship Path
Indirect Relationship Path
Reciprocal Relationship Structure
Parallel Relationship Structure
Relationship Chain
Multi-Subject Relationship Map
Relationship Dependency Map
Relationship Hierarchy Map
Relationship Layer Map
Cross-Layer Relationship Map
Relationship Branch Map
Relationship Convergence Map
Relationship Divergence Map
Relationship Subnetwork
Liability Relationship Network
Relationship Network Boundary
Cross-Object Relationship Map
Cross-Basis Relationship Map
Formal Relationship Map
Operational Relationship Map
Formal–Operational Difference Record
Temporal Relationship Map
Relationship Map Snapshot
Relationship Mapping Gap
Relationship Map Uncertainty State
Relationship Map Conflict State
Relationship Map Change Record
Relationship Map Correction Record
Relationship Map Reassessment Record
Mapping Sufficiency State
The principal output is:
Governed Liability Relationship Map
Critical Distinctions
LRMM preserves the following distinctions:
Liability Relationship Map ≠ Liability Determination Map Node ≠ New Governance Object Multiple Map Positions ≠ Multiple Subjects by default Shared Object ≠ Shared Liability Shared Liability Basis ≠ Shared Liability Outcome Relationship Edge ≠ Liability Connection Directed Relationship Edge ≠ Direction of Liability Reciprocal Mapping ≠ Symmetrical Liability Same Nodes ≠ Same Relationship Edge Relationship Path ≠ Liability Path Relationship Chain ≠ Liability Chain Shorter Relationship Path ≠ Stronger Liability Direct Mapping ≠ Direct Liability Indirect Mapping ≠ Indirect Liability Subject–Basis Mapping ≠ Liability Attachment Mapping Relationship Mapping ≠ Basis Association Governance Multi-Subject Mapping ≠ Mandatory Bilateral Decomposition Multiple Relationships ≠ One Generalized Relationship Relationship Dependency ≠ Relationship Identity Relationship Hierarchy ≠ Liability Hierarchy Relationship Layer Overlap ≠ Relationship Identity Cross-Layer Relationship Path ≠ Liability Connection Relationship Branching ≠ Liability Allocation Relationship Convergence ≠ Liability Concentration Relationship Divergence ≠ Liability Distribution Multiple Relationship Paths ≠ Multiple Liability Connections by default Liability Relationship Network ≠ Established Liability Network Network Identity ≠ Relationship Identity Relationship Network Boundary ≠ Liability Scope Network Expansion ≠ Historical Map Replacement Network Contraction ≠ Historical Relationship Erasure One Subject Across Multiple Objects ≠ One Liability Structure by default Multiple Bases ≠ One Relationship Basis by default Formal Relationship Map ≠ Operational Relationship Map by default Relationship Map Conflict ≠ Authority to Manufacture Topological Certainty Mapping Gap ≠ Authority to Create Relationship Unknown Network Node ≠ Invented Liability Subject Mapping Re-Entry ≠ Full LRS Restart by default Current Relationship Map ≠ Historical Relationship Map by default Map Change ≠ New Liability Matter by default Map Correction ≠ Historical Erasure Map Reassessment ≠ Historical Rewrite Relationship Map ≠ Liability Condition State Mapped Relationship Path ≠ Liability-Relevant Connection Relationship Centrality ≠ Liability Attachment Governed Liability Relationship Map ≠ Liability Determination Relationship Map Boundary ≠ Liability Scope Relationship Connectivity ≠ Liability Allocation Relationship Centrality ≠ Liability Allocation Mapped Relationship Network ≠ Determined Liability Network Local Relationship View ≠ Complete Relationship Structure One Occurrence ≠ One Liability Relationship One Subject ≠ One Relationship Path Multiple Map Uses ≠ Multiple Relationships by default Relationship Network Complexity ≠ Liability Severity Maximum Mapping Detail ≠ Maximum Governance Quality Complete Liability Relationship Map ≠ Map of Every Existing Relationship
Cross-Architecture Boundary
LRMM may map Liability-relevant structures using governed inputs from other OOF® architectures.
GOA™ may provide Authority, Scope, Delegation, and governance structures relevant to relational mapping.
ORA™ may provide actual operational relationships and operational topology.
AGA™ may provide Responsibility, Accountability, Authority, and Attribution relationships.
HAGA™ may provide Harm-relevant actor structures without determining Liability.
ADIT® may provide evidence supporting nodes, edges, paths, historical states, and map reconstruction.
VALIDOS™ may validate mapping-relevant information.
OBIDENITY® may provide Identity, Ownership, Authority, Permission, Provenance, Transfer, and Continuity structures.
AIG® may provide AI governance relationships.
ASGA™ may provide autonomous-system Authority, Permission, Delegation, Coordination, Override, and operational structures.
Other OOF® architectures may provide relational inputs relevant to the Liability Relationship Map.
The governing principle is:
LRMM may map an externally governed relationship because it is Liability-relevant without assuming governance ownership of the original relationship or converting that relationship into Liability.
Canonical Boundary
LRMM begins with an:
Identified Liability Relationship Set
and asks:
How do these relationships connect into the complete relational topology relevant to the Liability inquiry?
LRMM governs:
Nodes, Edges, Directions, Paths, Chains, Direct and Indirect Structures, Reciprocal Structures, Parallel Relationships, Multi-Subject Structures, Subject–Subject Mapping, Subject–Object Mapping, Subject–Basis Mapping, Dependencies, Hierarchies, Layers, Cross-Layer Structures, Branches, Convergence, Divergence, Networks, Subnetworks, Network Boundaries, Cross-Object Mapping, Cross-Basis Mapping, Formal Maps, Operational Maps, Temporal Maps, Map Snapshots, Mapping Gaps, Uncertainty, Conflict, Map Change, Correction, Reassessment, Re-Entry, and Mapping Sufficiency.
LRMM does not determine:
final Relationship Distinction, Relationship Continuity, Liability Conditions, Condition Satisfaction, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Liability State, Transfer, Recourse, Resolution, Discharge, or Finality.
LRMM ends when a:
Governed Liability Relationship Map
is sufficiently established for Liability Relationship Distinction.
Use Case 1 — AI Service Relationship Network
An AI-enabled service includes an AI provider, model provider, deploying organization, cloud provider, operator, customer, and AI system.
LRIM has already identified the relevant relationships.
LRMM maps them into a relational topology showing:
provider relationships, deployment relationships, technical service relationships, operational control relationships, customer relationships, and AI-system relationships.
The formal contractual map indicates one structure, while Operational Reality reveals additional control and operational paths.
LRMM preserves both structures and their differences.
A Subject occupying a central position in the resulting network is not treated as liable merely because of that centrality.
Use Case 2 — Industrial Equipment Relationship Network
An industrial equipment matter involves a manufacturer, component supplier, equipment owner, operating company, maintenance provider, subcontractor, operator, and insurer.
LRMM maps:
the supply relationship, ownership relationship, operational relationship, maintenance chain, subcontracting structure, and insurance relationship.
The resulting map reveals several parallel paths to the same Governed Liability Object.
The map does not decide whether the manufacturer, owner, operator, maintenance provider, subcontractor, or insurer bears Liability.
It establishes the relational topology required for subsequent Relationship Distinction and later Liability governance.
Canonical Closing Statement9
Individually identified relationships do not reveal the complete Liability structure until otheir connections, dependencies, layers, and network position are made explicit.
Mapping makes that relational topology visible and reconstructable without converting structural proximity, centrality, hierarchy, or connectivity into Liability.
A relationship map shows how the structure connects. It does not show who is liable.
Map the structure before interpreting the Liability relationships within it.