schema_version: "1.0"

id: "FM-ECO-013"

title: "FM-ECO-013 — Conditional Coercive Delivery"

slug: "fm-eco-013-conditional-coercive-delivery"

type: "failure_mode"

status: "draft"

version: "0.1.0"

last_updated: "2026-06-19"

summary: "Conditional Coercive Delivery occurs when needed resource, support, access, care, payment, repair, authority, protection, information, or relief is made available only under conditions that force dependency, compliance, surrender of rights, identity capture, unwanted coupling, silence, extraction, degraded agency, or acceptance of incoherent terms."

canonical_url: "/archive/failure-modes/registry/economy/fm-eco-013-conditional-coercive-delivery"

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

canon:

tier: "registry"

state: "draft"

source: "UTS — Failure Modes Registry"

source_id: "FM-ECO-013"

legacy_ids:

• "FM-ECOX-005"

classification:

family: "failure-modes"

module: "economy"

module_group: "economy"

density: "advanced-reference"

audience:

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

tags:

• "failure-modes"
• "economy"
• "conditional-coercive-delivery"
• "fm-eco-013-conditional-coercive-delivery"
• "fm-ecox-005-conditional-coercive-delivery"
• "coercion"
• "conditionality"
• "delivery"
• "consent"
• "dependency"
• "forced-coupling"
• "hidden-debt"
• "coherence"

aliases:

• "Conditional Coercive Delivery"
• "Coercive Conditional Delivery"
• "Conditional Support Trap"
• "Coerced Access"
• "Conditional Relief"
• "Conditional Aid Capture"
• "Support with Coercive Terms"
• "Access Through Compliance"
• "Dependency-Conditioned Delivery"
• "Relief-for-Control Exchange"

related:

laws:

• "Forced Coupling"
• "Consent Drift"
• "Exit Denial"
• "Coercive Contract"
• "Dependency Lock-In"
• "Forced Profit"
• "Parasitic Extraction"
• "Under-Delivery"
• "Mis-Targeting"
• "U4 Truth Substitution"
• "Victim Burden Inversion"
• "Capacity-Inverting Restoration"

invariants:

• "Support Must Preserve Agency"
• "Delivery Must Not Require Coercive Surrender"
• "Consent Requires Viable Refusal"
• "Relief Must Not Become Capture"
• "Access Conditions Must Be Auditable"
• "Need Must Not Be Weaponized"
• "Repair Must Not Create Dependency Debt"

operators:

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

gates:

• "Consent Gate"
• "Delivery Gate"
• "Conditionality Gate"
• "Coercion Gate"
• "Dependency Gate"
• "Exit Gate"
• "Contract Gate"
• "Restoration Gate"
• "Auditability Gate"

diagnostics:

• "Consent Validity"
• "Condition Legitimacy"
• "Coercion Load"
• "Exit Cost"
• "Dependency Burden"
• "Agency Preservation"
• "Delivery Fit"
• "Hidden Debt"
• "Auditability"
• "Local Coherence"

failure_modes:

• "FM-ECO-001 — Under-Delivery"
• "FM-ECO-003 — Mis-Targeting"
• "FM-ECO-008 — Forced Profit"
• "FM-ECO-012 — Late Delivery"
• "FM-ECO-025 — Coercive Contract"
• "FM-ECO-026 — Dependency Lock-In"
• "FM-CORE-008 — Forced Coupling"
• "FM-ISC-009 — Consent Drift"
• "FM-ISC-011 — Invisible Intrusion"
• "FM-ISC-015 — Force Masked as Care"
• "FM-C-021 — Parasitic Extraction"
• "FM-JC-007 — Manufactured Consent"
• "FM-JC-011 — Locked-In Renegotiation Failure"
• "FM-RX-005 — Victim Burden Inversion"

restoration_arcs:

