LDIM — Liability Determination Input Module
LDIM — Liability Determination Input Module
Architecture: LIGA™ — Liability Governance Architecture
Parent Standard: Liability Determination Standard (LDS)
Category: Governance & Enforcement
Subcategory: Liability Governance
Type: Core Module
Governed Space: Liability Determination Inputs
Module ID: LIGA-LDS-LDIM-001
Origin ID: OOF.CM.LIGA.07.01.01
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 23 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 Determination Input Module (LDIM) governs how the materially relevant inputs required for Liability Determination are identified, selected, associated, bounded, structured, classified, synchronized, and preserved before Determination Evaluation begins.
LDIM transforms the complete upstream Liability governance structure into an explicit Governed Liability Determination Input Set for a defined Determination Object and Determination Scope.
It ensures that Liability Determination does not begin from an undefined mixture of allegations, facts, evidence, Harm, Claims, relationships, assumptions, operational events, or conclusions.
LDIM does not evaluate whether Liability attaches.
It governs the transition:
Governed Liability Connection Structure → Determination Object & Scope → Input Identification → Input Association → Input State & Sufficiency Governance → Governed Liability Determination Input Set Its foundational distinction is:
Determination Input ≠ Liability Determination.
Operational Role
The operational role of LDIM is:
to establish exactly what governed information may enter Liability Determination, what each input represents, where it originates, which Determination it belongs to, what state it possesses, and whether the resulting input structure is sufficiently complete for Determination Evaluation.
LDIM asks:
What governed inputs must be evaluated to determine whether Liability attaches within this specific Liability structure?
It does not ask:
Does Liability attach?
That belongs downstream.
Position in the Parent Standard Flow
The internal LDS progression is:
Liability Determination Input → Liability Determination Evaluation → Liability Determination & Attachment → Liability Determination Rationale → Liability Determination Versioning LDIM governs:
Liability Determination Input
Its principal immediate input is:
Governed Liability Connection Structure
Its principal output is:
Governed Liability Determination Input Set
Its canonical handoff is:
Governed Liability Determination Input Set → Liability Determination Evaluation
Central Operational Question
What governed inputs are materially necessary, relevant, sufficiently bounded, and appropriately associated for the defined Liability Determination to proceed to evaluation?
Governed Space
LDIM governs:
Determination Object Formation, Determination Scope Formation, Determination Input Identification, Input Identity, Input Origin, Input Ownership, Input Classification, Input Association, Input Relevance, Input Applicability, Input State, Input Temporal Alignment, Input Scope, Input Boundary, Input Dependency, Input Conflict, Input Uncertainty, Input Assumption, Input Duplication, Input Version, Input Completeness, Input Sufficiency, Input Change, Input Correction, Input Reassessment, and Determination Input Handoff.
Determination Object
Before inputs can be formed, LDIM should establish what Liability Determination is being prepared.
The Determination Object may identify:
the relevant Liability Subject, Liability Relationship, Governed Liability Object, Liability Basis, Connection, and defined Liability inquiry.
Therefore:
Liability Matter ≠ Determination Object by default.
Determination Object Identity
Each materially distinct Determination Object should possess a sufficiently stable identity.
This allows inputs to remain associated with the correct Determination across:
evaluation, Attachment, rationale, versioning, Scope & Allocation, and later lifecycle stages.
Determination Object and Liability Object
The Determination Object should not be confused with the Governed Liability Object established by LOS.
The Liability Object is the governed matter in relation to which Liability is considered.
The Determination Object identifies the specific Liability determination being prepared.
Therefore:
Liability Object ≠ Liability Determination Object.
Determination Scope
LDIM should explicitly define the boundary of the Determination inquiry.
Scope may identify:
Subject, Relationship, Object, Basis, Condition set, Connection, time period, or another materially relevant boundary.
Determination Scope and Liability Scope
The scope of the inquiry is not the substantive extent of Liability.
Therefore:
Determination Scope ≠ Liability Scope.
Liability Scope belongs to LSAS.
Scope Integrity
The Determination Scope should be sufficiently narrow to preserve methodological precision and sufficiently broad to contain the materially necessary inputs.
Therefore:
Broad Matter Description ≠ Governed Determination Scope.
Multi-Subject Scope
Where several Subjects are involved, LDIM should determine whether:
one shared Determination Input Set, separate Subject-specific sets, or a combined structure with Subject-specific partitions is methodologically appropriate.
Subject-specific distinctions should remain visible.
Multi-Relationship Scope
A Subject may participate in several Liability Relationships.
Inputs relevant to one Relationship should not automatically be transferred to another.
Therefore:
Input Relevant to Relationship A ≠ Input Relevant to Relationship B by default.
Multi-Object Scope
Where several Liability Objects exist, the Determination Input structure should preserve Object-specific relevance.
Therefore:
Input Relevant to Object A ≠ Input Relevant to Object B by default.
Multi-Basis Scope
The same matter may involve several Liability Bases.
LDIM should preserve Basis-specific input associations.
Therefore:
Input Relevant under Basis A ≠ Input Relevant under Basis B by default.
Determination Input
A Determination Input is a governed object, state, relationship, structure, reference, or other materially relevant element admitted into the defined Liability Determination process.
An input should possess sufficient identity and context to prevent ambiguous use.
Input Identity
Each material Determination Input should be identifiable.
Input identity may reference an upstream governed object rather than create a new object.
Therefore:
Input Reference ≠ New Governance Object by default.
Input Origin
LDIM should preserve where each input originated.
Origin may include:
a LIGA™ Parent Standard, another OOF® architecture, an external authority, a governed evidence system, a validated source, or another explicitly identified origin.
Input Origin and Ownership
Input origin does not transfer governance ownership to LDS.
Therefore:
Determination Use ≠ Governance Ownership Transfer.
The originating governance domain retains ownership of its governed object.
Upstream LIGA™ Inputs
LDIM may reference the complete upstream LIGA™ structure, including:
Governed Liability Context, Governed Liability Object, Governed Liability Basis, Governed Liability Relationship Structure, Governed Liability Condition Structure, and Governed Liability Connection Structure.
These should remain distinguishable.
Liability Context Input
Liability Context may provide environmental, temporal, institutional, operational, technical, contractual, or other relevant context.
Context does not establish Liability.
Therefore:
Context Input ≠ Determination Outcome.
Liability Object Input
The Governed Liability Object establishes the matter in relation to which Liability is being determined.
The Object should remain stable enough to prevent Determination drift.
Liability Basis Input
The Governed Liability Basis establishes why Liability may potentially exist.
LDIM should identify the specific Basis applicable to the Determination.
Therefore:
Liability Basis Input ≠ Liability Attachment.
Liability Relationship Input
The Governed Liability Relationship Structure identifies relevant Subjects and their Liability-relevant Relationships.
LDIM should preserve the specific Relationship relevant to the Determination.
Therefore:
Liability Relationship Input ≠ Liability Determination.
Liability Condition Input
The Governed Liability Condition Structure identifies applicable Conditions, Requirements, States, Exceptions, Exclusions, and continuity information.
LDIM should preserve the Condition state relevant to the Determination lifecycle moment.
Liability Connection Input
The Governed Liability Connection Structure is the principal immediate upstream input.
It may include:
Connection identities, Relationships, Chains, Networks, Qualification States, evidence associations, uncertainties, and historical information.
Therefore:
Governed Liability Connection Structure ≠ Liability Determination.
Operational Reality Input
ORA™ may provide governed Operational Reality states.
LDIM may admit those states where materially relevant.
Therefore:
Operational Reality Input ≠ Liability Determination.
Harm Input
HAGA™ may provide governed Harm states.
Where Harm is relevant to the applicable Liability Basis, LDIM may include those states.
Therefore:
Harm Input ≠ Liability.
Responsibility Input
AGA™ may provide governed Responsibility states.
Responsibility may be relevant to some Liability structures.
Therefore:
Responsibility Input ≠ Liability Determination.
Accountability Input
AGA™ may provide governed Accountability or Attribution states.
These may be relevant inputs without becoming Liability.
Therefore:
Accountability Input ≠ Liability.
Authority Input
GOA™ or another appropriate governance structure may provide Authority, Delegation, Scope, or related states.
Authority may be materially relevant without independently establishing Liability.
Identity Input
OBIDENITY® may provide governed Identity, Ownership, Authority, Permission, Provenance, Transfer, or Continuity states.
These remain external governed objects used as Determination inputs where relevant.
AI and Autonomous-System Input
AIG® and ASGA™ may provide governed states concerning:
behavior, authority, permission, execution, override, escalation, memory, or autonomous operation.
Their relevance should be explicitly associated with the Determination.
Prediction Input
PGA™ may provide governed Prediction states where predictions, reliance, forecast outputs, or prediction governance are materially relevant.
Therefore:
Prediction Failure Input ≠ Liability Determination.
Simulation Input
SIMULOS® may provide governed Simulation outputs.
Simulation may inform the Determination without becoming operational reality.
Therefore:
Simulation Output ≠ Operational Reality ≠ Liability Determination.
Validation Input
VALIDOS™ may provide governed Validation states.
Validation establishes the state of the validated object within its own governance domain.
Therefore:
Validation Input ≠ Liability Determination.
Evidence Reference Input
ADIT® may provide governed evidence and auditability structures.
LDIM may reference those structures.
Evidence should remain distinct from the substantive state it supports.
Therefore:
Evidence Input ≠ Liability Determination.
External Authority Input
A competent external authority may provide:
decision, finding, classification, status, or another relevant governed output.
LDIM should preserve:
authority identity, scope, time, and relevance.
Claim-Related Input
A Claim may produce information relevant to Determination.
However, the Claim itself remains separate from Liability.
Therefore:
Claim Input ≠ Liability.
Input Classification
LDIM should classify inputs where classification materially improves Determination integrity.
Potential classes may include:
Foundational, Contextual, Structural, Conditional, Connective, Operational, Harm-related, Accountability-related, Identity-related, Evidentiary, Validated, External Authority, Assumptive, or another governed class.
Foundational Input
A Foundational Input is necessary to define the Determination itself.
Examples may include:
Determination Object, applicable Liability Basis, Subject, and relevant Liability Relationship.
Structural Input
Structural Inputs describe the governed architecture of the Liability inquiry.
Examples may include:
Relationship Structure, Condition Structure, and Connection Structure.
Contextual Input
Contextual Inputs inform interpretation without independently establishing Liability.
Therefore:
Contextual Importance ≠ Determinative Effect.
Conditional Input
Conditional Inputs represent governed Liability Conditions and their relevant states.
Their effect should remain Basis-specific.
Connective Input
Connective Inputs represent the governed Liability Connection structure required for Determination.
They should preserve Qualification and evidentiary association states where relevant.
External Input
An External Input originates outside LIGA™.
Its admission should preserve its original governance identity and boundary.
Therefore:
External Input Admission ≠ External Governance Absorption.
Derived Input
A Derived Input results from a governed transformation of one or more other inputs.
Its derivation should remain traceable.
Therefore:
Derived Input ≠ Independent Source by default.
Input Association
Each input should be associated with the Determination element to which it is materially relevant.
Associations may include:
Subject, Relationship, Object, Basis, Condition, Connection, time, or Determination criterion.
Subject Association
An input relevant to Subject A should not automatically be applied to Subject B.
Therefore:
Shared Matter ≠ Shared Subject Input Relevance.
Relationship Association
Inputs should preserve the Liability Relationship to which they apply.
This is particularly important where one Subject participates in multiple Relationships.
Basis Association
Input relevance may change depending upon the Liability Basis.
Therefore:
General Relevance ≠ Basis-Specific Relevance.
Condition Association
An input may be relevant to one Condition but not another.
Condition association should remain explicit where materially necessary.
Connection Association
Inputs may relate to:
a Connection, Connection Relationship, Connection Chain, Connection path, or specific Connection state.
Association granularity should remain sufficient for Determination.
Input Relevance
An input is relevant where it materially affects the defined Determination inquiry.
Relevance should be governed rather than presumed.
Therefore:
Available Input ≠ Relevant Input.
Input Materiality
An input is material where its inclusion, exclusion, correction, or changed state could affect the Determination process or outcome.
Materiality should remain explicit where necessary.
Irrelevant Input
An available object may be excluded from the active Determination Input Set where it is not materially relevant.
Its existence should not be confused with relevant Determination evidence or input.
Input Applicability
A relevant input may still be inapplicable to the particular:
Basis, Subject, Relationship, Object, Condition, Connection, or lifecycle moment.
Therefore:
Relevance ≠ Applicability.
Input State
Each material input should preserve its governed state where applicable.
Potential states may include:
Current, Historical, Active, Inactive, Satisfied, Failed, Unknown, Uncertain, Disputed, Pending, Superseded, Corrected, or another domain-specific state.
Current Input
A Current Input represents the presently applicable governed state.
Current does not mean historically complete.
Therefore:
Current Input ≠ Complete Input History.
Historical Input
A Historical Input may remain relevant even when it is no longer current.
Historical states should not be discarded merely because a later state exists.
Superseded Input
A superseded input may no longer control the current Determination but may remain necessary for historical reconstruction.
Therefore:
Superseded Input ≠ Deleted Input.
Corrected Input
A corrected input should preserve both:
the earlier representation, and the corrected representation where historical integrity requires it.
Therefore:
Input Correction ≠ Historical Erasure.
Pending Input
An input may remain pending where an upstream process has not completed.
Therefore:
Pending Input ≠ Missing Input.
Unknown Input
An input state may be unknown where the relevant information cannot presently be established.
Therefore:
Unknown Input ≠ Negative Input.
Uncertain Input
An input may be represented while material uncertainty remains.
Therefore:
Uncertain Input ≠ Unknown Input.
Disputed Input
An input may remain disputed where competing governed representations exist.
Therefore:
Disputed Input ≠ Invalid Input by default.
Input Temporal Alignment
LDIM should preserve the time to which each input applies.
Liability Determination may require reconstructing the input structure at a specific lifecycle moment.
Event Time
The time of an underlying event should remain distinguishable from:
input creation time, input discovery time, input validation time, and Determination time.
Knowledge Time
The time at which an input became known may be materially relevant.
Therefore:
Input Reality at T1 ≠ Knowledge of Input at T1 by default.
Later Knowledge
A later-discovered input should not be represented as though it had necessarily been available earlier.
Therefore:
Later Knowledge ≠ Earlier Knowledge.
Temporal Mismatch
Inputs representing different lifecycle moments should not be combined as though they described one simultaneous state unless the methodology permits.
Therefore:
Current Input + Historical Input ≠ Single-Time State by default.
Input Boundary
Each input should retain a sufficient boundary defining what it represents and what it does not represent.
Boundary integrity prevents overextension of input meaning.
Input Scope
Input Scope should identify the portion of the Determination to which the input applies.
Therefore:
Input Scope ≠ Determination Scope by default.
One input may cover only part of the inquiry.
Input Dependency
An input may depend upon another governed input.
Dependency should remain explicit where it affects Determination integrity.
Therefore:
Dependent Input ≠ Independent Input.
Derived Input Dependency
Where an input derives from another object, LDIM should preserve that dependency.
Multiple derived outputs from one source should not automatically be treated as independent inputs.
Input Duplication
Multiple records may represent the same underlying input.
Therefore:
Multiple Input Records ≠ Multiple Independent Inputs.
Duplicate consolidation should preserve provenance.
Input Corroboration
Independent inputs may corroborate the same relevant state.
Corroboration should remain distinct from duplication.
Therefore:
Corroboration ≠ Duplication.
Input Conflict
Two or more inputs may materially conflict.
The conflict should remain explicit.
Therefore:
Input Conflict ≠ Authority to Select Convenient Input.
Conflict Scope
LDIM should identify what the input conflict concerns.
Examples include:
Subject identity, Object state, Condition state, Connection, time, authority, or another material characteristic.
Conflict Preservation
LDIM does not resolve substantive conflicts that belong to upstream governance.
It should preserve and route them appropriately.
Input Assumption
An assumption may be admitted where methodology permits and where its status is explicit.
Therefore:
Assumed Input ≠ Established Input.
Hypothetical Input
A hypothetical input may be used for conditional or scenario evaluation.
It must remain clearly separated from established governed inputs.
Therefore:
Hypothetical Input ≠ Historical Fact.
Inferred Input
An input may be inferred where a governed methodology permits inference.
Its derivation and uncertainty should remain traceable.
Therefore:
Inferred Input ≠ Directly Established Input.
Input Completeness
Input Completeness asks whether the defined Determination Input Set contains the materially necessary input categories and objects for the defined Determination.
It does not require all conceivable information.
Therefore:
Input Completeness ≠ Information Exhaustiveness.
Input Sufficiency
Input Sufficiency asks whether the available governed input structure is sufficient to proceed to Determination Evaluation.
Completeness and sufficiency are related but distinct.
A set may be structurally complete while containing unresolved material states.
Complete but Insufficient Input Set
A Determination Input Set may contain all required categories but remain insufficient because a material input is:
Unknown, Uncertain, Disputed, Pending, or otherwise unusable for the required evaluation.
Therefore:
Input Completeness ≠ Input Sufficiency.
Incomplete but Evaluatable Input Set
A methodology may permit evaluation despite non-material missing information.
The missing information and rationale should remain explicit.
Therefore:
Missing Non-Material Input ≠ Automatic Evaluation Failure.
Material Missing Input
A material missing input should block or limit Determination Evaluation where the applicable methodology requires that input.
LDIM should not manufacture a replacement.
Input Sufficiency State
LDIM may represent the Determination Input Set as:
Sufficient
Conditionally Sufficient
Insufficient
Pending
Unknown
Uncertain
Disputed
where appropriate.
Sufficient
Sufficient means the input structure satisfies the applicable requirements for Determination Evaluation.
It does not mean Liability attaches.
Therefore:
Sufficient Inputs ≠ Attached Liability.
Conditionally Sufficient
Conditionally Sufficient means evaluation may proceed subject to explicit limitations, assumptions, or unresolved nonblocking states.
Those conditions should remain visible downstream.
Insufficient
Insufficient means the input structure does not presently support reliable Determination Evaluation within the defined scope.
Therefore:
Insufficient Inputs ≠ No Liability.
Pending Sufficiency
Pending means sufficiency cannot yet be finalized because a material input or upstream process remains unresolved.
Input Quality
Input quality may affect sufficiency.
However, LDIM should not duplicate the validation, evidence, or domain-specific quality governance owned elsewhere.
It should reference those governed states.
No Evidence-Volume Shortcut
A large amount of evidence does not compensate automatically for a missing structural input.
Therefore:
Evidence Volume ≠ Determination Input Sufficiency.
No Harm Shortcut
Established Harm does not make the Determination Input Set sufficient where other required Liability structures are absent.
Therefore:
Harm ≠ Complete Determination Input Set.
No Causation Shortcut
Established operational causation does not replace:
Basis, Conditions, Relationships, or other required Liability inputs.
Therefore:
Operational Causation ≠ Complete Determination Input Set.
No Claim Shortcut
A detailed Claim does not replace the governed Liability input structure.
Therefore:
Claim Detail ≠ Determination Input Sufficiency.
No Authority Shortcut
A statement from an authoritative Subject may be an important input.
Its authority does not automatically make the complete input structure sufficient.
Therefore:
Authority of Source ≠ Determination Input Sufficiency.
No Narrative Shortcut
A coherent narrative does not substitute for explicit governed inputs.
Therefore:
Narrative Coherence ≠ Determination Input Sufficiency.
Input Change
The Determination Input Set may change when:
new information appears, upstream governance changes, an input is corrected, a state changes, or a previously unknown input becomes available.
Change should remain traceable.
Input Correction
A Determination Input association or representation may be corrected.
The correction should preserve:
the earlier state, corrected state, reason, time, and provenance.
Therefore:
Input Correction ≠ Historical Rewrite.
Input Reassessment
A previously admitted or excluded input may require reassessment.
Reassessment should preserve the earlier governance state.
Input Versioning
Material changes to the Determination Input Set may require a new version.
Therefore:
New Input Set Version ≠ New Liability Origin by default.
Input Re-Entry
Later LDS stages may reveal that the input structure is defective or incomplete.
LDIM should support targeted re-entry.
Therefore:
Input Re-Entry ≠ New Liability Origin by default.
Upstream Re-Entry
Where LDIM identifies an upstream governance defect, it should route the matter to the earliest materially affected governance space.
Examples:
Connection defect → LCNS Condition defect → LCOS Relationship defect → LRS Basis defect → LBS Object defect → LOS Context defect → LCS LDIM should not repair those structures by silently modifying their outputs.
Historical Input Integrity
The system should preserve the Determination Input Set as it existed at materially relevant lifecycle moments.
Therefore:
Current Determination Input Set ≠ Complete Determination Input History.
Input Reality, Knowledge, and Record
LDIM should distinguish where relevant:
Input Reality
Input Knowledge
Input Record
Input Admission into Determination An input may exist before it becomes known.
It may become known before it is admitted.
Therefore:
Input Reality ≠ Input Knowledge ≠ Input Admission by default.
Input Admission Record
Material input admission should remain traceable.
The record may identify:
input identity, origin, association, state, scope, time, and reason for admission.
Input Exclusion Record
Where a potentially relevant input is excluded, the reason should remain traceable where material.
Therefore:
Input Exclusion ≠ Input Nonexistence.
Determination Input Set
The principal output of LDIM is:
Governed Liability Determination Input Set
It may contain:
Determination Object, Determination Scope, Governed Liability Context references, Governed Liability Object, Governed Liability Basis, Governed Liability Relationship Structure, Governed Liability Condition Structure, Governed Liability Connection Structure, external governed inputs, input associations, input states, input conflicts, input uncertainties, input assumptions, temporal states, dependency records, and Input Sufficiency State.
Meaning of the Output
A Governed Liability Determination Input Set means that the inputs required for Liability Determination have been made explicit, bounded, associated, traceable, and assessed for sufficiency.
It does not mean Liability has been evaluated.
Therefore:
Governed Liability Determination Input Set ≠ Liability Determination Evaluation.
Handoff to Liability Determination Evaluation
LDIM hands the:
Governed Liability Determination Input Set
to:
LDEM — Liability Determination Evaluation Module
The next governance question becomes:
What does the governed Determination Input Set establish when evaluated under the applicable Liability Basis, Conditions, Connection structure, and Determination criteria?
LDIM does not answer that question.
Minimum Implementation Framework
A conforming implementation of LDIM must provide exactly the following eight capabilities:
Determination Object & Scope Formation
Capability to establish the specific Determination Object and bounded Determination Scope before substantive Liability evaluation begins.
Input Identification, Identity & Origin Governance
Capability to identify materially relevant Determination Inputs and preserve their identities, origins, governance ownership, and authoritative references.
Input Classification & Association Governance
Capability to classify inputs and associate them explicitly with the relevant Subject, Relationship, Object, Basis, Condition, Connection, time, or Determination criterion.
Input State, Scope & Temporal Governance
Capability to preserve current, historical, pending, unknown, uncertain, disputed, corrected, superseded, and other relevant input states together with their applicable scope and time.
Input Dependency, Duplication, Conflict & Assumption Governance
Capability to distinguish independent, dependent, duplicated, corroborating, conflicting, assumed, hypothetical, inferred, and derived inputs without manufacturing certainty.
Input Completeness & Sufficiency Governance
Capability to assess whether the Determination Input Set is complete and sufficiently governed for Determination Evaluation while distinguishing completeness from exhaustiveness and sufficiency from Liability Attachment.
Input Change, Correction, Versioning & Re-Entry
Capability to preserve input changes, corrections, reassessments, versions, historical states, and targeted lifecycle reentry without historical erasure.
Determination Input Handoff
Capability to produce a Governed Liability Determination Input Set sufficiently explicit, bounded, traceable, and structured for handoff to Liability Determination Evaluation without prematurely evaluating Liability.
Governance Logic
The canonical LDIM governance logic is:
Governed Liability Connection Structure
↓
Define Determination Object
↓
Define Determination Scope
↓
Identify Applicable Liability Basis
↓
Identify Relevant Liability Subjects & Relationships
↓
Reference Governed Liability Object
↓
Reference Governed Liability Condition Structure
↓
Reference Governed Liability Connection Structure
↓
Identify Material External Governed Inputs
↓
Establish Input Identity & Origin
↓
Classify Inputs
↓
Associate Inputs with Subject / Relationship / Object / Basis / Condition / Connection
↓
Preserve Input State & Temporal Relevance
↓
Identify Dependency / Duplication / Corroboration
↓
Identify Conflict / Uncertainty / Assumptions
↓
Assess Input Completeness
↓
Assess Input Sufficiency
↓
Preserve Admission / Exclusion / Change History
↓
Governed Liability Determination Input Set
↓
Handoff to Liability Determination Evaluation
Governance Outputs
LDIM may produce:
Liability Determination Object
Liability Determination Scope
Determination Input Identity Record
Determination Input Origin Record
Determination Input Classification
Determination Input Association
Subject-Specific Input Set
Relationship-Specific Input Set
Object-Specific Input Set
Basis-Specific Input Set
Condition-Specific Input Set
Connection-Specific Input Set
External Governed Input Reference
Current Input State
Historical Input State
Pending Input State
Unknown Input State
Uncertain Input State
Disputed Input State
Input Dependency Record
Input Duplication Record
Input Corroboration Record
Input Conflict Record
Input Assumption Record
Input Temporal Record
Input Admission Record
Input Exclusion Record
Input Completeness State
Input Sufficiency State
Input Correction Record
Input Reassessment Record
Input Version Record
Historical Input Set Record
The principal output is:
Governed Liability Determination Input Set
Critical Distinctions
LDIM preserves the following distinctions:
Determination Input ≠ Liability Determination Liability Matter ≠ Determination Object by default Liability Object ≠ Liability Determination Object Determination Scope ≠ Liability Scope Input Relevant to Relationship A ≠ Input Relevant to Relationship B by default Input Relevant to Object A ≠ Input Relevant to Object B by default Input Relevant under Basis A ≠ Input Relevant under Basis B by default Input Reference ≠ New Governance Object by default Determination Use ≠ Governance Ownership Transfer Context Input ≠ Determination Outcome Liability Basis Input ≠ Liability Attachment Liability Relationship Input ≠ Liability Determination Governed Liability Connection Structure ≠ Liability Determination Operational Reality Input ≠ Liability Determination Harm Input ≠ Liability Responsibility Input ≠ Liability Determination Accountability Input ≠ Liability Prediction Failure Input ≠ Liability Determination Simulation Output ≠ Operational Reality ≠ Liability Determination Validation Input ≠ Liability Determination Evidence Input ≠ Liability Determination Claim Input ≠ Liability Contextual Importance ≠ Determinative Effect External Input Admission ≠ External Governance Absorption Derived Input ≠ Independent Source by default Shared Matter ≠ Shared Subject Input Relevance General Relevance ≠ Basis-Specific Relevance Available Input ≠ Relevant Input Relevance ≠ Applicability Current Input ≠ Complete Input History Superseded Input ≠ Deleted Input Input Correction ≠ Historical Erasure Pending Input ≠ Missing Input Unknown Input ≠ Negative Input Uncertain Input ≠ Unknown Input Disputed Input ≠ Invalid Input by default Input Reality at T1 ≠ Knowledge of Input at T1 by default Later Knowledge ≠ Earlier Knowledge Current Input + Historical Input ≠ Single-Time State by default Input Scope ≠ Determination Scope by default Dependent Input ≠ Independent Input Multiple Input Records ≠ Multiple Independent Inputs Corroboration ≠ Duplication Input Conflict ≠ Authority to Select Convenient Input Assumed Input ≠ Established Input Hypothetical Input ≠ Historical Fact Inferred Input ≠ Directly Established Input Input Completeness ≠ Information Exhaustiveness Input Completeness ≠ Input Sufficiency Missing Non-Material Input ≠ Automatic Evaluation Failure Sufficient Inputs ≠ Attached Liability Insufficient Inputs ≠ No Liability Evidence Volume ≠ Determination Input Sufficiency Harm ≠ Complete Determination Input Set Operational Causation ≠ Complete Determination Input Set Claim Detail ≠ Determination Input Sufficiency Authority of Source ≠ Determination Input Sufficiency Narrative Coherence ≠ Determination Input Sufficiency Input Correction ≠ Historical Rewrite New Input Set Version ≠ New Liability Origin by default Input Re-Entry ≠ New Liability Origin by default Current Determination Input Set ≠ Complete Determination Input History Input Reality ≠ Input Knowledge ≠ Input Admission by default Input Exclusion ≠ Input Nonexistence Governed Liability Determination Input Set ≠ Liability Determination Evaluation
Cross-Architecture Boundary
LDIM may receive governed inputs from other OOF® architectures.
ORA™ governs Operational Reality.
HAGA™ governs Harm.
AGA™ governs Responsibility, Accountability, Authority, and Attribution.
GOA™ governs governance authority, scope, delegation, and related structures.
ADIT® governs evidence and auditability.
VALIDOS™ governs validation.
OBIDENITY® governs Identity, Ownership, Authority, Permission, Provenance, Transfer, and Continuity.
AIG® and ASGA™ govern AI and autonomous-system governance states.
PGA™ governs Prediction.
SIMULOS® governs Simulation.
LDIM does not re-govern those domains.
It determines only whether and how their governed outputs become materially relevant inputs to Liability Determination.
The canonical interoperability principle is:
A governed object may become a Liability Determination Input without becoming a LIGA™-owned object and without changing the governance domain that established it.
Canonical Boundary
LDIM begins with a sufficiently governed:
Governed Liability Connection Structure
and asks:
What governed inputs are required for this specific Liability Determination to proceed to evaluation?
LDIM governs:
Determination Object, Determination Scope, Input Identification, Input Identity, Input Origin, Input Classification, Input Association, Input Relevance, Input Applicability, Input State, Input Temporal Alignment, Input Scope, Input Boundary, Input Dependency, Input Duplication, Input Corroboration, Input Conflict, Input Uncertainty, Input Assumption, Input Completeness, Input Sufficiency, Input Admission, Input Exclusion, Input Change, Input Correction, Input Reassessment, Input Versioning, Historical Integrity, and Determination Input Handoff.
LDIM does not determine:
whether Liability attaches, the substantive result of Determination Evaluation, Liability Scope, Liability Allocation, Liability State, Liability Transfer, Recourse, Resolution, Discharge, or Finality.
LDIM ends when a:
Governed Liability Determination Input Set
is sufficiently explicit and governed for Liability Determination Evaluation.
Use Case 1 — Autonomous System Determination Inputs
An autonomous industrial system performs an action followed by equipment damage.
Earlier LIGA™ governance has established a Governed Liability Connection Structure involving:
the operator, the autonomous system, an execution decision, machine action, operational event, equipment state, and relevant Conditions.
LDIM forms the Determination Object and identifies the applicable Liability Basis.
It then structures the relevant Determination Inputs, including:
the Governed Liability Object, operator and system Relationships, Condition states, qualified Connection structure, relevant autonomous-system authority and execution states, Operational Reality, and governed evidence references.
A simulation output may also exist but remains explicitly classified as Simulation rather than Operational Reality.
LDIM assesses whether this input structure is sufficient for Determination Evaluation.
It does not determine whether the operator or another Subject is liable.
Use Case 2 — Multi-Party Industrial Incident
An industrial incident involves an owner, operator, maintenance provider, and component producer.
The matter contains several Liability Bases and several distinct Connection paths.
LDIM does not create one undifferentiated pool of inputs.
Instead, it preserves Subject-specific, Relationship-specific, Basis-specific, and Connection-specific Determination Input structures.
Maintenance records may be relevant to the maintenance-provider Determination.
Operational-control records may be relevant to the operator Determination.
Production records may be relevant to the producer Determination.
Ownership may be relevant to the owner under a different Basis.
Conflicting, unknown, and pending inputs remain explicit.
The resulting Governed Liability Determination Input Sets can then be evaluated independently by LDEM without assuming that the shared incident creates identical Liability for every Subject.
Canonical Closing Statement
Liability Determination should never begin with an undefined collection of facts, allegations, evidence, Harm, Claims, operational events, or assumptions.
Before Liability can be evaluated, the Determination itself must be bounded and the inputs entering that Determination must be explicit.
LDIM establishes that foundation.
It determines what may enter the Liability Determination process, where each input came from, what it represents, which part of the inquiry it belongs to, and whether the complete input structure is sufficient for evaluation.
It does not determine Liability.
A Determination is only as governable as the inputs from which it is formed.
Govern the inputs before evaluating Liability.