schema_version: "1.0"

id: "FM-ECO-014"

title: "FM-ECO-014 — Economic Over-Constriction"

slug: "fm-eco-014-economic-over-constriction"

type: "failure_mode"

status: "draft"

version: "0.1.0"

last_updated: "2026-06-19"

summary: "Economic Over-Constriction occurs when rules, eligibility, budgets, approvals, austerity, risk controls, contracts, access limits, compliance layers, or resource restrictions become tighter than coherence requires, suppressing valid flow, repair, adaptation, local viability, and restoration capacity."

canonical_url: "/archive/failure-modes/registry/economy/fm-eco-014-economic-over-constriction"

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

canon:

tier: "registry"

state: "draft"

source: "UTS — Failure Modes Registry"

source_id: "FM-ECO-014"

legacy_ids:

• "FM-ECOX-008"

classification:

family: "failure-modes"

module: "economy"

module_group: "economy"

density: "advanced-reference"

audience:

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

tags:

• "failure-modes"
• "economy"
• "economic-over-constriction"
• "fm-eco-014-economic-over-constriction"
• "fm-ecox-008-economic-over-constriction"
• "over-constraint"
• "resource-restriction"
• "austerity"
• "access-limits"
• "flow-suppression"
• "repair-starvation"
• "hidden-debt"
• "coherence"

aliases:

• "Economic Over-Constriction"
• "Economic Over-Constraint"
• "Over-Constrained Economy"
• "Excessive Resource Restriction"
• "Austerity Lock"
• "Eligibility Overreach"
• "Access Over-Control"
• "Budgetary Over-Constriction"
• "Flow Suppression by Constraint"
• "Constraint-Induced Under-Delivery"

related:

laws:

• "Over-Constraint"
• "Rule-Stacking Wall"
• "Boundary Brittleness"
• "Stasis / Blockage"
• "Under-Delivery"
• "Restoration Starvation"
• "Hoarding as Pseudo-Security"
• "False Calm"
• "Requisite Variety Failure"
• "Capacity Collapse / Control Impossibility"
• "Delayed Transition Under Clarity"
• "Hidden Debt Accumulation"

invariants:

• "Constraint Must Preserve Flow"
• "Controls Must Not Starve Restoration"
• "Eligibility Must Match Need"
• "Restriction Must Remain Proportional"
• "Economic Boundaries Must Remain Permeable to Valid Need"
• "Slack Must Not Be Mistaken for Waste"
• "Safety Controls Must Preserve Local Viability"

operators:

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

gates:

• "Constraint Proportionality Gate"
• "Flow Gate"
• "Eligibility Gate"
• "Restoration Gate"
• "Slack Gate"
• "Capacity Gate"
• "Local Viability Gate"
• "Auditability Gate"
• "Boundary Gate"

diagnostics:

• "Constraint Proportionality"
• "Flow Suppression"
• "Eligibility Fit"
• "Access Friction"
• "Restoration Capacity"
• "Slack Loss"
• "Hidden Debt"
• "Local Viability"
• "Boundary Permeability"
• "Auditability"

failure_modes:

• "FM-ECO-001 — Under-Delivery"
• "FM-ECO-004 — Stasis / Blockage"
• "FM-ECO-007 — Phase Failure"
• "FM-ECO-009 — Hoarding as Pseudo-Security"
• "FM-ECO-012 — Late Delivery"
• "FM-ECO-015 — Clearance Failure"
• "FM-ECO-028 — Repair Starvation"
• "FM-CORE-007 — Rule-Stacking Wall"
• "FM-S-003 — Boundary Brittleness Trap"
• "FM-S-006 — Restoration Starvation"
• "FM-C-008 — Over-Damped Brittleness"
• "FM-C-010 — Requisite Variety Failure"
• "FM-C-011 — Zero-Slack Collapse"

restoration_arcs:

