1. Short Definition

Pressure Before Repair Hazard occurs when a system increases load, coupling, velocity, scope, or power before repairing existing incoherence.

This causes scaling to amplify unresolved debt rather than increase coherence.

2. Canonical Pattern

Scale↑ before H↓ + R↑ + Au↑ + BΣ↑ ⇒ H amplification

Expanded:

Existing H + Scale Pressure↑ + R insufficient ⇒ H propagation↑ + O↓ + ι↑

Plain form:

Scaling an unrepaired system spreads the unrepaired pattern.

3. Mechanic Description

SCALE-004 marks one of the most common scaling failures.

A system often tries to solve pressure by expanding capacity, speed, control, automation, authority, funding, reach, staffing, enforcement, or throughput. But if the system’s existing hidden debt is not repaired first, expansion gives that debt more pathways.

Scaling before repair can make the system look more capable in the short term while increasing long-term instability.

Examples:

• An institution expands a broken process instead of repairing the process.
• An AI system scales deployment before auditability and restoration are sufficient.
• A governance system adds enforcement before repairing legitimacy.
• A biological system increases performance demand before recovery capacity returns.
• An economy pursues expansion before circulation and resilience are restored.
• A security system adds surveillance before fixing boundary and trust failures.

The key issue is sequence.

Scaling is not automatically wrong. Scaling becomes hazardous when it happens before repair capacity, boundary integrity, auditability, and hidden debt reduction are sufficient.

The UTS–Scaling reference frames scaling as the ability to increase scope, load, complexity, coupling, and visibility pressure without losing coherence; SCALE-004 names the failure mode where that increase happens before the repair layer is ready.

4. UTS Variable Mapping

5. Diagnostic Questions

1. What unresolved hidden debt already exists?
2. Is the system expanding before repairing known failure patterns?
3. Has auditability improved, or is the system scaling opacity?
4. Are damaged boundaries being repaired before deeper coupling?
5. Is restoration capacity increasing before load increases?
6. Is scaling being used to avoid repair?
7. Are visible metrics improving while recurrence remains?
8. Is expansion creating more places for the same failure to propagate?
9. Is slack being protected for repair, or consumed by growth?
10. Has the system passed ring-down after the prior failure?

6. Failure Signatures

1. Debt Propagation

H unresolved + Scale↑ ⇒ H propagation↑

Unresolved incoherence spreads across the expanded system.

2. Expansion as Avoidance

Repair needed + Expansion chosen ⇒ H↑

The system grows instead of repairing.

3. Auditability Lag

Scale↑ while Au_eff↓ ⇒ H↑ + O↓

The system becomes larger and less inspectable.

4. Boundary Damage Amplification

BΣ damaged + Coupling↑ ⇒ leakage↑ + consent risk↑ + cascade risk↑

Boundary damage becomes more consequential under scale.

5. Restoration Deficit

Load↑ before R_eff↑ ⇒ restoration starvation

The system increases demand before repair capacity can support it.

7. Related Failure Modes

• hidden debt propagation
• pseudo-scaling
• restoration starvation
• auditability collapse
• overcoupling
• boundary brittleness
• recurrence lock
• legitimacy shock
• silent extraction
• compression depth collapse
• delayed transition cost

8. Related Diagnostics

9. Restoration Implications

If SCALE-004 is active, the restoration priority is sequence correction.

Required actions:

1. Pause or slow further scale pressure.
2. Identify existing hidden debt.
3. Restore auditability before expanding complexity.
4. Repair boundaries before increasing coupling.
5. Increase restoration capacity before increasing load.
6. Preserve slack for repair.
7. Reduce gain if unresolved debt is being amplified.
8. Validate ring-down and recurrence reduction.
9. Resume scaling only after support capacity is restored.

Core restoration rule:

Repair before expansion.

10. Compact Registry Entry

id: SCALE-004
name: "Pressure Before Repair Hazard"
family: "SCALE-A — Core Scaling Definition and Viability"
type: "scaling-hazard-rule"
status: "draft-ready"
short_definition: "Pressure Before Repair Hazard occurs when a system increases scale pressure before repairing existing hidden debt, boundary damage, audit loss, or restoration deficits."
canonical_pattern: "Scale↑ before H↓ + R↑ + Au↑ + BΣ↑ ⇒ H amplification"
failure_signature: "Existing H + Scale Pressure↑ + R insufficient ⇒ H propagation↑ + O↓ + ι↑"
primary_variables:
  - O
  - H
  - ε
  - ι
  - Au
  - µᵢ
  - BΣ
  - K
  - R
  - Φ
primary_diagnostics:
  - H
  - R_eff
  - Au_eff
  - BΣ
  - σ(t)
  - 𝓓(t)
  - τ_m
  - Cv(t)
  - Load
  - Gain
related_failure_modes:
  - hidden_debt_propagation
  - pseudo_scaling
  - restoration_starvation
  - auditability_collapse
  - overcoupling
  - boundary_brittleness
  - recurrence_lock
restoration_implication: "Pause scale pressure, repair hidden debt, restore auditability, repair boundaries, increase restoration capacity, then resume scaling."

11. One-Line Canon

Scaling before repair does not resolve hidden debt; it gives hidden debt more pathways.