1. Short Definition

Integration Cost Scaling means that as systems scale, the cost of integrating actions, signals, decisions, and consequences rises faster than the cost of executing local actions.

Execution can continue after integration has already degraded.

2. Canonical Pattern

U6 integration cost > U3 execution cost

Expanded:

Scale↑
⇒ local execution may remain viable
while whole-system integration cost↑
⇒ U3 continues while U6 degrades

Plain form:

Systems can keep acting after they stop integrating.

3. Mechanic Description

SCALE-022 identifies why scaled systems often appear functional while becoming incoherent.

Execution happens locally.

Integration happens across the whole field.

A system may still be able to:

• process tasks
• produce outputs
• enforce rules
• answer questions
• transact
• run procedures
• ship products
• issue decisions
• complete operations
• suppress symptoms

while losing the ability to integrate those actions into whole-system coherence.

Integration requires:

• context
• timing
• memory
• meaning
• cross-layer coordination
• feedback interpretation
• boundary reconciliation
• consequence tracking
• restoration planning
• recurrence validation
• whole-system sensemaking

As scale increases, integration becomes more expensive because more parts, more delays, more consequences, more hidden pathways, and more stakeholders must be reconciled.

Under scarcity or compression, systems often preserve execution because execution is visible and proximate.

They sacrifice integration because integration is costly, slower, and harder to measure.

This creates pseudo-scaling: the system does more while understanding less.

The UTS–Scaling reference names this plainly: integration is more expensive than execution, and systems often preserve execution while losing integration.

4. UTS Variable Mapping

5. Diagnostic Questions

1. Is the system still executing while integration declines?
2. Are local actions connected to whole-system coherence?
3. Are decisions integrated across time, memory, and consequence?
4. Is execution speed being prioritized over integration quality?
5. Are metrics tracking output but not integration?
6. Is recurrence increasing despite successful local action?
7. Is repair happening at the symptom level only?
8. Are boundary effects being reconciled?
9. Is enough slack reserved for integration work?
10. Does the system know how local success affects global coherence?

6. Failure Signatures

1. Execution-Integration Split

U3 throughput↑ while U6 coherence↓

The system performs locally while whole-system integration declines.

2. Output Without Reconciliation

actions↑ + consequence_tracking↓ ⇒ H↑

The system acts without integrating consequences.

3. Integration Starvation

K↓ + integration_cost↑ ⇒ U6↓

Slack loss prevents integration work.

4. Metric Bias Toward Execution

Φ_execution↑ while O↓

The system rewards visible output over coherence.

5. Recurrence After Action

task_completion↑ while τ_m↑

Tasks are completed, but failure patterns recur.

7. Related Failure Modes

• pseudo-scaling
• execution-integration split
• integration starvation
• hidden debt accumulation
• symptom-level repair
• recurrence lock
• performance-coherence divergence
• auditability collapse
• meaning collapse
• local-global divergence
• operational hollowing

8. Related Diagnostics

9. Restoration Implications

If SCALE-022 is active, restoration requires slowing or restructuring execution enough to restore integration.

Required actions:

1. Identify where execution is outpacing integration.
2. Reduce throughput if integration capacity is exceeded.
3. Reserve slack for integration work.
4. Reconnect local actions to whole-system coherence.
5. Improve consequence tracking.
6. Restore memory and recurrence analysis.
7. Rebalance metrics away from execution-only proxies.
8. Increase cross-layer coordination.
9. Repair hidden debt from unintegrated actions.
10. Validate whether recurrence decreases.

Core restoration rule:

Do not mistake completed action for integrated action.

10. Compact Registry Entry

id: SCALE-022
name: "Integration Cost Scaling"
family: "SCALE-D — Compression and Depth Collapse Mechanics"
type: "integration-scaling-mechanic"
status: "draft-ready"
short_definition: "As systems scale, integration becomes more costly than execution, allowing local action to continue while whole-system coherence declines."
canonical_pattern: "U6 integration cost > U3 execution cost"
failure_signature: "U3 throughput↑ while U6 coherence↓ ⇒ H↑ + recurrence↑ + pseudo-scaling"
primary_variables:
  - O
  - H
  - ε
  - ι
  - Au
  - µᵢ
  - BΣ
  - K
  - R
  - Φ
primary_diagnostics:
  - U3_throughput
  - U6_coherence
  - O
  - H
  - τ_m
  - K
  - σ(t)
  - Au_eff
  - µᵢ
  - R_eff
  - Φ_execution
related_failure_modes:
  - pseudo_scaling
  - execution_integration_split
  - integration_starvation
  - hidden_debt_accumulation
  - symptom_level_repair
  - recurrence_lock
  - performance_coherence_divergence
  - local_global_divergence
  - operational_hollowing
restoration_implication: "Slow or restructure execution, reserve slack for integration, reconnect local actions to whole-system coherence, and validate recurrence reduction."

11. One-Line Canon

Execution can scale after integration fails, creating the appearance of function without whole-system coherence.