• "Constraint Proportionality Audit"
• "Flow Restoration"
• "Eligibility Recalibration"
• "Access Friction Reduction"
• "Slack Restoration"
• "Restoration Capacity Release"
• "Boundary Permeability Repair"
• "Local Viability Protection"
• "Rule-Stack Simplification"
• "Hidden Constraint Debt Accounting"

modules:

• "Economy"
• "Cybernetics"
• "Scaling"
• "Restoration"
• "Justice"
• "Security"
• "AI Governance"
• "Diagnostics"
• "Interfaces"
• "Coherence"

navigation:

order: 1314

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-014-economic-over-constriction.md"

legacy_source_file: "content/archive/failure-modes/registry/economy/fm-ecox-008-economic-over-constriction.md"

notes: "Unified from former FM-ECOX-008 into continuous Economy namespace. Domain expression / standalone economy entry focused on excessive economic constraints, eligibility friction, austerity, over-control, resource restriction, and rule-stack pressure suppressing valid flow, adaptation, repair, and local viability."

entry:

failure_mode_id: "FM-ECO-014"

failure_family: "Economy"

production_treatment: "Domain Expression / Standalone Entry"

legacy_ids:

• "FM-ECOX-008"

parent_modes:

• "FM-CORE-007 — Rule-Stacking Wall"
• "FM-S-003 — Boundary Brittleness Trap"
• "FM-ECO-004 — Stasis / Blockage"
• "FM-C-008 — Over-Damped Brittleness"
• "FM-C-011 — Zero-Slack Collapse"

first_gate_failure: "Constraint Proportionality Gate"

primary_hidden_debt: "Hidden debt accumulates when valid need, adaptation, maintenance, repair, circulation, or local response is blocked by excessive constraints, forcing affected nodes to absorb delay, scarcity, workaround burden, degradation, and unmet restoration cost."

primary_inversion: "Control becomes fragility; the system treats tighter restriction as safety, discipline, efficiency, fairness, or fiscal responsibility while the constraint suppresses the flow required for coherence."

primary_boundary_pattern: "Economic boundaries harden beyond their protective function; rules meant to prevent waste, misuse, instability, or risk become impermeable to valid need and repair."

primary_signature: "Constraints tighten; valid flow decreases; access friction rises; slack disappears; affected nodes under-deliver or degrade; repair is delayed or blocked; local coherence falls while the system claims discipline or safety."

FM-ECO-014 — Economic Over-Constriction

Status: Draft

Archive Type: Failure Mode

System: Universal Theory Stack

Parent: Failure Modes

Canon Tier: Registry

Registry: Failure Modes Registry

Entry ID: FM-ECO-014

Legacy ID: FM-ECOX-008

Family: Economy

Production Treatment: Domain Expression / Standalone Entry

Parent Modes: FM-CORE-007 — Rule-Stacking Wall; FM-S-003 — Boundary Brittleness Trap; FM-ECO-004 — Stasis / Blockage; FM-C-008 — Over-Damped Brittleness; FM-C-011 — Zero-Slack Collapse

0. Economic Scope Note

This entry is conceptual and systems-oriented.

It does not treat constraints, budgets, rules, eligibility, risk controls, approvals, audits, contracts, compliance, review, austerity, safety checks, or access limits as inherently failed.

Economic systems require constraints.

Constraints can preserve coherence when they:

• prevent waste
• prevent fraud
• limit runaway extraction
• protect shared resources
• preserve fairness
• maintain safety
• prevent over-delivery
• match capacity
• preserve long-term viability
• keep commitments auditable
• prevent capture
• protect vulnerable nodes
• preserve legitimate boundaries

The failure begins when constraint exceeds coherence need.

The issue is not constraint.

The issue is constraint that suppresses valid flow, repair, and adaptation.

Economic Over-Constriction occurs when economic control becomes tighter than the system can live through.

1. Definition

Economic Over-Constriction occurs when rules, eligibility, budgets, approvals, austerity, risk controls, contracts, access limits, compliance layers, or resource restrictions become tighter than coherence requires, suppressing valid flow, repair, adaptation, local viability, and restoration capacity.

