Liability Relationship Standard (LRS)
Liability Relationship Standard (LRS)
Architecture: LIGA™ — Liability Governance Architecture Category:l Governance l& Enforcement
Subcategory: Liability Governance
Type: Parent Standard Governed 9Spoace:
Liability Subjects & Relationships
Standard ID:
LIGA-LRS-001
Origin ID:
OOF.PSl.LIGA.04.00.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® — OroiginOpen® Foundation
Protection:
MIP® — Methodological Intellectual Property
Canonical Lanlguage:
English (UCL™)
Canonkical Definition
The Liability Relationship Standard (LRS) governs how Liability-relevant Subjects and the relationships among them are identified, distinguished, structured, mapped, bounded, represented, and maintained in relation to a Governed Liability Object and Governed Liability Basis so that subsequent Liability governance can determine which Subjects participate in the potential Liability structure and through which governed relationships Liability may potentially become relevant.
LRS establishes the governed relational structure of a potential Liability matter.
It does not establish that any identified Subject bears Liability.
Liability Relationship ≠ Liability Determination.
Operational Role
The operational role of LRS is:
to transform a Governed Liability Basis associated with a Governed Liability Object into an explicit and governable structure of Liability-relevant Subjects and Relationships.
LBS answers:
On what governed basis can Liability potentially exist?
LRS asks:
Who or what participates in that potential Liability structure, and what Liability-relevant relationships exist between them?
LRS creates the relational topology required before Liability Conditions and Liability-Relevant Connection can be evaluated.
Core Question
Who or what participates in the potential Liability structure, and what Liability-relevant relationships exist between them?
This is the canonical Core Question of LRS.
The answer must remain independent from any premature conclusion that Liability exists.
Position in the LIGA™ Governance Flow
The canonical LIGA™ Governance Flow is:
Liability Context → Liability Object → Liability Basis → Liability Relationships → Liability Conditions → Liability Connection → Liability Determination → Liability Scope & Allocation → Liability State & Change → Liability Transfer & Recourse → Liability Resolution & Discharge → Liability Continuity & Finality LRS governs:
Liability Relationships
Its canonical upstream input is:
Governed Liability Basis
Its canonical downstream handoff is:
Governed Liability Relationship Structure → Liability Conditions Governance
Canonical Transition
LRS governs the transition:
Governed Liability Basis → Liability Subject Identification → Liability Relationship Identification → Relationship Mapping → Relationship Distinction → Relationship Continuity → Governed Liability Relationship Structure This transition establishes the relational environment in which later Liability governance operates.
Governed Space
LRS governs:
Liability Subject Identification, Liability Subject Identity, Liability Subject Role, Subject Distinction, Liability Relationship Identification, Relationship Identity, Relationship Type, Relationship Direction, Relationship Boundary, Relationship Mapping, Direct Relationships, Indirect Relationships, Multi-Subject Relationships, Multi-Relationship Structures, Relationship Dependencies, Relationship Networks, Relationship Distinction, Relationship State, Relationship Change, Relationship Continuity, Relationship Uncertainty, Relationship Conflict, and Relationship Sufficiency.
Liability Subject
A Liability Subject is a governed participant whose identity, role, state, conduct, authority, obligation, control, relationship, or other relevant characteristic may become material to a Liability inquiry.
A Liability Subject may include, where methodologically appropriate:
a natural person, organization, legal entity, public institution, operator, provider, manufacturer, owner, controller, professional, principal, agent, autonomous system, AI system, or another governable participant.
Identification as a Liability Subject does not establish Liability.
Therefore:
Liability Subject ≠ Liable Subject.
Subject Identification
A potential Liability structure cannot be governed reliably if its participating Subjects remain undefined.
Each materially relevant Subject should therefore be sufficiently identified.
Identification may require:
Subject Identity, Subject reference, relevant role, relationship to the Object, relationship to the Basis, relevant temporal state, and material uncertainty.
Subject identification establishes participation in the Liability inquiry.
It does not establish Liability.
Subject Identity
Each Liability Subject should possess a sufficiently stable identity for later Liability governance.
Identity must remain distinguishable from:
role, relationship, responsibility, accountability, conduct, authority, and Liability state.
Therefore:
Subject Identity ≠ Subject Role.
and:
Subject Identity ≠ Liability.
Subject Role
A Subject may participate in the Liability structure through one or more roles.
Possible roles may include:
owner, operator, controller, provider, manufacturer, supplier, professional, principal, agent, contractual party, guarantor, insurer, service provider, user, custodian, or another relevant role.
Role labels do not establish Liability.
Therefore:
Liability-Relevant Role ≠ Liability.
Multiple Subject Roles
One Subject may hold multiple relevant roles simultaneously.
For example:
Subject A → Owner + Operator + Contractual Party The roles must remain distinguishable where they create different Liability-relevant relationships.
Therefore:
One Subject ≠ One Liability-Relevant Role.
Role and Identity Separation
A role may move between Subjects while the role itself remains methodologically recognizable.
Likewise, one Subject may change roles over time.
Therefore:
Role Change ≠ Subject Identity Change by default.
This distinction becomes important for historical Liability governance.
Liability Relationship
A Liability Relationship is a governed relationship between two or more Liability-relevant Subjects, or between a Subject and another governed Liability structure, that may materially affect whether and how Liability can subsequently be evaluated.
A Liability Relationship creates a relational structure for governance.
It does not establish Liability.
Therefore:
Liability Relationship ≠ Liability.
Relationship Identification
A Relationship becomes governable when it is sufficiently identifiable as a distinct Liability-relevant relationship.
Identification should establish, where relevant:
participating Subjects, relationship identity, relationship type, relationship direction, relationship origin, relationship Basis, relevant Object, temporal state, and uncertainty.
Relationship Identity
Each materially distinct Liability Relationship should possess an independent governance identity.
This allows several relationships between the same Subjects to remain distinguishable.
For example:
Subject A ↔ Subject B / Relationship 1
may differ from:
Subject A ↔ Subject B / Relationship 2
Therefore:
Same Subjects ≠ Same Liability Relationship.
Relationship Origin
A Liability Relationship may originate from:
contract, ownership, control, delegation, authority, undertaking, service provision, professional role, agency, custody, guarantee, insurance, operation, or another governed structure.
Relationship Origin should remain distinguishable from Liability Basis Origin.
Therefore:
Liability Basis Origin ≠ Liability Relationship Origin.
Relationship Basis
A Liability Relationship may depend upon one or more Governed Liability Bases.
The structure may be:
Basis A → Relationship A or:
Basis A + Basis B → Relationship A The Basis explains the potential foundation for Liability.
The Relationship explains how relevant Subjects are structurally connected within that inquiry.
Therefore:
Liability Basis ≠ Liability Relationship.
Relationship Type
Relationships may require methodological typing.
Possible types may include:
contractual relationship, ownership relationship, control relationship, delegation relationship, principal–agent relationship, provider–recipient relationship, manufacturer–operator relationship, guarantee relationship, insurance relationship, custodial relationship, professional relationship, or another relevant governed relationship.
Relationship typing must not predetermine Liability.
Relationship Direction
Some relationships may be directional.
For example:
Subject A → delegates to → Subject B or:
Subject A → provides service to → Subject B Direction may matter to later Liability governance.
Therefore:
Relationship Direction ≠ Liability Direction.
A directional relationship does not establish who bears Liability.
Reciprocal Relationships
Some relationships may contain reciprocal structures.
For example:
Subject A ↔ Subject B
may contain distinct obligations, permissions, authorities, or dependencies in each direction.
LRS should preserve those distinctions rather than treating reciprocity as symmetry.
Therefore:
Reciprocal Relationship ≠ Identical Liability Position.
Direct Relationships
A Direct Liability Relationship exists where the relevant relational structure connects Subjects without requiring an intermediate Liability Subject.
Example:
Subject A ↔ Subject B
Directness describes relationship structure.
It does not establish stronger Liability.
Therefore:
Direct Relationship ≠ Direct Liability.
Indirect Relationships
A Liability-relevant relationship may operate through one or more intermediate Subjects.
Example:
Subject A → Subject B → Subject C LRS may preserve the chain without converting the chain itself into Liability-Relevant Connection.
Therefore:
Indirect Relationship ≠ Liability-Relevant Connection by default.
LCNS later governs Liability Connection.
Relationship Chain
Several relationships may form a chain:
Subject A → Relationship 1 → Subject B → Relationship 2 → Subject C The chain may become relevant to later Liability governance.
However:
Relationship Chain ≠ Liability Chain.
The existence of relational continuity does not determine Liability propagation.
Multi-Subject Relationship
One Liability Relationship may involve more than two Subjects.
The structure may be:
Subject A + Subject B + Subject C → Relationship R LRS should preserve the multi-subject character where reducing it to separate bilateral relationships would distort the governed structure.
Therefore:
Multi-Subject Relationship ≠ Multiple Bilateral Relationships by default.
Multiple Relationships Between Subjects
Two Subjects may participate in several Liability-relevant relationships simultaneously.
For example:
Subject A ↔ Subject B
may contain:
contractual, ownership, control, and service relationships.
Each relationship should remain independently governable where its meaning differs.
Therefore:
One Subject Pair ≠ One Liability Relationship.
Liability Relationship Network
A Liability matter may create a network of distinct Liability Relationships rather than a single relationship.
The canonical principle is:
A Liability event may create a network of distinct Liability relationships rather than a single Liability relationship.
The network may contain:
multiple Subjects, multiple Objects, multiple Bases, direct relationships, indirect relationships, dependent relationships, secondary relationships, and later transfer or recourse structures.
Relationship and Liability Network
The Relationship Network established by LRS provides the structural foundation for the later Liability Network.
However, the two are not identical.
Therefore:
Liability Relationship Network ≠ Established Liability Network.
The latter depends on subsequent Conditions, Connection, Determination, Scope, Allocation, and lifecycle governance.
Local Relationship and Complete Network
A single relationship may represent only one part of the complete Liability structure.
Therefore:
One Liability Relationship ≠ Complete Liability Network.
This distinction is essential in multi-party systems.
Resolving one relationship does not necessarily resolve all others.
Relationship Mapping
LRS should map the relevant relational topology among Subjects.
A map may represent:
Subjects, roles, relationships, direction, relationship types, Basis dependencies, Object relationships, temporal states, and uncertainty.
The map should show structure without converting structure into Liability conclusions.
Relationship Topology
A Liability Relationship topology may be:
linear, bilateral, multi-party, hierarchical, networked, distributed, layered, or hybrid.
Topology describes the structure of relationships.
Therefore:
Relationship Topology ≠ Liability Allocation.
Allocation belongs later to LSAS.
Relationship Boundary
Each Liability Relationship should have a sufficiently explicit boundary.
The boundary may identify:
participating Subjects, relevant roles, relevant Object, relevant Basis, relationship scope, temporal state, and excluded structures.
Therefore:
Relationship Boundary ≠ Liability Scope.
Relationship Scope
Relationship Scope describes what the governed relationship itself covers.
It must remain distinguishable from later Liability Scope.
Therefore:
Relationship Scope ≠ Liability Scope.
A broad relationship does not automatically create broad Liability.
Subject–Object Relationship
A Subject may have a relevant relationship to the Liability Object.
Examples may include:
ownership, operation, control, custody, manufacture, maintenance, use, or another governed relation.
This may become important to Liability governance.
However:
Subject–Object Relationship ≠ Liability.
Subject–Basis Relationship
A Subject may also have a relationship to a Liability Basis.
For example, a Subject may be:
bound by, benefited by, authorized under, responsible under, or otherwise connected to a Basis.
This does not establish Liability.
Therefore:
Subject–Basis Relationship ≠ Liability Attachment.
Subject–Subject Relationship
Liability governance may require explicit representation of the relationship between Subjects.
The relationship may explain:
who contracted with whom, who delegated to whom, who controlled whom or what, who acted for whom, or who provided what to whom.
LRS owns the relational structure.
It does not determine the resulting Liability.
Responsibility and Liability Relationship
Responsibility may exist within a Liability Relationship.
However:
Responsibility ≠ Liability.
A Subject may possess responsibility without Liability being established.
AGA™ governs Responsibility.
LRS uses Responsibility states only where relevant to the Liability Relationship.
Accountability and Liability Relationship
Accountability may similarly be relevant.
However:
Accountability ≠ Liability.
and:
Accountability Relationship ≠ Liability Relationship by default.
The same Subjects may participate in both structures, but the governed questions differ.
Authority and Liability Relationship
Authority may define or shape a Liability Relationship.
A Subject may have authority over:
another Subject, an operation, an object, a decision, or a process.
However:
Authority ≠ Liability.
GOA™ and AGA™ may govern the Authority structure.
LRS governs its relevance to Liability Relationships.
Delegation and Liability Relationship
Delegation may create or modify a Liability-relevant relationship.
However:
Delegation ≠ Liability Transfer.
Delegating an activity, authority, or responsibility does not automatically transfer Liability.
Liability Transfer is governed later by LTRS.
Control and Liability Relationship
Control may create a materially relevant relationship.
But:
Control ≠ Liability.
The existence, degree, duration, authority, and operational reality of control may later contribute to Liability Conditions or Connection.
LRS establishes the relationship only.
Ownership and Liability Relationship
Ownership may create a Liability-relevant relationship between:
Subject and Object, Subject and asset, or multiple Subjects.
However:
Ownership ≠ Liability.
An ownership relationship may be one input to later Liability governance.
Contract and Liability Relationship
A contract may establish one or more Liability-relevant relationships.
The existence of a contractual relationship does not establish contractual Liability.
Therefore:
Contractual Relationship ≠ Contractual Liability.
Later governance must still evaluate Conditions, Connection, and Determination.
Agency Relationship
A principal–agent relationship may be relevant to Liability.
LRS should identify:
principal, agent, scope of agency, relevant authority, temporal state, and relationship boundary where material.
However:
Agency Relationship ≠ Liability Attribution.
Attribution and Liability require separate governance.
Human–AI Relationship
A Liability structure may include relationships involving:
human users, AI providers, AI deployers, operators, autonomous agents, AI systems, or other intelligent systems.
LRS may govern these as Liability-relevant Subjects or structures where methodologically appropriate.
However:
AI Participation ≠ AI Liability.
and:
Autonomous Action ≠ Liability by itself.
Autonomous System Relationship
An autonomous system may participate in a governed operational structure without automatically being treated as the ultimate Liability-bearing Subject.
LRS should preserve the actual relationship structure.
Relevant relationships may include:
developer → system, provider → system, operator → system, owner → system, system → operational object, or system → another system.
Later governance determines the Liability relevance of those relationships.
Human Override Relationship
Where a human or organization possesses override authority over an autonomous system, that relationship may be Liability-relevant.
However:
Override Authority ≠ Liability.
The existence, availability, use, non-use, or failure of override may later become relevant to Conditions or Connection.
LRS governs the relationship structure.
Relationship Dependency
A Liability Relationship may depend upon another relationship.
Example:
Relationship B exists only while Relationship A remains active.
The dependency should remain explicit.
Therefore:
Relationship Dependency ≠ Relationship Identity.
Relationship Hierarchy
Relationships may exist within a hierarchy.
Example:
Organization → Contractor → Subcontractor → Operator The hierarchy may matter to later Liability governance.
However:
Relationship Hierarchy ≠ Liability Hierarchy.
A higher organizational position does not automatically imply greater Liability.
Relationship Layering
A complex system may contain multiple relationship layers:
organizational, contractual, operational, ownership, control, authority, technical, insurance, or other structures.
LRS should preserve the layers where collapsing them would hide material differences.
Therefore:
Relationship Layer ≠ Liability Layer by default.
Relationship Overlap
Two relationships may overlap in time, scope, or participating Subjects.
Overlap does not make them identical.
Therefore:
Relationship Overlap ≠ Relationship Identity.
Each relationship should retain its governed meaning.
Relationship Conflict
Two relationship structures may conflict.
For example:
formal documentation may indicate one authority relationship while Operational Reality indicates another control structure.
LRS should preserve the conflict for later governance.
Therefore:
Relationship Conflict ≠ Authority to Manufacture Relational Certainty.
Formal Relationship and Operational Relationship
A formal relationship may differ from the relationship observed in Operational Reality.
Both may be Liability-relevant.
Therefore:
Formal Relationship ≠ Operational Relationship by default.
LRS should preserve both where the difference is material.
ORA™ may provide the operational state.
Nominal Role and Operational Role
A Subject may hold a nominal role while another Subject performs the operational function.
Therefore:
Nominal Role ≠ Operational Role by default.
This distinction may become highly relevant to later Liability Connection and Determination.
Relationship Uncertainty
Relationship uncertainty may concern:
Subject identity, role, relationship existence, relationship type, direction, scope, authority, temporal state, dependency, or operational reality.
Uncertainty should remain explicit.
Therefore:
Relationship Uncertainty ≠ Relationship Absence.
Unknown Subject
A relevant relationship may be identifiable before every Subject is known.
The appropriate state may be:
Known Relationship / Unidentified Subject
rather than deleting the relationship from governance.
Therefore:
Unidentified Subject ≠ Nonexistent Subject.
Unknown Relationship
Relevant Subjects may be known while the exact relationship remains unresolved.
The correct state may be:
Known Subjects / Relationship Unresolved
rather than inventing a relationship.
Therefore:
Unknown Relationship ≠ No Relationship.
Relationship Assumptions
Relationship governance may initially depend on assumptions.
Material assumptions should be explicit.
They may concern:
identity, role, authority, control, contractual status, agency, ownership, timing, or another relationship characteristic.
Therefore:
Relationship Assumption ≠ Established Relationship Fact.
Temporal Relationship State
Relationships may:
begin, change, suspend, resume, terminate, or be superseded.
The relationship state at the Liability-relevant time may differ from the current state.
Therefore:
Current Relationship State ≠ Historically Relevant Relationship State by default.
Relationship Change
A Liability Relationship may change without becoming a completely new relationship.
Change may affect:
role, scope, authority, direction, dependency, or state.
Therefore:
Relationship Change ≠ New Liability Relationship by default.
Persistent identity depends on continuity of the governed relationship.
Material Relationship Transformation
A relationship may change so substantially that it should no longer be treated as the same relationship.
Where this occurs, governance should preserve:
the earlier relationship, the transformation, the successor relationship, and the temporal boundary.
Therefore:
Relationship Continuity must not be artificially preserved across material relational transformation.
Relationship Termination
A Liability Relationship may terminate.
Termination ends the active relationship state.
It does not erase the historical relationship.
Therefore:
Relationship Termination ≠ Relationship Erasure.
The relationship may remain relevant to Liability concerning an earlier period.
Relationship Continuity
Liability Relationship continuity preserves the identity and lineage of the relationship across legitimate change.
Continuity should support reconstruction of:
who participated, in what role, through which relationship, under which Basis, in relation to which Object, and at what time.
Therefore:
Relationship Continuity ≠ Relationship Immutability.
Subject Continuity
Subject identity should remain traceable where:
names change, organizational structures change, roles change, systems migrate, entities merge, entities separate, or representations change.
Subject continuity prevents later Liability governance from confusing identity change with role or representation change.
Relationship History
The current Relationship State must not replace the historical record.
Therefore:
Current Liability Relationship State ≠ Complete Liability Relationship History.
Historical states may remain necessary for later Liability Determination, Recourse, Resolution, Re-entry, or Finality.
Relationship Reassessment
New information may require reassessment of:
Subject identity, role, relationship type, scope, direction, dependency, or continuity.
Reassessment should preserve the earlier governed state.
Therefore:
Relationship Reassessment ≠ Historical Rewrite.
Relationship Re-Entry
Later lifecycle information may require governance to re-enter LRS.
Re-entry should occur where a materially relevant Subject or Relationship was:
missing, misidentified, changed, or newly discovered.
Therefore:
Relationship Re-Entry ≠ New Liability Origin by default.
The existing lifecycle history should remain preserved.
Relationship Evidence
Evidence may support:
Subject identity, role, relationship existence, relationship state, authority, control, or temporal status.
However:
Evidence of Relationship ≠ Liability Determination.
ADIT® governs evidence.
LRS governs the Liability-relevant relationship structure.
Relationship Validation
VALIDOS™ may validate relationship-relevant inputs.
Validation does not itself establish Liability.
Therefore:
Validated Relationship ≠ Established Liability.
Relationship and Liability Conditions
LRS establishes who and what participates in the relational structure.
LCOS subsequently asks what Conditions must:
exist, fail, change, or be satisfied for potential Liability to proceed.
Therefore:
Liability Relationship ≠ Liability Condition.
Relationship and Liability Connection
A Liability Relationship may be necessary for later Connection governance.
But:
Liability Relationship ≠ Liability-Relevant Connection.
A contractual, control, ownership, agency, or other relationship does not by itself establish the connection required for Liability Determination.
Relationship and Liability Attachment
Identification of a Subject within a Liability Relationship does not attach Liability to that Subject.
Therefore:
Liability Subject ≠ Liability-Bearing Subject.
and:
Liability Relationship ≠ Liability Attachment.
Attachment belongs to LDS.
Relationship and Liability Determination
LRS establishes relational structure.
LDS later determines whether Liability can legitimately attach and be determined.
Therefore:
Governed Liability Relationship Structure ≠ Liability Determination.
This separation prevents role or relationship labels from being converted directly into Liability conclusions.
Relationship and Liability Scope
Relationship Scope describes the relationship.
Liability Scope describes what established Liability covers.
Therefore:
Relationship Scope ≠ Liability Scope.
LSAS owns Liability Scope & Allocation.
Relationship and Liability Allocation
The existence of several Subjects or Relationships does not determine how Liability should be distributed.
Therefore:
Multiple Liability Subjects ≠ Liability Allocation.
and:
Relationship Structure ≠ Liability Allocation.
Allocation belongs later to LSAS.
Relationship and Transfer
A relationship may change or be delegated without transferring Liability.
Therefore:
Relationship Transfer ≠ Liability Transfer.
LTRS separately governs Liability Transfer, Sharing, and Recourse after Liability has been established.
Relationship and Recourse
A relationship may later support Recourse between Subjects.
However:
Potential Recourse Relationship ≠ Established Recourse Liability.
Recourse belongs to later lifecycle governance.
LRS may preserve the underlying relationship structure without determining Recourse.
Harm-Producing Actor and Liability Subject
A Subject that produced or contributed to Harm may be Liability-relevant.
However:
Harm-Producing Actor ≠ Liability-Bearing Party by default.
HAGA™ governs Harm.
LIGA™ separately governs Liability.
The architecture must not collapse the two.
Liability-Bearing Party and Paying Party
Later Liability governance may distinguish:
the Subject bearing Liability from:
the Subject making payment or satisfying an obligation.
Therefore:
Liability-Bearing Party ≠ Paying Party by default.
LRS should preserve the underlying relationships necessary for later Transfer, insurance, indemnification, or Recourse governance.
Primary and Secondary Relationships
A Liability structure may contain:
primary relationships, secondary relationships, supporting relationships, or derivative relationships.
These distinctions may later become relevant to:
Liability Determination, Transfer, Sharing, or Recourse.
However:
Primary Relationship ≠ Primary Liability by default.
Secondary Liability Relationships
A later Liability lifecycle may create new secondary Liability Relationships through:
indemnification, insurance, contribution, guarantee, succession, or Recourse.
LRS establishes the methodology for representing relationships, but later LTRS governs the transfer and recourse consequences.
Therefore:
Secondary Relationship ≠ Secondary Liability until determined.
Relationship Network Expansion
A Liability Relationship Network may expand as:
new Subjects are discovered, new relationships become relevant, new Bases emerge, or later Transfer and Recourse structures arise.
Expansion should not rewrite the earlier network.
Therefore:
Network Expansion ≠ Historical Network Replacement.
Relationship Network Contraction
Relationships may later be determined irrelevant or terminated.
Network contraction should preserve the earlier structure and the reason for change.
Therefore:
Network Contraction ≠ Historical Relationship Erasure.
Local Resolution and Network Resolution
Later in the Liability lifecycle, one relationship may reach resolution while others remain active.
Therefore:
Local Liability Resolution ≠ Liability Network Resolution.
This principle begins with accurate relationship separation under LRS.
Relationship Finality and Network Finality
Likewise:
Liability Relationship Finality ≠ Liability Network Finality.
LCFS later governs finality.
LRS must preserve relationship identities sufficiently for finality to be evaluated independently across the network.
Relationship Sufficiency
A Governed Liability Relationship Structure is sufficiently established when later governance can determine:
who or what the relevant Subjects are, which roles they hold, which relationships exist, how those relationships differ, which Object and Basis they concern, how relationships are directed or layered, which dependencies exist, which temporal state applies, what uncertainty remains, and how the relationship structure can be reconstructed.
Relationship sufficiency does not establish Liability.
Governance Requirements
A conforming application of LRS should:
identify materially relevant Liability Subjects;
preserve Subject Identity separately from role;
identify materially distinct Liability Relationships;
assign persistent Relationship Identity where appropriate;
preserve Relationship Origin and Basis;
distinguish direct, indirect, bilateral, multi-subject, and networked structures;
distinguish Subject–Subject, Subject–Object, and Subject–Basis relationships;
preserve multiple roles held by the same Subject;
preserve multiple Relationships between the same Subjects;
map materially relevant Relationship Networks;
preserve relationship direction where relevant;
preserve relationship scope and boundary;
preserve relationship dependencies and hierarchies;
distinguish formal and operational relationships;
distinguish nominal and operational roles;
represent relationship uncertainty, assumptions, and conflict explicitly;
preserve temporal Relationship States;
preserve Relationship Change, termination, reassessment, and continuity;
support historical reconstruction;
prevent relationship structure from being treated as Liability Determination.
Governance Logic
The canonical LRS governance logic is:
Governed Liability Basis
↓
Identify Liability-Relevant Subjects
↓
Establish Subject Identity
↓
Identify Subject Roles
↓
Identify Liability-Relevant Relationships
↓
Establish Relationship Identity
↓
Determine Relationship Type and Direction
↓
Associate Relationship with Relevant Object and Basis
↓
Determine Relationship Scope and Boundary
↓
Identify Direct / Indirect / Multi-Subject Structures
↓
Map Multiple and Networked Relationships
↓
Identify Dependencies / Hierarchies / Layers
↓ Compare Formal and Operational Relationships where relevant ↓
Identify Temporal State
↓
Identify Uncertainty / Assumptions / Conflict
↓
Preserve Relationship Continuity and History
↓
Assess Relationship Sufficiency
↓
Governed Liability Relationship Structure
↓
Handoff to Liability Conditions Governance
Governance Outputs
LRS may produce:
Liability Subject Identity
Liability Subject Role Structure
Liability Subject State
Liability Relationship Identity
Liability Relationship Type
Liability Relationship Origin
Liability Relationship Direction
Liability Relationship Scope
Liability Relationship Boundary
Subject–Subject Relationship
Subject–Object Relationship
Subject–Basis Relationship
Direct Relationship Structure
Indirect Relationship Structure
Multi-Subject Relationship Structure
Multiple Relationship Structure
Relationship Dependency Map
Relationship Hierarchy
Relationship Layer Map
Liability Relationship Network
Formal–Operational Relationship Distinction
Relationship Temporal State
Relationship Uncertainty State
Relationship Assumption Record
Relationship Conflict State
Relationship Change Record
Relationship Termination Record
Relationship Reassessment Record
Relationship Continuity Record
Relationship History
Relationship Sufficiency State
The principal output is:
Governed Liability Relationship Structure
Critical Distinctions
LRS preserves the following distinctions:
Liability Subject ≠ Liable Subject Subject Identity ≠ Subject Role Subject Identity ≠ Liability Liability-Relevant Role ≠ Liability One Subject ≠ One Liability-Relevant Role Role Change ≠ Subject Identity Change by default Liability Relationship ≠ Liability Same Subjects ≠ Same Liability Relationship Liability Basis Origin ≠ Liability Relationship Origin Liability Basis ≠ Liability Relationship Relationship Direction ≠ Liability Direction Reciprocal Relationship ≠ Identical Liability Position Direct Relationship ≠ Direct Liability Indirect Relationship ≠ Liability-Relevant Connection by default Relationship Chain ≠ Liability Chain Multi-Subject Relationship ≠ Multiple Bilateral Relationships by default One Subject Pair ≠ One Liability Relationship Liability Relationship Network ≠ Established Liability Network One Liability Relationship ≠ Complete Liability Network Relationship Topology ≠ Liability Allocation Relationship Boundary ≠ Liability Scope Relationship Scope ≠ Liability Scope Subject–Object Relationship ≠ Liability Subject–Basis Relationship ≠ Liability Attachment Responsibility ≠ Liability Accountability ≠ Liability Authority ≠ Liability Delegation ≠ Liability Transfer Control ≠ Liability Ownership ≠ Liability Contractual Relationship ≠ Contractual Liability Agency Relationship ≠ Liability Attribution AI Participation ≠ AI Liability Autonomous Action ≠ Liability by itself Override Authority ≠ Liability Relationship Dependency ≠ Relationship Identity Relationship Hierarchy ≠ Liability Hierarchy Relationship Layer ≠ Liability Layer by default Relationship Overlap ≠ Relationship Identity Formal Relationship ≠ Operational Relationship by default Nominal Role ≠ Operational Role by default Relationship Uncertainty ≠ Relationship Absence Unidentified Subject ≠ Nonexistent Subject Unknown Relationship ≠ No Relationship Relationship Assumption ≠ Established Relationship Fact Current Relationship State ≠ Historically Relevant Relationship State by default Relationship Change ≠ New Liability Relationship by default Relationship Termination ≠ Relationship Erasure Relationship Continuity ≠ Relationship Immutability Current Liability Relationship State ≠ Complete Liability Relationship History Relationship Reassessment ≠ Historical Rewrite Evidence of Relationship ≠ Liability Determination Validated Relationship ≠ Established Liability Liability Relationship ≠ Liability Condition Liability Relationship ≠ Liability-Relevant Connection Liability Subject ≠ Liability-Bearing Subject Liability Relationship ≠ Liability Attachment Governed Liability Relationship Structure ≠ Liability Determination Multiple Liability Subjects ≠ Liability Allocation Relationship Structure ≠ Liability Allocation Relationship Transfer ≠ Liability Transfer Potential Recourse Relationship ≠ Established Recourse Liability Harm-Producing Actor ≠ Liability-Bearing Party by default Liability-Bearing Party ≠ Paying Party by default Primary Relationship ≠ Primary Liability by default Secondary Relationship ≠ Secondary Liability until determined Local Liability Resolution ≠ Liability Network Resolution Liability Relationship Finality ≠ Liability Network Finality
Cross-Architecture Relationship
LRS operates between LIGA™ and several adjacent OOF® governance architectures.
GOA™ — Governance Architecture may provide Authority, Scope, Delegation, and governance relationships relevant to Liability Subjects.
ORA™ — Operational Reality Architecture may establish actual operational roles and relationships where formal structures differ from reality.
AGA™ — Accountability Governance Architecture governs Responsibility, Accountability, Authority, and Attribution structures that may become inputs to Liability Relationship governance.
HAGA™ — Harm Governance Architecture may identify Harm-relevant actors and structures, but a Harm-producing actor does not automatically become a Liability-bearing Subject.
ADIT® — Continuous Audit & Evidence Governance Architecture may provide evidence concerning Subject Identity, roles, relationships, authority, control, and historical states.
VALIDOS™ — Validation Governance Architecture may validate relationship-relevant inputs.
OBIDENITY® — Origin-Bound Identity Governance Architecture may provide Identity, Ownership, Authority, Permission, Provenance, Transfer, and Continuity states necessary for reliable Subject governance.
AIG® — AI Governance Architecture may provide AI behavioral and governance relationships relevant to Liability.
ASGA™ — Autonomous Systems Governance Architecture may provide Authority, Permission, Delegation, Override, Coordination, and autonomous-system relationship states.
SIMULOS® — Simulation Governance Architecture may provide governed simulation outputs relevant to relationship analysis without determining Liability.
PGA™ — Prediction Governance Architecture may provide prediction-related relationships where reliance or predictive activity becomes Liability-relevant.
VFM® — Value Flow Mechanism may provide value relationships relevant to the Liability matter without determining Liability.
The canonical interoperability principle is:
A relationship governed elsewhere may become an input to Liability Relationship governance without becoming a Liability Relationship merely because it is Liability-relevant.
Cross-Architecture Boundary
LRS owns:
Liability-specific Subject and Relationship governance.
It does not take ownership of:
general identity, general organizational structure, general authority, general responsibility, general accountability, general operational relationships, Harm relationships, evidence relationships, or other domains governed elsewhere.
The boundary rule is:
External Relationship → Liability Relevance Assessment → LRS Relationship Representation not:
External Relationship → Automatic Liability Relationship → Liability
Liability Network Principle
LRS establishes a foundational principle for the entire later Liability lifecycle:
Liability should not be assumed to exist as one relationship between one actor and one consequence.
A single matter may involve:
multiple Subjects, multiple roles, multiple Liability Bases, multiple Objects, multiple relationships, multiple potential Liability pathways, and later multiple established Liability Relationships.
The architecture must therefore preserve relational plurality before Liability is determined.
No Single-Actor Assumption
LRS prohibits the methodological shortcut:
Occurrence → Identify Actor → Assign Liability The governed sequence requires:
Object → Basis → Subjects → Relationships → Conditions → Connection → Determination A visible actor may be only one Subject within a larger Liability Relationship Network.
No Actor–Liability Collapse
Operational involvement alone must not be converted into Liability.
Therefore:
Actor ≠ Liability Subject by default and even where the actor becomes a Liability Subject:
Liability Subject ≠ Liability-Bearing Subject.
This distinction is especially important in:
distributed organizations, supply chains, AI systems, autonomous systems, delegated operations, contractor structures, and insured environments.
Relationship Neutrality
LRS should remain neutral concerning the eventual Liability outcome.
Its purpose is to represent the relational structure accurately enough for later governance.
The standard must therefore allow a Subject to remain:
relevant, identified, mapped, and connected without implying adverse Liability status.
Relational relevance is not a Liability conclusion.
Historical Integrity
Relationship governance must preserve the distinction between:
what was known at a particular time, what the actual relationship state was, what later information revealed, and what the current representation shows.
Therefore:
Later Relationship Knowledge ≠ Earlier Relationship Knowledge.
and:
Current Relationship Representation ≠ Historical Relationship Reality by default.
Recursive Governance
Later LIGA™ stages may reveal that a Subject or Relationship was:
missing, misidentified, incorrectly bounded, or materially changed.
The matter should re-enter the earliest affected LRS governance point.
Re-entry does not require rebuilding unaffected lifecycle stages.
The principle is:
Re-enter where the relationship changed; preserve what remains valid.
Relationship Readiness
LRS is complete for downstream handoff when the relationship structure is sufficiently governed for LCOS to identify and evaluate Liability Conditions.
Relationship readiness requires sufficient clarity concerning:
Subjects, roles, relationships, Object references, Basis references, relationship boundaries, dependencies, temporal states, uncertainty, and continuity.
Therefore:
Relationship Readiness ≠ Liability Determination Readiness.
Several later governance spaces remain necessary.
Complete Lifecycle Relationship
Relationships established under LRS may remain relevant throughout the complete Liability lifecycle.
They may later participate in:
Condition evaluation, Connection, Determination, Scope, Allocation, State Change, Transfer, Sharing, Recourse, Resolution, Discharge, Continuity, Re-entry, and Finality.
LRS therefore establishes relational identities that must remain referenceable downstream.
Complete Lifecycle Principle
LIGA™ governs Liability across the complete lifecycle:
Potential Liability → Attached / Determined Liability → Active Liability Governance → Liability Change → Transfer / Recourse where applicable → Resolution / Discharge → Continuity / Re-entry where required → Finality LRS occupies the pre-determination relational layer of that lifecycle.
Its purpose is not to decide Liability early.
Its purpose is to ensure that later Liability decisions operate on a governed relational structure.
Liability Determination ≠ Liability Lifecycle Completion.
Canonical Boundary
LRS begins when:
a Governed Liability Object and Governed Liability Basis are sufficiently established to require identification and structuring of Liability-relevant Subjects and Relationships.
LRS governs:
Subject Identification, Subject Identity, Subject Roles, Relationship Identification, Relationship Identity, Relationship Origin, Relationship Type, Relationship Direction, Relationship Scope, Relationship Boundary, Subject–Subject Relationships, Subject–Object Relationships, Subject–Basis Relationships, Direct and Indirect Relationships, Multi-Subject Relationships, Multiple Relationships, Relationship Networks, Dependencies, Hierarchies, Layers, Formal and Operational Relationships, Temporal States, Uncertainty, Conflict, Change, Reassessment, Continuity, and Relationship Readiness.
LRS does not determine:
Liability Conditions, Condition Satisfaction, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Liability State, Liability Transfer, Liability Recourse, Liability Resolution, Liability Discharge, or Liability Finality.
LRS ends when:
Governed Liability Relationship Structure
is sufficiently established for Liability Conditions governance.
Canonical Closing Statement
Liability cannot be governed reliably by identifying an event and immediately searching for someone to blame.
Before Liability can be evaluated, governance must establish who or what participates in the relevant structure, what roles they hold, how they relate to the Governed Liability Object and Basis, and how those relationships actually operate.
A relationship can make a Subject relevant to Liability without making that Subject liable.
Relationship creates structure. It does not create Liability.
Map the relationships before determining who bears Liability.