schema_version: "1.0"

id: "FM-ECO-026"

title: "FM-ECO-026 — Dependency Lock-In"

slug: "fm-eco-026-dependency-lock-in"

type: "failure_mode"

status: "draft"

version: "0.1.0"

last_updated: "2026-06-19"

summary: "Dependency Lock-In occurs when an economic node becomes structurally dependent on a provider, platform, contract, infrastructure, employer, lender, supply chain, tool, policy pathway, or resource channel such that exit, substitution, renegotiation, repair, or independent operation becomes prohibitively costly or practically unavailable."

canonical_url: "/archive/failure-modes/registry/economy/fm-eco-026-dependency-lock-in"

citation_id: "FM-ECO-026-v0-1-0"

canon:

tier: "registry"

state: "draft"

source: "UTS — Failure Modes Registry"

source_id: "FM-ECO-026"

legacy_ids:

• "FM-ECOX-022"

classification:

family: "failure-modes"

module: "economy"

module_group: "economy"

density: "advanced-reference"

audience:

• "UTS readers"
• "economic systems researchers"
• "platform researchers"
• "contract researchers"
• "justice researchers"
• "restoration researchers"
• "cybernetics researchers"
• "AI governance researchers"
• "security researchers"
• "coherence researchers"
• "machine readers"

tags:

• "failure-modes"
• "economy"
• "dependency-lock-in"
• "fm-eco-026-dependency-lock-in"
• "fm-ecox-022-dependency-lock-in"
• "lock-in"
• "dependency"
• "exit-cost"
• "platform-dependency"
• "vendor-lock-in"
• "forced-coupling"
• "hidden-debt"
• "coherence"

aliases:

• "Dependency Lock-In"
• "Economic Dependency Lock-In"
• "Vendor Lock-In"
• "Platform Lock-In"
• "Contractual Lock-In"
• "Infrastructure Lock-In"
• "Exit-Cost Capture"
• "Dependency Capture"
• "Non-Exit Dependency"
• "Locked Dependency Trap"

related:

laws:

• "Exit Denial"
• "Forced Coupling"
• "Coercive Contract"
• "Conditional Coercive Delivery"
• "No Alternative Framing"
• "⊗ Without Λ"
• "Forced Profit"
• "Parasitic Extraction"
• "Economic Over-Constriction"
• "Hoarding as Pseudo-Security"
• "Hidden Debt Accumulation"
• "Exported Economic Incoherence"

invariants:

• "Dependency Must Preserve Exit"
• "Critical Access Requires Portability"
• "Lock-In Must Remain Auditable"
• "Substitution Paths Must Remain Viable"
• "Dependency Must Not Replace Consent"
• "Shared Infrastructure Must Preserve Autonomy"
• "Repair Must Not Require Deeper Dependency"

operators:

• "BΣ — Boundary Integrity"
• "Λ — Compatibility"
• "⊗ — Fusion / Binding"
• "Φ — Flow / Resource Movement"
• "Γ — Selection"
• "K — Constraint / Load"
• "H — Hidden Debt"
• "Au — Auditability"
• "R — Restoration Capacity"
• "Ψ — Observation / Interface"
• "G — Gain"
• "D — Damping"
• "O — Coherence"
• "Τ — Trajectory / Time"

gates:

• "Exit Gate"
• "Dependency Gate"
• "Portability Gate"
• "Substitution Gate"
• "Consent Gate"
• "Contract Gate"
• "Compatibility Gate"
• "Auditability Gate"
• "Restoration Gate"

diagnostics:

• "Exit Cost"
• "Dependency Load"
• "Portability"
• "Substitution Viability"
• "Lock-In Pressure"
• "Consent Validity"
• "Contract Burden"
• "Hidden Debt"
• "Auditability"
• "Local Coherence"

failure_modes:

• "FM-ECO-008 — Forced Profit"
• "FM-ECO-013 — Conditional Coercive Delivery"
• "FM-ECO-021 — “No Alternative” Framing"
• "FM-ECO-022 — ⊗ Without Λ"
• "FM-ECO-023 — Asymmetric Bandwidth"
• "FM-ECO-025 — Coercive Contract"
• "FM-ECO-027 — Extraction Masking Instability"
• "FM-ECO-028 — Repair Starvation"
• "FM-CORE-008 — Forced Coupling"
• "FM-ISC-009 — Consent Drift"
• "FM-JC-011 — Locked-In Renegotiation Failure"
• "FM-C-021 — Parasitic Extraction"