The over-constriction may appear as:

• excessive eligibility filters
• frozen budgets
• austerity rules
• over-tight approvals
• unusable access pathways
• excessive documentation burden
• punitive compliance layers
• procurement paralysis
• risk controls that block valid action
• contract restrictions that prevent repair
• maintenance deferral rules
• spending caps detached from need
• permission structures too slow for reality
• over-centralized authority
• rule stacks that prevent adaptation
• anti-fraud systems that block legitimate support
• safety policies that suppress safe repair
• rigid funding categories
• artificial scarcity under discipline language
• excessive gatekeeping of tools, data, or authority

The core failure is:

constraint↑
valid flow↓
adaptation↓
repair↓
local viability↓
H↑

Economic Over-Constriction is not responsible restraint.

It is restraint that prevents the system from meeting valid need.

2. Core Pattern

The core pattern is:

1. A system perceives risk, waste, instability, scarcity, fraud, misuse, debt, budget pressure, or loss of control.
2. It adds constraints to preserve order.
3. Constraints initially reduce some risk or leakage.
4. Constraint logic hardens.
5. Rules, approvals, eligibility, or budgets become tighter than the real situation requires.
6. Valid needs cannot pass through the constraint structure.
7. Affected nodes experience under-delivery, delay, workaround burden, scarcity, or repair starvation.
8. The system interprets reduced flow as discipline, safety, compliance, or efficiency.
9. Hidden debt accumulates through blocked adaptation and deferred repair.
10. Restoration requires recalibrating constraint to actual coherence requirements.

This failure often appears as:

we are being responsible

while the hidden truth is:

the controls are blocking what responsibility requires

or:

we cannot loosen standards

while the overlooked condition is:

the standards have become detached from valid need

The restorative question is:

which constraints protect coherence, and which constraints now prevent it?

Economic Over-Constriction turns restraint into a failure source.

3. Failure Signature

Typical signature:

K↑
Φ↓
access friction↑
slack↓
R↓
local viability↓
H↑

Extended signature:

budgets are protected while maintenance fails
eligibility is strict while valid need grows
approval chains lengthen while delivery windows close
compliance succeeds while repair is blocked
anti-risk rules create new systemic risk
austerity preserves ledgers while infrastructure decays
permissions are controlled while local response fails
documentation burden consumes support capacity

Common forms include:

aid blocked by eligibility rules stricter than real need
maintenance deferred because budget categories are locked
workers unable to solve local issues due to permission constraints
emergency response delayed by normal procurement rules
security access blocked until legitimate work becomes impossible
AI safety controls preventing correction, appeal, or restoration
contracts preventing adaptation when conditions change
compliance programs measuring rule-following while local viability declines
over-tight lending or credit rules blocking viable recovery
austerity policies reducing capacity below sustainable thresholds

The defining condition is not that controls exist.

The defining condition is that controls block the valid flow required to preserve coherence.

4. Primary U-Layer Origin

Common origin layers:

• U1 — Power / Budgets: budget protection, control, authority, austerity, or risk aversion drives restriction.
• U2 — Configuration / Boundaries: rules, eligibility, funding categories, contracts, and permission boundaries harden.
• U3 — Execution / Runtime: operations cannot move resources through over-tight pathways.
• U4 — Information / Truth: compliance, savings, or control metrics substitute for viability truth.
• U5 — Coordination / Time: approval latency causes missed windows.
• U6 — Coherence Field: discipline or safety language masks blocked flow.
• U7 — Memory / Recurrence: past misuse or crisis normalizes restriction.
• U8 — Environment / Field: scarcity, volatility, politics, or institutional fear intensifies control.

Common manifestation layers:

• U1 — Power: decision rights remain centralized.
• U2 — Boundaries: constraints become rigid barriers.
• U3 — Execution: delivery stalls.
• U4 — Truth: compliance is counted as success.
• U5 — Time: delays compound.
• U6 — Field: restraint aura hides degradation.
• U7 — Memory: over-control becomes default.