• "Consent Validity Audit"
• "Condition Legitimacy Review"
• "Coercive Term Removal"
• "Agency Restoration"
• "Exit Cost Reduction"
• "Dependency Debt Repair"
• "Unconditional Baseline Support"
• "Contract Rebalancing"
• "Delivery Path Restoration"
• "Local Coherence Restoration"

modules:

• "Economy"
• "Justice"
• "Contracts"
• "Restoration"
• "Cybernetics"
• "Security"
• "AI Governance"
• "Interfaces"
• "Coherence"

navigation:

order: 1313

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-013-conditional-coercive-delivery.md"

legacy_source_file: "content/archive/failure-modes/registry/economy/fm-ecox-005-conditional-coercive-delivery.md"

notes: "Unified from former FM-ECOX-005 into continuous Economy namespace. Standalone economy entry focused on support, relief, access, payment, repair, protection, authority, or care being delivered only under coercive conditions that compromise consent, agency, exit, compatibility, or restoration."

entry:

failure_mode_id: "FM-ECO-013"

failure_family: "Economy"

production_treatment: "Standalone Entry"

legacy_ids:

• "FM-ECOX-005"

parent_modes:

• "FM-CORE-008 — Forced Coupling"
• "FM-ISC-009 — Consent Drift"
• "FM-ECO-008 — Forced Profit"
• "FM-ECO-025 — Coercive Contract"
• "FM-C-021 — Parasitic Extraction"

first_gate_failure: "Consent Gate"

primary_hidden_debt: "Hidden debt accumulates when needed delivery is accepted under coercive conditions, causing affected nodes to carry dependency, degraded agency, compliance burden, suppressed refusal, future lock-in, or repair obligations created by the conditional terms."

primary_inversion: "Support becomes capture; the system treats conditional delivery as help while using need as leverage to impose terms that would not be accepted under viable refusal."

primary_boundary_pattern: "The boundary between legitimate eligibility and coercive conditionality collapses; conditions attached to delivery exceed what is necessary for coherence and become mechanisms of control, extraction, or dependency."

primary_signature: "Need exists; delivery is available only through imposed conditions; refusal is costly or impossible; affected nodes accept support under degraded agency; dependency and hidden debt accumulate; delivery is counted as aid despite coercive structure."

FM-ECO-013 — Conditional Coercive Delivery

Status: Draft

Archive Type: Failure Mode

System: Universal Theory Stack

Parent: Failure Modes

Canon Tier: Registry

Registry: Failure Modes Registry

Entry ID: FM-ECO-013

Legacy ID: FM-ECOX-005

Family: Economy

Production Treatment: Standalone Entry

Parent Modes: FM-CORE-008 — Forced Coupling; FM-ISC-009 — Consent Drift; FM-ECO-008 — Forced Profit; FM-ECO-025 — Coercive Contract; FM-C-021 — Parasitic Extraction

0. Economic Scope Note

This entry is conceptual and systems-oriented.

It does not treat all conditions, eligibility rules, verification steps, sequencing requirements, safeguards, standards, contracts, reciprocal obligations, or delivery criteria as coercive.

Some conditions are legitimate.

Conditions can preserve coherence when they:

• verify real need
• prevent misuse
• match resource to phase
• protect safety
• preserve fairness
• maintain auditability
• align responsibility
• prevent over-delivery
• protect vulnerable nodes
• clarify scope
• establish mutual accountability
• preserve local coherence

The failure begins when conditions exploit need.

The issue is not conditional delivery.

The issue is delivery made conditional on surrendering agency, rights, boundaries, refusal, standing, or compatibility.

Conditional Coercive Delivery occurs when the condition attached to support becomes more than a coherence requirement. It becomes a control mechanism.

1. Definition

Conditional Coercive Delivery occurs when needed resource, support, access, care, payment, repair, authority, protection, information, or relief is made available only under conditions that force dependency, compliance, surrender of rights, identity capture, unwanted coupling, silence, extraction, degraded agency, or acceptance of incoherent terms.

The condition may require the affected node to:

• surrender future claims
• accept silence clauses
• accept surveillance
• accept unwanted affiliation
• accept a coercive contract
• accept degraded service
• accept exploitative pricing
• accept debt dependency
• waive repair rights
• waive audit rights
• waive appeal rights
• submit to identity capture
• join a system they would otherwise avoid
• accept extraction as the price of help
• accept public gratitude or optics use
• comply with irrelevant ideology
• give data, labor, attention, or access
• remain in a harmful relationship
• forfeit exit paths
• absorb blame
• accept terms under emergency pressure

The core failure is:

need exists
support offered with coercive terms
viable refusal↓
dependency↑
agency↓
H↑

Conditional Coercive Delivery is not help with standards.

It is help whose conditions convert need into leverage.

2. Core Pattern

The core pattern is:

1. An affected node needs support, relief, access, resource, payment, repair, protection, or capacity.
2. A delivery channel exists.
3. The delivery is made conditional.
4. Some conditions may appear procedural, protective, efficient, or fair.
5. The condition set exceeds legitimate delivery requirements.
6. The affected node cannot refuse without unacceptable loss.
7. The node accepts the support under degraded agency.
8. The delivering system records the event as aid, care, access, payment, relief, or repair.
9. The coercive condition creates dependency, lock-in, extraction, silence, compliance, or boundary loss.
10. Hidden debt accumulates behind the appearance of delivery.
11. Restoration requires separating valid conditions from coercive ones.

This failure often appears as:

support is available if you meet the conditions

while the hidden truth is:

the conditions convert need into control

or:

they agreed to the terms

while the overlooked condition is:

refusal was not viable

The restorative question is:

which conditions are necessary for coherence, and which conditions exploit dependency?

Conditional Coercive Delivery turns access into leverage.

3. Failure Signature

Typical signature:

need↑
conditionality↑
refusal viability↓
agency↓
dependency↑
delivery counted as support
H↑

Extended signature:

relief requires silence
access requires surveillance
payment requires waiver
repair requires loyalty
aid requires public optics
care requires compliance
support requires lock-in
protection requires surrender of standing
resource requires unwanted coupling

Common forms include:

emergency aid tied to unrelated behavioral compliance
repair payments requiring silence about the harm
platform access requiring invasive data surrender
housing support requiring dependency on degrading terms
contract payment requiring waiver of future claims
work access requiring acceptance of exploitative scheduling
health support requiring acceptance of unrelated surveillance
technical support requiring lock-in to a vendor ecosystem
relief funds requiring public gratitude or reputation laundering
AI access requiring surrender of data, cognition, labor, or authorship beyond necessity

The defining condition is not that rules exist.

The defining condition is that the rules use need to impose terms that would not remain coherent under free refusal.

4. Primary U-Layer Origin

Common origin layers:

• U1 — Power / Budgets: stronger nodes control needed resources and set terms.
• U2 — Configuration / Boundaries: eligibility, contract, access, or permission boundaries are designed to capture agency.
• U3 — Execution / Runtime: delivery operations enforce coercive conditions.
• U4 — Information / Truth: agreement, compliance, or eligibility substitutes for consent truth.
• U5 — Coordination / Time: urgency, crisis, or delay weakens refusal viability.
• U6 — Coherence Field: the appearance of aid masks coercive structure.
• U7 — Memory / Recurrence: conditionality becomes normalized as standard access logic.
• U8 — Environment / Field: scarcity, emergency, dependency, or lack of alternatives makes refusal costly.

Common manifestation layers:

• U1 — Power: delivery is controlled by a stronger node.
• U2 — Boundaries: conditions reshape the receiving node’s agency boundaries.
• U3 — Execution: coercive terms are operationalized.
• U4 — Truth: formal agreement hides coerced acceptance.
• U5 — Time: urgency compresses choice.
• U6 — Field: support optics conceal capture.
• U8 — Environment: constrained alternatives enforce acceptance.

Conditional Coercive Delivery is primarily a U1 / U2 / consent-boundary failure.