restoration_arcs:

• "Dependency Map Audit"
• "Exit Cost Reduction"
• "Portability Restoration"
• "Substitution Path Rebuilding"
• "Contract Unbundling"
• "Dependency Load Reduction"
• "Consent Revalidation"
• "Lock-In Debt Accounting"
• "Restoration Path Reopening"
• "Local Coherence Restoration"

modules:

• "Economy"
• "Contracts"
• "Justice"
• "Restoration"
• "Interactions"
• "Cybernetics"
• "Security"
• "AI Governance"
• "Infrastructure"
• "Coherence"

navigation:

order: 1326

parent: "failure-modes"

visible: true

provenance:

created_from: "failure-mode-registry-production"

source_thread: "UTS Failure Modes Registry production"

source_file: "content/archive/failure-modes/registry/economy/fm-eco-026-dependency-lock-in.md"

legacy_source_file: "content/archive/failure-modes/registry/economy/fm-ecox-022-dependency-lock-in.md"

notes: "Unified from former FM-ECOX-022 into continuous Economy namespace. Domain expression / standalone economy entry focused on economic dependency becoming non-exitable through platform control, vendor lock-in, contract bundling, infrastructure reliance, data capture, switching costs, degraded alternatives, or repair paths that require deeper dependence."

entry:

failure_mode_id: "FM-ECO-026"

failure_family: "Economy"

production_treatment: "Domain Expression / Standalone Entry"

legacy_ids:

• "FM-ECOX-022"

parent_modes:

• "FM-CORE-008 — Forced Coupling"
• "FM-ISC-009 — Consent Drift"
• "FM-ECO-025 — Coercive Contract"
• "FM-JC-011 — Locked-In Renegotiation Failure"
• "FM-C-021 — Parasitic Extraction"

first_gate_failure: "Exit Gate"

primary_hidden_debt: "Hidden debt accumulates when economic participation, service continuity, repair, access, livelihood, data portability, or operational viability depends on remaining inside a structure whose exit costs, switching costs, or substitution barriers keep rising."

primary_inversion: "Dependency becomes stability; the system treats continued participation as proof of satisfaction or fit while the dependent node remains because exit has become too costly, risky, or unavailable."

primary_boundary_pattern: "The boundary between chosen reliance and captured dependence collapses; what began as useful support becomes a non-exitable condition for functioning."

primary_signature: "Dependency grows; alternatives degrade or disappear; exit cost rises; renegotiation weakens; provider or structure gains leverage; affected node remains under constrained choice; hidden dependency debt accumulates."

FM-ECO-026 — Dependency Lock-In

Status: Draft

Archive Type: Failure Mode

System: Universal Theory Stack

Parent: Failure Modes

Canon Tier: Registry

Registry: Failure Modes Registry

Entry ID: FM-ECO-026

Legacy ID: FM-ECOX-022

Family: Economy

Production Treatment: Domain Expression / Standalone Entry

Parent Modes: FM-CORE-008 — Forced Coupling; FM-ISC-009 — Consent Drift; FM-ECO-025 — Coercive Contract; FM-JC-011 — Locked-In Renegotiation Failure; FM-C-021 — Parasitic Extraction

0. Economic Scope Note

This entry is conceptual and systems-oriented.

It does not treat dependence, specialization, partnership, infrastructure reliance, vendor use, platform participation, credit use, employment, shared services, supply-chain reliance, or technical integration as inherently failed.

Economic systems require dependency.

Dependency can preserve coherence when it is:

• consent-valid
• exit-aware
• portable where needed
• auditable
• compatible
• reciprocal
• repairable
• not exploitative
• not dependency-deepening by default
• paired with substitution paths
• transparent about switching costs
• protective of affected-node autonomy
• able to adapt under changed conditions

The failure begins when reliance becomes captivity.

The issue is not dependency.

The issue is dependency whose exit, substitution, or renegotiation becomes practically unavailable.

Dependency Lock-In occurs when a node can no longer leave, change, repair, or negotiate the dependency without disproportionate loss.