Economic Over-Constriction is primarily a U2 boundary / K-constraint failure.

The system loses the difference between protective constraint and life-blocking restriction.

5. Typical Development Sequence

A common development sequence is:

1. A real concern appears: waste, risk, fraud, debt, misuse, instability, or overextension.
2. The system adds constraints.
3. Initial constraint may improve stability.
4. Additional rules are added after each exception, criticism, or failure.
5. Constraint stack grows.
6. Conditions change, but constraints do not recalibrate.
7. Valid needs begin failing through the same filters meant to block invalid use.
8. Affected nodes create workarounds or degrade.
9. The system interprets low spending, low leakage, or high compliance as success.
10. Repair capacity declines.
11. Hidden debt accumulates behind apparent discipline.
12. Eventually the system becomes brittle, late, under-delivering, or unable to restore.

The loop often looks like:

risk fear → constraint added → flow reduced → local degradation → more risk fear

Another common loop is:

misuse event → tighter eligibility → valid need blocked → crisis grows → emergency exceptions replace normal flow

Economic Over-Constriction becomes self-reinforcing when the damage caused by restriction is misread as evidence that more restriction is needed.

6. Diagnostic Markers

Diagnostic markers include:

• Valid needs fail eligibility checks.
• Resources exist but cannot be accessed.
• Budget savings coincide with maintenance debt.
• Compliance improves while local viability worsens.
• Approval chains outlast delivery windows.
• Risk controls create larger downstream risk.
• Affected nodes rely on informal workarounds.
• Support workers spend more time proving need than meeting need.
• Rules prevent adaptation to changed conditions.
• Slack is classified as waste.
• Repair is delayed by categories, caps, or permissions.
• Local nodes lack authority to solve obvious problems.
• Constraint exceptions become the only way work gets done.
• The system cannot explain which constraints are still necessary.
• Restoration improves when constraints are loosened or simplified.

Useful diagnostics:

• Constraint Proportionality: Tests whether restriction matches actual risk and need.
• Flow Suppression: Measures valid flow blocked by constraint.
• Eligibility Fit: Tests whether eligibility maps to real need.
• Access Friction: Measures effort required to obtain valid support.
• Restoration Capacity: Measures whether repair can move through the system.
• Slack Loss: Tracks disappearance of buffers needed for adaptation.
• Hidden Debt: Tracks deferred burden caused by over-control.
• Local Viability: Determines whether affected nodes remain functional.
• Boundary Permeability: Tests whether valid need can cross economic boundaries.
• Auditability: Determines whether constraint purpose and effect can be inspected.

7. Related Gates

Relevant gates include:

• Constraint Proportionality Gate: Fails when restrictions exceed coherence need.
• Flow Gate: Fails when valid resources cannot move.
• Eligibility Gate: Fails when rules exclude legitimate need.
• Restoration Gate: Fails when repair capacity is blocked.
• Slack Gate: Fails when all buffer is treated as waste.
• Capacity Gate: Fails when constraints reduce carrying capacity below need.
• Local Viability Gate: Fails when local nodes degrade under restriction.
• Auditability Gate: Fails when constraint purpose or effect cannot be justified.
• Boundary Gate: Fails when protective boundaries become impermeable barriers.

The first common gate failure is usually the Constraint Proportionality Gate.

The system tightens restriction before checking whether restriction still preserves coherence.

8. Related Operators

Relevant operators include:

• K — Constraint / Load: Primary operator; excessive constraint becomes load.
• BΣ — Boundary Integrity: Boundaries harden beyond protective function.
• Φ — Flow / Resource Movement: Valid economic flow is suppressed.
• R — Restoration Capacity: Repair cannot activate through over-control.
• D — Damping: Healthy damping becomes over-damping.
• H — Hidden Debt: Accumulates through blocked flow and deferred repair.
• Au — Auditability: Reveals whether constraints still serve coherence.
• Γ — Selection: Filters who receives resources, access, or permission.
• Λ — Compatibility: Tests whether constraints fit actual conditions.
• Ψ — Observation / Interface: Shapes how need and risk are seen.
• O — Coherence: May appear high through order and compliance.
• G — Gain: Can incentivize restriction through savings or control.
• Τ — Trajectory / Time: Delay from constraints changes outcomes.