The system controls the gate to needed flow and uses that gate to extract concession.

5. Typical Development Sequence

A common development sequence is:

1. A need becomes active.
2. The affected node seeks support, access, payment, repair, protection, or relief.
3. The delivering node controls the needed pathway.
4. Conditions are attached.
5. Some conditions are legitimate, but others exceed coherence requirements.
6. The affected node faces constrained alternatives.
7. Delay, scarcity, urgency, dependency, or threat makes refusal impractical.
8. The node accepts the condition.
9. Delivery occurs.
10. The system records the delivery as support or legitimate exchange.
11. The condition produces future burden, silence, lock-in, extraction, or dependency.
12. The coercive nature is hidden behind formal acceptance.
13. The same structure repeats for future access.

The loop often looks like:

need → conditional access → coerced acceptance → dependency → stronger future conditionality

Another common loop is:

support requested → conditions imposed → agency reduced → future support need increases

Conditional Coercive Delivery becomes self-reinforcing when each instance of help deepens the dependency that makes future conditions harder to refuse.

6. Diagnostic Markers

Diagnostic markers include:

• Support is available, but only if unrelated concessions are accepted.
• The condition protects the provider more than the receiving node.
• The affected node formally agrees while expressing lack of real choice.
• Refusal creates disproportionate loss, danger, exclusion, or burden.
• Aid, payment, or repair requires silence, loyalty, waiver, surveillance, or optics use.
• Conditions expand after dependency forms.
• Delivery is framed as generosity while terms preserve control.
• The receiving node must give up future standing to receive present support.
• Access requires data, labor, attention, or affiliation beyond necessity.
• The condition set is more complex than the delivery need requires.
• Emergency timing is used to force acceptance.
• The provider treats acceptance as proof of consent.
• Local coherence decreases after “support” is delivered.
• Restoration improves when baseline support is separated from coercive terms.

Useful diagnostics:

• Consent Validity: Tests whether acceptance included viable refusal.
• Condition Legitimacy: Determines whether attached terms are necessary for coherent delivery.
• Coercion Load: Measures pressure created by scarcity, urgency, dependency, or threat.
• Exit Cost: Tests whether the affected node can refuse or leave without punitive burden.
• Dependency Burden: Measures future dependence created by the condition.
• Agency Preservation: Tests whether support preserves decision-rights and boundaries.
• Delivery Fit: Determines whether conditions improve or degrade fit.
• Hidden Debt: Tracks future costs created by acceptance under pressure.
• Auditability: Determines whether condition logic can be inspected.
• Local Coherence: Tests whether delivered support improves the receiving node’s actual state.

7. Related Gates

Relevant gates include:

• Consent Gate: Fails when acceptance is counted despite non-viable refusal.
• Delivery Gate: Fails when support is counted without evaluating condition burden.
• Conditionality Gate: Fails when conditions exceed coherence requirements.
• Coercion Gate: Fails when need is used as leverage.
• Dependency Gate: Fails when delivery creates future lock-in.
• Exit Gate: Fails when refusal or exit becomes punitive.
• Contract Gate: Fails when terms preserve power asymmetry under formal agreement.
• Restoration Gate: Fails when repair is made conditional on surrender.
• Auditability Gate: Fails when condition logic cannot be justified or traced.

The first common gate failure is usually the Consent Gate.

The system treats acceptance as consent before testing whether refusal was viable.

8. Related Operators

Relevant operators include:

• Φ — Flow / Resource Movement: Determines what support moves and under what terms.
• BΣ — Boundary Integrity: Protects or violates agency, refusal, and rights boundaries.
• Λ — Compatibility: Tests whether conditions fit the actual delivery need.
• Γ — Selection: Selects which conditions attach to delivery.
• K — Constraint / Load: Rises through coercive pressure and compliance burden.
• H — Hidden Debt: Accumulates through dependency, waiver, silence, and lock-in.
• R — Restoration Capacity: May be captured when repair is conditional.
• Au — Auditability: Reveals condition legitimacy.
• Ψ — Observation / Interface: Shapes how support and consent are represented.
• O — Coherence: May appear improved because delivery occurred.
• G — Gain: Amplifies provider incentive to extract concessions.
• D — Damping: Should limit condition expansion.
• Τ — Trajectory / Time: Urgency compresses refusal and changes coercion load.