1. Definition

Dependency Lock-In occurs when an economic node becomes structurally dependent on a provider, platform, contract, infrastructure, employer, lender, supply chain, tool, policy pathway, or resource channel such that exit, substitution, renegotiation, repair, or independent operation becomes prohibitively costly or practically unavailable.

The lock-in may involve:

• vendor systems
• platform access
• employment dependency
• housing dependency
• debt dependency
• lender dependency
• insurance dependency
• supply-chain dependency
• payment rails
• data hosting
• cloud infrastructure
• AI tools
• proprietary formats
• subscription ecosystems
• bundled services
• licensing terms
• single-source procurement
• public-service privatization
• critical infrastructure access
• maintenance contracts
• healthcare access pathways
• identity systems
• marketplace access
• social graph dependency

The core failure is:

dependency↑
exit viability↓
substitution paths↓
provider leverage↑
H↑

Dependency Lock-In is not ordinary reliance.

It is reliance that becomes non-exitable.

2. Core Pattern

The core pattern is:

1. A node adopts a dependency because it provides value, access, efficiency, repair, employment, infrastructure, credit, reach, or capability.
2. The dependency deepens over time.
3. Alternatives weaken, disappear, or become costly.
4. Data, workflows, relationships, contracts, habits, skills, identity, revenue, infrastructure, or operations become embedded in the dependency.
5. Exit cost rises.
6. The provider or controlling structure gains leverage.
7. Terms, prices, surveillance, extraction, quality decline, or burdens can increase.
8. The dependent node remains because leaving would cause disproportionate damage.
9. Continued participation is counted as preference or market validation.
10. Hidden dependency debt accumulates.
11. Restoration requires rebuilding exit, portability, substitution, and renegotiation capacity.

This failure often appears as:

they keep using it, so it must be working

while the hidden truth may be:

they keep using it because leaving has become too costly

or:

the market chose this provider

while the overlooked condition is:

the market lost the ability to choose otherwise

The restorative question is:

what would it cost this node to leave, and who benefits from that cost?

Dependency Lock-In turns continued participation into false consent.

3. Failure Signature

Typical signature:

dependency↑
exit cost↑
substitution viability↓
renegotiation power↓
provider leverage↑
consent validity↓
H↑

Extended signature:

platform access becomes required for livelihood
data cannot be exported without loss
contract terms worsen after alternatives disappear
workflows depend on proprietary tools
public service depends on private infrastructure
credit dependency prevents refusal
employment dependency blocks negotiation
AI tool dependency displaces local skill and review capacity
supply chain dependency makes local resilience impossible

Common forms include:

a business cannot leave a platform because customers, payments, and reputation are trapped there
an institution cannot leave a vendor because data, workflows, and staff training are locked in
workers cannot reject terms because income, healthcare, housing, or scheduling access depends on compliance
users cannot leave a service because their social graph, identity, history, or creative archive is trapped
a government depends on a private provider for critical public infrastructure
a supply chain depends on a single supplier with no redundancy
a borrower cannot refinance or exit because fees and penalties compound
an AI workflow becomes dependent on one provider before portability, audit, or appeal exists

The defining condition is not that dependency exists.

The defining condition is that dependency suppresses exit, substitution, and renegotiation.

4. Primary U-Layer Origin

Common origin layers:

• U1 — Power / Budgets: control over access, capital, livelihood, infrastructure, or terms creates leverage.
• U2 — Configuration / Boundaries: data, contracts, workflows, identity, permissions, and infrastructure boundaries trap the node.
• U3 — Execution / Runtime: daily operations become dependent on the locked pathway.
• U4 — Information / Truth: continued use substitutes for preference or consent truth.
• U5 — Coordination / Time: lock-in deepens gradually until exit windows close.
• U6 — Coherence Field: convenience, familiarity, or stability aura masks capture.
• U7 — Memory / Recurrence: repeated reliance becomes default and later becomes dependency memory.
• U8 — Environment / Field: market consolidation, scarcity, policy, or degraded alternatives remove practical substitutes.

Common manifestation layers:

• U1 — Power: provider leverage increases.
• U2 — Boundaries: portability and exit boundaries close.
• U3 — Execution: operations depend on the locked system.
• U4 — Truth: usage is read as satisfaction.
• U5 — Time: lock-in grows through gradual embedding.
• U6 — Field: dependency feels like stability.
• U8 — Environment: alternatives degrade.