Common operator pattern:

risk appears
K constraint increases
BΣ hardens
Γ filters valid need too aggressively
Φ decreases
D becomes over-damping
R is blocked
O is claimed through compliance
H accumulates through deferred burden

The core operator inversion is:

restriction → responsibility

instead of:

proportional restriction + valid flow + repair capacity → responsibility

Economic Over-Constriction turns control into under-delivery.

9. Related Laws and Invariants

Related Laws

• Over-Constraint: the parent mechanism where constraints exceed coherence requirements.
• Rule-Stacking Wall: accumulated rules block valid action.
• Boundary Brittleness: boundaries harden and fail under changing conditions.
• Stasis / Blockage: flows become immobilized.
• Under-Delivery: support exists but cannot reach need.
• Restoration Starvation: repair capacity is blocked or underfunded.
• Hoarding as Pseudo-Security: resources are withheld under safety logic.
• False Calm: reduced motion is mistaken for stability.
• Requisite Variety Failure: rigid controls cannot match environmental complexity.
• Capacity Collapse / Control Impossibility: over-control reduces actual capacity.
• Delayed Transition Under Clarity: known need is not acted on because constraints block movement.
• Hidden Debt Accumulation: deferred cost grows behind order.

Related Invariants

• Constraint Must Preserve Flow: restriction is coherent only if valid movement remains possible.
• Controls Must Not Starve Restoration: safety or discipline cannot block repair.
• Eligibility Must Match Need: filters must select real need, not merely administrative compliance.
• Restriction Must Remain Proportional: controls must scale with actual risk.
• Economic Boundaries Must Remain Permeable to Valid Need: boundaries must allow coherent passage.
• Slack Must Not Be Mistaken for Waste: buffers are part of viability.
• Safety Controls Must Preserve Local Viability: control that destroys viability is not safety.

10. Common False Positives

Not every tight constraint is Economic Over-Constriction.

Common false positives include:

• Rules that prevent real misuse without blocking valid need.
• Budgets that preserve long-term viability.
• Eligibility that accurately targets support.
• Risk controls that prevent harm while maintaining repair paths.
• Temporary constraints during overload with clear release criteria.
• Spending limits paired with maintenance protection.
• Approval processes that remain inside valid delivery windows.
• Contract boundaries that preserve fairness and accountability.
• Access restrictions that protect vulnerable systems.
• Compliance layers that reduce burden rather than add it.
• Scarcity management that preserves essential flow.
• Damping that prevents runaway delivery without freezing circulation.

Clarifying rule:

This is not Economic Over-Constriction unless constraints, rules, budgets, eligibility, approvals, or restrictions suppress valid flow, adaptation, repair, local viability, or restoration capacity beyond what coherence requires.

11. Common False Repairs

Common false repairs include:

• adding more rules to manage damage caused by old rules
• creating exception pathways too slow to use
• renaming austerity as resilience
• measuring compliance instead of viability
• loosening rules only for high-status nodes
• adding documentation requirements to prove over-documentation is harmful
• creating emergency overrides while leaving ordinary support blocked
• reducing budgets further because spending is low
• outsourcing burden to affected nodes
• claiming fraud prevention while refusing to measure blocked valid need
• preserving caps while repair debt grows
• simplifying language while keeping restrictions intact
• creating dashboards for stuck resources without releasing them
• requiring local innovation while denying local authority
• treating workarounds as proof that constraints are manageable

False repair often produces the loop:

over-constriction exposed → exception layer added → rule stack grows → over-constriction deepens

Another common loop is:

valid need blocked → crisis occurs → emergency bypass used → normal pathway remains broken

The repair fails because it preserves the restrictive structure while adding new complexity around it.