Common operator pattern:

need rises
Φ support is gated
Γ attaches conditions
K pressure rises
BΣ agency boundary weakens
refusal viability falls
O is claimed through delivery
H accumulates through dependency
Au is needed to distinguish help from capture

The core operator inversion is:

accepted condition → valid consent

instead of:

accepted condition + viable refusal + condition legitimacy → valid consent

Conditional Coercive Delivery turns delivery into a consent-obscuring event.

9. Related Laws and Invariants

Related Laws

• Forced Coupling: delivery binds nodes into unwanted dependency.
• Consent Drift: conditions become less valid as dependency deepens.
• Exit Denial: refusal or exit is made too costly.
• Coercive Contract: formal terms hide constrained acceptance.
• Dependency Lock-In: support creates future non-exit.
• Forced Profit: providers may extract gain from need.
• Parasitic Extraction: one node draws value through dependency.
• Under-Delivery: coercive conditions reduce the effective support value.
• Mis-Targeting: support targets compliance rather than need.
• U4 Truth Substitution: formal acceptance replaces consent truth.
• Victim Burden Inversion: affected nodes carry burden to access repair.
• Capacity-Inverting Restoration: repair demands consume the receiving node’s capacity.

Related Invariants

• Support Must Preserve Agency: help should not erase refusal, standing, or self-direction.
• Delivery Must Not Require Coercive Surrender: access should not depend on unrelated concession.
• Consent Requires Viable Refusal: agreement is invalid when refusal is structurally blocked.
• Relief Must Not Become Capture: emergency need cannot justify dependency construction.
• Access Conditions Must Be Auditable: attached terms must be inspectable and justifiable.
• Need Must Not Be Weaponized: vulnerability must not become leverage.
• Repair Must Not Create Dependency Debt: restoration should reduce future capture, not deepen it.

10. Common False Positives

Not every condition attached to delivery is Conditional Coercive Delivery.

Common false positives include:

• Eligibility checks tied directly to real need.
• Safety conditions that prevent harm.
• Scope boundaries that clarify what is being delivered.
• Verification that prevents fraud without blocking legitimate access.
• Mutual obligations that remain proportional and refusal-valid.
• Phased access that preserves readiness and capacity.
• Requirements chosen by the affected node.
• Conditions that protect vulnerable third parties.
• Documentation needed for auditability.
• Temporary restrictions paired with appeal, exit, and review.
• Pricing or contract terms that are transparent, proportional, and optional.
• Emergency triage that prioritizes without exploiting dependency.
• Support that preserves agency even while bounded.

Clarifying rule:

This is not Conditional Coercive Delivery unless needed support, access, payment, repair, protection, or relief is made conditional on terms that degrade agency, suppress refusal, create dependency, force unwanted coupling, enable extraction, or require surrender beyond what coherence requires.

11. Common False Repairs

Common false repairs include:

• simplifying coercive terms without removing coercion
• adding consent checkboxes while refusal remains nonviable
• relabeling coercive conditions as standards
• offering alternative pathways that are too slow, costly, or degraded to use
• making coercive terms more transparent but still mandatory
• providing partial support while keeping full repair conditional
• creating appeal processes after the support window closes
• reducing the visible burden while preserving dependency
• allowing exit only after punitive cost
• offering symbolic agency while controlling the real pathway
• separating legal consent from actual consent validity
• treating acceptance as gratitude
• blaming affected nodes for accepting bad terms
• calling coercive delivery empowerment
• using delivery records to deny future repair claims

False repair often produces the loop:

coercive terms exposed → terms reworded → refusal still nonviable → capture continues