Dependency Lock-In is primarily a U2 boundary / U5 time-embedding failure, anchored by U1 power asymmetry.

The system allows reliance to become captivity over time.

5. Typical Development Sequence

A common development sequence is:

1. A node adopts a tool, provider, contract, platform, employer, lender, supply channel, or infrastructure path.
2. Initial value is real.
3. The node invests time, data, training, identity, workflow, customers, obligations, or infrastructure into the dependency.
4. Alternatives become less available or less usable.
5. Switching costs rise.
6. The provider or controlling structure changes terms, prices, access, rules, or quality.
7. The dependent node wants to leave, contest, or renegotiate.
8. Exit cost is too high.
9. The node remains.
10. Continued participation is treated as validation.
11. The dependency deepens further.
12. Hidden debt accumulates through lost autonomy, degraded bargaining power, and constrained repair.

The loop often looks like:

useful reliance → embedded workflow → switching cost → reduced exit → deeper reliance

Another common loop is:

alternatives weaken → provider leverage rises → terms worsen → resources to exit decline

Dependency Lock-In becomes self-reinforcing when the dependency consumes the resources needed to escape it.

6. Diagnostic Markers

Diagnostic markers include:

• The node remains despite declining quality, rising cost, or harmful terms.
• Alternatives exist nominally but are too costly, degraded, incompatible, or risky.
• Data, history, customers, identity, reputation, or workflows cannot be transferred cleanly.
• Exit requires losing access to critical service or livelihood.
• Contract penalties or technical barriers make switching punitive.
• The provider changes terms after dependency deepens.
• Renegotiation is unavailable or ineffective.
• Local capability atrophies because the dependency replaces internal capacity.
• Support, repair, or appeals require staying inside the dependency.
• The dependent node cannot test alternatives without major disruption.
• Continued use is invoked as proof of satisfaction.
• The dependency started as convenience and became necessity.
• Restoration improves when portability, redundancy, and exit paths are restored.

Useful diagnostics:

• Exit Cost: Measures cost, risk, loss, or disruption created by leaving.
• Dependency Load: Measures how much functioning depends on the locked structure.
• Portability: Tests whether data, workflows, rights, identity, and value can move.
• Substitution Viability: Determines whether alternatives can actually replace the dependency.
• Lock-In Pressure: Measures forces keeping the node inside.
• Consent Validity: Tests whether continued participation remains choice-valid.
• Contract Burden: Measures clauses, penalties, renewals, and bundled obligations.
• Hidden Debt: Tracks autonomy loss, capacity loss, and accumulated switching debt.
• Auditability: Determines whether lock-in mechanisms can be inspected.
• Local Coherence: Tests whether dependency improves or degrades affected-node viability.

7. Related Gates

Relevant gates include:

• Exit Gate: Fails when leaving becomes punitive or practically impossible.
• Dependency Gate: Fails when reliance crosses into captivity.
• Portability Gate: Fails when value, data, identity, or workflow cannot move.
• Substitution Gate: Fails when alternatives are nominal but unusable.
• Consent Gate: Fails when continued participation is counted despite non-exit.
• Contract Gate: Fails when terms create or exploit lock-in.
• Compatibility Gate: Fails when dependency persists despite poor fit.
• Auditability Gate: Fails when lock-in mechanisms are hidden.
• Restoration Gate: Fails when repair requires deeper dependence.

The first common gate failure is usually the Exit Gate.

The system allows participation to continue after exit viability has collapsed.

8. Related Operators

Relevant operators include:

• BΣ — Boundary Integrity: Protects autonomy, exit, and separation boundaries.
• Λ — Compatibility: Tests whether the dependency still fits.
• ⊗ — Fusion / Binding: Binding increases as dependency deepens.
• Φ — Flow / Resource Movement: Routes money, access, data, customers, labor, and service through the dependency.
• Γ — Selection: Selects provider, pathway, or dependency structure.
• K — Constraint / Load: Rises as switching cost and dependency burden increase.
• H — Hidden Debt: Accumulates as autonomy and substitution capacity decline.
• Au — Auditability: Reveals lock-in mechanisms and exit cost.
• R — Restoration Capacity: Must support exit, repair, and substitution.
• Ψ — Observation / Interface: Shapes how dependency and choice are represented.
• G — Gain: Incentivizes providers to deepen lock-in.
• D — Damping: Should limit dependency acceleration.
• O — Coherence: May appear high because the dependency provides continuity.
• Τ — Trajectory / Time: Tracks gradual embedding and closing exit windows.

