LSUIM — Liability Subject Identification Module
LSUIM — Liability Subject Identification Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Relationship Standard (LRS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Subject Identification
Module ID: LIGA-LRS-LSUIM-001
Origin ID: OOF.CM.LIGA.04.01.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 Subject Identification Module (LSUIM) governs how persons, organizations, entities, systems, and other governable participants that may be materially relevant to a potential Liability structure are recognized, identified, distinguished, referenced, and maintained as Liability Subject Candidates so that subsequent Liability Relationship governance proceeds from explicit Subject identities rather than assumptions based on visibility, proximity, role labels, Harm involvement, ownership, control, responsibility, accountability, or alleged Liability.
LSUIM governs the transition:
Governed Liability Basis → Potential Subject Recognition → Subject Candidate Identification → Subject Identity Establishment → Subject Relevance Assessment → Identified Liability Subject Its foundational distinction is:
Liability Subject ≠ Liable Subject.
Operational Role
The operational role of LSUIM is:
to determine who or what must enter the Liability Relationship inquiry as an identifiable Liability-relevant Subject.
LSUIM does not determine:
who is liable, which relationship exists, whether Liability Conditions are satisfied, whether a Liability-Relevant Connection exists, or whether Liability attaches.
It establishes the participants that later relational governance must evaluate.
Position in the Parent Standard Flow
The internal LRS progression is:
Liability Subject Identification → Liability Relationship Identification → Relationship Mapping → Relationship Distinction → Relationship Continuity LSUIM governs:
Liability Subject Identification
Its principal input is:
Governed Liability Basis
together with the relevant Governed Liability Object and preserved upstream governance states.
Its principal output is:
Identified Liability Subject Set
Its canonical handoff is:
Identified Liability Subject Set → Liability Relationship Identification
Central Operational Question
Who or what is sufficiently relevant to the potential Liability structure to require explicit identification as a Liability Subject?
The question concerns participation in the Liability inquiry.
It does not ask who bears Liability.
Governed Space
LSUIM governs:
Potential Subject Recognition, Subject Candidate Identification, Subject Identity, Subject Reference, Subject Type, Subject Relevance, Subject Role Reference, Human Subjects, Organizational Subjects, Institutional Subjects, System Subjects, AI and Autonomous-System Subjects, Multiple Subjects, Unknown Subjects, Partially Identified Subjects, Duplicate Subject Records, Subject Distinction, Subject Temporal State, Subject Uncertainty, Subject Change, Subject Correction, Subject Reassessment, and Subject Identification Sufficiency.
Liability Subject Candidate
A Liability Subject Candidate is a person, organization, entity, system, or other governable participant whose involvement may be materially relevant to the Liability inquiry but whose Subject status has not yet been sufficiently established.
Candidate status preserves uncertainty.
Therefore:
Potential Subject ≠ Identified Liability Subject.
Subject Recognition
Potential Subjects may become visible through:
the Governed Liability Object, the Governed Liability Basis, operational activity, ownership, control, authority, delegation, contract, service provision, manufacture, maintenance, custody, professional activity, Harm-related involvement, evidence, or another governed input.
Recognition is the entry point.
It is not a Liability conclusion.
Recognition Trigger
A Subject Recognition Trigger is any governed information indicating that a participant may require evaluation within the Liability Relationship structure.
A trigger may originate from:
upstream LIGA™ governance, another OOF® architecture, evidence, a governed record, or later lifecycle re-entry.
Therefore:
Recognition Trigger ≠ Subject Qualification as Liable.
Subject Identification
A Subject becomes identified when its identity is sufficiently established for subsequent relationship governance.
Identification should answer:
Who or what is the participant?
How is it uniquely referenced?
What kind of Subject is it?
Why is it relevant to the Liability inquiry?
Which Object and Basis make it relevant?
What uncertainty remains?
Subject Identity
Subject Identity is the governed identity of the participant independently of the participant's role or eventual Liability state.
The architecture must preserve:
Subject Identity ≠ Subject Role.
A person or organization remains the same Subject even where its role changes, unless the underlying identity itself changes.
Persistent Subject Reference
Each identified Subject should receive or retain a sufficiently stable reference allowing the Subject to be traced across later LIGA™ governance.
The reference should survive ordinary changes in:
name, role, system location, record identifier, representation, or organizational context.
Therefore:
Subject Reference Change ≠ Subject Identity Change by default.
Subject Type
Subject typing may assist later relationship governance.
Possible methodological types may include:
Natural Person, Organization, Legal Entity, Public Institution, Organizational Unit, Operational Entity, System, AI System, Autonomous System, Agent, or another governable participant type.
Subject Type describes what kind of participant is being represented.
It does not establish Liability.
Natural Person
A natural person may become a Liability Subject where their participation is materially relevant to the Liability inquiry.
Possible relevance may arise from:
action, decision, authority, control, professional role, ownership, operation, delegation, or another governed factor.
Identification does not establish personal Liability.
Therefore:
Identified Natural Person ≠ Personally Liable Person.
Organization
An organization may become a Liability Subject where its governed participation is materially relevant.
Identification should distinguish the organization from:
employees, owners, directors, contractors, subsidiaries, parent entities, agents, or other related Subjects.
Therefore:
Organizational Relationship ≠ Subject Identity Merger.
Legal Entity
Where legally recognized entity status is relevant, the entity should be represented independently from the broader organization or group to which it belongs.
Therefore:
Corporate Group ≠ Individual Legal Entity.
and:
Brand Identity ≠ Legal Entity Identity by default.
LSUIM preserves the distinction without making jurisdiction-specific legal Liability determinations.
Organizational Unit
A division, department, branch, site, or other organizational unit may be operationally relevant without possessing an independent Liability-bearing legal identity.
LSUIM may still identify it where necessary to understand later relationships.
Therefore:
Operationally Relevant Unit ≠ Independent Liability-Bearing Entity by default.
Public Institution
A public institution or public body may become a Liability Subject where materially relevant.
Identification should preserve:
institutional identity, relevant unit, authority structure where known, and temporal state.
Identification does not determine public-law Liability or jurisdiction-specific immunity.
System as Subject Candidate
A technical or intelligent system may be materially relevant to Liability governance.
LSUIM may identify such a system as a Liability Subject Candidate where doing so is necessary to represent the Liability structure accurately.
However:
System Participation ≠ Legal Personhood.
and:
System Identification ≠ System Liability.
AI System
An AI system may be identified as a Liability-relevant Subject where its identity, behavior, authority, decision role, or operational participation is material to the Liability inquiry.
This is a methodological representation.
It does not determine whether the AI system can legally bear Liability.
Therefore:
AI Subject Identification ≠ AI Legal Liability.
Autonomous System
An autonomous system may require independent identification where it performs materially relevant actions or decisions.
The system should remain distinguishable from:
developer, provider, owner, deployer, operator, controller, user, and other Subjects.
Therefore:
Autonomous System ≠ Operator.
Autonomous System ≠ Provider.
Autonomous System ≠ Owner.
Agent
An agent may be:
human, organizational, software-based, AI-based, or otherwise operationally represented.
Agent identity should remain separate from:
principal identity, delegating Subject, system owner, and system operator.
Therefore:
Agent ≠ Principal.
The existence of agency is governed later as a relationship question.
Subject Relevance
A participant should enter LSUIM where there is sufficient reason to preserve it for subsequent Liability Relationship governance.
Relevance may derive from:
relationship to the Object, relationship to the Basis, operational participation, authority, control, ownership, responsibility, accountability, conduct, decision-making, service provision, manufacture, maintenance, custody, delegation, or another materially relevant factor.
Relevance does not establish Liability.
Relevance Threshold
LSUIM should avoid two opposite failures:
Under-Inclusion
where materially relevant Subjects are omitted, and:
Over-Inclusion
where every remotely connected participant is treated as Liability-relevant.
The relevance threshold should preserve Subjects whose inclusion could materially affect later Liability Relationship governance.
Proximity and Relevance
Physical, organizational, technical, or causal proximity may trigger Subject evaluation.
Proximity alone is insufficient.
Therefore:
Proximity ≠ Liability Relevance by default.
and even where relevance exists:
Liability Relevance ≠ Liability.
Visibility and Relevance
The most visible actor may not be the most relevant Subject.
Likewise, a less visible Subject may hold material authority, control, ownership, or another relevant relationship.
Therefore:
Visibility ≠ Liability Relevance.
LSUIM should not privilege the easiest Subject to observe.
Operational Actor
A Subject that performs an operational action may be Liability-relevant.
However:
Operational Actor ≠ Liability-Bearing Subject by default.
The operational actor may be one participant in a wider Liability Relationship Network.
Harm-Producing Actor
Where Harm exists, the actor associated with Harm production may become Liability-relevant.
However:
Harm-Producing Actor ≠ Liability-Bearing Party by default.
HAGA™ governs Harm.
LSUIM identifies Liability-relevant Subjects without converting Harm participation into Liability.
Owner
Ownership may justify identifying an owner as a Liability Subject where ownership is materially relevant.
However:
Owner ≠ Liable Subject by default.
Ownership becomes a relationship input for later governance.
Controller
A Subject exercising control may require identification.
Control may be:
formal, operational, technical, organizational, financial, or another relevant form.
However:
Controller ≠ Liable Subject by default.
Control relevance must later be evaluated through governed relationships, Conditions, and Connection.
Operator
An operator may be relevant because it operates the Governed Liability Object, system, process, or environment.
However:
Operator ≠ Liable Subject by default.
Operational participation does not substitute for Liability Determination.
Provider
A provider may become relevant through:
service provision, technology provision, infrastructure provision, professional service, or another governed activity.
Provider status does not establish Liability.
Therefore:
Provider ≠ Liability-Bearing Party by default.
Manufacturer
A manufacturer may be relevant to a Liability inquiry involving a product, component, equipment, or system.
Identification does not establish product-related or other Liability.
Therefore:
Manufacturer ≠ Liable Subject by default.
Contractor and Subcontractor
Contractors and subcontractors should be identified separately where their participation may materially affect the Liability structure.
A subcontractor must not be collapsed into the contractor.
Likewise, the contractor must not be treated as identical to the principal.
Therefore:
Contractor ≠ Subcontractor ≠ Principal.
Principal and Agent
Where a potential principal–agent structure exists, both Subjects should be separately identified before the relationship itself is determined.
Therefore:
Principal Identity ≠ Agent Identity.
LSUIM identifies the Subjects.
LRIM later identifies whether and how the agency relationship exists.
Insurer
An insurer may become Liability-relevant where insurance relationships may affect later payment, transfer, sharing, or Recourse structures.
However:
Insurer ≠ Primary Liability-Bearing Subject by default.
Payment responsibility and underlying Liability must remain distinct.
Paying Party
A party that makes or may make payment can be identified where materially relevant.
However:
Paying Party ≠ Liability-Bearing Party by default.
This distinction becomes especially important in insurance, indemnification, guarantees, and Recourse.
Multiple Subjects
A single Liability inquiry may contain many Subjects.
LSUIM should preserve each materially distinct Subject independently.
Therefore:
Multiple Subjects ≠ One Collective Liability Subject by default.
Grouping must not erase relevant identity differences.
Collective Subject Representation
A collective representation may be useful where several participants legitimately function as one governed unit for a particular analytical purpose.
However, the underlying Subjects should remain separately reconstructable where their individual identity may become materially relevant.
Therefore:
Collective Representation ≠ Identity Merger.
Related Organizations
Parent companies, subsidiaries, affiliates, joint ventures, contractors, and other related organizations must not be collapsed merely because they share ownership, branding, management, or infrastructure.
Therefore:
Organizational Affiliation ≠ Subject Identity.
Each materially relevant entity should be identified separately.
Subject and Role
LSUIM may preserve preliminary role information needed to distinguish Subjects.
However, complete relationship governance belongs downstream.
Therefore:
Subject Identification ≠ Complete Role Determination.
and:
Role Reference ≠ Liability Relationship Identification.
Subject and Liability Object
A Subject may be relevant because of its relationship to the Governed Liability Object.
Possible Object-related relevance may include:
ownership, operation, control, manufacture, maintenance, custody, use, or another relationship.
LSUIM records the relevance reference.
LRIM determines the relationship.
Therefore:
Object Relevance ≠ Established Subject–Object Relationship.
Subject and Liability Basis
A Subject may be identified because the Governed Liability Basis refers to or potentially affects that Subject.
However:
Basis Reference to Subject ≠ Liability Attachment.
LRS must still establish the relevant relational structure.
Subject and Responsibility
Responsibility may trigger Subject identification.
However:
Responsible Subject ≠ Liable Subject.
AGA™ owns Responsibility governance.
LSUIM uses governed Responsibility only as a relevance input where appropriate.
Subject and Accountability
Accountability may likewise make a Subject relevant.
However:
Accountable Subject ≠ Liable Subject.
Accountability does not become Liability merely because it enters LIGA™.
Subject and Authority
A Subject possessing Authority may require identification.
However:
Authority Holder ≠ Liability-Bearing Subject by default.
Authority may later affect relationship, Conditions, or Connection.
Subject and Evidence
Evidence may identify or distinguish a Subject.
However:
Evidence Reference ≠ Subject Identity by itself.
Evidence may be incomplete, ambiguous, outdated, or conflicting.
ADIT® governs evidence.
LSUIM governs the Subject identity derived for Liability purposes.
Subject Identity Conflict
Different records may identify the same apparent participant differently.
Conflict may concern:
name, legal identity, organizational identity, system identity, role, or temporal state.
LSUIM should preserve the conflict rather than force unsupported identity certainty.
Therefore:
Identity Conflict ≠ Authority to Manufacture Subject Identity.
Unknown Subject
A Liability inquiry may indicate that a materially relevant Subject exists without revealing who or what that Subject is.
LSUIM should permit states such as:
Unknown Liability Subject
or:
Unidentified Liability Subject Candidate
where appropriate.
Therefore:
Unidentified Subject ≠ Nonexistent Subject.
Partially Identified Subject
A Subject may be known only partially.
For example:
the relevant organization may be known, but the specific legal entity may remain uncertain.
Or:
the system may be known, but the responsible operator may not yet be identified.
Partial identity should remain explicit.
Therefore:
Partial Identification ≠ Complete Identification.
Subject Identity Uncertainty
Possible states may include:
Identified
Provisionally Identified
Partially Identified
Identity Uncertain
Identity Disputed
Unidentified
Uncertainty should propagate into downstream relationship governance where material.
Duplicate Subject Records
Several records may refer to the same underlying Subject.
Technical duplication must not create multiple methodological Subjects.
Therefore:
Multiple Subject Records ≠ Multiple Liability Subjects by default.
Identity reconciliation should preserve the source records while maintaining the governed Subject identity.
Similar Subjects
Two Subjects may have:
similar names, shared branding, shared ownership, shared addresses, shared personnel, or related system identifiers.
Similarity does not establish identity.
Therefore:
Subject Similarity ≠ Subject Identity.
Subject Separation
A participant previously represented as one Subject may later be found to contain several materially distinct Subjects.
The earlier representation should remain traceable.
Therefore:
Subject Separation ≠ Independent Historical Origin by default.
The resulting Subjects should preserve lineage to the earlier representation.
Subject Consolidation
Several records or candidate identities may later be determined to represent the same Subject.
Consolidation should preserve:
prior references, the reconciliation rationale, the resulting identity, and historical traceability.
Therefore:
Subject Consolidation ≠ Historical Record Erasure.
Temporal Subject Identity
A Subject's relevant identity state may change over time.
Examples include:
organizational restructuring, merger, separation, name change, ownership change, system replacement, or legal transformation.
LSUIM should identify the Subject state relevant to the Liability inquiry.
Therefore:
Current Subject State ≠ Historically Relevant Subject State by default.
Subject Change
A Subject may change without becoming a different Subject.
Examples may include:
name change, role change, location change, representation change, or internal restructuring.
Therefore:
Subject Change ≠ New Subject Identity by default.
The identity question depends on continuity of the underlying governed participant.
Material Subject Transformation
Some changes may create a genuinely different Subject.
Where identity continuity no longer holds, LSUIM should preserve:
the earlier Subject, the transformation, the successor or resulting Subject, and the relevant temporal boundary.
Therefore:
Subject Continuity must not be artificially preserved across genuine identity transformation.
Subject Correction
An earlier Subject identification may be incorrect.
Correction should preserve:
the earlier identification, the corrected identity, the reason for correction, and the relevant supporting governance input.
Therefore:
Subject Correction ≠ Historical Erasure.
Subject Reassessment
New information may require reassessment of whether a participant:
is the same Subject, is materially relevant, should remain within the Liability inquiry, or should be separated into multiple Subjects.
Therefore:
Subject Reassessment ≠ New Liability Origin.
The existing governance history should remain preserved.
Subject Inclusion
A Subject should be included in the identified Subject set where its participation may materially affect subsequent Liability Relationship governance.
Inclusion means:
retain this Subject for relationship analysis.
It does not mean:
this Subject bears Liability.
Therefore:
Subject Inclusion ≠ Liability Inclusion.
Subject Exclusion
A candidate may be excluded where sufficient governance establishes that it is not materially relevant to the Liability Relationship inquiry.
Exclusion should preserve the reason where material.
Therefore:
Subject Exclusion ≠ Proof of No Liability in every possible context.
The exclusion applies to the governed inquiry and current state.
Subject Re-Entry
A previously excluded or unidentified Subject may later become relevant because of new information.
The Subject may re-enter LRS governance.
Therefore:
Subject Re-Entry ≠ New Liability Lifecycle by default.
Re-entry should preserve earlier governance history.
Identification Sufficiency
Subject identification is sufficient when subsequent relationship governance can determine, to the extent materially required:
who or what the Subject is, how it is referenced, what Subject type is involved, why it is relevant, which Object and Basis make it relevant, which temporal state applies, and what identity uncertainty remains.
Identification sufficiency does not require a Liability conclusion.
Handoff to Relationship Identification
Once materially relevant Subjects are sufficiently identified, LSUIM produces:
Identified Liability Subject Set
The handoff should preserve:
Subject Identity, Subject Reference, Subject Type, Subject Relevance, preliminary role references where necessary, Object relevance, Basis relevance, temporal state, identity uncertainty, and identification history.
The next governance question becomes:
What Liability-relevant relationships exist among these Subjects and between the Subjects, Governed Liability Object, and Governed Liability Basis?
That question belongs to LRIM.
Minimum Implementation Framework
A conforming implementation of LSUIM must provide at least the following eight capabilities:
Potential Subject Recognition
Capability to recognize persons, organizations, entities, systems, and other governable participants that may be materially relevant to a Liability inquiry without treating recognition as Liability.
Subject Candidate Identification
Capability to establish identifiable Liability Subject Candidates and preserve the reason each candidate entered governance.
Subject Identity & Reference Governance
Capability to establish stable Subject Identity and reference structures independently of role, relationship, record location, and Liability state.
Subject Type & Relevance Governance
Capability to represent relevant Subject types and determine whether a participant is sufficiently relevant for subsequent Liability Relationship governance.
Multiple, Related & System Subject Governance
Capability to distinguish multiple Subjects, related organizations, natural persons, organizational units, AI systems, autonomous systems, agents, and other relevant participants without inappropriate identity collapse.
Unknown, Partial, Duplicate & Conflicting Identity Governance
Capability to preserve unidentified, partially identified, duplicate, similar, disputed, and conflicting Subject identities without manufacturing certainty.
Subject Change, Correction & Reassessment
Capability to govern identity-relevant change, separation, consolidation, correction, reassessment, exclusion, and re-entry while preserving historical traceability.
Subject Identification Sufficiency
Capability to determine whether the materially relevant Subject set is sufficiently identified for Liability Relationship Identification while preserving unresolved identity uncertainty.
Governance Logic
The canonical LSUIM governance logic is:
Governed Liability Basis + Governed Liability Object
↓
Identify Potential Subject Recognition Triggers
↓
Create Liability Subject Candidates
↓
Establish Subject Identity
↓
Establish Persistent Subject Reference
↓
Determine Subject Type
↓
Assess Liability Relevance
↓
Distinguish Related / Similar / Duplicate Subjects
↓
Identify Unknown or Partially Identified Subjects
↓
Identify Relevant Temporal Subject State
↓
Record Identity Uncertainty or Conflict
↓
Include / Exclude / Preserve Candidate State
↓
Assess Subject Identification Sufficiency
↓
Identified Liability Subject Set
↓
Handoff to Liability Relationship Identification
Governance Outputs
LSUIM may produce:
Liability Subject Candidate
Liability Subject Identity
Persistent Subject Reference
Liability Subject Type
Subject Relevance State
Subject Inclusion State
Subject Exclusion State
Natural Person Subject Record
Organizational Subject Record
Legal Entity Subject Record
Organizational Unit Subject Record
System Subject Record
AI System Subject Record
Autonomous System Subject Record
Agent Subject Record
Unknown Subject Record
Partial Subject Identity Record
Subject Identity Uncertainty State
Subject Identity Conflict State
Duplicate Subject Reconciliation
Subject Separation Record
Subject Consolidation Record
Temporal Subject State
Subject Correction Record
Subject Reassessment Record
Subject Re-Entry Record
Subject Identification Sufficiency State
The principal output is:
Identified Liability Subject Set
Critical Distinctions
LSUIM preserves the following distinctions:
Liability Subject ≠ Liable Subject Potential Subject ≠ Identified Liability Subject Recognition Trigger ≠ Subject Qualification as Liable Subject Identification ≠ Liability Determination Subject Identity ≠ Subject Role Subject Reference Change ≠ Subject Identity Change by default Subject Type ≠ Liability State Identified Natural Person ≠ Personally Liable Person Organizational Relationship ≠ Subject Identity Merger Corporate Group ≠ Individual Legal Entity Brand Identity ≠ Legal Entity Identity by default Operationally Relevant Unit ≠ Independent Liability-Bearing Entity by default System Participation ≠ Legal Personhood System Identification ≠ System Liability AI Subject Identification ≠ AI Legal Liability Autonomous System ≠ Operator Autonomous System ≠ Provider Autonomous System ≠ Owner Agent ≠ Principal Proximity ≠ Liability Relevance by default Liability Relevance ≠ Liability Visibility ≠ Liability Relevance Operational Actor ≠ Liability-Bearing Subject by default Harm-Producing Actor ≠ Liability-Bearing Party by default Owner ≠ Liable Subject by default Controller ≠ Liable Subject by default Operator ≠ Liable Subject by default Provider ≠ Liability-Bearing Party by default Manufacturer ≠ Liable Subject by default Contractor ≠ Subcontractor ≠ Principal Principal Identity ≠ Agent Identity Insurer ≠ Primary Liability-Bearing Subject by default Paying Party ≠ Liability-Bearing Party by default Multiple Subjects ≠ One Collective Liability Subject by default Collective Representation ≠ Identity Merger Organizational Affiliation ≠ Subject Identity Subject Identification ≠ Complete Role Determination Role Reference ≠ Liability Relationship Identification Object Relevance ≠ Established Subject–Object Relationship Basis Reference to Subject ≠ Liability Attachment Responsible Subject ≠ Liable Subject Accountable Subject ≠ Liable Subject Authority Holder ≠ Liability-Bearing Subject by default Evidence Reference ≠ Subject Identity by itself Identity Conflict ≠ Authority to Manufacture Subject Identity Unidentified Subject ≠ Nonexistent Subject Partial Identification ≠ Complete Identification Multiple Subject Records ≠ Multiple Liability Subjects by default Subject Similarity ≠ Subject Identity Subject Separation ≠ Independent Historical Origin by default Subject Consolidation ≠ Historical Record Erasure Current Subject State ≠ Historically Relevant Subject State by default Subject Change ≠ New Subject Identity by default Subject Correction ≠ Historical Erasure Subject Reassessment ≠ New Liability Origin Subject Inclusion ≠ Liability Inclusion Subject Exclusion ≠ Proof of No Liability in every possible context Subject Re-Entry ≠ New Liability Lifecycle by default
Cross-Architecture Boundary
LSUIM may receive governed identity and participation inputs from other OOF® architectures.
OBIDENITY® may provide Origin, Identity, Ownership, Authority, Permission, Provenance, Transfer, and Continuity information.
GOA™ may provide Authority, Scope, and Delegation structures.
ORA™ may identify actual operational participants.
AGA™ may provide Responsibility, Accountability, Authority, and Attribution states.
HAGA™ may identify Harm-relevant actors without determining Liability.
ADIT® may provide evidence supporting Subject identification.
VALIDOS™ may validate Subject-relevant information.
AIG® may provide AI-system governance identities and behavioral context.
ASGA™ may provide autonomous-system Identity, Authority, Permission, Delegation, and operational participation.
Other OOF® architectures may provide governed participants or states relevant to Subject identification.
The governing principle is:
Identification of a Subject in another governance domain may make that Subject relevant to LIGA™ without making the Subject liable or transferring governance ownership of its original identity domain to LIGA™.
Canonical Boundary
LSUIM begins when a:
Governed Liability Basis
and associated Governed Liability Object indicate that one or more participants may require explicit identification for Liability Relationship governance.
LSUIM governs:
Potential Subject Recognition, Subject Candidate Identification, Subject Identity, Persistent Subject Reference, Subject Type, Subject Relevance, Human Subjects, Organizational Subjects, Legal Entities, Organizational Units, System Subjects, AI Systems, Autonomous Systems, Agents, Multiple Subjects, Related Subjects, Unknown Subjects, Partially Identified Subjects, Duplicate Subjects, Subject Identity Conflict, Temporal Subject State, Subject Change, Subject Separation, Subject Consolidation, Subject Correction, Subject Reassessment, Subject Inclusion, Subject Exclusion, Subject Re-Entry, and Identification Sufficiency.
LSUIM does not determine:
complete Subject Roles, Liability Relationships, Relationship Mapping, Liability Conditions, Condition Satisfaction, Liability-Relevant Connection, Liability Attachment, Liability Determination, Liability Scope, Liability Allocation, Liability Transfer, Recourse, Resolution, Discharge, or Finality.
LSUIM ends when an:
Identified Liability Subject Set
is sufficiently established for Liability Relationship Identification.
Use Case 1 — AI-Enabled Operational Matter
A Liability inquiry concerns an AI-enabled operational process involving a technology provider, deploying organization, operator, customer, and AI system.
LSUIM identifies each materially relevant participant separately.
It does not collapse the AI provider into the deployer, the deployer into the operator, or the AI system into the organization operating it.
Where the specific operator remains unknown, LSUIM preserves an Unidentified Liability Subject rather than inventing an identity.
The resulting Subject set can then proceed to relationship identification without assuming that any identified Subject bears Liability.
Use Case 2 — Industrial Equipment Matter
An industrial equipment matter involves an equipment owner, operating company, maintenance provider, subcontractor, operator, manufacturer, and insurer.
LSUIM identifies each materially relevant Subject independently.
Shared branding, contractual proximity, physical presence, ownership, or payment involvement does not collapse their identities or establish Liability.
The operator who was physically present at the relevant moment remains one Subject among several potentially relevant participants.
The resulting Identified Liability Subject Set provides LRIM with the governed participants required to identify the actual Liability-relevant relationships.
Canonical Closing Statement
Liability governance should not begin by selecting the most visible actor and treating that actor as the liable party.
It should first determine which persons, organizations, entities, and systems actually belong within the Liability inquiry and preserve their identities without collapsing role, responsibility, proximity, Harm involvement, or operational participation into Liability.
Identification establishes who must be examined. It does not establish who must bear Liability.
Identify the Subjects before governing the relationships between them.