Another common loop is:

conditional support criticized → alternative path created → alternative path unusable → original coercion remains

The repair fails because it changes the appearance of consent without restoring refusal-valid delivery.

12. Restoration Direction

Restoration requires auditing conditions, separating legitimate eligibility from coercive leverage, restoring viable refusal, removing capture terms, repairing dependency debt, and providing support in ways that preserve agency and local coherence.

Primary restoration direction:

audit the conditions,
remove coercive terms,
restore viable refusal,
and repair dependency debt

A fuller restoration path includes:

1. Name the needed delivery. Identify the support, access, payment, repair, care, protection, authority, information, or relief.
2. List all conditions. Make explicit every term, requirement, waiver, dependency, silence clause, surveillance requirement, affiliation, or concession.
3. Classify condition purpose. Separate safety, fit, audit, scope, and reciprocity conditions from control, extraction, optics, or dependency conditions.
4. Test refusal viability. Determine whether the affected node could realistically decline.
5. Audit urgency and scarcity pressure. Identify whether time, crisis, dependency, or lack of alternatives made acceptance coerced.
6. Remove coercive terms. Eliminate conditions unrelated to coherent delivery.
7. Restore baseline access. Provide needed support without agency-compromising requirements where possible.
8. Repair dependency debt. Address burdens created by prior conditional acceptance.
9. Restore exit paths. Reduce punitive refusal and exit costs.
10. Reopen claims and standing. Reverse waivers or silence terms that suppressed repair.
11. Rebalance contracts. Make remaining terms proportional, transparent, and renegotiable.
12. Install condition auditability. Require justification for each attached condition.
13. Validate agency preservation. Confirm affected nodes retain meaningful choice.
14. Validate local coherence. Confirm delivery improves actual state without creating capture.
15. Prevent recurrence. Block future use of need as leverage.

A valid restoration path should reduce:

coercion load
dependency burden
exit cost
forced compliance
silence pressure
unwanted coupling
condition opacity
agency loss
H

Conditional Coercive Delivery is not repaired by making the terms easier to understand.

It is repaired by making support no longer depend on coerced surrender.

13. Cross-Module Links

• Economy: Core failure of delivery, access, dependency, reciprocity, and resource control.
• Justice: Repair, aid, remedy, or recognition can become coercive when tied to silence, waiver, or surrender of standing.
• Contracts: Coercive conditionality often appears as formal agreement under constrained refusal.
• Restoration: Repair must not require the harmed node to accept new burden.
• Cybernetics: Conditional channels can suppress feedback by making support contingent on compliance.
• Security: Access control can become coercive when safety requirements become control requirements.
• AI Governance: AI tools, support, appeals, memory correction, or platform access can be conditioned on data surrender, authorship capture, silence, or dependency.
• Interfaces: Interface paths can hide coercion through defaults, friction, bundled consent, or degraded alternatives.
• Coherence: Coherent delivery must preserve agency, compatibility, and viable refusal.

14. Relationship to Parent / Child Modes

Production treatment: Standalone Entry

This mode maps upward to:

• FM-CORE-008 — Forced Coupling
• FM-ISC-009 — Consent Drift
• FM-ECO-008 — Forced Profit
• FM-ECO-025 — Coercive Contract
• FM-C-021 — Parasitic Extraction

Sibling or related Economy modes include:

• FM-ECO-001 — Under-Delivery
• FM-ECO-003 — Mis-Targeting
• FM-ECO-008 — Forced Profit
• FM-ECO-012 — Late Delivery
• FM-ECO-021 — “No Alternative” Framing
• FM-ECO-025 — Coercive Contract
• FM-ECO-026 — Dependency Lock-In
• FM-ECO-027 — Extraction Masking Instability
• FM-ECO-028 — Repair Starvation

Related cross-family modes include:

• FM-CORE-008 — Forced Coupling
• FM-C-021 — Parasitic Extraction
• FM-ISC-009 — Consent Drift
• FM-ISC-011 — Invisible Intrusion
• FM-ISC-015 — Force Masked as Care
• FM-JC-007 — Manufactured Consent
• FM-JC-011 — Locked-In Renegotiation Failure
• FM-JC-012 — Parasitic Contracting
• FM-RX-005 — Victim Burden Inversion
• FM-RX-009 — Repair Through Suppressed Auditability
• FM-SEC-004 — Consent Theater / Invalid Authorization
• FM-SEC-007 — Silent Extraction / Parasitic Coupling

Aliases preserved from source material:

• Conditional Coercive Delivery
• Coercive Conditional Delivery
• Conditional Support Trap
• Coerced Access
• Conditional Relief
• Conditional Aid Capture
• Support with Coercive Terms
• Access Through Compliance
• Dependency-Conditioned Delivery
• Relief-for-Control Exchange

Legacy source preserved:

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

15. Minimal Entry Version

Definition: Conditional Coercive Delivery occurs when needed resource, support, access, care, payment, repair, authority, protection, information, or relief is made available only under conditions that force dependency, compliance, surrender of rights, identity capture, unwanted coupling, silence, extraction, degraded agency, or acceptance of incoherent terms.

Signature:

need↑
conditionality↑
refusal viability↓
agency↓
dependency↑
delivery counted as support
H↑

Restoration direction:

• name the needed delivery
• list all conditions
• classify condition purpose
• test refusal viability
• audit urgency and scarcity pressure
• remove coercive terms
• restore baseline access
• repair dependency debt
• restore exit paths
• reopen claims and standing
• rebalance contracts
• install condition auditability
• validate agency preservation
• validate local coherence
• prevent recurrence

16. Machine-Readable Summary

failure_mode:
  id: "FM-ECO-013"
  name: "Conditional Coercive Delivery"
  family: "Economy"
  production_treatment: "Standalone Entry"
  legacy_ids:
    - "FM-ECOX-005"
  parent_modes:
    - "FM-CORE-008 — Forced Coupling"
    - "FM-ISC-009 — Consent Drift"
    - "FM-ECO-008 — Forced Profit"
    - "FM-ECO-025 — Coercive Contract"
    - "FM-C-021 — Parasitic Extraction"
  primary_failure: "Needed support, access, payment, repair, protection, or relief is made conditional on terms that degrade agency, suppress refusal, create dependency, force unwanted coupling, enable extraction, or require surrender beyond what coherence requires."
  source: "UTS — Failure Modes Registry"
  source_id: "FM-ECO-013"
  deprecated_source_ids:
    - "FM-ECOX-005"
  scope_note: "Conceptual and systems-oriented; does not treat all conditions, eligibility rules, verification steps, sequencing requirements, safeguards, standards, contracts, reciprocal obligations, or delivery criteria as coercive."
  aliases:
    - "Conditional Coercive Delivery"
    - "Coercive Conditional Delivery"
    - "Conditional Support Trap"
    - "Coerced Access"
    - "Conditional Relief"
    - "Conditional Aid Capture"
    - "Support with Coercive Terms"
    - "Access Through Compliance"
    - "Dependency-Conditioned Delivery"
    - "Relief-for-Control Exchange"
  signature:
    - "need↑"
    - "conditionality↑"
    - "refusal viability↓"
    - "agency↓"
    - "dependency↑"
    - "delivery counted as support"
    - "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"
    - "R"
    - "Au"
    - "Ψ"
    - "O"
    - "G"
    - "D"
    - "Τ"
  first_gate_failure: "Consent Gate"
  restoration:
    - "Consent Validity Audit"
    - "Condition Legitimacy Review"
    - "Coercive Term Removal"
    - "Agency Restoration"
    - "Exit Cost Reduction"
    - "Dependency Debt Repair"
    - "Unconditional Baseline Support"
    - "Contract Rebalancing"
    - "Delivery Path Restoration"
    - "Local Coherence Restoration"