Common operator pattern:

Γ selects dependency
Φ routes more value through it
⊗ binding increases
BΣ exit boundary weakens
K switching cost rises
Λ fit may decline
O appears high through continuity
continued use is read as consent
H accumulates as exit capacity falls

The core operator inversion is:

continued use → preference / consent

instead of:

continued use + viable exit + substitution + renegotiation + portability → preference / consent

Dependency Lock-In turns continuity into capture.

9. Related Laws and Invariants

Related Laws

• Exit Denial: exit becomes unavailable or punitive.
• Forced Coupling: nodes remain bound against compatibility or preference.
• Coercive Contract: contractual terms enforce lock-in.
• Conditional Coercive Delivery: needed support is gated through dependency.
• No Alternative Framing: dependency is framed as inevitable.
• ⊗ Without Λ: binding persists without compatibility.
• Forced Profit: provider extracts from non-exitable users or nodes.
• Parasitic Extraction: provider draws value from captive dependence.
• Economic Over-Constriction: rules prevent alternative paths.
• Hoarding as Pseudo-Security: resources or access are withheld to maintain dependency.
• Hidden Debt Accumulation: switching and autonomy debt compound.
• Exported Economic Incoherence: burden is displaced onto dependent nodes.

Related Invariants

• Dependency Must Preserve Exit: reliance is coherent only while exit remains viable.
• Critical Access Requires Portability: essential resources must not trap affected nodes.
• Lock-In Must Remain Auditable: dependency mechanisms must be visible.
• Substitution Paths Must Remain Viable: alternatives must remain practical, not merely theoretical.
• Dependency Must Not Replace Consent: continued use under non-exit is not consent.
• Shared Infrastructure Must Preserve Autonomy: common systems must not erase self-direction.
• Repair Must Not Require Deeper Dependency: restoration should reduce capture, not intensify it.

10. Common False Positives

Not every strong dependency is Dependency Lock-In.

Common false positives include:

• Voluntary long-term reliance with viable exit.
• Specialized partnership with transparent substitution planning.
• Critical infrastructure dependency with portability and public accountability.
• Vendor use with accessible data export and fair termination.
• Employment dependency paired with real alternatives and protections.
• Supply-chain reliance with redundancy and contingency planning.
• Platform participation with interoperability and user portability.
• Contractual dependency with renegotiation under changed conditions.
• Temporary dependency during transition with planned exit.
• Shared infrastructure that preserves local autonomy.
• High switching cost that is known, compensated, and not exploitative.
• Dependency chosen by affected nodes after visible alternatives.

Clarifying rule:

This is not Dependency Lock-In unless reliance suppresses practical exit, substitution, renegotiation, repair, or independent operation while continued participation is treated as valid preference, consent, or stability.

11. Common False Repairs

Common false repairs include:

• offering data export that is unusable
• creating alternative providers that lack compatibility
• reducing price temporarily while preserving lock-in
• allowing termination with punitive loss
• giving migration tools that require the same provider
• claiming competition exists while switching cost remains prohibitive
• unbundling one feature while preserving critical dependency
• offering renegotiation only to high-status nodes
• creating portability standards without enforcement
• outsourcing lock-in to another intermediary
• adding transparency about lock-in without reducing it
• improving support while making exit harder
• calling dependency loyalty
• treating continued use after disclosure as renewed consent
• requiring deeper integration to access repair

False repair often produces the loop:

lock-in criticized → symbolic portability added → exit remains unusable → dependency persists

Another common loop is:

dependency causes harm → repair offered only inside dependency → dependency deepens

The repair fails because it improves the dependency experience without restoring exit or substitution.

12. Restoration Direction

Restoration requires mapping dependency pathways, reducing exit cost, restoring portability and substitution, unbundling coercive structures, reopening renegotiation, and repairing hidden debt created by dependency capture.

