LDVM — Liability Determination Versioning Module
LDVM — Liability Determination Versioning 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 Versioning
Module ID: LIGA-LDS-LDVM-001
Origin ID: OOF.CM.LIGA.07.05.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 Versioning Module (LDVM) governs how Liability Determinations retain stable identity, explicit version states, historical continuity, temporal ordering, traceable change, supersession relationships, and reconstructability throughout the Liability lifecycle.
LDVM integrates the governed Determination Inputs, Evaluation, Attachment State, and Determination Rationale into a version-controlled Liability Determination record.
It ensures that correction, reassessment, reversal, new information, changed upstream governance, or later authoritative determination can change the current Liability Determination without erasing or rewriting earlier governed states.
LDVM does not independently determine whether Liability attaches.
It governs the transition:
Governed Liability Attachment State + Governed Liability Determination Rationale → Determination Identity → Version Formation → Change & Supersession Governance → Historical Continuity → Current Determination State → Governed Liability Determination State Its foundational distinction is:
Current Liability Determination ≠ Complete Liability Determination History.
Operational Role
The operational role of LDVM is:
to preserve the complete governed identity and history of a Liability Determination while allowing that Determination to change legitimately through time.
LDVM answers:
What is the current Liability Determination, how did it reach that state, what preceded it, what changed, and can every materially relevant version be reconstructed?
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 LDVM governs:
Liability Determination Versioning
Its principal inputs are:
Governed Liability Attachment State
and:
Governed Liability Determination Rationale
Its principal output is:
Governed Liability Determination State
Its downstream handoff is:
Governed Liability Determination State → LSAS — Liability Scope & Allocation Standard
Central Operational Question
How can a Liability Determination change through time while preserving its identity, prior states, rationale, provenance, temporal sequence, and complete reconstructable history?
Determination Identity
Every materially distinct Liability Determination should possess a stable identity.
That identity should remain associated with the relevant:
Liability Object, Subject, Relationship, Basis, Determination Scope, and Liability origin structure.
Version change should not automatically create a new Determination identity.
Therefore:
New Determination Version ≠ New Liability Origin by default.
Determination Identity and Version Identity
The underlying Liability Determination and a particular version of that Determination are different governance objects.
Therefore:
Determination Identity ≠ Determination Version Identity.
One Determination may possess multiple governed versions.
Origin Continuity
The Origin Identity of the Liability Determination should remain stable across legitimate versions unless a genuinely new Liability Determination is formed.
The governing principle is:
A change in state does not by itself create a change in origin.
Version Formation
A new version should be formed where a material change affects the governed Liability Determination.
Material changes may include:
changed Attachment State, corrected Determination, reassessment, new material input, changed Evaluation, changed Rationale, resolved uncertainty, resolved dispute, new authoritative determination, or another material governance change.
Material vs Non-Material Change
Not every administrative change requires a new substantive Determination version.
A formatting correction, metadata normalization, or representation change that does not alter the governed meaning may remain within the same substantive version where the implementation permits.
Therefore:
Representation Change ≠ Substantive Determination Change by default.
Version State
Each version should identify its governance state.
A version may be:
Current
Historical
Superseded
Corrected
Reassessed
Reversed
Pending Supersession
or another explicitly governed state where required.
Current Version
The Current Version represents the presently operative governed Liability Determination within the defined scope.
It should be distinguishable from all historical versions.
Therefore:
Current Version ≠ Only Relevant Version.
Historical Version
A Historical Version represents an earlier governed Liability Determination state.
Historical status does not make the version irrelevant.
It may remain necessary for:
audit, review, Scope & Allocation history, state change, recourse, resolution, re-entry, or Finality.
Superseded Version
A later Determination may supersede an earlier version.
Supersession changes which version is current.
It does not delete the earlier state.
Therefore:
Supersession ≠ Historical Deletion.
Corrected Version
A Corrected Version addresses an error in an earlier Determination or its governed representation.
The corrected version should preserve:
what was corrected, why, when, by what authority or process, and which earlier version was affected.
Therefore:
Correction ≠ Historical Erasure.
Reassessed Version
A Reassessed Version results from renewed evaluation following new or changed governed circumstances.
Reassessment does not necessarily mean the earlier Determination was invalid when made.
Therefore:
Reassessment ≠ Correction.
Reversed Version
A later governed process may reverse an earlier Determination.
Examples include:
Attached → Not Attached or:
Not Attached → Attached The earlier version remains part of the Determination history.
Therefore:
Reversal ≠ Erasure.
Version Sequence
Versions should preserve their temporal and logical order.
The sequence should make it possible to determine:
which version preceded another, which version superseded another, why a transition occurred, and which version was current at a given lifecycle moment.
Version Lineage
Each version should remain connected to its relevant predecessor and, where applicable, successor.
The canonical structure is:
Determination Origin → Version 1 → Material Change → Version 2 → Material Change → Version N Version lineage should remain reconstructable even where multiple branches or authority-specific versions exist.
Branching Versions
Complex Liability matters may contain parallel Determination versions produced by different:
authorities, methodologies, jurisdictions, processes, or unresolved governance paths.
LDVM should not force these into artificial linearity.
Therefore:
Multiple Determination Versions ≠ One Universal Version Sequence by default.
Conflicting Versions
Two versions may materially conflict.
LDVM should preserve:
their identities, origins, authorities, scopes, times, rationales, and conflict state.
Therefore:
Version Conflict ≠ Authority to Delete One Version.
Authority-Specific Versions
Where different competent authorities produce separate Liability Determinations, their outputs should remain distinguishable.
LDVM should not represent one authority's Determination as automatically superseding another unless the applicable governance structure establishes that relationship.
Scope-Specific Versions
A Determination version should remain associated with its governed scope.
A new version affecting only one Subject, Relationship, Basis, or Object should not silently rewrite unrelated Determinations.
Therefore:
Local Determination Change ≠ Network-Wide Determination Change.
Subject-Specific Versioning
Where multiple Subjects exist, their Determination histories should remain distinguishable.
Therefore:
Version Change for Subject A ≠ Version Change for Subject B by default.
Relationship-Specific Versioning
Where one Subject participates in multiple Liability Relationships, a change concerning one Relationship should remain bounded to that Relationship unless a governed dependency requires broader change.
Basis-Specific Versioning
A change in Determination under one Liability Basis does not automatically change Determination under another Basis.
Therefore:
Basis A Version Change ≠ Basis B Version Change by default.
Attachment-State Versioning
A change in Attachment State is a material Determination change.
LDVM should preserve transitions such as:
Attached → Not Attached Pending → Attached Unknown → Not Attached Uncertain → Attached Disputed → Attached or other legitimate transitions.
State Transition Record
Each material transition should preserve:
previous state, new state, transition reason, effective time, recording time, authority or process, and relevant source version.
Determination Time
LDVM should preserve when each Determination version was established.
This should remain distinguishable from the time at which Liability is determined to have attached.
Therefore:
Determination Time ≠ Attachment-Effective Time by default.
Knowledge Time
Where materially relevant, LDVM should preserve when information causing a version change became known.
Therefore:
Change in Knowledge ≠ Change in Underlying Reality by default.
Effective Time
A new Determination version may become operative at a different time from when it was created.
Creation time and effective time should remain distinguishable where necessary.
Retrospective Change
A later version may determine that an earlier Liability state should be understood differently.
LDVM should preserve both:
the historical Determination actually made, and the later revised interpretation.
Therefore:
Retrospective Determination ≠ Historical Rewrite.
Input-Version Association
Each Determination version should remain traceable to the Governed Liability Determination Input Set used for that version.
Therefore:
New Inputs ≠ Automatic Revision of Earlier Determination Record.
New inputs may trigger a new Determination version.
Evaluation-Version Association
Each Determination version should remain associated with the relevant Governed Liability Determination Evaluation.
A changed Evaluation may trigger a changed Determination version.
Attachment-Version Association
The applicable Attachment State should be preserved for each Determination version.
This allows reconstruction of the Liability Attachment history.
Rationale-Version Association
Each Determination version should remain associated with the rationale supporting that version.
Therefore:
New Rationale ≠ Silent Replacement of Historical Rationale.
Provenance
Each version should preserve sufficient provenance to establish:
where it originated, what process produced it, what authority was involved, what previous version it relates to, and what material change produced the new version.
Version Traceability
A qualified reviewer should be able to trace a version backward through:
Rationale, Attachment State, Evaluation, Determination Inputs, and materially relevant upstream LIGA™ structures.
Therefore:
Version Record without Traceability ≠ Fully Governed Determination Version.
Historical Reconstruction
LDVM should enable reconstruction of the Liability Determination as it existed at a materially relevant time.
This may include:
then-current inputs, Evaluation, Attachment State, Rationale, authority, and applicable version.
Current-State Reconstruction
The system should also be able to identify the presently current Determination state without requiring the user to infer it from the entire historical record.
Therefore:
Historical Completeness ≠ Current-State Ambiguity.
Version Integrity
A version should not be modified in a manner that destroys the meaning of the historical state it represents.
Material correction should create a governed correction relationship rather than silently rewrite the historical record.
Immutable History vs Correctable Governance
Historical integrity does not require that incorrect Determinations remain current.
The governing distinction is:
History must remain preserved while current governance remains correctable.
No Silent Replacement
A later Determination should not silently overwrite an earlier one.
Therefore:
Current-State Replacement ≠ Historical Governance.
Every material replacement should be traceable.
No Version Collapse
Distinct versions should not be collapsed where doing so would remove materially relevant differences.
Therefore:
Similar Determination States ≠ Identical Determination Versions.
No False New Origin
A changed Determination should not automatically receive a new Liability Origin merely because its:
state, rationale, inputs, or evaluation changed.
Therefore:
Determination Change ≠ New Liability by default.
Genuine New Determination
A genuinely new Determination identity may be required where the governed object materially changes.
Examples may include a genuinely different:
Liability Object, Subject, Relationship, Basis, or independent Liability inquiry.
The distinction should be governed rather than assumed.
Re-Entry
Later Liability lifecycle stages may trigger re-entry into LDS.
Re-entry may produce a new Determination version.
It should preserve the existing Determination lineage.
Therefore:
Re-Entry ≠ New Origin by default.
Re-Entry Target
Where a later issue originates upstream, the process should return to the earliest materially affected governance space.
Examples:
Determination version issue → LDVM Rationale issue → LDRM Attachment issue → LDAM Evaluation issue → LDEM Input issue → LDIM Connection issue → LCNS Condition issue → LCOS Relationship issue → LRS Basis issue → LBS Object issue → LOS Context issue → LCS
Re-Entry and History
A re-entered process should not rewrite the state that existed before re-entry.
Instead, it should create the appropriate new governed state and preserve the relationship to the earlier state.
The principle is:
Re-entry must not rewrite history.
Determination Continuity
LDVM preserves continuity between Determination versions.
Continuity means that a qualified reviewer can understand how one state became another.
Therefore:
Determination Continuity ≠ Determination Immutability.
Determination History
The complete Determination History may include:
initial Determination, subsequent corrections, reassessments, reversals, external authority determinations, superseded versions, re-entry states, and current version.
Therefore:
Current Liability Determination State ≠ Complete Liability Determination History.
Multi-Authority History
Where several authorities or processes produce Determinations, LDVM should preserve their separate histories and relationships.
A court, insurer, arbitrator, regulator, contractual authority, internal governance process, or methodological assessment may each have distinct authority boundaries.
External Determination Version
External determinations may be represented as governed external states.
LDVM should preserve:
authority, scope, version, time, status, and relationship to the LIGA™ Determination structure.
LIGA™ does not replace the issuing authority.
AI-Generated Version
Where an AI or automated process participates in producing or revising a Determination, the relevant system and methodology version should remain identifiable where material.
Therefore:
Model Change ≠ Liability Determination Change by default.
A model update matters only where it materially changes the governed Determination process or output.
Human Revision
A human revision should be version-governed where it materially changes the Determination.
Therefore:
Human Edit ≠ Non-Versioned Change by default.
Authority does not eliminate the need for historical traceability.
Version Status
Each Determination version should have an explicit status sufficient to distinguish whether it is:
operative, historical, superseded, corrected, under reassessment, or otherwise non-current.
Version Finalization
A version may be finalized for its specific lifecycle state without establishing Liability Finality.
Therefore:
Determination Version Finalization ≠ Liability Finality.
Liability Finality belongs to LCFS.
Downstream Stability
Before handoff to LSAS, LDVM should identify which Governed Liability Determination State is the applicable current state for Scope & Allocation governance.
This prevents LSAS from operating on an obsolete or ambiguous Determination.
Downstream Historical Reference
Later standards may still need historical Determination versions.
LDVM should therefore preserve stable references to prior states.
Scope, Allocation, State Change, Recourse, Resolution, or Finality may depend on understanding which Determination was operative at a particular time.
Governed Liability Determination State
The principal output of LDVM and the complete LDS module sequence is:
Governed Liability Determination State
It integrates, at minimum:
Determination identity, current version, Determination Object, Determination Scope, Liability Subject or Relationship, Liability Basis, Attachment State, Evaluation reference, Rationale reference, authority, Determination time, Attachment-effective time where applicable, version lineage, historical states, and provenance.
Meaning of the Output
A Governed Liability Determination State means that the existence or non-existence of Liability within the defined Determination Scope has been methodologically determined, explicitly represented, reasoned, version-controlled, and made historically reconstructable.
It does not determine:
Liability Scope, Liability Allocation, ongoing Liability State, Transfer, Recourse, Resolution, Discharge, or Finality.
Therefore:
Governed Liability Determination State ≠ Complete Liability Lifecycle.
Handoff to Liability Scope & Allocation
LDVM hands the:
Governed Liability Determination State
to:
LSAS — Liability Scope & Allocation Standard
The next LIGA™ governance question becomes:
For what and to what extent does established Liability apply, and how is that Liability distributed where multiple Liability relationships exist?
The boundary is explicit:
LDS determines whether Liability attaches.
LSAS determines how far established Liability extends and how it is allocated.
Minimum Implementation Framework
A conforming implementation of LDVM must provide exactly the following eight capabilities:
Determination Identity & Origin Continuity
Capability to preserve stable Determination identity and Origin continuity across legitimate versions without creating false new Liability origins.
Version Formation, Identity & Status Governance
Capability to create, identify, classify, and maintain materially distinct Determination versions and their current, historical, superseded, corrected, reassessed, reversed, or other governed statuses.
Version Lineage & Temporal Governance
Capability to preserve predecessor-successor relationships, temporal sequence, Determination time, effective time, knowledge time where relevant, and branching version structures.
Input, Evaluation, Attachment & Rationale Version Association
Capability to associate every material Determination version with the governed Inputs, Evaluation, Attachment State, and Rationale from which it was formed.
Correction, Reassessment, Reversal & Supersession Governance
Capability to distinguish and govern corrections, reassessments, reversals, supersession, conflicting versions, and authority-specific determinations without historical deletion.
Historical Integrity & Reconstruction
Capability to preserve complete Determination history and reconstruct materially relevant Determination states as they existed at specific lifecycle moments.
Re-Entry, Change & Continuity Governance
Capability to govern lifecycle re-entry and material Determination change while preserving Origin identity, lineage, provenance, and historical continuity.
Scope & Allocation Handoff Governance
Capability to produce the current Governed Liability Determination State with sufficient identity, version certainty, history, and traceability for handoff to Liability Scope & Allocation governance.
Governance Logic
The canonical LDVM governance logic is:
Governed Liability Attachment State + Governed Liability Determination Rationale
↓
Confirm Determination Identity
↓
Confirm Origin Continuity
↓
Associate Inputs / Evaluation / Attachment / Rationale
↓
Identify Material Change
↓
Determine Whether New Version Is Required
↓
Create Version Identity
↓
Preserve Previous Version
↓
Establish Version Relationship
↓
Record Change Reason / Authority / Time
↓
Determine Current / Historical / Superseded Status
↓
Preserve Version Lineage
↓
Verify Historical Reconstruction
↓
Identify Current Governed Determination
↓
Governed Liability Determination State
↓
Handoff to Liability Scope & Allocation
Governance Outputs
LDVM may produce:
Liability Determination Identity
Determination Origin Record
Determination Version Identity
Current Version State
Historical Version State
Superseded Version State
Corrected Version State
Reassessed Version State
Reversed Version State
Version Status Record
Version Sequence Record
Version Lineage
Branching Version Record
Version Conflict Record
Authority-Specific Version Record
Subject-Specific Version Record
Relationship-Specific Version Record
Basis-Specific Version Record
Attachment-State Transition Record
Determination Time Record
Attachment-Effective Time Record
Knowledge-Time Record
Input-Version Association
Evaluation-Version Association
Attachment-Version Association
Rationale-Version Association
Version Provenance Record
Correction Record
Reassessment Record
Reversal Record
Supersession Record
Re-Entry Record
Historical Reconstruction Record
The principal output is:
Governed Liability Determination State
Critical Distinctions
LDVM preserves the following distinctions:
Current Liability Determination ≠ Complete Liability Determination History New Determination Version ≠ New Liability Origin by default Determination Identity ≠ Determination Version Identity Representation Change ≠ Substantive Determination Change by default Current Version ≠ Only Relevant Version Supersession ≠ Historical Deletion Correction ≠ Historical Erasure Reassessment ≠ Correction Reversal ≠ Erasure Multiple Determination Versions ≠ One Universal Version Sequence by default Version Conflict ≠ Authority to Delete One Version Local Determination Change ≠ Network-Wide Determination Change Version Change for Subject A ≠ Version Change for Subject B by default Basis A Version Change ≠ Basis B Version Change by default Determination Time ≠ Attachment-Effective Time by default Change in Knowledge ≠ Change in Underlying Reality by default Retrospective Determination ≠ Historical Rewrite New Inputs ≠ Automatic Revision of Earlier Determination Record New Rationale ≠ Silent Replacement of Historical Rationale Version Record without Traceability ≠ Fully Governed Determination Version Historical Completeness ≠ Current-State Ambiguity Current-State Replacement ≠ Historical Governance Similar Determination States ≠ Identical Determination Versions Determination Change ≠ New Liability by default Re-Entry ≠ New Origin by default Determination Continuity ≠ Determination Immutability Model Change ≠ Liability Determination Change by default Determination Version Finalization ≠ Liability Finality Governed Liability Determination State ≠ Complete Liability Lifecycle
Cross-Architecture Boundary
LDVM preserves versioned references to governed objects originating from other OOF® architectures where those objects materially contributed to Liability Determination.
It does not take governance ownership of those objects.
For example:
ORA™ retains governance of Operational Reality.
HAGA™ retains governance of Harm.
AGA™ retains governance of Responsibility and Accountability.
ADIT® retains governance of evidence and auditability.
VALIDOS™ retains governance of validation.
OBIDENITY® retains governance of identity and origin-bound structures.
AIG® and ASGA™ retain governance of AI and autonomous-system states.
PGA™ retains governance of Prediction.
SIMULOS® retains governance of Simulation.
Where an external governed object changes, LDVM records which version of that object informed which Liability Determination version.
The canonical interoperability principle is:
Versioning a Liability Determination preserves the references to its governed inputs; it does not absorb the lifecycle or version governance of those inputs into LIGA™.
Canonical Boundary
LDVM begins with a:
Governed Liability Attachment State
and:
Governed Liability Determination Rationale
and governs their integration into a historically coherent, version-controlled Liability Determination.
LDVM governs:
Determination Identity, Origin Continuity, Version Identity, Version Formation, Version Status, Version Sequence, Version Lineage, Temporal State, Input-Version Association, Evaluation-Version Association, Attachment-Version Association, Rationale-Version Association, Correction, Reassessment, Reversal, Supersession, Conflict, Re-Entry, Historical Integrity, Reconstruction, Current-State Identification, and downstream handoff.
LDVM does not govern:
new substantive Determination Input formation, substantive Evaluation, original Attachment decision-making, Liability Scope, Liability Allocation, ongoing Liability State & Change, Transfer, Recourse, Resolution, Discharge, or Finality.
LDVM ends when the:
Governed Liability Determination State
is sufficiently current, explicit, traceable, versioned, and historically reconstructable for Liability Scope & Allocation governance.
Use Case 1 — Liability Determination Reassessment
A Liability Determination initially establishes an Attached state based on the governed inputs available at T1.
At T2, a previously unavailable operational record materially changes the Governed Liability Connection Structure.
The matter re-enters the appropriate upstream governance space and produces a revised Evaluation and Attachment Determination.
LDVM creates a new Determination version.
The T1 Attached Determination remains historically preserved.
The T2 version becomes the current Determination.
The system records:
what changed, why it changed, which inputs changed, which Evaluation replaced the earlier Evaluation, which Attachment State now applies, and how both versions relate.
The new Determination does not erase the fact that the earlier governed state existed.
Use Case 2 — Multi-Authority Liability Determinations
A Liability matter is evaluated by an internal governance process and later by an external competent authority.
The two Determinations differ.
LDVM preserves both as distinct governed Determination states with their respective:
authority, scope, Basis, time, Attachment State, Rationale, and provenance.
The external Determination is not silently merged with the internal Determination.
Where the applicable governance structure establishes that the external decision supersedes the internal operational state, that supersession relationship is explicitly recorded.
The complete Determination history remains reconstructable for later Scope, Allocation, Recourse, Resolution, and Finality governance.
Canonical Closing Statement
A Liability Determination is not governed merely because its current outcome is known.
Its identity, origin, prior states, changes, corrections, reversals, rationale, authority, timing, and lineage must remain reconstructable.
LDVM allows Liability Determination to change without allowing history to disappear.
A later state may supersede an earlier state.
It must not erase it.
Current Liability Determination is a state. Liability Determination History is a governed lifecycle record.
Preserve every material Determination transition so that change never becomes historical loss.