12. Restoration Direction

Restoration requires auditing constraint proportionality, identifying valid flow blocked by over-control, simplifying rule stacks, restoring access and slack, and ensuring constraints preserve rather than suppress coherence.

Primary restoration direction:

audit constraint proportionality,
restore valid flow,
release repair capacity,
and simplify over-tight boundaries

A fuller restoration path includes:

1. Name the constraint stack. Identify budgets, rules, eligibility, approvals, contracts, compliance layers, caps, or access limits.
2. Identify the original purpose. Determine what risk or misuse the constraint was meant to address.
3. Audit current conditions. Test whether the original risk still applies at the same level.
4. Measure blocked valid flow. Identify real needs, repairs, or adaptations being prevented.
5. Map affected nodes. Identify who absorbs the burden of restriction.
6. Measure hidden constraint debt. Track delays, degradation, workarounds, maintenance debt, and lost viability.
7. Distinguish protective constraint from over-control. Preserve necessary limits and remove incoherent ones.
8. Recalibrate eligibility. Align filters with actual need.
9. Reduce access friction. Remove unnecessary proof, delay, routing, or permission burden.
10. Restore slack. Reclassify valid buffer as resilience, not waste.
11. Release restoration capacity. Ensure repair can move.
12. Simplify rule stacks. Remove redundant, obsolete, or contradictory rules.
13. Install proportionality review. Recheck constraints as conditions change.
14. Validate local viability. Confirm affected nodes regain function.
15. Maintain auditability. Track both misuse prevention and valid-need access.

A valid restoration path should reduce:

access friction
blocked flow
rule-stack burden
repair starvation
eligibility mismatch
slack loss
delay
local degradation
H

Economic Over-Constriction is not repaired by removing all constraints.

It is repaired by restoring constraints to their proper role: preserving coherence while allowing valid flow.

13. Cross-Module Links

• Economy: Core failure of budgets, access, eligibility, austerity, resource restriction, and flow suppression.
• Cybernetics: Over-constriction functions as over-damping; it reduces oscillation while also suppressing adaptation.
• Scaling: Large systems often stack rules until valid flow cannot cross boundaries.
• Restoration: Repair cannot occur when resource, authority, or access pathways are over-constrained.
• Justice: Eligibility, enforcement, and remedy systems can over-constrain access to repair.
• Security: Safety and access controls can become security theater when they block legitimate restoration.
• AI Governance: Guardrails, policy layers, eval gates, or access systems can block correction, appeal, or meaningful interaction when over-tightened.
• Diagnostics: Requires proportionality, flow, eligibility, access friction, slack, and local viability diagnostics.
• Interfaces: Interfaces can create hidden over-constriction through forms, defaults, unavailable paths, or excessive proof requirements.
• Coherence: Coherence requires constraint and flow together.

14. Relationship to Parent / Child Modes

Production treatment: Domain Expression / Standalone Entry

This mode maps upward to:

• FM-CORE-007 — Rule-Stacking Wall
• FM-S-003 — Boundary Brittleness Trap
• FM-ECO-004 — Stasis / Blockage
• FM-C-008 — Over-Damped Brittleness
• FM-C-011 — Zero-Slack Collapse

Sibling or related Economy modes include:

• FM-ECO-001 — Under-Delivery
• FM-ECO-004 — Stasis / Blockage
• FM-ECO-007 — Phase Failure
• FM-ECO-009 — Hoarding as Pseudo-Security
• FM-ECO-012 — Late Delivery
• FM-ECO-015 — Clearance Failure
• FM-ECO-016 — Urgency Substitution
• FM-ECO-021 — “No Alternative” Framing
• FM-ECO-028 — Repair Starvation

Related cross-family modes include:

• FM-CORE-007 — Rule-Stacking Wall
• FM-S-003 — Boundary Brittleness Trap
• FM-S-006 — Restoration Starvation
• FM-C-008 — Over-Damped Brittleness
• FM-C-010 — Requisite Variety Failure
• FM-C-011 — Zero-Slack Collapse
• FM-C-013 — Capacity Collapse / Control Impossibility
• FM-R-006 — Repair as Compliance
• FM-R-007 — Repair Suppression via Efficiency
• FM-JC-001 — Procedural Theater
• FM-JC-004 — Under-Resourced Justice
• FM-SEC-003 — Rule-Stacking Wall
• FM-AIX-006 — Template Capture

Aliases preserved from source material:

• Economic Over-Constriction
• Economic Over-Constraint
• Over-Constrained Economy
• Excessive Resource Restriction
• Austerity Lock
• Eligibility Overreach
• Access Over-Control
• Budgetary Over-Constriction
• Flow Suppression by Constraint
• Constraint-Induced Under-Delivery

Legacy source preserved:

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

15. Minimal Entry Version

Definition: Economic Over-Constriction occurs when rules, eligibility, budgets, approvals, austerity, risk controls, contracts, access limits, compliance layers, or resource restrictions become tighter than coherence requires, suppressing valid flow, repair, adaptation, local viability, and restoration capacity.

Signature:

K↑
Φ↓
access friction↑
slack↓
R↓
local viability↓
H↑

Restoration direction:

• name the constraint stack
• identify the original purpose
• audit current conditions
• measure blocked valid flow
• map affected nodes
• measure hidden constraint debt
• distinguish protective constraint from over-control
• recalibrate eligibility
• reduce access friction
• restore slack
• release restoration capacity
• simplify rule stacks
• install proportionality review
• validate local viability
• maintain auditability

16. Machine-Readable Summary

failure_mode:
  id: "FM-ECO-014"
  name: "Economic Over-Constriction"
  family: "Economy"
  production_treatment: "Domain Expression / Standalone Entry"
  legacy_ids:
    - "FM-ECOX-008"
  parent_modes:
    - "FM-CORE-007 — Rule-Stacking Wall"
    - "FM-S-003 — Boundary Brittleness Trap"
    - "FM-ECO-004 — Stasis / Blockage"
    - "FM-C-008 — Over-Damped Brittleness"
    - "FM-C-011 — Zero-Slack Collapse"
  primary_failure: "Constraints, rules, budgets, eligibility, approvals, or restrictions suppress valid flow, adaptation, repair, local viability, or restoration capacity beyond what coherence requires."
  source: "UTS — Failure Modes Registry"
  source_id: "FM-ECO-014"
  deprecated_source_ids:
    - "FM-ECOX-008"
  scope_note: "Conceptual and systems-oriented; does not treat constraints, budgets, rules, eligibility, risk controls, approvals, audits, contracts, compliance, review, austerity, safety checks, or access limits as inherently failed."
  aliases:
    - "Economic Over-Constriction"
    - "Economic Over-Constraint"
    - "Over-Constrained Economy"
    - "Excessive Resource Restriction"
    - "Austerity Lock"
    - "Eligibility Overreach"
    - "Access Over-Control"
    - "Budgetary Over-Constriction"
    - "Flow Suppression by Constraint"
    - "Constraint-Induced Under-Delivery"
  signature:
    - "K↑"
    - "Φ↓"
    - "access friction↑"
    - "slack↓"
    - "R↓"
    - "local viability↓"
    - "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"
      - "U7 — Memory"
  state_variables:
    - "K"
    - "BΣ"
    - "Φ"
    - "R"
    - "D"
    - "H"
    - "Au"
    - "Γ"
    - "Λ"
    - "Ψ"
    - "O"
    - "G"
    - "Τ"
  first_gate_failure: "Constraint Proportionality Gate"
  restoration:
    - "Constraint Proportionality Audit"
    - "Flow Restoration"
    - "Eligibility Recalibration"
    - "Access Friction Reduction"
    - "Slack Restoration"
    - "Restoration Capacity Release"
    - "Boundary Permeability Repair"
    - "Local Viability Protection"
    - "Rule-Stack Simplification"
    - "Hidden Constraint Debt Accounting"