Primary restoration direction:

map dependency,
restore exit,
rebuild substitution,
and repair lock-in debt

A fuller restoration path includes:

1. Name the dependency. Identify the provider, platform, employer, lender, infrastructure, tool, supply chain, policy path, or contract.
2. Map dependency pathways. Identify data, money, access, customers, identity, workflow, repair, support, and obligations routed through the dependency.
3. Measure exit cost. Determine what would be lost by leaving.
4. Measure substitution viability. Determine whether alternatives can actually replace the dependency.
5. Audit portability. Test whether value, data, identity, reputation, workflows, and rights can move.
6. Identify lock-in mechanisms. Locate contracts, formats, bundling, penalties, network effects, scarcity, skills decay, or infrastructure barriers.
7. Audit consent validity. Determine whether continued use is still choice-valid.
8. Reduce exit cost. Lower penalties, migration loss, technical barriers, and switching burden.
9. Restore portability. Enable movement of data, identity, workflows, records, funds, and relationships.
10. Rebuild alternatives. Resource practical substitution paths.
11. Unbundle critical access. Separate essential services from coercive dependency.
12. Reopen renegotiation. Allow terms to change when dependency burden is exposed.
13. Repair lock-in debt. Address burden accumulated under captive reliance.
14. Install dependency gates. Prevent future dependencies from becoming non-exitable.
15. Validate local coherence. Confirm affected nodes regain agency, resilience, and viable choice.

A valid restoration path should reduce:

exit cost
switching burden
provider leverage
contract lock
data captivity
substitution failure
dependency load
autonomy loss
H

Dependency Lock-In is not repaired by making the cage comfortable.

It is repaired by restoring the door.

13. Cross-Module Links

• Economy: Core failure of platform dependence, vendor lock-in, employment dependency, debt dependency, infrastructure reliance, and supply-chain capture.
• Contracts: Lock-in is frequently enforced through terms, penalties, bundling, and renegotiation failure.
• Justice: Captive nodes need standing to contest dependency-created burden.
• Restoration: Repair requires restoring exit, portability, and independent capacity.
• Interactions: Consent and exit are central; continued participation does not prove agreement.
• Cybernetics: Dependency can collapse feedback by making the controlled node unable to refuse.
• Security: Critical dependency can become systemic risk when exit, redundancy, or auditability are absent.
• AI Governance: AI platform, model, data, workflow, and compute dependency can lock users, institutions, or societies into non-exitable infrastructure.
• Infrastructure: Shared systems must preserve portability and failover.
• Coherence: Coherent dependency must remain compatible, auditable, repairable, and exitable.

14. Relationship to Parent / Child Modes

Production treatment: Domain Expression / Standalone Entry

This mode maps upward to:

• FM-CORE-008 — Forced Coupling
• FM-ISC-009 — Consent Drift
• FM-ECO-025 — Coercive Contract
• FM-JC-011 — Locked-In Renegotiation Failure
• FM-C-021 — Parasitic Extraction

Sibling or related Economy modes include:

• FM-ECO-008 — Forced Profit
• FM-ECO-013 — Conditional Coercive Delivery
• FM-ECO-021 — “No Alternative” Framing
• FM-ECO-022 — ⊗ Without Λ
• FM-ECO-023 — Asymmetric Bandwidth
• FM-ECO-025 — Coercive Contract
• FM-ECO-027 — Extraction Masking Instability
• FM-ECO-028 — Repair Starvation
• FM-ECO-032 — Pseudo-Coherent Economic Stability

Related cross-family modes include:

• FM-CORE-008 — Forced Coupling
• FM-ISC-009 — Consent Drift
• FM-ISC-012 — Restoration Lock-In
• FM-ISC-015 — Force Masked as Care
• FM-C-021 — Parasitic Extraction
• FM-JC-009 — Enforcement Capture
• FM-JC-011 — Locked-In Renegotiation Failure
• FM-JC-012 — Parasitic Contracting
• FM-SEC-008 — Proxy-Relay Drift
• FM-SEC-012 — Exit Failure / Recapture
• FM-AIX-022 — Dependency Loop Formation
• FM-RX-010 — Basin-Protective Repair

Aliases preserved from source material:

• Dependency Lock-In
• Economic Dependency Lock-In
• Vendor Lock-In
• Platform Lock-In
• Contractual Lock-In
• Infrastructure Lock-In
• Exit-Cost Capture
• Dependency Capture
• Non-Exit Dependency
• Locked Dependency Trap

Legacy source preserved:

legacy_ids:
  - "FM-ECOX-022"
deprecated_source_ids:
  - "FM-ECOX-022"
source_aliases:
  - "Economy Extended Entry 022"

15. Minimal Entry Version

Definition: Dependency Lock-In occurs when an economic node becomes structurally dependent on a provider, platform, contract, infrastructure, employer, lender, supply chain, tool, policy pathway, or resource channel such that exit, substitution, renegotiation, repair, or independent operation becomes prohibitively costly or practically unavailable.

Signature:

dependency↑
exit cost↑
substitution viability↓
renegotiation power↓
provider leverage↑
consent validity↓
H↑

Restoration direction:

• name the dependency
• map dependency pathways
• measure exit cost
• measure substitution viability
• audit portability
• identify lock-in mechanisms
• audit consent validity
• reduce exit cost
• restore portability
• rebuild alternatives
• unbundle critical access
• reopen renegotiation
• repair lock-in debt
• install dependency gates
• validate local coherence

16. Machine-Readable Summary

failure_mode:
  id: "FM-ECO-026"
  name: "Dependency Lock-In"
  family: "Economy"
  production_treatment: "Domain Expression / Standalone Entry"
  legacy_ids:
    - "FM-ECOX-022"
  parent_modes:
    - "FM-CORE-008 — Forced Coupling"
    - "FM-ISC-009 — Consent Drift"
    - "FM-ECO-025 — Coercive Contract"
    - "FM-JC-011 — Locked-In Renegotiation Failure"
    - "FM-C-021 — Parasitic Extraction"
  primary_failure: "Reliance suppresses practical exit, substitution, renegotiation, repair, or independent operation while continued participation is treated as valid preference, consent, or stability."
  source: "UTS — Failure Modes Registry"
  source_id: "FM-ECO-026"
  deprecated_source_ids:
    - "FM-ECOX-022"
  scope_note: "Conceptual and systems-oriented; does not treat dependence, specialization, partnership, infrastructure reliance, vendor use, platform participation, credit use, employment, shared services, supply-chain reliance, or technical integration as inherently failed."
  aliases:
    - "Dependency Lock-In"
    - "Economic Dependency Lock-In"
    - "Vendor Lock-In"
    - "Platform Lock-In"
    - "Contractual Lock-In"
    - "Infrastructure Lock-In"
    - "Exit-Cost Capture"
    - "Dependency Capture"
    - "Non-Exit Dependency"
    - "Locked Dependency Trap"
  signature:
    - "dependency↑"
    - "exit cost↑"
    - "substitution viability↓"
    - "renegotiation power↓"
    - "provider leverage↑"
    - "consent validity↓"
    - "H↑"
  primary_layers:
    origin:
      - "U1 — Power / Budgets"
      - "U2 — Configuration / Boundaries"
      - "U3 — Execution / Runtime"
      - "U4 — Information / Truth"
      - "U5 — Coordination / Time"
      - "U6 — Coherence Field"
      - "U7 — Memory / Recurrence"
      - "U8 — Environment / Field"
    manifestation:
      - "U1 — Power"
      - "U2 — Boundaries"
      - "U3 — Execution"
      - "U4 — Truth"
      - "U5 — Time"
      - "U6 — Field"
      - "U8 — Environment"
  state_variables:
    - "BΣ"
    - "Λ"
    - "⊗"
    - "Φ"
    - "Γ"
    - "K"
    - "H"
    - "Au"
    - "R"
    - "Ψ"
    - "G"
    - "D"
    - "O"
    - "Τ"
  first_gate_failure: "Exit Gate"
  restoration:
    - "Dependency Map Audit"
    - "Exit Cost Reduction"
    - "Portability Restoration"
    - "Substitution Path Rebuilding"
    - "Contract Unbundling"
    - "Dependency Load Reduction"
    - "Consent Revalidation"
    - "Lock-In Debt Accounting"
    - "Restoration Path Reopening"
    - "Local Coherence Restoration"